RE: Issue: Should Operations permit alternate and multiple responses

Sanjiva, There were a bunch of ideas or issues you
expressed that I was partially reacting to. One
was the idea of generalizing existing groups 
(like request-response-operation) to service-type.
I am thinking that this may not be a good idea
because it seems to violate layering (assuming
that choreography notations can layer over interface
and binding info). 

Consider the idea of the "request-response" business
process. For peer-to-peer distributed systems, the
"natural" mapping for request-response is onto two
nodes each with an interface, each
with an OUT (or if you prefer to switch polarities, IN)
orientation. RosettaNet and ebXML asynchronous request
response designs would probably map most cleanly to
interfaces written up that way. However, it may be
of no interest to the WSDL interface group to make
its descriptions available for use in more peer-to-
peer orientations. [I don't see why not myself,
but I am still trying to understand what this group
really sees as its scope, and the charter is of limited help.]

I think there is something like "interface orientation" idea
that might be useful to capture. I don't think it is necessarily
equivalent to service-type, but if the possible interface
orientations were enumerated, then choreographies could link
up appropriately, even ones like BPSS and BPMI.

For the narrower issue--what to do about the unused interface
orientations--that seems to me a scope decision. For web services,
the IN-ish orientations are all that is really needed. For 
a more general approach to distributed interaction and
collaboration on the internet, I could see leaving all orientations
documented. Now if the scope is to build an adequate notation
for representing XML based data exchange, I think provision
for more peer-to-peer notations should be left in. If the idea
is document the XML inputs and outputs to a web server subprocess,
then maybe scrap the other interface orientations.

My preference is for a bit more generality in the interface language.
Eventually is OK, if the 1.2 version would not allow this. But
I could see depreacting the 1.1 operation type names and getting
a more neutral way of describing the interface orientations.

Also, since I wrote this, it occurred to me that IN, OUT, INOUT, and
OUTIN might also be poor choices for names of
operation types because people
might mix them up with formal 
parameter qualifiers that indicate
call-by semantics. So, some other naming
systems for interface orientation might
be formed by combinations of:
initiate versus receptive
simplex versus half-duplex (half-duplex, because I assume when there
is both input and output on a receptive interface, that they
are implicitly sequenced).

Anyway those are the semantic elements for asssembling names
that would seem more neutral.



-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Monday, April 29, 2002 12:40 PM
To: Dale Moberg; www-ws-desc@w3.org; Prasad Yendluri
Subject: Re: Issue: Should Operations permit alternate and multiple
responses


I agree that WSDL 1.1 already has slipped down the slope a bit.
The rationale was that the cases of sending a message, and that
of sending and receiving a message were pretty much fundamental
and justified special syntax. The output-only and solicit-response
were just the flips of those.

I find it hard to accept that one message in and two out is such
a fundamental pattern.

I'm not sure what side you're supporting Dale: Do you want WSDL
to have special syntax for supporting such patterns or to leave
that out of scope? My preference is the latter.

Prasad: Since you raised this, do you still want this inserted
as an issue? If so I will and we can discuss it later if you wish.

Sanjiva.

----- Original Message -----
From: "Dale Moberg" <dmoberg@cyclonecommerce.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>; <www-ws-desc@w3.org>
Sent: Friday, April 26, 2002 10:52 PM
Subject: 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 Tuesday, 30 April 2002 13:31:07 UTC