Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

XML messaging, Part 1

Write a simple XML message broker for custom XML messages

By Dirk Reinshagen, JavaWorld.com, 03/02/01

Page 2 of 7

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:

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.