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

On Thu, 15 Jul 2004 08:39:00 +0100
paul.downey@bt.com wrote:
> Hi Amy!
> 
> > As others have said on this subject, if someone wants to place some
> > details of how they are performing dispatching in the WSDL, that's
> > fine; I'm not opposed to an optional feature or extension of that
> > sort.
> > 
> > I'm strongly opposed to mandating this, because I've had to deal
> > frequently with customer-generated WSDL for which such a required
> > feature would be meaningless. Failing to deliver what the [potential]
> > users of the spec require strikes me as a Really Bad Idea.
> 
> So a WSDL interface describes two operations both with the same input
> message but with different actions and output messages. Would you expect
> something inside the message to describe the operation to be invoked?

There are several possibilities.  I do not know what they are, as a
consumer of the service.  I do not need to.  There may be additional
information carried in the headers of the SOAP envelope, in the headers of
the protocol in use, or there may be an out of band understanding that the
element "form name" selects the operation.

> Or could the dispatching be achieved from something out of band - it's
> raining, i've sent twenty messages previously, it's my birthday, the ISS
> is overhead, etc? If so, where would this policy based dispatching be
> described?

1) sure.  2) I don't know.  This is a case in which the consumer cares,
and the information is presumably communicated.

Note, please, that *most* communication between web services is not the
"initial contact".  Rather, web services, especially the ones using
noxious underdocumented facilities of this sort, are automating existing
processes (which at least improves the state of documentation for these
processes).

> i'm not totally against you all wanting to do such a thing, just want to
> know how far down this rabbit hole we're all headed.

I don't particularly want to do it.  I don't feel that I, as a
representative of my company, implicitly defending the use cases of our
customers, can accept a nonsense restriction.  In the case above, for
instance, when dispatch occurs based on artificial astronomical events,
someone creates a Stupid Feature called
"http://wsdl.requires.this.stupid.feature/" which has this documentation:

"Stupid Feature fulfills the requirement for a dispatch feature.  It is
not documented how it does so."

Whoopee.

Make it optional, and it's something that we can live with.  Make it
required, and you just force Stupid Workarounds because it is *not*, in
fact, required by all services.

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

Received on Thursday, 15 July 2004 12:04:38 UTC