Web Services - Concepts, Architecture and Applications Part 3: Asynchronous middlewareMessage oriented middlewareQueues in TP-MonitorsQueues in practiceReliable queuingQueuing systemsTransactional queuesProblems solved (I)Problems solved (II)ImplementationAdvantages of queues in EAIMessage brokersMessage brokers across organizationsLimitations of message brokersMessage oriented business exchangesOld fashioned e-commerce ...Message based interactionWeb Services - Concepts, Architecture and ApplicationsPart 3: Asynchronous middlewareGustavo Alonso and Cesare PautassoComputer Science DepartmentETH Zü[email protected]://www.inf.ethz.ch/~alonso©ETH Zürich Part 3: Async. middleware 2Message oriented middleware©ETH Zürich Part 3: Async. middleware 3Queues in TP-Monitors Any synchronous middleware introduces a tight coupling between the caller and the called. Name and directory services help to minimize the effects of this coupling but the tight connection between components is nevertheless there. It also creates considerable problems when trying to implement certain properties or manage the interaction between client and servers (fault tolerance, availability, etc.)  The first systems to provide alternatives were TP-Monitors which offered two choices:Ä asynchronous RPC: client makes a call that returns immediately; the client is responsible for making a second call to get the resultsÄ Reliable queuing systems (e.g., Encina, Tuxedo) where, instead of using procedure calls, client and server interact by exchanging messages. Making the messages persistent by storing them in queues added considerable flexibility to the systemclientservice callget resultsserverservicereturn resultsClient stubServer stubRPC supportexternal applicationexternal applicationInput queue Output queueInput queueOutput queueReliablequeuingsystem©ETH Zürich Part 3: Async. middleware 4Queues in practice To access a queue, a client or a server uses the queuing services, e.g., :Ä put (enqueue) to place a message in a given queueÄ get (dequeue) to read a message from a queueÄ mput to put a message in multiple queuesÄ transfer a message from a queue to another In TP-Monitors, these services are implemented as RPC calls to an internal resource manager (the reliable queuing service) These calls can be made part of transaction using the same mechanisms of TRPC (the queuing system uses an XA interface and works like any other resource manager)persistentrepositoryclientput…Client stub(queuingservice)putqueuemanagementget mputQueuing serverserverget…Client stub(queuingservice)©ETH Zürich Part 3: Async. middleware 5Reliable queuing Reliable queuing turned out to be a very good idea and an excellent complement to synchronous interactions:Ä Suitable to modular design: the code for making a request can be in a different module (even a different machine!) than the code for dealing with the responseÄ It is easier to design sophisticated distribution modes (multicast, transfers, replication, coalescing messages) and it also helps to handle communication sessions in a more abstract wayÄ More natural way to implement complex interactionsdo with answerdo with answerrequest()request()receiveprocessreturnqueuequeue©ETH Zürich Part 3: Async. middleware 6Queuing systems Queuing systems implement asynchronous interactions. Each element in the system communicates with the rest via persistent queues. These queues store messages transactionally, guaranteeing that messages are there even after failures occur. Queuing systems offer significant advantages over traditional solutions in terms of fault tolerance and overall system flexibility: applications do not need to be there at the time a request is made! Queues provide a way to communicate across heterogeneous networks and systems while still being able to make some assumptions about the behavior of the messages. They can be used when embedded (workflow, TP-Monitors) or by themselves (MQSeries, Tuxedo/Q). external applicationclientInput queueInput queue Output queueOutput queueReliable queuing systemMonitoringAdministrationPersistent storage©ETH Zürich Part 3: Async. middleware 7Transactional queues Persistent queues are closely tied to transactional interaction:Ä to send a message, it is written in the queue using 2PCÄ messages between queues are exchanged using 2PCÄ reading a message from a queue, processing it and writing the reply to another queue is all done under 2PC This introduces a significant overhead but it also provides considerable advantages. The overhead is not that important with local transactions (writing or reading to a local queue). Using transactional queues, the processing of messages and sending and receiving can be tied together into one single transactions so that atomicity is guaranteed. This solves a lot of problems!external applicationexternal applicationInput queueInput queueOutput queueOutput queue2PC2PC2PC2PC2PC©ETH Zürich Part 3: Async. middleware 8Problems solved (I)SENDING RECEIVINGexternal application2PCexternal application2PCMessage is now persistent. If the nodecrashes, the message remains in thequeue. Upon recovery, the application can look in the queue and see whichmessages are there and which arenot. Multiple applications can write tothe same queue, thereby “multiplexing”the channel.Arriving messages remain in the queue.If the node crashes, messages are notlost. The application can now take itstime to process messages. It is also possible for several applications to readfrom the same queue. This allows toimplement replicated services, do loadbalancing, and increase fault tolerance.©ETH Zürich Part 3: Async. middleware 9Problems solved (II) An application can bundle within a single transaction reading a message from a queue, interacting with other systems, and writing the response to a queue. If a failure occurs, in all scenarios consistency is ensured:Ä if the transaction was not completed, any interaction with other applications is undone and the reading operation from the input queue is not committed: the message remains in the input queue. Upon recovery, the message can be processed again, thereby achieving exactly once semantics.Ä If the transaction was completed, the write to the output queue is committed, i.e., the response remains in the queue.Ä If replicated services are used, if one fails and the message remains in the input