RE: Describing which blobs are to be optimized.

Hi Hugo, Marc:

The interesting part of this, if you interpret it as Hugo has below, is
that a feature marked optional at the operation level might imply that
the response from the server is in a format that a client who does not
understand that feature cannot accept.  With respect to MTOM/XOP over
HTTP, I would think we could use the "accept" header to indicate the
client's ability to accept optimized responses, but the general case is
perhaps more interesting.

The way we've been talking about it up until this point is that optional
features are optional in that the originator may or may not engage them,
but the server must support them.  In other words, if a WSDL specifies
that a security feature is optional for a given SOAP binding, and you
want to implement a service that uses that binding, you must understand
and accept whatever rules are specified by the security feature.  No
such requirement exists on the client, though - that guy is free to
simply ignore the feature declaration if it's optional.  This way of
looking at it is focused on the originator making the decision to engage
the feature, not the server.

If we want to allow "server engaged" optional features, I think we get
into the same kind of pattern which might require the client to
understand them in order to claim full understanding of the WSDL.  If I
can say that the server *might* send back an encrypted response, then
mightn't the client need to understand the encryption mechanism in order
to successfully communicate?

We can deal with this in a number of ways.  First, the simple way -
optional extensions may be ignored by clients, but failures may always
happen at runtime, perhaps as a result of a server engaging something
which was marked optional.  To some extent this can happen anyway, in
that a given service may decide to use an extension that wasn't
mentioned in the WSDL, but putting in optional extension declarations at
least gives both sides more of a clue as to what is supported.  I think
this is pretty much status quo.

Second, we could add something like a "mustUnderstand" attribute to
feature/module declarations, which indicates that anyone using the WSDL
must understand the given extension, but that the usage of that
extension is still optional unless "required='true'" is specified.
Required extensions would remain as they are - where both usage and
understanding are mandated.  This would allow specifying features which
may or may not be used, but whose use affects the syntax/semantics of
the exchange enough that failure to understand them would completely
screw things up in the event they were used.

In general, I think we need to be as crystal clear as we can be about
which kinds of extension declarations might affect which portions of an
interaction described by WSDL.  That said, a third option entails making
sure we have the expressive capability to indicate that a particular
extension may be in use, and which side(s) of an interaction may use it
- which probably involves the kind of things Hugo discusses below (i.e.
it's pretty clear that an optional feature on the <output> of a given
request-response interaction is going to be something the server may
do), combined with clear text which tells us what it means when
extensions are used at the higher levels.

This is just some off-the-cuff thinking.  We probably want to talk about
this on a call soon or at the F2F.

--Glen

> -----Original Message-----
> From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org] On Behalf Of Hugo Haas
> Sent: Monday, June 07, 2004 10:16 AM
> To: Marc Hadley
> Cc: Jonathan Marsh; www-ws-desc@w3.org; xml-dist-app@w3.org
> Subject: Re: Describing which blobs are to be optimized.
> 
> Hi Marc.
> 
> * Marc Hadley <Marc.Hadley@Sun.COM> [2004-06-04 16:03-0400]
> > On a related note I'm unclear on the semantics implied by 
> marking the 
> > MTOM/XOP feature as optional. I can see several interpretations:
> > 
> > (i) a service will never use it but a client may
> > (ii) a service will not use it unless client does first
> > (iii) a service will always use it but a client isn't obliged to
> 
> Section 2.7.1[1] specifies: 
> 
> | The presence of a feature component in a WSDL description indicates 
> | that the service supports the feature and may require a requester 
> | agent that interacts with the service to use that feature.
> 
> When the use of the MTOM feature is not required, it just 
> means that the service supports it, which means that the 
> requester agent or the provider agent may use it, depending 
> on the direction of the message
> 
> Your interpretations can be described with:
> 
> (i) the input message description has an optional MTOM 
> feature component associated with it, and the output message doesn't.
> 
> (iii) the input message description has an optional MTOM 
> feature component associated with it, and the output message 
> has a required MTOM feature component associated with it.
> 
> If an optional MTOM feature were specified on an operation, 
> both the requester and provider agent may use it.
> 
> I don't believe that (ii) is describable with WSDL 2.0. It 
> goes into the domain of policies, I think.
> 
> Regards,
> 
> Hugo
> 
>   1. http://www.w3.org/TR/2004/WD-wsdl20-20040326/#Feature_details
> --
> Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
>

Received on Monday, 7 June 2004 11:49:27 UTC