Oddly, there is remarkably little discussion of this need, especially when you consider the how much public debate there has been over what XML can represent and how it could or should represent it. The XML-RPC (Remote Procedure Call) initiative promotes the notion of an RPC-like mechanism for exchanging XML over HTTP. But as we shall see, RPC for largely distributed systems is a highly limited mechanism -- particularly when those systems connect multiple businesses across the Internet.
In contrast, there is a natural fit between XML and Java messaging -- from the problems they try to solve to the design philosophies behind their use. This article aims to illuminate how well these technologies work together.
As organizations deploy distributed Java applications on ever-larger scales -- across offices of an enterprise or between businesses in a business-to-business (B2B) capacity -- the demands placed upon their communication and transaction infrastructures expand geometrically. Upon examination, direct RMI or RPC mechanisms quickly fail to meet the challenges presented in such environments.
Consider, for example, a B2B scenario wherein information on changing prices is to be communicated from a supplier to a number of retailers, and the retailers may in turn wish to place orders for items at a new price. While this is perhaps the most simplistic of B2B scenarios, could you imagine trying to implement such an infrastructure using a bare RPC mechanism?
You would need to create a listener that would respond to all incoming orders, which doesn't sound so bad. You would also need to manage the list of price change recipients, with appropriate provisions for easily adding new ones -- again, not an impossible task, but perhaps a bit tedious.
Next, you would need to ensure that each party receives and processes all the transactions that are sent its way. Now things get sticky. What if one of the retailers is offline, or network routing to its server fails? Your application would need to keep trying to establish communications with all such recipients until the transaction could be successfully sent. What if the power on the supplier's server dropped, or the server required a reboot prior to all recipients receiving a price change? Or, even worse, prior to the supplier receiving an order?
Clearly, you would need to provide persistence for critical transactions until all required recipients acknowledge them. And, of course, you'd want to ensure that all parties performing transactions are allowed access and are who they say they are, and that no transaction is compromised during transmission. RPC does not provide assistance for any of these problems, requiring the application to carry the additional weight itself.