O'Reilly - Java Message Service
O'Reilly - Java Message Service
O'Reilly - Java Message Service
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Java</strong> <strong>Message</strong> <strong>Service</strong><br />
When one part of the system goes down, everything halts. When you post an order to an<br />
order entry system, it needs to make a synchronous call to each of the other systems. This<br />
causes the order entry system to block and wait until each system is finished processing the<br />
order. [1]<br />
[1] Multithreading and looser RPC mechanisms like CORBA's one-way call are options, but these<br />
solutions have their own complexities and require very sophisticated development. Threads are<br />
expensive when not used wisely, and CORBA one-way calls still require application-level error<br />
handling for failure conditions.<br />
It is the synchronized, tightly coupled, interdependent nature of RPC systems that cause<br />
entire systems to fail as a result of failures in subsystems. When the tightly coupled nature<br />
of RPC is not appropriate, as in system-to-system scenarios, messaging provides an<br />
alternative.<br />
1.4.2 Enterprise Messaging<br />
Problems with the availability of subsystems are not an issue with <strong>Message</strong>-Oriented<br />
Middleware. A fundamental concept of MOM is that communication between applications<br />
is intended to be asynchronous. Code that is written to connect the pieces together assumes<br />
there is a one-way message that requires no immediate response from another application.<br />
In other words, there is no blocking. Once a message is sent, the messaging client can<br />
move on to other tasks; it doesn't have to wait for a response. This is the major difference<br />
between RPC and asynchronous messaging, and is critical to understanding the advantages<br />
offered by MOM systems.<br />
In an asynchronous messaging system, each subsystem (Accounts Receivable, Inventory,<br />
etc.) is decoupled from the other systems (see Figure 1.9). They communicate through the<br />
messaging server, so that a failure in one does not impede the operation of the others.<br />
Figure 1.9. JMS provides a loosely coupled environment where partial failure of system<br />
components does not impede overall system availability<br />
Partial failure in a networked system is a fact of life. One of the systems may have an<br />
unpredictable failure or need to be shut down at some time during its continuous operation.<br />
This can be further magnified by geographic dispersion of in-house and partner systems. In<br />
17