| Having all producers and all consumers of messages participate in one global transaction would defeat the purpose of a loosely coupled asynchronous messaging environment. In a loosely coupled environment, applications need to hand off their messages to the messaging environment using local transactions, and go about their business. They don't need to be concerned about whether all the other interested parties are available to concurrently participate in a global transaction on the piece of data that the message represents. 5.5.1 Local Transactions Within the context of an individual sender or an individual receiver, many MOM implementations have a model for grouping together multiple operations as a single transaction that is locally scoped to an individual sender or receiver. One such case is the grouping together of multiple messages in an all-or-nothing fashion. The transactions follow the convention of separating the send operations from the receive operations. Figure 5-14 shows a transactional send of a group of messages, in which either all of them or none of them will get to the message server. From the sender's perspective, the messages are held by the message server until a commit command is issued. If a failure occurs or if a rollback command is issued, the messages are discarded. Messages delivered to the message server in a transaction are not forwarded to the consumers until the producer commits the transaction. Figure 5-15. Transactional messages are sent in an all-or-nothing fashion 
The message server will not start to deliver the messages to its consumers until the producer issues a commit command on the session. A message-based local transaction can include any number of messages. There is also the notion of a transactional receive, in which a group of transacted messages are received by the consumer on an all-or-nothing basis (Figure 5-15). From the receiver's perspective, the messages are delivered as expeditiously as possible, but are held in a recoverable storage mechanism by the message server until the receiver issues a commit command. If a failure occurs or a rollback command is issued, the messaging system will attempt to redeliver all the messages. Figure 5-16. Transactional messages are received by a consumer in an all-or-nothing fashion 
Local transactions can also be used to group receive and send operations (Figure 5-16). In this case, the client application is both a consumer and a producer. It may receive one message, modify its content, and send the new message along to another destination. By using the local transaction to group together the send and receive, a single commit operation will remove the message from the server's persistent storage and send it to its next destination. Figure 5-17. Receive and send operations can be grouped together in a single local transaction 
5.5.2 Transactions with Multiple Resources It is sometimes necessary to coordinate the sending or receiving of a local transaction with the update of another transactional resource, such as a database or a transactional EJB entity bean. This typically involves an underlying transaction manager that takes care of coordinating the prepare, commit, or rollback operations of each resource participating in the transaction. A MOM implementation may provide transaction interfaces for accomplishing this, allowing a message producer or consumer to participate in a transaction with any other resource that is compliant with the XOpen/XA two-phase-commit transaction protocol (Figure 5-17). Figure 5-18. A message producer or consumer may participate in a two-phase-commit transaction with any XA-compliant resource, such as a database 
Technically, this is a "distributed" transaction. However, from a MOM perspective, it is simply tying the message server interactions with the processing of a message that involves the use of another transactional resource. Multiple message clients would not participate in the same global transaction in a distributed manner, as this would defeat the purpose of a loosely coupled asynchronous environment. In an ESB, each participant in a message exchange needs to be able to rely on having transactional integrity with its interaction with the bus, and not with the other applications that are plugged into the system. 5.5.3 An ESB Removes the Low-Level Complexities The usual way of using a MOM, whether it is JMS-based, SOAP-based, or something else, is to write code into an application client that manages things such as establishing a connection with the messaging server; creating publishers, subscribers, queue senders, and queue receivers; and managing the transactional demarcation and recovery from failure. An ESB removes this complexity by delegating that responsibility to the ESB service container. An integration architect can use an administrative tool to configure an ESB service to send and receive messages using pub/sub, point-to-point queues, or other kinds of transport mechanisms simply by configuring the inputs and outputs of the service. The container takes care of the rest. It is even possible for an output channel to use pub/sub, which is eventually mapped onto an outbound web service invocation using SOAP. More details on service containers and their use of inbound and outbound channels can be found in Chapter 6, Chapter 7, and Chapter 8. | 