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

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.

> 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 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?

> > 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?

> 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"?

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:

1) Whether the operation name itself must appear in the message.
2) What "operation's fragment identifier" means about what goes into a
message.
3) How a service that simply used unique GEDs for each message would
interact with this feature.
4) What is the implication of a built-in required feature on the syntax
and the component model.
5) Why is an explicit feature URI useful if the feature represents a
static quality of any working Web service.

Received on Monday, 23 February 2004 16:40:41 UTC