What are the pros and cons of JMS over RMI and vice versa? Which technology is best suited for what kind of projects?
Remote Procedure Call (RPC) technologies like RMI attempt to mimic the behavior of system that runs in one process. When a remote procedure is invoked the caller is blocked until the procedure completes and returns control to the caller. This synchronized model allows the developer to view the system as if its all running on one process. Work is performed sequentially ensuring that tasks are completed in a predefined order. The synchronized nature of RPC tightly couples the client (the software making the call) to the server (the software servicing the call). The client can not proceed (its blocked) until the server responds. The tightly-coupled nature of RPC creates highly interdependent systems where a failure on one system has an immediate and debilitating impact on other systems. In J2EE, for example, the EJB server must be functioning properly for the Servlets to function. RPC works well in many scenarios, but its synchronous, tightly coupled nature is a severe handicap in system-to-system processing where vertical applications are integrated together. In system-to-system scenarios the lines of communication between vertical systems are many, and also multi-directional.
Consider the challenges of implementing a multi-application infrastructure using a tightly-coupled RPC mechanism. There is the many to many problem of managing the connections between these systems. When you add another application to the mix, you have to go back and let all the other systems know about it. Also, Systems can crash. Scheduled downtimes need to happen. Object interfaces need to be upgraded. When one part of the system goes down, everything halts. When you post an order an order entry system, it needs to make a synchronous call right then and there to the helpdesk system to let it know there is a new customer. This causes the order entry system to stop and wait for this to happen. Its the synchronized, tightly coupled, interdependent nature of RPC systems that cause entire systems to fail as a result of failures in subsystems. When the tightly coupled nature of RPC is not appropriate, as in system-to-system, messaging provides an alternative.
With the use of Message Oriented Middleware (MOM), problems with the availability of subsystems are not an issue. A fundamental concept of MOM is that communications between components is intended to be asynchronous in nature. Code that is written to connect the pieces together assume that there is a one-way message that requires no immediate response. In other words, there is no blocking. Once a message is sent the client can move on to other tasks; it doesn't have to wait for a response. This is the major difference between RPC and asynchronous messaging and is critical to understanding the advantages offered by MOM systems.
In an asynchronous messaging system each subsystem (Accounts Receivable, Inventory, etc) is decoupled form the other systems. They communicate through the messaging server, so that a failure in one does not impede the operation of the others.
Partial failure in a networked system is a fact of life. One of the systems will have an unpredictable failure or need to be shut down at sometime during the life of the system. This can be further magnified by geographic dispersion of your in-house and partner systems. In recognition of this JMS provides guaranteed delivery, which ensures that its intended consumers will eventually receive a message sent even if partial failure occurs.
Guaranteed delivery uses a store and forward mechanism, which means that the underlying message server will write the incoming messages out to a persistent store if the intended consumers are not currently available. When the receiving application becomes available at a later time, the store and forward mechanism will deliver all of the messages that the consumers missed while unavailable.
Dig Deeper on Topics Archive
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.