W3C home > Mailing lists > Public > xml-dist-app@w3.org > June 2002

RE: Web-friendly SOAP

From: Glen Daniels <gdaniels@macromedia.com>
Date: Mon, 17 Jun 2002 14:33:18 -0400
Message-ID: <CB1FF0A474AEA84EA0206D5B05F6A4CB01E9FD63@S1001EXM02.macromedia.com>
To: "'Paul Prescod'" <paul@prescod.net>
Cc: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>

Hi Paul et al!

Just jumping in here for a moment...

> When you use SOAP over HTTP you get one set of addressing mechanisms,
> message exchange patterns and semantics. When you use SOAP over UDP,
> SMTP etc., you will get a totally different set.

To some extent this is true, but the way you deal with it can be made easier by using certain patterns, already existent in the SOAP 1.2 spec.  See below...

> > ... This is better for everyone
> > than if ICE defines its own bindings to each protocol, as 
> is required by the
> > pre-SOAP ICE 1.0 standard (1998).
> Let's say that ICE has a "getFoo" method that takes a string 
> and returns
> an integer. How is that going to magically work on SOAP running over a
> protocol without request-response behaviour? (like the current binding
> of SOAP to SMTP).
> Do we expect every protocol binding to implement every 
> message exchange
> protocol?

Absolutely not, and the same is true with transport-provided security, reliability, etc...   Not every binding is going to natively provide every semantic.  This is precisely why we created the concept of "features" in SOAP 1.2 (part one, section 3).  The idea is that you abstractly describe a given semantic (either in english or by using a distributed state machine notation) in terms of a set of properties that go "in" (should be available) and "out" (are exposed), and then you can build other specs which concretely implement these features in EITHER bindings or modules.

Some salient points about this framework:

* Features, bindings, and modules are all named with URIs.  You can therefore refer to them in other specifications, or in machine-readable artifacts like WSDL documents or RDF assertions.

* It is possible to design software that dynamically decides, either through "design-time" interpretation of service descriptions or through run-time negotations, how to bind particular features (and the data associated with them) into concrete implementations.  A quick example of how this might work:

You have a description (WSDL) for a service you'd like to call.  It says something like this:
   <operation name="getStockQuote" mep="http://w3.org/2002/request-response-mep">
   <binding name="1" type="http://w3.org/2002/soap-http-binding">
   <binding name="2" type="http://w3.org/2002/soap-UDP-binding">

Your software knows that the "soap-http-binding" as specified in SOAP 1.2 natively provides the "request-response-mep" feature.  Therefore, if you make a call using this binding, the response is expected on the HTTP response stream, and life is good.  However, if you use the "soap-UDP-binding", we know (from the binding spec) that the request-response feature is NOT natively provided.  Your software, being the intelligent sort, has a SOAP module kicking around called "simple-correlation" or somesuch, which implements the request-response feature/mep with SOAP headers.  So it can be smart enough to engage this module and insert a header (probably with "mustUnderstand" set to "true") which specifies a correlation ID and an endpoint URL, enabling the guy on the server side, assuming he also has this module available, to get you a response.  (clearly there are a few missing pieces in here, this is just a quick overview)

> There is no doubt that non-HTTP transports and non-request-response
> models are also important. I just don't think that you can expect for
> that stuff to *automatically work* just by choosing to build on SOAP.

I believe that a framework for specifying and describing these sorts of things (MEPs, QoS, etc) and how they go from abstract specifications to "the rubber meeting the road" is a key (perhaps *the* key) element of the Web Services architecture which will assumedly arise from the WS-arch group.  This will clearly also very deeply involve the description language which arises from WS-desc.

Essentially, while there is no real "magic" (TAANSTAFL), by putting a clean framework around how we describe abstract interactions, perhaps we can enable various kinds of software to utilize descriptions, negotation, and common terminology to actually acheive this sort of thing.

Received on Monday, 17 June 2002 14:33:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:50 UTC