Re: Action Item 2004-07-01 Solution to 168/R114

Amelia A Lewis wrote:

>On Tue, 13 Jul 2004 21:21:36 +0600
>Sanjiva Weerawarana <sanjiva@watson.ibm.com> wrote:
>  
>
>>I'm +1 to leaving dispatching out of band on the basis that
>>its the server's business to know how to dispatch and the WSDL
>>is what the server has decided to tell *the client*. There's no
>>need for the server to tell the client how *it* does its internal
>>work.
>>    
>>
>
>Thank you for being so precise in making the distinction.  This was, in
>fact, precisely the rule used in determining what characteristics of MEPs
>our spec should describe.
>
>I agree with the sentiment of the folks who really, really *want* to see
>the dispatch made visible; coding around the dispatch problem strikes me
>as one of the most painful of tasks.  However, I cannot agree that it must
>be made mandatory, because it leads rapidly into loss of meaning, into
>definition of features that "fulfill" the requirement by definition, but
>not by content.
>
>
>I'm going to quote myself, from an internal memo recently sent around:
>
>The operation-qname is encoded into the message in some fashion.  What
>follows are known possibilities for encoding (this is known by the
>shorthand "the dispatch problem"):
>
>1) by assigning unique types to each message in a portType/interface,
>allowing them to be disambiguated by schema
>
>2) by using RPC style, which wraps the content of each message in an
>element named for the operation
>
>3) by placing a particular value into a header in the protocol envelope,
>which is mapped (typically in the WSDL) to a particular operation
>
>4) by placing a particular value in a SOAP header (WS-Addressing defines a
>header for this purpose)
>
>5) by placing a particular value in a particular element in the message
>body (considered bad practice, but widespread, especially for stuff
>converted from HTML forms hitting a database)
>
>6) by encoding the operation name, or an identifier that is intended to
>map uniquely to the operation name, in the URL
>
>[end self-quote]
>
>Note that these are "known" patterns, meaning that I've seen them in
>customer WSDL or deployment.  Each of these could be encoded as an
>dispatch algorithm URI, and offered as a possibility to go into a feature.
> Several other possibilities have been mentioned on this list.  Note that,
>in asynchronous protocols (that is, protocols in which a single message
>exchange is not implicitly correlated and addressed via the use of an
>existing open socket), the dispatch problem crops up for messages after
>the initial message.
>
>The only solution that I have seen for this is to *allow people to do
>their own dispatch*.  Sure, tools can be offered to implement particular
>patterns (SOAPAction, first child of SOAP body, WS-Addressing Action,
>etc.), but, as Sanjiva correctly points out, it is *not necessary* for the
>node interacting with the service to understand what it is that the
>service uses to dispatch on.  Further, any enumeration of possible
>dispatch algorithms is guaranteed to be incomplete.
>
I am afraid you are skewing the requirement a bit. The problem is not 
really exposing how the dispatch is done, the
problem is exposing to the client enough information so that it knows 
how to construct messages AND headers so that dispatch can be done by 
the receiver. I have said this many times in this thread that there are 
many ways a service can implement it, the question is what the client 
must know to enable the dispatch. If your view of the world is that WSDL 
does not contain the contract and there is some other out of band 
mechanism to communicate this information, then we are arguing about a 
different problem.

If the client needs to generate extra headers, use SOAP Action, etc. it 
is darn clear in the WSDL if it is declared. That is ALL I am proposing 
that we DO.

As you pointed out at some point in this discussion, there are different 
ways even messaging vendors may implement their own dispatching 
mechanism. Some may use the topic in a pub/sub where they may be able to 
utilize the operation name. If there is a dependency on this, 
declaration of this information in WSDL allows these systems to be able 
to plug in as back ends to web services. Why should we disable different 
implementations?

>
>I cannot see why a feature should be made mandatory if it is both
>unnecessary and incomplete.
>
Why is it incomplete? I am suspecting you are referring to the dev/null 
feature.

>
>It is certain that WSDL authors faced with this sort of requirement will
>define some sort of null-feature URL to bypass it
>(http://localhost/dev/null: the ultimate embodiment of safe operations,
>and completely self-describing too).  Given an open enumeration (that is,
>given that the "mandatory feature" can be fulfilled by anyone who wishes
>to define a URL), someone will define a URL that effectively says "none of
>your business, okay?" and, in effect, make the feature optional. 
>file://localhost/dev/urandom 
>ftp://ftp.station.gov.acent/rules/2204/immigration/handbook.xml 
>blackbox:opaque.  Since client toolkit authors, examining the situation,
>will rapidly discover that they don't have to care what the dispatch
>mechanism on the service side is, they'll ignore this.  "Yup, yup, I
>understand blackbox:opaque, no worries."
>
That is perfectly fine with my proposal. Let me give you an example.

Lets say that your dispatching is done by inferring from the content of 
the message. There is some magic that happens that interprets the 
content and does the dispatch (not by the type) but actual content of 
XML documents. The client needs to do nothing additional here. If it 
does not need to generate additional headers, etc. Fine for the client. 
 From its perspective, knowing the blackbox:opaque, it abides by the 
contract.

I was assuming that you did not require additional header support but 
the rest of the message says something different below.


>And finally: the means of dispatch may actually be dependent upon the
>protocol in use.  Again, it just doesn't matter to the node that is
>interacting with the service; the WSDL supplies enough information that
>that node can construct a correct message, which is likely to include
>*something* that the service will dispatch on.  But this means that
>blackbox:opaque is as much information as can be provided in the
>interface.  Perhaps, using SOAP, we'll use a SOAP header, but using NNTP,
>it's stuffed into an X-Extension header, and using JMS, it's a combination
>of destination and the content of a property.  I do not see that the
>dispatch mechanism used by a particular service is appropriately defined
>in the abstract interface.
>
Ah, but now your defn of the block box is no longer a black box unless 
you say that your extension maps into the specific headers for the 
bindings you describe.

Who stuffes the information in an SOAP Header? Who stuffs the 
information in an NNTP header? If you are the provider of both the 
client and service's tools, you are fine. You don't have to do anything. 
You are the ruler of the world and you don't give a damn about interop. 
However, my client tools will not know which headers to stuff info on. 
However, if

-- you have declared your blackbox extension in the WSDL
-- told the world in your spec of blackbox that you will use a soap 
header for SOAP, X-Extension for NNTP, whatever


My client can interpret the URL and will know how to operate with you 
because it knows which headers to use for specific protocols provided 
that you were a good citizen and wrote it in some extension spec. ;-)

>
>Amy!
>
So, the idea is not to restrict/expose how to dispatch. It is to expose 
to the client what the client must do. Dispatching is web service's 
business, exposing the necessary contract is WSDL's.

--umit

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com