Enterprise-Level Health-Care Applications
When the Transaction Manager receives a response from the component, it forwards the response to the communication layer that sent the request. The communication layer then translates the result into a format that is recognizable by the data client. The data is then sent back to the client in its native format.
We needed to make changing the user interface as easy as possible. The first test came when we wanted to adapt an existing PC-based browser interface to a wireless Palm Pilot and cell phone. We wanted to allow our field personnel to use a very simple tool—cell phones—to access the database. Our first challenge was to deliver driving directions to a patient's home on a browser-enabled cell phone or wireless Palm Pilot. By using our translator technology, we were able to take an existing web-based application (in this case a report with 150 columns of data) and adapt it using a new template to the wireless world. We ported to a WML interface in less than four hours, with no recoding of the business or database components (see Figure 4). We reproduced this feat using web clipping technology to the Palm VIIX. It took four hours because we were not familiar with WML or web clipping. The Yankee Group says there are up to 12 million potential users in the medical industry of wireless technology. The Web is our tool today, but we will soon witness an explosion of wireless interfaces. We would be shortsighted to have an architecture that would require any recoding of business components (see Figure 5).
Interfaces and translators, which are part of the Communication Layer, package data for the business components. Interfaces and translators also format data that is sent back to the original client source. As one technique to format the data, the interpreter can use a template; for example, an HTML template could represent a classic master detail report.
Interfaces and translators enable developers to focus on the business logic without the distractions of how the data is formatted or presented. These translators can use a common stream of data coming from the business component and move it to virtually any front end: Web, IVR, wireless or even print streams.
More importantly, this allows reuse of components if the data client changes. Having the presentation and communication logic separate from the business logic speeds software development and allows for faster application deployment and updates. It also enables developers, particularly web and graphics programmers, to focus on the presentation without having to worry about the business logic or database I/O.
eTransMan uses a component software model. Data clients and other requesters invoke managed business components and developers design business components or modify their components by focusing on the business processes. This development strategy enables developers to build components quickly with their existing knowledge and skills.
We needed the ability to alter the availability of individual business components without affecting any other components. We found that this feature was missing from many of the commercial and open-source transaction platforms that we surveyed.
Health care's computing environments require administrative vigilance. Performance and security monitoring, failure and alert management, and a host of other operational tasks are more difficult in a distributed environment. We also designed web-based administration capabilities to bring eCommerce applications on-line and off-line. The easiest way to address this was to use the interface and translation layer to manage it through the Web. We use eTransMan to manage eTransMan (see Figure 6).
eTransMan's Database Abstraction Layer provides a common interface for database interaction. This layer enables developers to interact with any database without modifying business component code.
The advantage of the Data Abstraction Layer is that a business component need not notice if the underlying data source changes, say from DB2 running on an IBM mainframe to Oracle running on Linux. Component programmers need not have their logic depend upon the specifics of a particular database. There are no SQL or HLLAPI manipulation routines in a component, for example. All of the data source access is through a specific component that translates generic requests into a format for a particular data source.
Unlike some transaction platforms that interact with a database using JDBC or ODBC, eTransMan can take advantage of the database's native libraries for database interaction. This engineering achieves fast database access with minimal overhead.
A metadata layer, stored and read by the component at instantiation, controls calling from the component to data access procedures for the database. This lets each software layer do what it does best: the database to read and write data, the application program to run business logic. This layered abstraction has already allowed us to move an application developed in one RDBMS to a different data layer.
- High-Availability Storage with HA-LVM
- DNSMasq, the Pint-Sized Super Dæmon!
- March 2015 Issue of Linux Journal: System Administration
- Localhost DNS Cache
- Real-Time Rogue Wireless Access Point Detection with the Raspberry Pi
- Days Between Dates: the Counting
- PostgreSQL, the NoSQL Database
- The Usability of GNOME
- Linux for Astronomers
- You're the Boss with UBOS