Re: [wsdm] MUWS - 2.1.2 Message Exchange Patterns

[Sanjeev Kumar <sakumar@attbi.com>]

Jeff Bohren wrote:
> 
> I have some practical experience in this area. I developed an
> asynchronous notification solution based on web services using XML/HTTPS
> (effort pre-dated the SOAP 1.0 standard). The system had a manager
> sending XML/HTTPS request to an agent which would then return an
> immediate response that the request was received. At some point in the
> future the the agent would send an XML/HTTPS request to the manager with
> the result of the original request. The agent could also send
> unsolicited notifications to the manager using the same mechanism.

This is exactly what I had in mind. At Resonate, we developed a very
similar management server and a network of agents which used XML-RPC
for communication messages, but used our home-grown comm protocol
over TCP, which made life easier than using HTTP.

> This solution requires that both the manager and the agent be able to
> act as either web service clients or servers. It seems clear that the
> "management agent" needs to be a web service server to support the
> simple request/response model and adding the capability to be a web
> service client does not introduce much more complexity. It also seems
> the a management system needs to be a web service client to support the
> simple request/response model. The problem is the making a management
> system also a web service server will add a lot more complexity and
> security issues.

Yes, agreed. The cases where the management system is a WS server is
rare though. The most typical case would be when it needs to
communicate with other domains, or to support a hierarchy of such
systems.

> In reality SOAP/HTTPS is a poor choice for asynchronous messaging. SOAP
> over a messaging system is a much better fit. But do we want to take on
> defining two different transport bindings for the first version of WSDM?

I think our focus for the first cut should be to a minimalistic spec
that works with SOAP/HTTP(S), even if we have to punt on supporting
asynchronous message semantics.

Sanjeev K.