Enterprise-Level Health-Care Applications
The build or buy decision was easy, there was nothing to buy. We chose to build a transaction engine on steroids—eTransMan. eTransMan, eCommerce Transaction Manager, is the result (see Figure 1).
eTransMan is the heart of an easy-to-use architecture that provides an environment where developers easily build and manage N-tier applications for health care's pervasive computing environment. Developers write their business processes as modular components using any computer language—C, C++, Java, COBOL, Perl, Visual Basic and even assembler. eTransMan runs these components in a highly scalable, portable, high-performance, secure transaction environment.
Developing components for eTransMan is simple by design. Our company's developers write business components in C++ and Java. Other companies may not have developers with these skills. They may only have COBOL, Visual Basic or PowerBuilder developers. With eTransMan, companies avoid the time and expense of a weeklong class just to learn how to the transaction engine followed by another week of Java or C++ training.
The Transaction Manager is the architectural hub of eTransMan. The Transaction Manager provides fault tolerance, load balancing, scheduling, security and business component location (routing).
eTransMan's architecture is based upon the classic N-tier model with some enhancements. This model separates the presentation, business logic and data access layers. The main goals of this architecture were to:
create a transaction manager capable of very high transaction throughput on modest hardware;
create a component-based architecture that is robust, reliable and easy to manage and control in a production environment; and
enable component developers to design and add business components to the infrastructure as simply and as quickly as possible, with a minimum understanding of the architecture.
The Transaction Manager is written in C/C++ on Linux and compiled with the open-source gcc compiler. We can thus easily port to any system that supports gcc, from embedded platforms to an IBM 390 mainframe. eTransMan has exceeded performance expectation due to the efficient engineering provided on this platform. We are currently running eTransMan on two dual PIII 700 servers. The total production hardware cost was under $30,000 for 40 sites serving 450 on-line users (see Figure 2). Resources are only allocated when needed, enabling rapid responses on our modest hardware. Load average is never more than 2%. eTransMan is a compiled application, so it runs without an interpreter.
eTransMan includes many features that support high-application availability: processing of availability checks, timeout checks, automatic component restart and recovery procedures and user-definable recovery procedures. Business components run as dæmons for extremely fast response from the Apache web server. eTransMan not only controls the flow of activity in the application but also ensures smooth, efficient operations of all components (see Figure 3).
eTransMan balances the load between multiple identical components to ensure maximum application throughput. eTransMan tracks which components are available for a specific transaction. It dynamically creates additional component instances to handle increased transactional demands, destroying them when they are no longer needed. This feature allows eTransMan to allocate resources optimally to satisfy current demands. Using Linux's open architecture, eTransMan can dynamically map requests to components, exercising broad control over the flow of processing for the applications.
By multiplexing and managing the relationships between clients and applications, eTransMan provides all the capabilities needed for mission- and business-critical applications, including the capacity for large volumes of centralized or distributed data, high-message throughput, high data integrity and security and high-application availability, including 24/7 processing.
Resources are used as specified by configuration files but are only used as necessary, enabling rapid responses on modest hardware. We built a web interface to manage our configuration files. The eTransMan architecture follows the N-tier model. The workflow progresses as follows:
Intelligent data clients, such as Linux workstations, Windows 2000/98/95 workstations, Mac workstations, Wireless Devices, Interactive Voice Response Systems (IVR), virtually all commercial versions of UNIX, batch inputs, point-of-sale terminals, video data stream and other devices optimized for specific data and presentation functions gather information for subsequent processing and display information.
Client-specific interpreters prepare data for eTransMan. Interpreters package the incoming data stream in a format that the business components expect. The interpreters then forward the data client's request to eTransMan. Adding a new user client is as easy as creating a translator that can convert client-specific data formats to and from the simple eTransMan data exchange format. The business logic never changes.
eTransMan validates the transaction request and then forwards the request and data to the business component.
Components can access databases with several methods. To minimize cost and increase efficiency we developed our own pooled database component to access our Oracle 8i database running on Linux. We can connect to other databases via native libraries, ODBC, JDBC or via an HLLAPI component on a mainframe. Our business component returns the response and associated data back to eTransMan, which sends the response back to the interpreter. The interpreter formats the data according to its own rules.
One type of data interpreter supplied with the eTransMan architecture matches the response and associated data with a template. The interpreter merges the data with the template in the client's native format and returns the result. Templates can handle singleton or tabular data in the same response.