Tutorial on Basic Client/Server Middleware

Definition of Middleware: Middleware is a set of common business-unaware services that enable applications and end users to interact with each other across a network. In essence, middleware is the software that resides above the network and below the business-aware application software and denotes a reusable, expandable set of services and functions that benefit many applications in a networked environment.

According to this definition, the key ingredients of middleware are (see Figure 1):

• It provides common business-unaware services

• It enables applications and end users to interact with each other across a network

• It resides above the network and below the business-aware application software

Figure 1: Middleware Overview

Middleware is business-unaware (i.e., it does not have any business logic) and is available as a common set of routines (see Figure 2). The services provided by these routines are available to the applications through application programming interfaces (APIs) and to the human users through commands and/or graphical user interfaces (GUIs). The commonality implies that these routines are available to multiple applications and users. Ideally, middleware should be transparent to end-users but necessary -- the end-users should be unaware when it is there and aware only when it is not. According to our definition, the following software qualifies as middleware (if you do not know about these, do not worry; the rest of the book is filled with information about many of these software packages):

• Email (it is business unaware and interconnects users at different sites)

• Terminal emulators and file transfer packages (these business unaware services connect users to resources)

• Web browsers and Web servers (they are business unaware and support user access to resources on the Internet). As a matter of fact  the World Wide Web is a collection of middleware services.

• Database drivers and gateways such as ODBC drivers and Sybase Omni Server (they provide access to remotely located databases)

• Web Services (WS) and Object Management Group’s CORBA (Common Object Request Broker Architecture) because they provide connectivity services for distributed applications.

Here is a list of software that does not qualify as middleware, according to our definition:

• Operating systems such as Unix (it operates only on local resources)

• Airline reservation system (it is business aware)

• Network routers (they do not reside above the network -- they are part of network services) 

Figure 2: Middleware - A Look In Terms of the Open Layered Model

Transaction Processing Middleware for eCommerce

Business transactions are at the core of electronic commerce (EC). Examples of typical EC transactions are purchasing, claim processing, and billing/payment. For business to business activities in EC, the importance of supporting highly reliable and secure business transactions is quite obvious. Basic knowledge of transaction processing is essential for developing “serious” websites that handle billing, payment, credit card processing and other financial services.

Formally, a transaction is a collection of operations on a database which has the so-called ACID properties:

• Atomicity: All of the operations in the transaction must take place, or none must take place. In practice, if any of the elementary steps that are part of the transaction action fails, then all the steps must be undone;

• Consistency: The result of performing all the operations in the transaction is to take the database from one consistent state to another consistent state;

• Isolation: Other users of the database are isolated from any intermediate states of the transaction, i.e., they may see the state of the database before the transaction begins or after it completed, but not any state in the middle;

• Durability: Once all the actions in the collection have completed, the effects endure even in the event of system crashes.

EC is a mixture of decision support and transaction processing activities. Normally, only a portion of the core EC activities are transactional. Two main types of EC transactions are relevant:

• EC transactions between trusted business partners (e.g., suppliers and corporations that enter business agreements and contracts to buy and sell products). These transactions typically are large in volume (large amounts of money and goods), introduce medium traffic, and require rigorous security. These transactions are perfect candidates for Extranets.

• EC transactions between suppliers and the general public (e.g., Internet shopping malls)

Transactional support is implemented differently in different types of systems. For centralized mainframe systems, on-line transaction processing (OLTP), has been built for ACID transactions and has been a backbone of commercial data processing since the early 1970s. Mainframe-based transaction managers (TMs) such as CICS and IMS-DC/IMS-TM have matured over the years to provide high performance and reliable services The situation is dramatically different in distributed environments that characterize EC:

• TP-Less, i.e., do not use any transaction management facilities;

• TP-Light, i.e., use database procedures to handle updates;

• TP-Heavy, i.e., use a distributed transaction manager to handle updates.

Which one of these approaches works depends on the type of EC activities being considered. It appears that each one of these approaches have certain pluses and minuses for EC. The following questions should be asked before deciding on the approach:

• In what format is the data stored (databases, flat files)? If the data is stored in multiple databases and flat files, then TP-Light is not suitable (database procedures only work in RDBMS environments);

• How many SQL servers does the data reside on? If the application needs to update and commit data that is stored on multiple servers, then TP-Heavy should be used (database procedures cannot participate with other database procedures in a distributed transaction).

• What is the requirement for data synchronization? If the data synchronization interval is periodic, then a TP-Light solution combined with a data replication server may be useful to handle updates against replicated data.

• What are the requirements for performance and load balancing?

Figure 3: Models of Distributed Transactions

TP-Less works well when you do not need any transaction processing capabilities. TP-Lite solutions with database procedures are much faster, on the surface, than the TP-Heavy solutions that require synchronization between sites. But TP-Heavy solutions provide many sophisticated procedures for dynamic load balancing, priority scheduling, process restarts, and pre-started servers that are especially useful for large scale production environment. These features are the main strength of TP-Heavy products because many of these products have been used over the years to handle thousands of transactions in production OLTP (on-line transaction processing) environments. Figure 3 shows a basic model of a distributed transaction processor that may use TP-Heavy in distributed environments. The protocol used in this case is two phase commit. 

While the debate between the TP-Lite and TP-Heavy proponents continues, most EC projects are completely ignoring this whole issue by focusing primarily on EDI and in some sense re-inventing the wheel. EDI, at best, is a TP Less approach. Some EC applications are being deployed by using TP-Lite while large mission critical EC applications, if any, use TP-Heavy only at back-end mainframe systems. In the meantime, it seems that many small EC applications are quite happy with TP-Less.