RE: PROPOSAL: Drop interface/operation/(input|output)/@headers

If Glen were still here in my office I would have gone over to him this morning and probably whacked him on the head.  :-)

The syntax for declaring a property that is a header, after declaring that you are using the feature that *is* headers, is NOT simple.

The syntax that we have now is pretty straightforward.  I know what data is going to be in the (implementation defined) headers.  I have declared what the XML representation of the header is going to look like, probably using XML Schema.  My tools or my program can put together a request with headers and body data, probably in a SOAP envelope, without too much trouble.

As to whether the headers belong in the abstract interface to my server or not, I don't think that we should waste time talking too much about that.  Yes, I will need to know what the headers are for, or more specifically what *values* to put in the headers.  BUT THAT IS OK.  I don't think I need a feature spec if I want to require an identity key for my web service.

I don't think we want to remove headers and force users to dive in to F&P in order to do headers.

--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Glen Daniels [mailto:gdaniels@sonicsoftware.com] 
Sent: Tuesday, October 28, 2003 12:13 AM
To: Roberto Chinnici
Cc: 'Sanjiva Weerawarana'; www-ws-desc@w3.org
Subject: Re: PROPOSAL: Drop interface/operation/(input|output)/@headers


Hi Roberto!

OK, a little more on this tonight, then bed.

> > Correct.  Essentially, the only kinds of headers that are worth
specifying
> > with the mechanism that exists today are the "cookie-esque" ones - i.e.
> > "please send me the value 'xq57jb' back in the header
'myns:SeekritCode'.
> > Oh, and send it on every single message, too."  Anything with more
complex
> > semantics than that can't really be accommodated with the current
syntax.
> > So I think it's a pretty simple matter to define a "sideband data" SOAP
> > module which simply takes a property consisting of a set of elements,
and
> > inserts them as SOAP headers.
>
> My head is spinning dangerously fast right now. Can you write down an
> example? I don't quite see how you'd translate the declaration of a
> header ns1:bar of type ns2:Foo into propertiese (or featurese, the
> language). In a SOAP-independent way, if possible.

The simple way to do this, I think, is just to associate the name and type
QNames, by defining a well-known property which has a schema something like:

<element name="element" minOccurs="1" maxOccurs="unbounded">
 <complexType>
  <attribute name="qname" type="qname"/>
  <attribute name="type" type="qname"/>
 </complexType>
</element>

So you'd express it thusly (namespaces assumed to be already mapped):

<property uri="http://features.com/SidebandData/elements">
  <value>
   <element qname="ns1:bar" type="ns2:Foo"/>
   ...
  </value>
</property>

(yes, I know we can't do exactly this with present syntax because of the
simpleType restriction, but I've argued against that already and I'll
continue to do so :))

This is pretty SOAP-independent, although I was imagining a SOAP-specific
solution.  I can see wanting to pass simple values as SOAP headers - I find
it more difficult to imagine having some generic mapping of those same
things to either SOAP or HTTP headers, but maybe.... In any case, this is
semantically equivalent to defining an element and then using @headers.

Honestly, though, I think this sort of usage of SOAP headers is
inappropriate, since the client doesn't really know what they're sending,
and therefore doesn't fully understand the QNames they're putting in the
envelope.  I'd much rather see a *particular* SOAP header be defined for
this kind of "cookie-esque" behavior, and then the content of that header
could be arbitrarily described by WSDLs.  I can also see such a "cookie"
feature having an obvious mapping to HTTP....

> > There are two ways of thinking about the current way of dealing with
> > headers.  First, I can describe a given header QName and leave the value
up
> > to the user - in this case, I am trusting the code or the user to
understand
> > what the appropriate value is to stick in there, which is exactly the
same
> > thing as asking them to understand a feature/property/policy identifier
(the
> > semantics are external).  Aside from the fact that this is a really bad
way
> > to do things (you can't easily specify extensions for which certain
headers
> > may or may not appear depending on context, for instance), the work
involved
> > is the same as in the F&P case.
>
> Not quite. I can describe a header qname and type and leave the
> semantics up to the user. This is exactly how operations are dealt with
> -- cheaply and effectively. Do you want to have more semantics in the
> WSDL itself? Use RDF or your favorite formalisms and sprinkle it on
> the document as extensions. I'm worried by F&Ps requiring users to
> provide specifications for a feature, its properties and their
> binding-specific realization(s) to do the equivalent of @headers.
> It sounds like an awful lot of work.

I'm not asking for more semantics in the WSDL, I'm talking about exactly the
same level of description as you are in this case.  You define a named thing
(a feature/property uri or a header/operation qname) and you expect the user
(or software) to understand it, where "understanding" is dependent on an
external definition.  When you say "up to the user" you really mean "up to
the user's specification", no?  Without some kind of specification, how else
do I know what the heck to fill in for the <robertoNS:widget> header's
value?

As for the amount of work, I think for the more realistic case where there
are actual semantics associated with the SOAP module (not just random
headers with static values), the work is identical with F&P as it would be
with @headers - and in fact it may well be less, since setting a particular
property might cause two or three headers to appear in a given message,
which I'd assume you would have to account for somehow with multiple
@headers...in fact you'd probably need to change the semantic of @headers to
say something like "these headers *might* appear in the message, but you
should read the spec to find out how and when to actually send them", which
puts us right back in policy/F&P territory.

> > Second, I can describe a particular value for a given header, as in the
> > "cookie-esque" description above.  There is arguably some use in this
sort
> > of thing (dispatch, for instance?), and as noted we could define a
normative
> > "sideband data" module to handle this.  It would need to be very clear
in
> > the spec for the module that you can use it to send/receive arbitrary
> > headers, and it's up to the user to make sure that the receivers are
capable
> > of correctly understanding those headers.
>
> OK, so it can be done. But is it desirable? I mean, it would make for a
> very odd feature! It almost makes F&Ps sounds like another extensibility
> mechanism parallel to the built-in one (the extensible content model,
> that is).

Is it desirable?  Sure, if people want a generic way of doing this type of
thing.  As mentioned above, I'd much rather see a "state/cookie" module with
a single well-defined header QName than some way of arbitrarily setting
header values that aren't necessarily truly understood by the senders.

And F&P *is* parallel to the built-in extensibility, as discussed at the
last F2F.  Anything you can do with F&P, you *could* do by defining your own
extension and simply writing the spec for that extension in terms of F&P.
And in a bunch of cases, people are going to do just that so that the WSDL
looks cleaner/nicer.  That's fine.

The generic syntax is useful for two reasons I can think of - first, because
it allows us to talk about features and properties as defined in SOAP
extension specs without the necessity of another layer of indirection
through WSDL extension specs as well.  Second, because you may want generic
processors being able to decouple the WSDL processing of features/properties
from the actual mechanisms used by the SOAP engines to implement the
relevant functionality.... Let me give you an example of that one.  Say I
have a WSDL processor built on top of a SOAP processor that has a direct API
for something like SOAP 1.2's Message Exchange Context: i.e.
context.setProperty(uri, value), that kind of thing.  I can imagine a WSDL
processor reading a document with <property> settings which cause the right
things to happen in the SOAP processor even without the WSDL processor
needing to know about the specific extension in play.

> >>BTW, I'd be interested in furthering the policy discussion a
> >>bit. In particular, your argument about @headers being
> >>useless without a policy would seem to extend to features and
> >>properties as well. Would you then argue for removing F&P on
> >>the same grounds?
> >
> > Not to speak for Sanjiva here, but I would say this doesn't make sense.
F&P
> > is a way of expressing policies, as well as controlling their
realizations
> > in on-the-wire messages.  The @headers syntax is simply a way to
> > mechanically control the structure of a SOAP message in a very blunt
> > fashion, which is why it's confusing and not as generally useful.
>
> Now it really sounds like F&P is a sort of policy framework scoped to a
> single operation only, as opposed to the whole service or even groups of
> interacting services. I guess I'm either on a path to understanding or
> hopelessly confused...  ;-)

Or perhaps both, like the rest of us. :)  I never said anything about a
single operation.  Features/Properties may be scoped in a variety of ways
depending on how you write the specs and the WSDL, which is why we allow the
F&P elements to appear in a variety of places.  If you set a property in an
<operation>, then that property is set for that operation.  If you set it in
an <interface> then it is set for all operations in that interface, etc.  If
you read the SOAP spec's model [1] of the world, you'll see it talks about
some properties being a result of a particular message exchange, and others
coming from a larger environment, which might include values scoped to a
session, a connection, etc.  Of the properties we are interested in (the
ones you can set via a WSDL description), the interesting scopes are the
same as the WSDL model - operation, binding, interface, etc.  However
nothing prevents you from having features/properties which are scoped in
arbitrary other ways.

For instance, I might have a WSDL which declares an interface that uses a
particular feature, and then constrains the value space of a particular
property.  Then a BPEL process which happens to use that WSDL might set a
particular individual value for the property throughout the lifetime of that
process.  As long as the values are compatible, that should work fine,
although we in the WSDL group don't have anything to say about how the BPEL
part works.

--Glen

[1] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#modprop

Received on Tuesday, 28 October 2003 14:37:33 UTC