Java/M 3 tier system solution
gives an overview of the work being done to investigate the possibility of using Java and
a 3 tier solution for VISTA's CIRN application. The decision to investigate a
three-tier solution is driven by the need for sharing of patient information between
hospitals and non-VA systems.
The idea of sharing information between systems is not a new idea. Ever since serial communication computers have been sharing information (there could be earlier examples, but this is as far back as I go!). When you think of HL7, it is a standardized stream of characters that enable systems to share information. Basically an agreement between to HL7 systems that specify where to expect certain data in a stream of characters.
With the advent of the Object world and acceptance of Delphi within VISTA, a 3-tier solution allows us to take sharing of information to the next level of communication, specifically objects. This leads into Object Request Brokers (basically software that serves up Objects rather than a stream of characters). This of course lead to Common Object Request Broker Architecture (CORBA) which defines a standard way that ORBs talk. And of course this leads to spin-offs like a group called CORBAMed that defines standard ways that clinical Objects are used in the same way that HL7 standardized a stream of characters.
What does Objects provide over parsing a streams of characters? Think of an HL7 character stream that may be made up of 1000's of characters and you want the patient's last name. In this stream there are multiple names (Doctor's name, Patient Name, maybe next of kin, etc.). This basically forces you to learn a very lengthy standard to figure out just how to get the patient's name and where it is located. This is an over-simplified example, but it gets the point across (especially for those of you who had to carry the HL7 standard documentation around).
Now in the object world, this could be as simple as: MyCORBAMedObject.getPatientLastName(). That's it. Setting data is just as easy as MyCORBAMedObject.setPatientLastName("Smith"). Much easier to use.
When you also realize that objects support more than characters, like images or sound you begin to realize that a lot more potential and value exists in the object world.
The CIRN project is an initiative within the Department of Veteran's Affairs to integrate patient information within the VA. Historically, patient information was not easily or readily available between VA Medical Centers (VAMCs). The CIRN project allows a VAMC to have access to up-to-date clinical information for a patient. This information is a history of the patients care that may span many VAMCs. This is not a project that "combines" databases, but rather allows sharing of patient information between VA Medical Centers.
Current Data Transportation using an Object Request Broker (ORB)
|The technology being
utilized in this discussion is a three tier solution using a CORBA compliant ORB server as
the middle tier. Please view our Java Links section for more
information on CORBA and our Technical Diagram section for
information on how this three-tier solution works.
Basically, a middle tier separates the client system from the database. This means the client does not care whether the data is coming from a M-System database, SQL Database (MS Access, MS-SQL, etc.) or any other platform.
What this provides the Department of Veteran's Affairs is the following:
|What needs to be done to implement this design?||All the pieces
already exist to implement a three-tier solution all the way from the Client end
(Java/Delphi to the VISTA database using the current Kernel RPC). The work can be
accomplished by pulling all the "pieces" together. Here is a general list
of the parts of the system I designed:
For more technical "stuff", visit Technical Ingredients page that describes some of the Java
classes in more detail.
VISTA Demo utilizing a 3 tier solution
|The following demonstration displays a user session. This is a screen-capture of a "Live" demo using the system here at the Altoona VAMC.|
Making M-Database into ORB objects
|The majority of work in implementing this
architecture is transforming VISTA data into objects that can be used with the ORB
server. To create an ORB object is very similar to the current VISTA Delphi/M
architecture. One must first define the object, write the M-RPC calls to support the
object, and then place the data into the object. Eventually this mapping process
A solution to this problem that has been investigated is to write a Java program that will compile an ORB Object based on a VISTA FileMan file. This FileMan file would operate very much like a FileMan print template. But instead of compiling the template for output to a device, the file would compiled to produce the necessary data-extraction routines, Kernel RPC calls, ORB server routine, and ORB skeleton objects necessary to implement the the ORB object.
This may sound complicated, but it isn't and allows M-programmers not familiar with Java, Delphi, Objects, etc. to create objects required by COTS or VISTA GUI's.
M-Legacy System and Business logic
|A major consideration when designing a
client/server or 3-tier system is the location of the business logic. When an
M-System is not separated, this is not an issue as the User Interfaces (UI's) and business
logic is contained within the M-environment.
However, what happens when you develop a GUI (using Java, Delphi, etc.) that becomes the front-end to your M-system? You will notice that business logic tends to become duplicated causing a maintenance headache.
For example, let's say you are to design a patient registration form that has a prompt "Date of Birth" as one of the prompts. Simple enough...right? Well, not really. As any programmer would ask is "what is a valid date?" Should I allow 100 years, 110 years, 120 years in the past to be entered? (hmmm...). The first act is to "peek" at the legacy system to see how they do it...ahh..the limit is 110 years...my answer...so that gets coded into the GUI. Two weeks later, a change is made on the legacy system to make 120 years a valid date, but they don't notify the GUI programmer...now your GUI is inconsistent with your legacy system. Multiply this one prompt by a large system like VISTA and you have a major problem.
Your goal should be to make your GUI as unintelligent as possible...make it sing the song "If I only had a brain". Code your forms to collect information (not process) and have these forms sent to the legacy system to be accepted or rejected. If the form is rejected by legacy, a message describing the problem is given to the user. Obviously minor logic will still need to be contained in the GUI. For example, date prompts should only allow dates and number prompts should only allow numbers.
The additional two alternatives begin to go outside the scope of this discussion, but are worth mentioning if you goal is to eventually replace your M-System:
The second alternative is to place your business logic on the middle-tier (in this case Java). This becomes much more complex to implement when you consider all the legacy business logic that will have to be converted to your ORB server. This may be an appropriate solution if your overall goal is to eventually move your data to another platform. You will need to make sure your newly converted ORB objects don't access data "the old way" (using RPCs) since you will have to convert these when you drop in your new database. A black box should be considered that can be "switched" to the new database access logic.
A better alternative is to research Object Oriented Databases that have ORBs built into the database. This basically combines the 2nd and 3rd tier into one. You client systems will deal with an object environment and this eliminates the need to create objects on-the-fly from a legacy system as mentioned in the previous sections. You would basically design your objects and then move your legacy data into these objects during time of conversion.
|When considering to Implement a 3-tier
solution, you would assume that it means a major investment in another technology outside
the M-system. By keeping your business logic and data on the M-System and
implementing automated ORB wrappers and basic GUI forms, your major investment still
remains with your M-System and M-professionals.
Also, keep in mind that once you setup your ORB server, you can utilize any CORBA compliant front-end GUI (Delphi for example). It does not have to be a total Java solution. Java on the client end is good if you want your GUI to be compatible with many different platforms (not just Windows).
As with any system, technology should not drive the system requirements. You need to determine your business requirements, and then technology should be researched to determine the best approach. There are other alternatives such as Java->M-System (no ORB server) or you could use Java RMI (Remote Method Invocation). Java RMI is "free" unlike commercial ORB Servers, but it isn't as robust.
|The opinions expressed contained in this section is that of a programmer stuck in a corner with the window-shades pulled down for an extreme period of time and not that of the Department of Veteran's Affairs. Read at your own risk.|
About the author
|Bob Yacobucci has been involved with VISTA and M since 1984 and currently works at the Altoona VAMC for the Birmingham IRMFO.|
[Home Page] [VISTA Demonstration] [Java Links]
[Technical Diagrams] [Technical Ingredients]