Re: Issue: Should Operations permit alternate and multiple responses

Done:

<issue id="issue-operation-patterns">
  <head>Should more operation patterns be supported?</head>
  We discussed this briefly at the April F2F (perhaps) but, I think
  it would be extremely helpful to permit alternate and multiple
  responses to a request. That is permit multiple output messages in
  an operation like we have multiple faults in an operation. It would
  then be helpful to make them alternate or sequence. That is, do all
  of them come back or just one of them.
  <source>Prasad Yendluri</source>
</issue>

Sanjiva.

----- Original Message -----
From: "Prasad Yendluri" <pyendluri@webmethods.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
Cc: <www-ws-desc@w3.org>
Sent: Tuesday, April 30, 2002 1:48 AM
Subject: Re: Issue: Should Operations permit alternate and multiple
responses


> >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.
>
> Please do. Thanks.
>
>
>
> Sanjiva Weerawarana wrote:
>
> > 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.
>
> --
> ---------------------------------------------------------------
> Principal Architect, ATG; webMethods Inc.,
> 432 Lakeside Drive, Sunnyvale, CA 94088-3793, USA
> Tel: (408) 962-5226 mailto: pyendluri@webmethods.com
> ---------------------------------------------------------------
>

Received on Monday, 29 April 2002 16:05:34 UTC