Transactional middleware, which includes TP monitors and application servers, provide benefits to distributed computing and EAI that cannot be found in traditional development tools.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
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.Transactional Middleware
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.
A 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 transaction’s 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.
Transactional 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 Multiplexingis 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)
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)
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.
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.
The standards that define how transactional middleware functions are the International Standards Organizations (ISO) and X/Open’s 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 transaction services simply requires that you programmatically define the functions that the service will perform when accessed by the required TP monitor APIs.
They 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)
The 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
Application 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.
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.
TP monitors will remain the dominant transactional middleware because they provide the best mix of standards, scaling features and reputations
Traditional 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.
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.
RPCs 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 clientRPC & Messaging
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/server systems. In addition to many database-oriented middleware layers, they are capable of running network operating systems, such as Sun’s NFS (Network File System) and DCE (from Open Software Foundation)
Distributed object technology, such as COM and CORBA, leverage RPCs effectively in order to provide object-to-object communications.
DCE is complex (but effective) middleware solution. It was developed by OSF and it makes many diverse computers function as a single virtual system – excellent for distributed computing.
Fig. 9.2 The DCE Architecture
But, DCE allows developers to reach across platforms to access many types of application services, including database, distributed objects, and TP monitors.
DCE also provides a sophisticated naming service, a synchronization service, a distributed file system, and built-in network security. Another plus is that DCE is available on almost any platform.
If the required bandwidth is not available for use with an RPC middleware, or in the situation where a server cannot be depended upon to always be up and running, message-oriented middleware (MOM) is more advisable than any other type of middleware.
MOM utilizes one of the two macro-messaging models
Process-to-Process both the sending and receiving processes must be active for messages to be exchanged
Message Queuing allows messages to be stored in a queue, so only one process needs to be active (the sender process). This method is the most beneficial when communication is taking place between computers that are not always up and running, over networks that are not always dependable, or when there is a limitation on bandwidth.
MOM message functions can return immediately even though the request has not actually been completed. This allows the application to continue processing, assured that it will know when the request is completed.
The queuing model is the most useful from transactions-oriented EAI applications that must transverse multiple platforms.
Unlike DCE, the platform does not have to be up and running for an application to request services. If the server is down the request remains in queue. When the server comes back online, the request will be processed.
In addition to these features, MOM provides concurrent execution features, allowing the processing of more than one request at the same time.
MOM is also good for “defensive” communication, or when the network between applications fails a lot. Also it’s a good option for when communications between processes need to be logged.
MOM and messaging tend to be better EAI fits than RPC based middleware, but MOM alone does not provide all the infrastructure necessary for EAI.
Message Brokers add value to traditional MOM products by providing data and schema transformation function, as well as intelligent routing and event-driven processing to move information on an enterprise network. (see Fig. 9.4)
It’s a Windows NT/2000 based and COM enabled MOM. It is also a key product for Microsoft as it joints the Microsoft Transaction Server (MTS), Internet Information Server (IIS), SQL Server, and Microsoft’s Active Platform.
MSMQ provides a set of Active X components that implements an API to all MSMQ features. Active X allows these other Microsoft products to access MSMQ.
MSMQ can guarantee the delivery of messages by utilizing disk based intermediary storage and log-based recovery techniques. Some of the protocols MSMQ works well with are IPX/SPX and TCP/IP. Using MSMQ as a common translation mechanism these protocols can even be mixed and matched.
MSMQ is tightly integrated with MTS and MTS services participate in the MSMQ transaction.
On time, in order delivery of messages from source to destination
Message-routing services, which give the EAI applications the ability to send messages to their destination using least-cost routing
Notification services, which informs the sender that the message was received and processed.
Message priorities, which allow developers to assign priorities to messages.
Journaling, which maintains copies of the messages moving in the system.
When an application needs to place a message in the queue, it uses the MSMQ Open API, which has an Active X control wrapped around it. By passing in, the name and destination queue, a queue handle is created, allowing the MSMQ to identify the destination queues to the MSMQ server sending the message.
Once a queue handle has been created, the next step is to create a message by allocating local memory and adding information to the message. At this step, parameters (time-out values, names of response queues, priorities, etc) can be added. The message is then sent through the MSMQ “Send API”. Finally the application closes the queue handle using the MSMQ “Close API” function (MQCloseQueue).
The receiver application requires the Open API, along with queue identification information, to create the queue handle. When calling the MSMQ Receiver API, MSMQ will pass back a pointer with control information to the message.
Fig. 9.5 The Architecture of MSMQ
IBM has over 65% of the middleware market and although is not the best of the message middleware software, the IBMs MQSeries is at the top of the EAI world as the preferred messaging layer for moving information through an enterprise network.
MQSeries support a variety of platforms working with IBM OS/390, Pyramid, Open VMS, IBM AIX, NCR UNIX, Solaris, Windows NT, MacOS, etc.
MQseries supports all the features of MSMQ, including support for transactions, journaling, message routing and priorities. It also provides a common API for use across a variety of development environments and on a variety of platforms.
The interesting thing is that MQSeries provides a single multiplatform API, so messages can be sent from a Windows 2000 computer and routed via UNIX, VMS, etc, before reaching their final destination.
Fig. 9.6 MQSeries MOM
Customer Application Options
Trusted Messaging Backbone
Comprehensive Communications Choices
Fig. 9.7 The 3 Layers of MQSeries
Trusted Messaging Backbone guarantees that messages are delivered to their destinations and that the information encapsulated in those messages is secure.
Comprehensive Communications Choices allow MQSeries to leverage any number of protocols and networks for message traffic.
Database-message resource coordination (DMRC)
Smart message distribution
Supports NT/2000 & OS/2
Ability to support large message