Java/M 3 tier system solution

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)

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:

1. It opens VISTA up to COTS application that need to extract data from our database without COTS needing to directly interface with the database itself.
2. We use a non-propriety industry standard for accessing our database.  In other words, access to a VISTA database is not tied to a vendor specific implementation.
3. Security is provided with utilities provided by the ORB server and also by design.  Software is now executed on the Server that is in a controlled environment.  This means that critical data and software designed remain on the server and not installed on an unsecured client machine.
4. Speed is also a consideration.  Most data processing remains on the server which eliminates the need for porting large amounts of data to the client machine for processing.  For example: A large search process would take place on the server end and only the result of the search is ported to the client machine.
5. Software distribution to client machines is kept to a minimum or eliminated.  With Java running in a web-page, software is loaded on the client machine automatically or as-needed.  Also, since the majority of software is executed on the ORB Server, software updates need only be loaded on the server and not the clients.

What needs to be done to implement this design?

1. Client System (MS Window NT, Win95, Win98, Internet Browser, Unix, etc.)

   - Basic Kernel tools for user sign-on
   - GUI Workbench (provides basic utilities for displaying GUI forms)

2. Server System (MS Windows NT, Win95, Win98)

   - Kernel RPC broker DLL that supports silent logon
   - Basic kernel tools for managing user sign-ons
   - ORB Server
   - Application Objects Wrappers

3. Legacy System (M-Database)

   - Kernel RPC support

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

Making M-Database into ORB objects

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

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.

Summary

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.

Disclaimer

About  the author