XML messaging, Part 1 - JavaWorld March 2001
Tutorial Details:
XML messaging, Part 1
XML messaging, Part 1
By: By Dirk Reinshagen
Write a simple XML message broker for custom XML messages
ML messaging represents a rapidly growing, dynamic area of IT, a situation that makes it exciting and tiresome at the same time. As B2B exchanges and other forms of inter-business electronic communication grow, XML messaging will be more widely deployed than ever.
Read the whole "XML Messaging" series:
Part 1: Write a simple XML message broker for custom XML messages
Part 2: XML messaging the SOAP way
Part 3: JAXM and ebXML set the new standard for XML messaging
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.
What is XML messaging?
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 XML messaging?
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.
When evaluating whether to use a message-oriented design it is important to understand the pros and cons of such a system. The pros include:
Loose coupling
Easier message routing and transformation
More flexible payload (can include binary attachments, for example)
Can use several messages together to invoke a given procedure
In general, a message-oriented approach proves more flexible than an RPC approach.
Now here are some cons:
It requires more work to develop a client/server interaction using a message-oriented approach compared with an RPC approach like RMI because developing a client/server interaction via a message represents another level of indirection from RPC. Complexity is added through the creation of the message on the client side (versus a procedure invocation in an RPC approach) and on the server side with message-processing code. Because of its added complexity, a message-oriented design can be more difficult to understand and debug.
There is a risk of losing type information for the programming language in which the message was sent. For example, double in Java may not translate as a double in the message.
In most cases the transactional context in which the message was created does not propagate to the messaging server.
Considering the pros and cons, when should you use a message-oriented approach? The most common scenario occurs when the client/server communication takes place over the Internet and the client and server belong to different companies. In this scenario it could be fairly difficult to have the two companies agree on the procedure interface. Also, it's possible that the companies might not want to use the same programming language. In another example, the companies involved may want to use an asynchronous communication model so that neither will depend on the other's application being up and running.
Another attractive messaging scenario occurs when you're developing an event-based system in which events are created and then consumed by interested parties. Most GUIs are event-based. For instance, they might create a mouse click event in which interested parties listen for the event and perform some action based on it. In this scenario, using a messaging approach allows you to remove the dependency between an event (or action in a system) and the system's reaction to the event that is performed on the server.
Now that we understand a bit about messaging, we're ready to add XML to the equation. The addition of XML to messaging means that we are able to make use of a flexible data formatting language for our messages. In messaging, both the client and the server need to agree on a message format. XML makes this easier by deciding many data formatting issues and with the addition of other XML standards such as Rosetta Net. No additional work is required to come up with a message format.
What does an XML message broker do?
A message broker acts as the server in a message-oriented system. Message broker software performs operations on messages it receives. These operations include:
Header processing
Security checks and encryption/decryption
Error and exception handling
Routing
Invocation
Transformation
Header processing
Header processing is usually one of the first functions performed in the message upon its receipt within an XML broker. Header processing involves examining the header fields of incoming messages and performing some functions. Header processing could include adding a tracking number to an incoming message or ensuring that all of the header fields necessary to process the message exist. In the example XML message below, the message broker could check the to header field to ensure that this is the proper destination for this message.
Security checks and encryption/decryption
From a security perspective, a message broker can perform several different operations, but most likely you'll want to accomplish the "big three" of security: authentication, authorization, and encryption. First, once it determines that the message contains data that can be used to authenticate, the message broker will authenticate messages against a security database or directory. Second, the message broker will authorize operations that can be performed with this type of message and an authorized principal. Finally, the message that arrives at the message broker may be encrypted using some encryption scheme. It will be the broker's responsibility to decrypt the message in order to process it further.
Error and exception handling
Error and exception handling is another important piece of functionality performed by the message broker. Generally, the message will respond to the client (assuming a synchronous invocation) with an error message, caused when the message sent to the broker does not contain sufficient or accurate information. Another cause for errors or exceptions would occur when servicing the request (actually invoking a procedure/method based on the payload of the message).
Routing
Message routing is branching logic for messages. It occurs at two different levels in a message. The first, header-level routing, determines if an incoming message is bound for this application or needs to be resent to another application. The second, payload routing, determines which procedure or method to invoke once the broker determines that the message is bound for this application. Together these two types of routing enable a rich set of functionality when dealing with messages.
Invocation
Invocation means to actually call or invoke a method with the data (payload) contained in the incoming message. This could produce a result that is then returned through the broker back to the client. What is invoked could be anything, including an EJB Session bean, class method, and so on.
Transformation
Transformation converts or maps the message to some other format. With XML, XSLT is commonly used to perform transformation functionality.
An example XML message
Below you'll find an XML message used in the sample application that follows. Notice the header and body portions. This
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: XML messaging, Part 1 - JavaWorld March 2001
View Tutorial: XML messaging, Part 1 - JavaWorld March 2001
Related
Tutorials:
 XML messaging, Part
3
XML messaging, Part
3
|
Web services hits
the Java scene,
Part 1
Web services hits
the Java scene,
Part 1
|
Connect the
enterprise with the JCA, Part 1
Connect the
enterprise with the JCA, Part 1
|
XSLT blooms with
Java
XSLT blooms with
Java
|
Cache SOAP services on
the client side
Cache SOAP services on
the client side
|
Discover and publish Web services with JAXR
Discover and publish Web services with JAXR
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
Jabber away with instant
messaging
Jabber away with instant
messaging
|
Yes, you can secure your Web services documents, Part 1
Yes, you can secure your Web services documents, Part 1
|
Yes, you can secure your Web services documents, Part 2
Yes, you can secure your Web services documents, Part 2
|
Business process
automation
made easy with
Java, Part 2
Business process
automation
made easy with
Java, Part 2
|
Sun boosts
Sun boosts enterprise Java
|
Manage users with
JMS
Manage users with
JMS
|
The Java Web Services Tutorial
This tutorial is a beginner\'s guide to developing Web services and Web applications using the Java Web Services Developer Pack (Java WSDP).
|
SAAJ: No strings attached
SAAJ: No strings attached
|
JSP 2.0: The New Deal, Part 3
JSP 2.0: The New Deal, Part 3
More Flexible JSP Document Format Rules
The JSP specification supports two types of JSP pages: regular JSP pages containing any type of text or markup, and JSP Documents, which are well-formed XML documents; i.e., docum
|
XML Messaging Using JBoss
It\'s common practice to share data using FTP, but an increasingly popular alternative is to use a messaging service. As always, each approach has its own pros and cons, depending on the nature of "what to share," how easy it is to implement the technolog
|
The JavaTM Web Services Tutorial
A beginner's guide to developing Web services and Web applications on the Java Web Services Developer Pack
|
Power Messaging, Maps and more...
BuddySpace is an instant messenger with four novel twists: (1) it allows optional maps for geographical & office-plan visualizations in addition to standard 'buddy lists'; (2) it is built on open source Jabber, which makes it interoperable with ICQ, MSN,
|
Solaris 10 OS Certification Beta Exams
If you are an expert in system and network administration, you can get involved in the creation of three new Solaris 10 certification exams. These Beta exams count toward official Solaris Certification and allow you to provide comments and technical feedb
|
|
|
|
