THIN, DISCONNECTED CLIENTS ON A HOSPITAL IT NETWORK

Transcription

1 THIN, DISCONNECTED CLIENTS ON A HOSPITAL IT NETWORK By Robert P. Bialek & Peter Brøndum Project No: SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE AT UNIVERSITY OF COPENHAGEN COPENHAGEN, DENMARK SEPTEMBER 2001 c Copyright by Robert Bialek & Peter Brødnum, 2001

2 Abstract An application that supports a work-flow in a hospital puts special requirements on the system: 1. The application must be reliable. We can not risk any loss of the data. 2. The application should preferably execute on a hand held computer. The hospital workforce is mobile. 3. The application should be available and function continuously even though the hand held computer is periodically disconnected from the network. There may be some areas without network coverage. 4. The application must be able to exchange the data with servers on the fixed network automatically and transparently for users. There may be no time to go and synchronize the data. Creating a system that fulfills all these requirements is the challenge in this thesis. The mentioned requirements are shared by many other types of environments other than the hospital environment. Consequently, we see a use for a general system that supports creation of reliable applications for periodically disconnected hand held computers. In this thesis, we have clarified the concepts of how to build a client-server support system that combines the support for disconnections and support for reliability in one hand held device. We have performed a bottom-up analysis of the issues that arise when building such a system. We have also designed and implemented a prototype of a general client-server support system. The client-server support systems guarantees delivery of requests and responses. The system is able to sustain crashes and recover its state. The system is also able to handle varying degrees of connectivity that stretch from connected, intermittently connected to disconnected computers. We have demonstrated the general client-server system by building a hospital work-flow application using it. The application is a browser and the work-flow tasks are expressed in forms generated by a server. The server cooperates with a hospital IT system created by Radiometer A/S. ii

3 Acknowledgements This work was done as a part of the project apparater.dk. We would like to thank our advisor professor Eric Jul from the Department of Computer Science at the University of Copenhagen for his good advices, general support and motivating attitude. We would also like to thank Radiometer Medical A/S for an interesting project and a general support. We would especially like to thank our contact person at Radiometer Medical A/S, Tommy Andreasen, for good support around Rime. Finally, we thank Symbol Technologies Inc. for test equipment and a good service. iii

4 iv UNIVERSITY OF COPENHAGEN Date: September 3, 2001 Authors: Title: Robert Pawel Bialek & Peter Brøndum Thin, Disconnected Clients on a Hospital IT Network Project No: Degree: Supervisor: Department: Master of Science Professor Eric Jul Computer Science Department (DIKU) Convocation: September 2001 Permission is herewith granted to University of Copenhagen to circulate and to have copied for non-commercial purposes, at its discretion, the above title upon the request of individuals or institutions. Signature of the author Signature of the author Signature of the supervisor

5 Contents 1 Introduction Problem formulation Goals Our approach System overview Demarcation Structure of the report Background for the thesis The hospital application Work process using a central repository Work flow using distribution Work flow modifications Implications of disconnections Existing IT system General requirements for hospital systems Technology restrictions Processing and battery limitations of hand held computers Limitations of hand held computers due to network connectivity Requirements to the system support Structure of the analysis 22 4 Client server models Basic concepts Simple request/reply scheme Analysis of client server layers Communication layer Application support layer Choosing client server model structure and interface Object oriented client server model v

6 CONTENTS vi Internet type model Choosing client server model structure and interface - conclusion Summary - Client server models Client server system for hand held computers Processing and memory reduction Device-specific adaptation Placement of adaption logic General technics for adaption Identifying client capabilities Transformation of server response Summary - Device-specific adaptation Network limitations Network adaptation problems General design Adaptation methods Summary - Network adaptation Summary - Client server system for hand held computers Client server model with disconnections Important issues concerning disconnections Analysis of overall approach Changing low level protocol Asynchronous client server system Client-agent-server system General issues when using local server data and logic Mobile object model Client-proxy-server Our approach Summary - Overall approach Analyzing the proxy Support for complex servers Support for simple object servers Requirements for downloaded objects Transformation between request/response and messages Encoding of request Cache coherency Management of cache Handling outdated requests Finding the agent Asynchronous interface to application One-way requests MOM primitives used Summary - Proxy

7 CONTENTS vii 6.4 Analyzing the agent Analysis of a simple agent Analysis of a complex agent Analyzing the server Support for mobile objects Advantages of the client-agent-server model Analysis of MOM communication layer Methods for exchanging messages between MOM-queues Handling network disconnection Analysis of browser application Awareness of disconnection Browser sessions Application level cache Control of parameters in system Summary - Client server model with disconnections Reliable client server systems Fault model for the client server system Level of reliability Containment strategy Strategy for guaranteed delivery of request/reponses Strategy for guaranteed delivery of request/reponses Summary - Fault model for the client-server system Handling errors in modules Saving state necessary for recovery Location of persistent state Summary - Handling errors in modules Handling errors between modules Transactional protocol Summary - Handling errors between modules Recovering from system faults Maintaining module functionality Restarting modules Summary - Recovering from errors Summary - Reliable client server systems Application supporting a work-flow process in a hospital Overall approach Analysis of a work-flow process Analysis of task execution in an IT system Work flow management systems Integration with Radiometers existing IT-system Conclusion on application

8 CONTENTS viii 9 Analysis Conclusion Choice of client-server model Implications when using hand held computers Implication when client is periodically disconnected Implications of reliability on a client-server system A hospital application using a disconnected system Design General overview of the design Communication layer design Flexibility of Communication layer Addressing messages Automation of message transportation Reliability of communication layer Summary - Communication layer design Application support layer design Connection to communication layer Separating application interface from the request reply manager Servicing requests during disconnection using cache Application agent Summary - Application support layer design Application layer design Interacting with user Managing underlying layers Controlling application logic Summary - Application layer design Implementation Choice of programming model/language Unimplemented functions System presentation Hand held side Communication layer on the fixed network side Application support on the fixed network side API Application on the fixed network side Source code from others System start up Starting fixed network system Starting palm application

9 CONTENTS ix 12 Test General test setup Hand held computer Wireless AP Stationary computer Network Software Performance Test General time distribution Request Time Time in local MOM Time of transport in MOM Time of parsing and displaying Servicing from cache Disconnections Transporting message to MOM Transporting message from MOM Disconnecting during transportation Reliability test Crash before synchronizing Crash after synchronizing Crash during the synchronization Related Work Object oriented systems Rover CORBA Data-servers Coda Bayou Oracle Mobile Agents and Oracle Lite Thin client systems WebExpress Gate-way solutions W Citrix/VNC/PCanywhere Conclusion Main problems Project goals The system Proxy Agent system Disconnected thin client application

10 CONTENTS x Portability Performance Future of the system A Appendix i A.1 XML i A.2 Rime interface ii A.3 URL addressing ii A.4 Design of the internet type model in Java iii A.5 Components in asynchronous systems iii A.6 MOMS v A.6.1 MOM systems in general v A.6.2 Types of MOM systems vi A.6.3 The Java Message Service (JMS) vii A.6.4 JMS in detail vii B Reliability methods ix B.1 Computer system faults in general ix B.2 General fault tolerance technics x B.2.1 Containment xi B.2.2 Masking xii B.2.3 Recovery xiii

11 List of Figures 1.1 Overview of the system The network environment for the off-line system Structure of the report Client-server applications cooperating Model of a simple client server system Client server models Adaptation methods General model Intercepting proxy-agent design A simple background server Message-oriented-middleware system Asynchronous client server system based on Message Oriented Middleware Client-agent-server design Local objects model with lazy synchronization with server objects Client-proxy-server model Our client-proxy-agent-server model Client-proxy-agent-server model with thin client applications Reliable client server model Process pair of watchdogs Serialized activities Merging activities Dependencies between activities Dependencies between activities Transporting activities in the system Design of the system on client and server side Design of the communication layer using MOM, with the JMS interface xi

12 LIST OF FIGURES xii 10.3 Design of the communication layer, that automatically transports messages between queues Application support layer Dividing application support Design of the server Design of application Logic (server side) Application on the client side Object and thread relationships Communication layer s objects and threads on the server side Server objects and threads The implemented system The round trip of a request Request times for different requests Request times with variable polling time Request times with variable synchronization time The relation between response message size and time of fetching the message The service time of the request on the fixed network side The relation between message size and the parsing time Request s service time from the cache A.1 Message Oriented Middleware v

13 Chapter 1 Introduction In this thesis, we will present a system that supports building reliable applications for periodically disconnected hand held computers. The system is a middleware system that can be used for building client server applications. The contribution of the system is that it combines support for disconnections and support for reliability in one general client-server support system made dedicated for small hand held computers. To our knowledge, this approach is new. The system has been built systematically bottom-up in order to take into account general limitations of hand held computers, support for disconnections and reliability issues. The system has been designed in a layered structure to ensure an open and flexible design. The system is able to handle varying degrees of connectivity that stretch from connected, intermittently connected to disconnected computers. The system is reliable, so even after a program crash the data are not lost and it offers delivery guarantee of requests and responses. Communication specific issues have been abstracted to a message-oriented-middleware layer. In addition to a general client-server support system, the contribution of this thesis is a hospital work-flow application that demonstrates the general system. The application is a thin client application expressed in XML-forms. The forms are generated by a server and executed in browser that can be disconnected. The application works with an existing hospital IT-system designed by Radiometer Medical A/S. We have used the requirements for the work flow application to deduct requirements for a general client-server support system. Because the application was designed for practical use in a hospital environment, there is a special epenthesis on reliability. We believe that support for reliable applications for hand held computers with periodic disconnections is generally useful and even needed in practical systems. 1

14 1.1 PROBLEM FORMULATION 2 We have implemented the most part of the system ourselves. The system has been implemented in Java and tested on the Palm platform. The thesis includes analysis, design and implementation of the system as well as a short analysis of the hospital application using the general system. We include the test results showing the main functionality of the system. The thesis will also contain treatment of the theory that is necessary to understand the system. 1.1 Problem formulation This thesis was done as a part of project apparater.dk. Radiometer Medical A/S is a participant in apparater.dk. Radiometer Medical A/S manufactures and sells measurement equipment to hospitals. The company saw a use for hand held computers to support work processes in a hospital in connection to their apparats. For example a work process could be: The hand held computers could be used by doctors to request a measurement. A nurse could use a hand held computer to fetch the requisition. When taking the blood sample for the measurement, the nurse could register important information like ID of the blood sample and patient temperature. The sample could then be transported to an apparatus (for example by pneumatic transport system) and measured. The measured data could then be send from the apparat to a central server and matched with the other data. Finally, the doctor could receive the measurement results on his hand held computer. The hand held computers in this system should be able to function disconnected. Many hand held computers are only equipped with a serial cable or Infra Red (IR) network connection so an continuous connection is very difficult. Hand held computers with wireless LAN might lose connection if the computer is carried outside of coverage. Additionally, temporary network or server application faults might result in disconnections. Support for disconnections can thus ensure availability of the system in the presence of faults. Radiometer s interest in this project was: 1. To get a documented prototype of a system that could support the above mentioned functionality. 2. To get inspiration on a theoretical level on how to make systems involving hand held computers and, in particular, how to support disconnections.

15 1.2 GOALS 3 We found the problem to be very interesting from a theoretical and practical point of view. What was needed, was a system that supported disconnected work and was designed specially for hand held computers. The hospital environment demanded special attention to reliability and to the varying capabilities of users. The application logic demanded that data created by a number of disconnected sources should be matched. The system could be build as a client server system. Our interest in the project (and DIKU s) has been to solve an interesting practical problem in a general way. To our knowledge it is a new approach to combine support for disconnections and support for reliability into one general client-server support system made dedicated for small hand held computers. Thus combining the interests of Radiometer and us, the problem in this thesis has been to analyze and design a reliable client-server system that supports disconnected work and executes on hand held computers with limited resources. The description of this analysis can be used as a source of inspiration on a theoretical level for Radiometer. In addition, using the general client sever support system, we will build a prototype for an application that support the hospital work process that Radiometer needs. The prototype will be integrated in Radiometer s existing hospital IT-system. We use this application to demonstrate the general system. The problem can be formulated in 4 subproblems: 1. How can we handle the general limitations of hand held computers in the client server support system? 2. How can we handle disconnections in the client server support system when hand held computers are involved? 3. How can we support reliability in the client server system when hand held computers are involved? 4. How we can design the work flow application that uses the system for disconnected work? 1.2 Goals In this section we present the goals of this thesis. We focus on both the theoretical and practical side of the project. Our goals with the project are: 1. To make an literature search of each of the four subproblems that were mentioned in problem formulation.

16 1.3 OUR APPROACH 4 2. To analyze the four problems and find the solutions for each of them, so they can be combined resulting in a system dedicated for hand held computers. 3. To design an open system that can be easily expanded, where system modules can be changed, and where using the system is not difficult. 4. To implement and document a prototype that demonstrates the system. This application is a proof-of-principle for the realism in our client server system. The application supports a work flow process in a hospital. The prototype should work with Radiometer s existing Hospital system. 5. To perform the test of the major parts of the system. The test should show the functionality of the system and its properties to sustain disconnections, crashes and limited capabilities of the devices. 1.3 Our approach We start by analyzing the general requirements for our client server system. We do this by looking at the hospital work-flow process, the general requirements for hospital applications and basic technology restrictions. We use these requirements to deduct realistic requirements for a system support layer. Then, we make a short analysis of the client server model. This analysis will introduce to the main concepts in the thesis. In order to find the solution for our problem and complete our goals, we search theories about the three first subproblems mentioned in problem formulation. For each subproblem we will start by creating simple models of our system. Performing analysis of the problems we will then successively improve and refine our model of the system. After every analysis, we will make a conclusion. The conclusion will be used to sharpen the later analyzes. After having completed the analysis of the general client server, we analyze an realistic application using it. We finally present the complete system design, our implementation of the system and a test of the implementation.

17 1.4 SYSTEM OVERVIEW System overview In this section we present an overview of our system. We believe this early introduction to the system will help the reader to understand the analysis in the thesis. Figure 1.1: Overview of the system. We have divided the system in three vertical layers: Communication layer, Application support layer and application layer. The system is also divided in two horizontal layers: The fixed network side and the hand held computer side. As shown on figure 1.1, the model describes two computers cooperating about a task: a hand held client and a server. The server is placed on a fixed network. The hand held computer connects to the fixed net through an access point (AP) that can be either a PC with serial cable, an Ir AP, or a wireless LAN AP. The hand held computer can be moved from AP to AP. The system has four layers that have different responsibilities: 1. Communication layer The communication layer consist of the protocol stack used to communicate between the two computers. The responsibility of this layer is to move bytes between the computers. The communication layer offers asynchronous communication primitives. This implies that using communication layer is not dependent on the network connectivity, since the control is returned immediately to the caller. In this way the communication layer abstracts all communication issues from layers using it.

18 1.4 SYSTEM OVERVIEW 6 The communication layer is built as a message oriented middleware (MOM) that guarantees message delivery. All communication is transported in messages. Messages are kept in a persistent queue until they can be transported to the target queue. When messages are received, they are kept in the queue, until they are fetched from it by the target process. 2. Application support layer The responsibility of the application support layer is to offer a client server interface to the application layer. Application support layer offers asynchronous invocations and supports disconnected work. We use an internet type interface (For example the http-protocol using GET,PUT, POST requests). The layer offers delivery guarantee for requests and responses. The application support layer uses the communication layer to transport data. The application support layer translates requests into messages and reconstructs replies from messages sent by server. During disconnections, the proxy services request from the cache and queues requests that can be not serviced. The proxy offers a simple write back functionality. Application logic takes care of writes i.e. it generates an update log. The proxy only updates a cache and sends the update log to the server. In an object model, the update logic can be included in the objects themselves. On the fixed network side, the application layer uses an agent that executes the requests against the server, which usually communicates using synchronous primitives. The agent translates server replies into messages. The agent s main responsibility in our model is to transform between an asynchronous model and a synchronous model. However, the agent can be extended to execute more complex tasks on behalf of the hand held computer. 3. Thin client support layer. This layer is actually a part of the application layer that we will describe later. However, because of its importance be will describe this sub-layer first. This layer consists of a browser and a form generator. The layer supports thin client applications, where the browser is responsible for displaying form-objects downloaded with the client server system. The browser is also responsible for issuing requests defined by links in the browser objects. In addition the browser is responsible for interacting with the user. The browser uses the application support layer. Downloaded objects like form-applications are cached and requests issued while the hand held computer is disconnected can be

19 1.4 SYSTEM OVERVIEW 7 queued. In a special page the browser can view pending requests and access responses when they return. The form generator is responsible for creating forms that can be displayed by the browser. The forms are generated specifically for the hand held computer platform that is used. 4. Application layer. The application layer is the layer including the final application logic. The application layer can use any of the three mentioned layers directly. Depending on the used layer, the programming paradigm changes: (a) Thin client support layer When using the thin client support layer, the client side of the application is expressed in forms. Most of the application logic is executed on the server. The thin client support layer is itself an application. This layer supports thin client programming paradigm 1. (b) Application support layer When using the application support layer directly by applications (Not shown in figure) both the client and the server access the application support layer, and perform asynchronous request-reply communication. This layer offers a general client server programming paradigm with an internet type interface and support for disconnections. (c) Communication layer When applications use the MOM communication layer directly (Not shown in figure), both the client and the server access the communication layer and communicate through messages. Using communication layer directly offers a very flexible programming model namely, the message passing paradigm. We built the specific prototype application for Radiometer using the Thin Client Support Layer. The application consists of a number of form-applications and a server that coordinates the work-flow and communicates with Radiometer s existing hospital IT-system. The model is simplified. We have only shown one server and one client. Notice that some of the functionalities that are placed in application support on the fixed network, might be abstracted to autonomous processes that run 1 Saying thin client programming paradigm, we mean the browser type programming

20 1.5 DEMARCATION 8 on other computers. In addition, we have not shown in detail how reliability is supported and we have generally not indicated any implementation details 2. In the analysis we will develop the system through successive improvement and refinement. The final system presented in the design section (see section 10) will be more complex than the system described here. However, the system described should give a useful general picture. 1.5 Demarcation In this section we present the boundaries of our project and describe relevant areas that we will not analyze. Figure 1.2: The network environment for the off-line system On figure 1.2 we present a model of the environment that our system should function in. The model is structured in a number of mobile nodes and a fixed network with a number of stationary nodes. The mobile nodes are hand held computers that access the fixed network through access points (AP). The AP can be wireless AP 3 or serial AP 4. They can access servers on both the local network and on the internet. We bind our project to an analysis 2 The modules could in principle be implemented as either libraries, threads or processes 3 Wireless LAN AP, infrared AP 4 Cradle with direct or indirect access to the fixed network