Re: Issue: Should Operations permit alternate and multiple responses

Like what Keith? The ones I know of are events and callbacks. What
else do you have in mind?

I never presupposed one usage of out-oriented operations; what I
have proposed is dropping them in favor of first-class support for
what they were intended to cover.

Sanjiva.

----- Original Message -----
From: "Keith Ballinger" <keithba@microsoft.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>; <www-ws-desc@w3.org>
Sent: Thursday, May 02, 2002 8:44 AM
Subject: RE: Issue: Should Operations permit alternate and multiple
responses


> >>So what I'm proposing is dropping the OUT operations
> and adding first class support for events (and whatever else OUT
> oriented stuff we find interesting).
>
> This presupposes that out operations are for events only. I'm begining to
think they have more fundamental uses.
>
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: Wed 5/1/2002 6:37 PM
> To: www-ws-desc@w3.org
> Cc:
> Subject: Re: Issue: Should Operations permit alternate and multiple
responses
>
>
>
> Hi Dale,
>
> I'd like to shelve this discussion until we start discussing
> this issue. I'll address one point because its simple:
>
> > Sanjiva> The problem with using an OUT operation to do that is
> > that its not clear where the OUT is targetted to.
> >
> > Well, that info could be part of a binding for the
> > actual implemented interfaces. It can be equally well said
> > that the problem with an IN operation is that it is not
> > clear who is targeting it. These interfaces are to be abstracted
> > from some "bits on the wire" details, right?
>
> No, the target of the OUT operation cannot be in the binding; if
> so its a fixed target that can never change! If OUTs are like
> events then one needs a subscription mechanism to register the
> listeners etc.. So what I'm proposing is dropping the OUT operations
> and adding first class support for events (and whatever else OUT
> oriented stuff we find interesting).
>
> Thanks,
>
> Sanjiva.
>
> ----- Original Message -----
> From: "Dale Moberg" <dmoberg@cyclonecommerce.com>
> To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>; <www-ws-desc@w3.org>
> Sent: Thursday, May 02, 2002 5:58 AM
> Subject: RE: Issue: Should Operations permit alternate and multiple
> responses
>
>
> > Responses interspersed below.
> >
> > Dale>> 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).
> >
> > Sanjiva>The service type idea was not an operation-level grouping; it
> > > was a grouping of portTypes to indicate their polarity.
> >
> > OK, maybe I misunderstood. I thought you were going to add
> > new names for groups, alongside request-response-operation and
> > the others.
> >
> > Sanjiva>> I'm not sure how that breaks layering. Can you elaborate
> > please?
> >
> > Maybe this example will be useful.
> > A given request-response interface can be doing different
> > things depending on the context of how it gets invoked.
> > Moving money into an account might be part of money laundering
> > or saving for college tuition. The different services rendered
> > (obscuring source of funds or saving) might have the same formal
> > mode of operation. If the interface description vocabulary
> > included service-types "save-for-college" and "launder-money,"
> > it would need to "know" something about the larger context
> > it was being invoked for. Those richer descriptions belongs
> > to the conversation/flow/collaboration level. The interface
> > writer can abstract away from environment, and just focus
> > on "deposit fund" functionality. So the callee doesn't need
> > to know the why and wherefore of being called, and the service
> > type info. seemed to me to conflict with that layering design goal.
> >
> >
> >
> > Dale>> 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)
> >
> > Sanjiva> The problem with using an OUT operation to do that is
> > that its not clear where the OUT is targetted to.
> >
> > Well, that info could be part of a binding for the
> > actual implemented interfaces. It can be equally well said
> > that the problem with an IN operation is that it is not
> > clear who is targeting it. These interfaces are to be abstracted
> > from some "bits on the wire" details, right?
> >
> > Sanjiva> Another way of achieving the same is to model the OUT
> > >as the invocation of an IN of the partner. Then the
> > >semantics are much clearer IMO; there are only IN operations
> > >and someone always calls them.
> >
> > I understand that there is a yin and a yang to the interface,
> > but as far as the aesthetics goes, I could find either mode
> > of description useful for different cases. A broadcast message
> > (e.g, request for quotes from multiple vendors) may go to variable
> > pools of URLs. It might be harder to characterize that operation
> > by enumerating a big choice over a bunch of INs... When I am
> > writing servlets, though, I would prefer using INs to announce
> > interfaces.
> >
> > Dale>> 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.]
> >
> > Sanjiva>I can't speak for the group, but personally I would like WSDL
> > >to be able to describe peer-to-peer oriented services.
> >
> >
> > >> 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.
> >
> > Sanjiva> Sorry but I'm not following? What's "interface orientation"?
> >
> > The stuff you know about the flow of XML messages other than
> > what the schema tells you. For example, that a node initiates
> > or is in some call-graph dependency position in the data flow.
> > That messages are just simple inputs or outputs or that
> > there is a sequence of one following the other. Doesn't show
> > up in the type definition. Says something about the data flow
> > that would be captured in swim lanes. Etc.
> >
> > Sanjiva>Also, what's BPSS?
> >
> > An ebXML business process modeling language that can be used in ebXML,
> > an OASIS XML messaging standardization effort. "Business Process
> > Specification Schema" I think.
> >
> > >> 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.
> >
> > Sanjiva> Again, I don't quite grok what exactly you're proposing. First
> > of
> > >all, do you agree that the out-oriented operations of WSDL 1.1 are
> > > not fully defined?
> >
> > The OUT operations always seemed a bit odd if what you really wanted
> > to do is specify xml messages consumed and created on the server side
> > of things. I guess you need to tell me what they were originally
> > intended to
> > do before I know whether to agree with you. I certainly agree that
> > elaboration would be useful.
> >
> >
> > Sanjiva >Which interpretation do you have for them: event,
> > > callback or something else? How do you propose clarifying them if
> > >we were to retain them?
> >
> > Illustrations of usage would be a good start. Prasad had
> > some use cases recently, I believe. I think the document
> > could benefit from explaining the idea of polarity explicitly, for
> > example.
> > Also,by saying that for the majority of current usages, people will
> > prefer
> > to use the IN style of description. Then say that some XML
> > message flows can be described by these other bits of WSDL, and that
> > some choreography notations might be written to reference these
> > formats. Say if you don't need to use them, don't bother with them.
> >
> > >> 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 assembling names
> > > that would seem more neutral.
> >
> > Dale> If the existing operation/port-type
> > names are already well-entrenched and
> > cause no confusion, then probably inertia favors retaining them.
> > But "Request-Response," for example, has a history describing
> > asynchronous XML message flows. Is a WSDL "Request-Response"
> > equally well suited to these forms of distributed communication
> > (with two endpoint URLs needed)? Or does it best fit the one
> > URL case, with synchronous response?
>
>

Received on Thursday, 2 May 2002 09:12:18 UTC