Transactional MiddlewareTransactional middleware, which includes TP monitors and application servers, provide benefits to distributed computing and EAI that cannot be found in traditional development tools.Scalability, fault tolerance, and an architecture that centralizes application processing are hallmarks of transactional middleware.In addition, transactional middleware has the ability to provide virtual systems and single logon capabilities and in many cases, has the ability to reduce the overall system cost.Also it ensures delivery of information from one application to the next and supports a distributed architecture (see Fig. 8.1)However, the cost of implementing transactional middleware may preclude its use with EAI.
Fig. 8.1 Transactional Middleware
There are some limitations to what transactional middleware can accomplish within most of the EAI problem domains. None of the TP monitors or application servers that exist today support either out-of-the-box content transformation or message transformation services, at least not without programming.What transactional middleware excels at is method-level EAI or, at least the sharing of common business logic to promote EAI.But Message Brokers or traditional, message-oriented middleware are much better tools for the simple sharing of information at the data level or the application interface level.Transactional middleware requires that complex applications be divided into small size units called transactions. Transactional middleware controls transactions from their beginning to their end, from the client to the resource server and then back again.
Fig. 8.2 Using Transactions to tie together back-end users
The ACID TestA transaction has ACID properties:Atomic refers to all or nothing quality of transactions. In other words the transaction either completes or aborts and there is no middle ground.Consistent refers to the fact that the system is always in a consistent state, regardless of whether or not it completes the transaction.Isolated refers to the transactions ability to work independently of other transactions that may be running in the same TP monitor environment.Durable means that the transaction, once committed and complete can survive system failures.
Scalable DevelopmentTransactional middleware processes transactions on behalf of the client or node and can route transactions through many diversified systems, depending on the requirements of the EAI problem domain.It also provides load balancing, thread pooling, object recycling and the ability to automatically recover from typical system problems.Database Multiplexing is one of the main benefits of transactional middleware. It has the ability to multiplex and manage transactions that result in the reduction of the number of connections and processing loads that larger systems place on a database.With transactional middleware in the architecture, it is possible to increase the number of clients without increasing the size of the database server.By funneling the clients requests, transactional middleware removes the process per client requirements (see Fig. 8.4)
Fig. 8.4 Database Multiplexing
In this scenario, a client simply invokes the transaction services that reside on the TP monitor, and those services can share the same database server connections (threads and processes)
Load Balancing When the number of incoming client requests surpasses the number of shared processes that the system is able to handle, other processes start automatically.Some transactional middleware can distribute the process load over several servers at the same time dynamically or distribute the processing over several processors in multiprocessing environments.This load balancing feature of transactional middleware also enables transactional middleware to prioritize.
Fault-Tolerant Transactional middleware was built from the ground up to provide a robust application deployment environment with the ability to recover from any number of system related problems.Transactional middleware provides high availability by employing redundant systems.
The transactions work through a two-phase-commit protocol to ensure that the transactions complete and to guard against transactions becoming lost electrons when hardware, operating systems, or network fail.
Communications Transactional middleware provides a good example of middleware that uses middleware, which includes message brokers. It communicates in a variety of ways, including RPCs, distributed dynamic program links (DPLs), inter-process communications, and MOM.Because transactional middleware is simply an API within an application, developers have the flexibility to mix and match all sorts of middleware layers and resource servers to meet the requirements of an application or EAI problem domain.
XA and X/OpenThe standards that define how transactional middleware functions are the International Standards Organizations (ISO) and X/Opens Distributed Transaction Process (DTP) specifications.The outcome was XA Interface which defines how a transaction manager and a resource manager (such as a database) can communicate.The XA Interface is a set of function calls, split between the transaction manager and the resource manager. Among the features XA provides are those functions provided by the transaction manager, which allow the resource manager to tell the transaction manager whether it is ready to work with a transaction or whether it is in a resting state and unable to respond.
Building TransactionsBuilding transaction services simply requires that you programmatically define the functions that the service will perform when accessed by the required TP monitor APIs.
Application ServersThey not only provide a location for application logic, they also coordinate many resource connections. Application servers were created for web based transactions and application development, but their usefulness to EAI is obvious, given the back end integration capabilities (their ability to bind together several source and target applications through a series of connectors provided by the applications server vendors-for example SAP, PeopleSoft, relational databases and middleware)
Fig. 8.5 Application Servers
Evolving TransactionsThe benefit of applications servers is clear. By placing some, or most, of the application logic on a middle tier, the developer can insert increased control over the application logic through centralization. Such a placement increases the ability to scale the application through a set of tricks, such as database multiplexing and load balancing.The end result is a traditional 3-tier client/server computing model.
Fig. 8.6 Application Architecture, using an application server
Enterprise Java BeansApplication servers are different from traditional transactional middleware (such as TP monitors) in that they are able to function around the notion of transactional components.Almost all applications servers using this transactional component type architecture are looking to employ EJB as the enabling standard.The EJB specifications define a server side component model for JavaBeans. EJB represent specialized JavaBeans that run on a remote server EJB look very similar to distributed objects such as COM and CORBA at least from the point of view of architecture.Using the same architecture as traditional JavaBeans, EJB can be clustered together to create a distributed application with a mechanism to coordinate the processing that occurs within JavaBeans.
Fig. 8.8 EJB define server-side component model
The EJB model supports the notion of implicit transactions. The EJB model defines the relationship between an EJB component and EJB container system. The EJB execution system is called EJB Server and it provides a standard set of services to support EJB components.
Future of Transactional MiddlewareTP monitors will remain the dominant transactional middleware because they provide the best mix of standards, scaling features and reputationsTraditional TP monitor environments, as well as the new line of Java-enabled application servers, will provide to be the best place for EJB.Integration problem domains that need to support transactions between applications, share logic as well as data, and are willing to incur cost of changing all connected applications, are perfect for transactional middleware-type solutions.
RPC & MessagingMessage-Oriented Middleware (MOM) and RPCs based middleware tend to be traditional, point-to-point middleware. Because of that, they are not effective solutions for most integration projects. Middleware itself is a common point of integration for source and target systems. Despite the limitations of this technology for EAI solutions, the appropriate tradeoffs in both technology and product decisions may make the inclusion of this middleware important to a particular integrationproblem domain.RPCsRPCs are a method of communicating with a remote computer, in which the developer invokes a procedure on the server by making a simple function call on the client
Fig. 9.1 Using RPCs
The client process that calls the function must suspend itself until the procedure is completed.This blocking of an application might become a problem for the performance of that application. Also there is a high level of network communication between the client and the server when using RPCs, thus the RPC architecture requires a high-speed network.RPCs were the base middleware layers of the early client