Re: Issue: Should Operations permit alternate and multiple responses

Keith Ballinger wrote:

> >>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.

Yes, I guess this is the Notification (Solicit-Response) issue we have open :)

>         -----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 Wednesday, 1 May 2002 23:28:33 UTC