Software platforms traditionally offered a publish/subscribe mechanism as one of the core platform services. With help from this mechanism, an application could raise events or express interest in events produced by other applications. The Internet and Web services are emerging as the next generation platform for distributed applications. While the new platform enables applications to communicate synchronously or asynchronously over standard Internet protocols, it is still lacking a service that would resemble a traditional publish/subscribe mechanism. In this article, I'll show how such a service can be developed by extending the functionality of an existing framework.

Background
There are many types of systems that could make use of a publish/subscribe service. Figure 1 presents one of them. This system consists of a number of agents and a few management applications. The agents monitor their environment and send status messages to the management applications. The applications process information collected through agents and make system management decisions either automatically or with help from a human operator. The decisions are mapped to actions performed by the agents.

 

Let's take a minute to examine the types of communication taking place between the agents and the management applications. First, there is a stream of system status messages flowing from the agents to the management applications. Second, there is a stream of control messages flowing back from the management applications to the agents.

The case of control messages is relatively straightforward. A control message has a well-defined source and a well-defined destination. Therefore, it can be delivered easily using a traditional, one-to-one request/reply protocol. All of the available RPC mechanisms, such as IIOP, Java RMI, COM, or SOAP-RPC, satisfy this requirement.

The case of status messages is much more interesting. Messages sent by agents are caused by changes in the environment and are therefore asynchronous by nature. In addition, an agent sending a message is decoupled from the management application and rarely knows who will be receiving the message on the other end. Finally, there can be many management applications receiving messages from a single agent. Therefore, what we have here is an asynchronous one-to-many type of messaging that cannot be carried over a traditional RPC link. Instead, a publish/subscribe mechanism is required.

This problem has been successfully solved in many products and middleware frameworks. Typically, it is addressed by introducing a stand-alone publish/subscribe service, sometimes called an event broker or an event intermediary. From the point of view of the event broker, the world is divided into two types of entities: event producers and event consumers. Event producers advertise event types and raise events by sending messages to the event broker. Event consumers express interest in events by registering event subscriptions with the event broker. The event broker matches the two parties by forwarding events sent by the producers to endpoints registered by the consumers. In the context of the management application described earlier, this can be seen in Figure 2.

 

In addition to forwarding events, the event broker can implement a slew of useful functions such as event filtering, event logging, guaranteed event delivery, event correlation, protocol translation, and others. In this article, however, I'll focus not on the functionality of the event broker but on the communication mechanism used by consumers and producers to access its services. In particular, we want to understand what it would take to deploy an existing event broker on the Internet as a Web service that could be easily accessed by other Web services and applications.

An Event Broker Overview
Let's begin with an overview of a hypothetical event broker that offers a basic set of services such as event advertising, event filtering, and event forwarding.

Advertising Events
The event broker features a catalog repository that contains metadata describing events exposed by the various event producers. A management agent, a relational database, and a file system folder are all examples of event producers. Metadata stored in the catalog is structured as a collection of namespaces. A catalog namespace contains a schema and a collection of other namespaces. The schema of a namespace consists of classes that describe events available from event producers that chose to advertise their events in that namespace.

A fragment of the catalog namespace tree is shown in Figure 3. The catalog namespace that is expanded corresponds to a file system event producer. The schema of this namespace contains three classes, the names of which are self-explanatory. Each class may have several properties describing the corresponding events, e.g. the file system path of the file, its MIME type, and others.

 

Subscribing for Events
Given the path of a namespace and the name of an event class, an application can subscribe for events described by this class. First the application must retrieve a handle to the namespace from the catalog. Second, it must create an event filter. An event filter is a query defined in terms of properties of the event class. Third, it must register the event filter and an object that implements an event listener interface with the event broker (see Listing 1).

The listener object implements the IEventListener interface defined as follows:

public interface IEventListener
{
public void handleEvent(IEvent event);
}

When an event matching the filter is detected by the event broker, the handle Event() method of the listener object is invoked. It receives the event object as an argument. The event object contains properties describing the event.

Sending Events
An application sending an event must first create an event object and then use the raise() method of the event broker API to broadcast this event to event consumers (see Listing 2).

I make no assumptions here about the mechanism used by event consumers and event producers to access services of the event broker. In this hypothetical example, they use these services by invoking methods of interfaces that are implemented by local or remote Java objects. In the next section we show how these interfaces can be mapped to a publish/subscribe Web service that can be easily invoked from a program written in essentially any programming language and running on practically any platform.

Publish/Subscribe Web Service
Two Styles of SOAP Encoding
There are two ways to encode information in the body of a SOAP message - either as an RPC call or as an XML document. The style of encoding is controlled by a switch in the WSDL contract for the service. The body of a SOAP message sent to an operation declared as

<soap:operation soapAction="uri" style="rpc">
.. .. ..
</soap:operation>

is encoded as an RPC call while the body of a message sent to an operation declared as

<soap:operation soapAction="uri" style="document">
.. .. ..
</soap:operation>

is encoded and interpreted as an XML document. There are strict rules governing how parameters of an RPC request shall be encoded in the body of a SOAP message. Document-style encoding, on the other hand, is very nonrestrictive and allows virtually any type of XML documents. When flexibility or extensibility is desired, document-style encoding is generally preferred.

Event broker methods used to manage event subscriptions are static in nature. Therefore, we can safely map them to operations with RPC encoding. The raise() method, on the other hand, is very dynamic. Event objects passed to this method are defined by classes stored in the catalog repository. We cannot afford to recompile an application every time someone adds a new event class to the catalog. Therefore, we choose document-style encoding for the raise() operation.

Format of Event Messages
As the first step, we define the XML format for encoding events in a SOAP message (see Listing 3). In order to reduce the number of network round trips, multiple events are encoded as part of a single SOAP message. Each event is mapped to an XML element whose name corresponds to the name of the class describing the event. Different namespaces in the event broker catalog may contain event classes with identical names. Therefore, we must properly qualify names of event elements by placing them in different XML namespaces. We derive the URL of an XML namespace containing the name of an event element from the path of the catalog namespace containing the corresponding event class.

The mapping is very simple. If the path of a catalog namespace is "Root/File System," then the URL of the corresponding XML namespace is "http://eventcentral.co m/Root/FileSystem". Properties of event objects are mapped to elements nested in the event element. All property values are encoded as strings. The original type of a property is indicated in the value of the "xsi:type" attribute.

Event Processing
We can now develop the portion of the public/subscribe service that deals with events submitted over SOAP/HTTP by external applications. It will be implemented as a servlet extending the JAXMServlet class defined in JAXM, one of the standard Java APIs for Web services. The onMessage() method of this servlet can be written as shown in Listing 4.

The SOAPCodec.decodeEventList() method is used here to convert event objects from XML elements to Java objects that can be forwarded to the event broker runtime via a Java interface.

Once we implement this portion of the service, we can compose some very interesting scenarios. Consider, for instance, the configuration presented in Figure 4.

 

With the help of a servlet capable of processing events encoded as SOAP messages, we can build an event gateway that allows applications located outside of a company firewall to send events to subscribers deployed on the internal company network. When an outside application submits a SOAP message to the gateway, these subscribers will receive MQSeries, MSMQ, or JMS messages.

Event Forwarding
At this point we can receive events over SOAP/HTTP and translate them to events in the event broker runtime system. As the next step, we enable the publish/subscribe service to forward events received from the event broker to external Web based event subscribers. We can accomplish this by implementing an event listener class (see Listing 5).

The publish/subscribe service is now virtually complete. Web-based applications can use it to send and receive events. In addition, it can play the role of a gateway translating event messages between SOAP/ HTTP and messaging protocols used on local networks such as MSMQ, MQSeries, or JMS (see Figure 5). Subscription management is the only building block that is still missing.

 

Subscription Management
As I mentioned earlier, we decided to use RPC encoding for the subscribe() operation of our service. We can now define a WSDL contract for this operation. Once the contract is ready, we can use a WSDL compiler to generate client-side and server-side stubs for automatic encoding and decoding of SOAP messages.

Writing a WSDL contract by hand is not for the weak of heart, however. A typical WSDL document is written in cryptic XML and consists of many interrelated sections. It's easy to make a mistake while preparing it manually. Fortunately, most Web services development kits are capable of generating a WSDL contract from an interface defined in a conventional programming language such as Java or C#. We will take advantage of this capability and define the subscription management interface in Java as shown in Listing 6.

An application can subscribe for events from the publish/subscribe service by submitting a collection of subscription objects. Every subscription object carries a number of properties: