MESSAGE-ORIENTED MIDDLEWARE

Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. Message Oriented Middleware (or MOM) is one particular form of middleware, which is capable of facilitating the transportation of asynchronous messages from one component to another. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols. The middleware creates a distributed communications layer that insulates the application developer from the details of the various operating system and network interfaces. MOM provides software elements that reside in all communicating components of a client/server architecture and typically support asynchronous calls between the client and server applications. MOM reduces the involvement of application developers with the complexity of the master-slave nature of the client/server mechanism

Advantages
Central reasons for using a message-based communications protocol include its ability to store (buffer), route, or transform messages while conveying them from senders to receivers.

Asynchronicity
MOM comprises a category of inter-application communication software that generally relies on asynchronous message-passing, as opposed to a request-response architecture. In asynchronous systems, message queues provide temporary storage when the destination program is busy or not connected. In addition, most asynchronous MOM systems provide persistent storage to back up the message queue. This means that the sender and receiver do not need to connect to the network at the same time (asynchronous delivery), and problems with intermittent connectivity are solved. It also means that should the receiver application fail for any reason, the senders can continue unaffected, as the messages they send will simply accumulate in the message queue for later processing when the receiver restarts.

Routing
Many message-oriented middleware implementations depend on a message queue system. Some implementations permit routing logic to be provided by the messaging layer itself, while others depend on client applications to provide routing information or allow for a mix of both paradigms. Some implementations make use of broadcast or multicast distribution paradigms.

Transformation
In a message-based middleware system, the recipient's message need not replicate the sender's message exactly. A MOM system with built-in intelligence can transform messages en route to match the [2] requirements of the sender or of the recipient. In conjunction with the routing and broadcast/multicast facilities, one application can send a message in its own native format, and two or more other applications may each receive a copy of the message in their own native format. Many modern MOM systems provide sophisticated message transformation (or mapping) tools which allow programmers to specify transformation rules applicable to a simple GUI drag-and-drop operation.

Forms of MOM:(i) Message Queuing (ii) Publish-Subscribe

Message Queuing

Publish-Subscribe

TRANSACTION ORIENTED MIDDLEWARE

A transaction combines a group of operations on data items into a single unit of work. Transactions are always executed in compliance with the ACID properties (Atomicity, Consistency, Isolation, Durability) Queued vs. Direct Transaction Processing Direct: Client waits until request is serviced. Service provided as quickly as possible and result is returned. Client and server are synchronized. Queued: Request enqueued and client continues execution. Server dequeues request at a later time and enqueues result. Client dequeues result later. Client and server unsynchronized.

Transaction Manager Middleware to support global atomicity of distributed transactions Application invokes manager when transaction is initiated Manager is informed each time a new server joins the transaction Application invokes manager when transaction completes Manager coordinates atomic commit protocol among servers to ensure global atomicity

Transaction processing monitors are an example of transaction oriented middleware Transaction processing (TP) monitor technology provides the distributed client/server environment the capacity to efficiently and reliably develop, run, and manage transaction applications Its mission is to monitor workflow status for transactions that require multiple steps. The TPM generally has the capability to post alerts and rollback errors or generate compensating transactions when an error occurs. TP Monitor Services Communication services Built on message passing facility of OS Transactional peer-to-peer and/or remote procedure call

ACID properties

Local isolation for a (non-db) server might be provided by a lock manager Implements locks that an application can explicitly associate with instances of any resource

Local atomicity for a (non-db) server might be provided by a log manager Implements a log that can be explicitly used by an application to store data that can be used to roll back changes to a resource

Global isolation and atomicity are provided by transaction manager

Routing and load balancing TP monitor can use load balancing to route a request to the least loaded member of a server class

Threading Threads can be thought of as low cost processes Useful in servers (e.g., application server) that might be maintaining sessions for a large number of clients TP monitor provides threads if OS does not

Recoverable queues Security services Encryption, authentication, and authorization

Miscellaneous servers File server Clock server

Communication Service Modules of a distributed transaction must communicate Message passing facility of underlying OS is inconvenient to use, lacks type checking. does not support transaction abstraction (atomicity)

Distributed transactions spread via messages => message passing facility can support mechanism to keep track of subtransactions

TP monitor builds an enhanced communication facility on top of message passing facility of OS Transactional remote procedure call