RE: Issue: Should Operations permit alternate and multiple responses

Sanjiva writes:

"I think this is a slippery slope .. clearly there are many message
exchange patterns in life. WSDL 1.1 picks a few "standard" ones
for direct syntactic support and leaves others upto richer
languages like orchestration languages.

"Adding support for multiple and optional outputs can be done with
allowing messages to be defined in terms of messages too. Again,
that's another slippery slope ... where does WSDL end and orchestration
start?"

At the face-to-face meeting, several people emphasized their
desire to have a clean demarcation between WSDL interface
definitions and bindings and also a clear line between the
the WSDL interface definitions and choreography notations.

I think the blurring of the boundaries (or the beginning of the
slope) for the choreography/interface topic begins with the current 
terminology of operations--one-way-, request-response-,solicit-response,
and notification-operation. These are just groups of various
combinations of wsdl:input, wsdl:output, and wsdl:fault, and
the particular semantic flavor of the current group names,
suggest that interface definitions are being defined 
reflecting semantic peculiarities from the viewpoint 
of the invoking environment (that is, semantic wisps of
some choreography). But no one knows how large the list
of semantic primitives for these choreography types really
is or even what among them will be needed eventually.

If terms like "InOut," "In" "Out" (and "OutIn" I guess) had
been used instead, no one would be tempted to say that we were
trafficing in cryptic choreography semantics. In addition,
we could be noncommittal about just which semantic choreography
primitives are needed, how they work, what they mean, and
how many have to be documented by the release of 1.2. As
interface types, "InOut" and so on, seem pretty familiar
from IDL specifications already, and people would expect
what they actually get.

Received on Friday, 26 April 2002 12:52:45 UTC