Smart Browser, Dumb Browser: Lessons Learned in a Health Care-related Project. ================================================ George Almasi, Dr. V. "Juggy" Jagannathan Concurrent Engineering Research Center West Virginia University 886 Chestnut Ridge Road Morgantown WV 26506-6506 juggy,almasi@cerc.wvu.edu 1. ARTEMIS Project - short description 2. Problems With The Old Approach 3. Browser Wishlist 4. Conclusion The ARTEMIS Project ------------------- ARTEMIS is the acronym for "Advanced Research Testbed for Medical InformaticS". The goal of the ARTEMIS project, sponsored by a grant from the National Library of Medicine, is to make patient care more efficient and affordable by use of modern computer technology. Check our home page at http://www.cerc.wvu.edu/nlm/nlm.html. The ARTEMIS technical and architectural approach includes the following high-level decisions: * Display of patient data on a web browser. Reasons: portability, low cost of GUI development, hopefully overall shorter software development cycle. * Backend (process and data support) based on CORBA. Reasons are the obvious ones - adaptability and interoperation of legacy systems through CORBA; long-term gain by standard compliance; etc. etc. There have been two distinct phases in software development in the ARTEMIS project. The first ("dumb browser") phase was characterized by a very reduced use of the web browser itself (only as a displaying and hyperlinking tool); intelligent processing was done at the server side. The result of this effort was the Web* software package developed at CERC: HTML templates containing "live" TCL and CORBA code get interpreted by a CGI script to generate HTML code interpretable by the browser. Communication between browser and services was restricted to the HTTP protocol; CORBA services could only be accessed from the server side. In the second ("smart browser") phase, started in the first quarter of 1996, we plan to use the features offered by the newer browsers to implement more intelligent GUIs. Netscape plugins, java applets and client side scripts allow better client-side processing; CORBA connection from the browser using Black Widow or similar Java/CORBA enabler makes sole reliance on the HTTP protocol obsolete. Problems With The Old Approach ------------------------------- *) need quicker reaction to user input (e.g. not wait till user submits a whole input form to point out an invalid date entry) *) need session control and resource management (i.e. automatic logout and freeing of resources and licenses when browser idle for long times or when user simply zaps browser) *) event notification, data recency issues and caching - e.g. lab test results that arrive to the server should be updated by the browser without explicit user action. *) consistency checks - in the first phase of ARTEMIS we were hampered by what we called the "back button anomaly" where the user hit the back button on the browser and interrupted a process that was supposed to span over several browser pages. *) standardized transaction control and session management needed. In ARTEMIS 1.0 database transactions can span multiple browser pages leaving the database in a vulnerable state if the user aborts in the middle of a transaction. *) better authentication of client and server. Client needs to authenticate server to make sure is getting info for the right patient. Server needs to authenticate client to insure access authority. Browser Wishlist ---------------- This is how we see potential new browser features helping us to avoid the problems mentioned above: *) Java will help bring the session state to the browser side. consistency checks are going to be easier to make. session control and resource management will be possible from the client side. *) Black Widow (and/or other similar applications) will enable us to write CORBA clients an services directly on the browser. Event notification caching issues will be solved this way, too. CORBA services can also be used for authentication purposes. *) Would really like to see COSS implemented for Java. Would help a lot in standardizing the way we implement patient care _processes_. *) An alternate [to Java] solution would be a netscape plug-in that is capable of calling/implementing CORBA services based on programs (scripts) downloaded from server. We briefly thought about implementing a client-side version of Web* as a plug-in. *) Would like to see a more efficient distributed programming environment. Java or CORBA do not support object migration and other features of distributed programming environment (like Obliq for instance) *) We would like to stress the need for low-level interoperability. Not every ORB claiming to be IIOP interoperable does actually work with other IIOP implementations. "Interoperable Object References aren't". *) complete and full data interchange between Java and client-side scripting languages is essential. Writing Java-based User Interfaces is a hard job, and would be made a lot easier if portions of the GUI could be written in HTML and with Javascript or something similar, but interact with Java applets instead of sending data over HTTP links. *) Would like to see a true security-enabled CORBA transaction implemented with Java. Essential for allowing patient information to travel over WANs. As a conclusion, we do recognize the extremely high speed with which browsers and the CORBA standard both evolve. Although we recognize the merits of the HTTP protocol in disseminating information, we think that for applications where client-server interaction needs to be more fine-grained (the ARTEMIS project is a good example of this) CORBA is the way to go. We would like to see implicit CORBA support on the browser side, and not only through Java; it should really be a browser feature. For now we will make do with Black Widow and with plug-ins. -- almasi@cerc.wvu.edu George Almasi Concurrent Engineering Research Center 1041/C Chestnut Ridge Rd 886 Chestnut Ridge Rd. Morgantown WV 26505 West Virginia University, Morgantown WV 26506-6506 (304) 599-0031