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 Wednesday, 1 May 2002 22:44:47 UTC