Re: Primer example & ambiguity issue

Hey Glen,

On Fri, Nov 14, 2003 at 04:39:11PM -0500, Glen Daniels wrote:
> Hi Mark:
> 
> > And this is example 5-5; "doc style and the soap message"
> >
> > <?xml version='1.0' ?>
> > <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
> >  <env:Body>
> > <customerName>Kevin Liu</customerName>
> > <checkInDate>2002-09-01</checkInDate>
> > <checkOutDate>2002-09-10</checkOutDate>
> > <roomType>double</roomType>
> > <comments>the customer will be arriving late in the evening</comments>
> >  </env:Body>
> > </env:Envelope>
> 
> Hm - I'm not sure this example is actually valid anymore with our current
> design.  In particular, the message="" attribute of <input> and <output> takes
> a single QName of a GED.  Thus I'm not sure we support the ability to create
> SOAP bodies with multiple top-level children.  IMHO, this is a fine thing, but
> we may want to consider the ramifications carefully.

Yes, I spotted that.  I figured it was a minor editorial boo-boo.
It doesn't matter for my purposes though.  What matters about that
example is that it appears RESTful, as there's no operation in the
body (a slight oversimplification, but close enough).

> > But in the latter message, there's no operation visible.  What then,
> > would success or failure refer to, and where would that symbol be
> > located?  Or is it implicit in a spec someplace?  If so, where?
> 
> Heh.  We had this very discussion at the F2F.  Without the "uniqueness on the
> wire" constraint of a unique GED per operation, you need some other as yet
> undefined mechanism for looking at a given message and determining which
> operation is relevant.

Well, there ya go, you understand me after all. 8-) What you describe
there is most of what my "ambiguous interface semantics" issue is all
about, though my issue digs a bit deeper I think (into application
protocols).

>  The group bucked pretty hard against an enforced
> uniqueness constraint, so Umit and I are scheduled to write up a proposal for
> an abstract Feature description which passes operation information over the
> wire.  This Feature could be implemented in a variety of ways, such as a) using
> the RPC style, b) using soapAction, c) using a well-defined SOAP module to put
> an identifier in a header, etc.  The proposal may include wording to the effect
> that this feature would be, by default, required - which would mean that unless
> something in the description implemented the feature, the document would be
> invalid.

There's a *LOT* of gotchas there, regarding interaction with application
protocols, and remaining self-descriptive (or as self-descriptive as
possible) in the face of various & extensible messaging styles.  I
eagerly await your proposal. 8-)

> If you guarantee that there is some way of identifying the operation, you
> enable server-side skeleton builders to successfully build a framework for the
> service which knows how to dispatch correctly.

Not to mention that you enable firewalls to do their job. 8-)

> > Also, where's the "document style" style?  WSDL 2.0 only defines RPC,
> > and get/set.
> 
> The "document style" is the default (i.e. no style), and rather than making any
> specific claims about programming model hinting, it implies nothing in
> particular except that the messages infosets will look a particular way.  The
> other styles are there to hint that particular programming models were in use
> when this WSDL was generated, and that processors may wish to utilize that
> information.

Ah, I thought I heard that, but I couldn't see where that was specified.
Probably didn't look hard enough.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Friday, 14 November 2003 18:16:01 UTC