pub-sub text

One way to handle asynchrony in web services is via a
"publish-and-subscribe" (pub-sub) message exchange pattern.  Pub-sub is a
traditional middlware mechanism used heavily in the application integration
industry because it allows good decoupling between senders and recipients:
message senders do not need to know in advance the recipients of the
messages.

The publish-and-subscribe message exchange pattern involves a source node
sending a SOAP message to an intermediate node (publishing), with the
intention that the intermediate node forward the message to a set of nodes
that have previously stated their interest in receiving a copy of the
message (subscribing). A subscriber node can respond to the received message
by sending back a response message, via the intermediate node, to the
publisher node. The entire message exchange can occur in a synchronous mode
(the publisher node blocks until it receives the responses) or, most
typically, in an asynchronous mode (the publisher node does not wait for
responses, and it might receive the responses later on a separate thread of
execution, or it might not need to receive any response at all).

A number of issues come to mind when sketching this SOAP exchange mechanism
against the Web services Architecture. Here are some of them.

- What is the role played by the intermediate node? The intermediate node
should be seen as a gateway and not as a proxy, so the intermediate node
cannot be a SOAP intermediary.

- What kind of MEPs are involved? Is it possible to identify a unique and
specific pub-sub MEP? Or does it make more sense to talk about the
combination of separate MEPs for the publisher-intermediate exchange and for
the intermediate-subscribers exchange? 

- What types of bindings are possible?  Is it also possible to bind to HTTP
the publish-intermediate segment and/or the intermediate-subscriber
segments?

- Which SOAP features need to be defined? Are extension headers required in
the SOAP
message, or can we rely on the underlying transport to carry return
addresses, correlation ids, etc.? Is any form of message routing needed?

- Pub-sub middleware often assumes the existence of message cacheing,
queing, store and forward, or other reliable messaging mechanism.  Thus
pub-sub 

- How should WSDL be extended to express pub-sub?

- How can web services pub-sub mechanisms interoperate with proprietary
middeware systems via gateways?

Specific implementations of pub-sub web services technologies include CORBA,
the proprietary message-oriented middleware from several vendors, and XML
"spaces" systems that implement "tuple spaces" using XML and HTTP.

Received on Thursday, 14 November 2002 15:07:33 UTC