23.07.2013 Views

O'Reilly - Java Message Service

O'Reilly - Java Message Service

O'Reilly - Java Message Service

SHOW MORE
SHOW LESS

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 />

With J2EE, JSP and Servlets represent the presentation tier while Enterprise <strong>Java</strong>Beans is<br />

the middle tier. Microsoft's DNA is architecturally similar to J2EE, relying on ASP for<br />

presentation and COM+ for the middle tier. Regardless of the platform, the core<br />

technology used in these systems is RPC-based middleware. Whether it's the EJB or<br />

COM+, RPC is the defining communication paradigm.<br />

RPC attempts to mimic the behavior of a system that runs in one process. When a remote<br />

procedure is invoked, the caller is blocked until the procedure completes and returns<br />

control to the caller. This synchronized model allows the developer to view the system as<br />

if it runs in one process. Work is performed sequentially, ensuring that tasks are completed<br />

in a predefined order. The synchronized nature of RPC tightly couples the client (the<br />

software making the call) to the server (the software servicing the call). The client cannot<br />

proceed - it is blocked - until the server responds.<br />

The tightly coupled nature of RPC creates highly interdependent systems where a failure<br />

on one system has an immediate and debilitating impact on other systems. In J2EE, for<br />

example, the EJB server must be functioning properly if the servlets that use enterprise<br />

beans are expected to function.<br />

RPC works well in many scenarios, but its synchronous, tightly coupled nature is a severe<br />

handicap in system-to-system processing where vertical applications are integrated<br />

together. In system-to-system scenarios, the lines of communication between vertical<br />

systems are many and multidirectional, as Figure 1.8 illustrates.<br />

Figure 1.8. Tightly coupled with synchronous RPC<br />

Consider the challenge of implementing this infrastructure using a tightly coupled RPC<br />

mechanism. There is the many-to-many problem of managing the connections between<br />

these systems. When you add another application to the mix, you have to go back and let<br />

all the other systems know about it. Also, systems can crash. Scheduled downtimes need to<br />

happen. Object interfaces need to be upgraded.<br />

16

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!