RE: 2004-02-12 Action Item: Clarification to the OperationName feature

RE: 2004-02-12 Action Item: Clarification to the OperationName
featureBonjour, Jonathan (just getting ready for next week):

> Jonathan wrote:
> > > Unique message element QNames is a reasonable way to
> ensure that a
> > > service can dispatch a message to the right operation.
> > >  But as I understand it, such a mechanism would not satisfy the
> > > OperationName feature, which would require extra (and
> unnecessary in
> > > this case) goo to be squirted into the message.
>
> Glen responded:
> > Hm, I think you are missing something here.  Making the
> operationName
> > feature an ABSTRACT feature was precisely so that we can allow
> multiple
> > different ways of satisfying it.  One of these ways is
> using the RPC
> > style, for instance - that does not require any "extra goo" in the
> > message at all.  It simply says "when using this style, the
> feature is
> > satisfied because the QNames are unique".
>
> I don't want to be argumentative, but no it doesn't.  It specifically
> says: "If an operation is defined using the style property
> indicating RPC style, the Name of the operation is required
> to be part of the message exchanged, because the QName of the
> input element must match the operation targetNamespace and
> NCName and it uniquely identifies the operation. Therefore,
> the operations within interfaces that utilize the RPC style
> are considered to be compliant with this feature as operation
> names are part of the GED. However, if bindings support one
> of the implementations as stated above, the additional header
> defined by OperationDispatch module is allowed to be
> included, but not required, when RPC style is used."
>
> My paraphrase differs from yours, and says that the feature
> is satisfied because the operation names _are_ encoded in the
> message.  Just using unique GEDs on your messages doesn't
> constrain the GEDs to match the operation names, and
> therefore fails to satisfy the feature.

Sorry, yes, you're quite right, I didn't phrase that as well as I might
have.  It's not the uniqueness of element QNames that matters in the
RPC-style case, but their precise equivalence to the operation QNames.  The
case below is different.

> > We could also imagine another
> > feature or style whose spec said essentially the same thing without
> the
> > other RPC rules about schema structure.  But you still want
> SOMETHING
> in
> > the WSDL to describe what's going on - a hint to the processor that
> says
> > "hey I'm asserting that all my QNames are unique, so you
> can feel free
> > to fault if you discover duplicates".
>
> Like I said, that might be a good idea (indeed that's what I
> thought this proposal going to look like), but I don't think
> that would satisfy the OperationName feature, which says:
> "OperationName feature is an abstract feature that indicates
> that the Name of the operation will be conveyed to the
> receiver in a message exchange."  Later on there's some stuff
> about an "operation's fragment identifier" but I can't make
> much sense of that so I'm taking the _Name_ as the thing that
> must go into the message.

I think that a feature as described above (unique element QNames but not
exactly those of the operations) would still carry that same information,
but it would do it through the isomorphic relationship of the element QNames
to the operation QNames.

> > > I agree that a service needs to be able to know what to
> do with any
> > > particular message.  That's built into my assumption about how to
> > > build any Web service.  But constraining the solution to this
> > > problem to the particular strategy of inserting the
> Operation Name
> > > into the message doesn't seem right.
> >
> > Agreed, and the feature doesn't say that you must insert it
> into the
> > message explicitly in any way.  It just says that the
> information MUST
> > somehow be transmitted from the sender to the receiver.
>
> Ah, OK, if we're not constraining the message in any way I
> have less concern.  The proposal text should make that
> clearer.  The logical extreme of what you're saying is that I
> can actually satisfy this feature by sending messages that
> are indistinguishable on the wire and the server can use
> extra-sensory perception for all I care to tell them apart.  Right?

Yup, exactly.  The key bit is that anyone processing the WSDL has to
understand the way this is being done, which simply means understanding that
"my-esp-feature" is a valid way to implement the operationName feature.

> > > In any case, if functionality is always "required", there doesn't
> > > seem to be much point in giving it a feature URI that can
> appear in
> > > the markup and will appear in the component model,
> instead of just
> > > using text in the spec.
> >
> > Two reasons.  First, for consistency, since it is a real feature.
>
> Currently, a feature in WSDL can be engaged or disengaged.
> This feature is apparently always on, from which I infer that
> it always appears in the component model.  We don't have that
> concept in WSDL right now, which is why I'm probing at this
> point.  Since it doesn't fit into our current framework,
> perhaps it shouldn't be shoehorned into that framework.  And
> if the framework needs expanding, aren't there lots of other
> qualities/attributes/features/functionalities of a working
> Web service that should be treated this way?

I don't think there's any "shoehorning" needed here.  We could certainly do
this by saying "this is a required semantic which we aren't going to name,
but you have to do it somehow".  The problem with that approach is that it
becomes difficult to indicate in a binding/extension/etc that "I do *that*
thing".  This is precisely what features are for, and if it looks like a
duck, and quacks like a duck....  Making it a "built in" feature is
certainly a first, yes, but doesn't seem that odd to me.

> > Second, because giving it a URI allows other specifications to be
> > written (i.e. the operationName SOAP module, or another
> binding which
> > might include operation names in some transport-specific way) to
> > unambiguously refer to the semantic we're talking about.
> That's the
> > whole point of naming it.  As a side benefit, you can also make RDF
> > assertions about the feature once it has been given a URI.
>
> I can't think of useful reasoning.  It can't be turned on or
> off, and so can only be usefully referred to as a static
> quality of a correctly working Web service.  You can already
> make statements about a WSDL-conformant Web service by using
> the WSDL spec URI - this assertion could easily be part of
> that assertion.  Or are you suggesting we give URIs to each
> quality we can distinguish, for instance "this service
> exchanges messages"?

I'm not sure if I'd go that far, but certainly MEPs and the like (which we
do call out) are things you might reason about.  And it's not so much that
you'd be reasoning about a particular service, but more likely that you'd be
reasoning somehow about the feature itself.  Let's say someone wrote a
feature which actually satisfied all the rules of the operationName feature,
but didn't note that in their spec.  You could make an RDF assertion that
said "feature A implements the operationName feature", and that would enable
anyone who understood that assertion to use feature A as such an
implementation.

> My purpose here is to clarify the proposal so we can make
> faster progress on it - I hope you take my questions in that
> spirit.  To recap, some things that aren't clear in my
> reading of the proposal:

I need to go and read Umit's version of the proposal again, actually - some
of my statements here are based on an earlier take, so I should vet them
against the version on the public list.  I'll do that ASAP.  All the answers
below should be considered prefixed with "IMO".

> 1) Whether the operation name itself must appear in the message.

Not as such, no.

> 2) What "operation's fragment identifier" means about what
> goes into a message.

I think that's referring to the fact that operation names are in fact QName
*tuples* made up of the interface QName and the operation QName, therefore
there are really two QNames you need to uniquely identify an operation.
 Hm - this might actually be a problem, in that the "unique GEDs" or
RPC-style approaches do not actually carry the interface information... but
I guess the claim there is that the GEDs are unique for all operations in
the aggregated interface, no matter which parent interfaces they come from,
so it's still a good mapping.  We should change the description of how RPC
style works to account for that.

> 3) How a service that simply used unique GEDs for each
> message would interact with this feature.

You *could* state that the "default" implementation of the feature is to
simply map unique GEDs to their operation names, and then it would only be a
problem if you a) didn't find anything else in the WSDL (a SOAP module /
binding) which implemented the feature AND b) there were in fact duplicate
or undefined GEDs.  I would prefer an approach which forces the WSDL
developer to somehow explicitly assert (via a style or a feature
declaration) the claim that all the relevant GEDs are unique.  This is kind
of the same reason we have the RPC style - you *could* figure it out on your
own by just looking at the schema, but the style helps you decide up front
how you want to deal, and whether to bother engaging potentially expensive
checks.

> 4) What is the implication of a built-in required feature on
> the syntax and the component model.

No impact on the syntax, and the component model gets a single required
feature component which is always assumed to be there, I think.

> 5) Why is an explicit feature URI useful if the feature
> represents a static quality of any working Web service.

See above.  First so that you can say "hey, this here new module does *that*
thing" and second so that you can unambiguously refer to the semantic in
whatever way (RDF) you want.

--Glen

Received on Tuesday, 24 February 2004 13:17:03 UTC