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

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 cannot see why a feature should be made mandatory if it is both
unnecessary and incomplete.

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

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.

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Tuesday, 13 July 2004 11:58:35 UTC