|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Read the whole "XML Messaging" series:
In this article, we'll first explore XML messaging and why it is useful. Then we'll delve into specific XML messaging features, including message routing, transformation, and brokering. Finally, we'll finish up with a simple example of an XML broker. After you read and understand the concepts, you should clearly understand which scenarios lend themselves to implementing an XML messaging solution.
To start our exploration, we need to understand the basic premise of XML messaging and what the term messaging implies. For purposes of this article, I define message as follows:
A collection of data fields sent or received together between software applications. A message contains a header (which stores control information about the message) and a payload (the actual content of message).
Messaging uses messages to communicate with different systems to perform some kind of function. We refer to the communication as being message-oriented because we would send and receive messages to perform the operation, in contrast to an RPC (Remote Procedure Call)-oriented communication. A simple analogy may help: think of messaging as email for applications. Indeed, messaging possesses many of the attributes of individuals sending email messages to one another.
In the past, when you were using or working on a message-oriented system, it meant that you were using some kind of MOM (message-oriented middleware) product like Tibco's Rendezvous, IBM's MQSeries, or a JMS provider to send messages in an asynchronous (one-way) fashion. Messaging today doesn't necessarily mean that you are using a MOM product, and it doesn't necessarily mean that you are communicating asynchronously. Rather, messaging can be either synchronous (two-way) or asynchronous and use many different protocols such as HTTP or SMTP, as well as MOM products.
Why would you want to develop a system using messaging? What makes messaging a useful design technique and what are the benefits? As mentioned earlier, we can chose from two alternatives when requiring two applications to talk to each other over a network: RPC or message-oriented. Using an RPC-based approach (RMI falls into this category) means that the client (or caller) of the procedure call knows the procedure it wants to invoke and knows the parameters it wishes to pass to the procedure. Also, the caller wishes to wait while the called server (the application) completes the request.
In the second approach -- message-oriented -- the caller does not necessarily know the exact procedure that will be invoked, but instead creates a message of a specific format known to both the client and the server. The client creates the message and then sends it to the server over the network. Therefore, the client does not depend on the server or the server's procedures, but is dependent on the message format. Also, the communication likely takes place in an asynchronous fashion, meaning that the client will send off a request but will not wait (block) for the response. This enables the client to continue to function even if the server becomes unavailable (crashes, for example). This design, where the client is more independent of the server, is considered to be more loosely coupled.