W3C home > Mailing lists > Public > www-ws-desc@w3.org > January 2004

A scenario investigating questions of conformance and scoping

From: Amelia A Lewis <alewis@tibco.com>
Date: Fri, 30 Jan 2004 12:03:01 -0500
To: WS Description List <www-ws-desc@w3.org>
Message-id: <20040130120301.4c4b60d9.alewis@tibco.com>


After the discussion late on Thursday (at the face to face, or in my
case phone to face) on conformance issues (issue 79), I thought that I
would write up this scenario, to raise questions.

It's always the same question: should the WSDL processor proceed,
ignoring irrelevant stuff that it doesn't understand, or should it halt
because there is something in the WSDL that it doesn't understand, or
should it do-something-else when it encounters unknown information that
it does not understand?

In this scenario, we propose that there is a common installed base of
WSDL 2.0 tools, which, like WSDL 1.1 tools, implement the client/server
HTTP-centric SOAP-centric stuff.  That is, they know in-out, in-only,
http binding, soap binding.  Let's say, for the sake of this scenario,
that they ignore any optional extensions or features that they don't
understand.  All this looks good.

I'm not going to write a complete WSDL, but I'm going to summarize it. 
The scenario uses that old chestnut, the stock quote service.  So, there
is an interface that contains one operation, getQuote, which uses
in-out.  There is a soap-over-http binding.  There is a service,
containing an endpoint which uses that binding.

Now, someone has come along and created an email binding.  As it
happens, any email binding must provide a feature of some sort for
in-band message addressing (we won't use a specific existing
specification, but it could be used).  That feature/policy/functionality
is required for any email binding.  As it happens, the service owners
decide, initially, to use MEPs that they consider better-fitted to
email, so they create a second interface, which contains getStockQuote
defined as in-optional-out.  The email binding binds this new interface.
 It contains the required in-band addressing
feature/policy/functionality.  Since a new interface had to be created,
a new service is created, and an endpoint pointing at soap-over-email is

Okay so far?  Two interfaces, two bindings, two services.  One is the
"common case" using soap over http, the other uses the soap over email

Now, I have a client, and I grab the WSDL, and I start looking at it. 
My client is a common-case client; it doesn't know about the soap over
email binding or the in-optional-out MEP or the in-band addressing

Now, about half of this WSDL is stuff that my processor doesn't support.
 Can I use the WSDL at all?

Suppose that I grabbed the WSDL once before the addition of the second
service, and used it successfully.  Now there's a new service, with
stuff I don't care about, but I should still be able to use it,
shouldn't I?  If I'm going to use the soap-over-http endpoint, and
therefore the soap-over-http binding and the interface that it binds, I
understand all of that stuff.  I ought to be able to succeed, even
though there's great swathes of this WSDL that I don't understand.

Now, the service could make it easy by splitting out the whole email
service in a separate WSDL, and then I would succeed, if I got the
correct WSDL.  Suppose, though, that the service designers *didn't* want
to use a different interface for email; in-out is okay.  Now they can
create a soap-over-email binding that binds to the same interface as the
soap-over-http binding; instead of creating a new service, they create a
new endpoint in the same service pointing at the soap-over-email
binding.  Can my email-ignorant processor handle this?  Again, these
changes *haven't* changed my path through the wsdl: I can start at the
interface end or the endpoint end and create a path through the WSDL
that doesn't include any elements that I don't understand.

Should I report an error?  Give a warning?  Ignore the stuff that I just
don't care about?  Fail?  Continue?

Now, suppose that I've got a WSDL that has two interfaces, three
bindings (soap-over-email bound to the getStockQuote in-out and to the
getStockQuote in-optional-out), and two services, one with two endpoints
(soap-over-http and soap-over-email; in-out interface), one with one
(soap-over-email; in-optional-out interface).  Again, can I succeed,
with a client that only does in-out, soap-over-http?  What if I have a
client designed for mobile devices, that only does soap-over-email for
some reason?

If I create a WSDL processor that only understands the XMPP binding for
Simple Exchange for XML (a hypothetical SOAP competitor), and only
understands the (also hypothetical) in-multiple-out MEP, do I have a
conformant processor?  I can't understand any of the scenario WSDLs
mentioned above, not even the "simplified" sort which separates the
soap-over-http and soap-over-email variants into separate WSDLs.  But
for the bindings and MEPs that I *do* support, I'm conformant.

So, if I write a WSDL processor that doesn't understand *any* MEP or
binding, is it conformant?*  Is it possible to have a conformant WSDL
processor that cannot find a "path of understanding" through a WSDL?

* trick question, note: it is perfectly reasonable to design such a
thing, with pluggable MEPs and bindings.  So I could plug in in-out and
soap-over-http, and have the common-case processor mentioned above, or I
could plug in in-multi-out and sex-over-xmpp and have the odd processor
mentioned two paras up.

Should processors be asked to call themselves "conformant for MEPs(x, y,
z) and bindings(a, b, c)"?  But what about that completely modular
processor that doesn't natively support *anything*, but still provides
the complete framework, with plugins?

Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
Received on Friday, 30 January 2004 12:03:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:28 GMT