Read an Excerpt
Chapter 8: SOAP Architecture Using Messages
- Point-to-Point vs. Publish-Subscribe messaging
- The principles of Java Message Service
- Working SOAP examples with Java Message Service
- The JavaSpaces architecture
- The advantages of JavaSpaces over Java Message Service
- Getting JavaSpaces running on your system
- Working SOAP examples with JavaSpaces
Messaging Systems in GeneralMessaging systems came into being with the first networks, and a variety of messages are exchanged over computer networks. Naturally, one thinks first of the ubiquitous e-mail; however, many other types of valuable data are moved over networks, making messaging systems very important in enterprise-level computing, even without e-mail.
There has been a recent trend to recognize messaging systems as a separate class of application, frequently called Message-Oriented Middleware (MOM). A MOM system takes responsibility for transmitting application messages over a network and provides support for load balancing, fault tolerance, and transactions. Basically, there are two models for messaging:point-to-point and publish/subscribe.
The Point-to-Point ModelIn this model, a message is transmitted from a sender to a single recipient. As shown in Figure 8. 1, once the sender, client A, dispatches a message to a local router, the message can travel directly to the recipient, client B, or be relayed through additional routers to client C. Once the sender has succeeded in getting the message to the router, the sender's work is done.
The router holds the message in a message queue, which may or may not be backed up to permanent storage. Each queue has a unique name. A given queue can be associated with one recipient or multiple recipients, but the router ensures that each message goes only to a single recipient. You might use multiple recipients for load-balancing jobs between multiple worker processes.
The Publish/Subscribe ModelIn a point-to-point system, a message is sent to a named queue where it is held until it's retrieved by a specific receiver. In the publish/subscribe model, a message is sent by a mes- sage producer, or publisher, to a topic, and copies are sent to all of the topic's subscribers.
This architecture is depicted in Figure 8.2 with a single router, but the message distribution system could involve many router applications.
AdvantagesBecause of the services a MOM system provides, messaging offers some advantages over the client-server or remote procedure call (RPC)architectures:
Asynchronous With MOM, the sender and receiver of a message do not have to be working, be connected, and have available CPU cycles at the same time.
Fault tolerance MOM software can route around network problems, adjust to network loads, and resend messages in the event of errors.
Ignore network architecture Applications using MOM can totally ignore all of the complexities of the network architecture past the initial entry point.
Security MOM systems can enforce security precautions independently from the applications.
DisadvantagesAn obvious disadvantage for MOM systems is speed. Message transmission through an interme- diary server can never be as fast as direct client-server or RPC connectivity. Another possible disadvantage is the added complexity of maintaining yet another application in the form of the message server, with the attendant storage, network traffic, and processing power requirements.
Reliability RequirementsAs the number of separate components in enterprise networks grows, messaging becomes more and more attractive, despite the disadvantages. The rush to wireless connectivity and the trend toward the distribution of computing power into smaller and simpler devices emphasizes the problem of maintaining reliability. Although device reliability keeps increas- ing, the number of connected devices increases even faster. Therefore, it is a good probabil- ity that some part of your network will not be working at some point along the way.
SOAP Standards and MessagingAlthough SOAP is basically a protocol for sending an XML-encoded message via any transport mechanism, work on standards and example implementations has not been evenly distributed over the universe of possible SOAP uses. In fact, so far the standardization effort has emphasized HTTP transport and the RPC model of request and response. The Apache SOAP implementa- tion reflects this emphasis;it provides minimal support for various messaging architectures.
Fortunately, the suitability of Java for creating messaging services has been apparent from the very start. There are two approaches to messaging with Java APIs:Java Message Service (JMS)API and JavaSpaces. The JMS API has been mature since 1998 and has numerous commercial implementations. The more innovative JavaSpaces API has been developed in connection with Sun's Jini initiative and does not have as many commercial implementations.
Java Message ServiceCreation of the JMS API was accomplished by Sun in close cooperation with industry vendors of MOM software. Although the initial intent was simply to create an API for messaging, the increasing industry interest in messaging as an alternative to Remote Method Invocation (RMI) resulted in a much more complete API than originally planned. The current reference version of JMS can be downloaded from the following site: