Re: Issue: Should Operations permit alternate and multiple responses

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

The service type idea was not an operation-level grouping; it
was a grouping of portTypes to indicate their polarity.

I'm not sure how that breaks layering. Can you elaborate
please?

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

The problem with using an OUT operation to do that is 
that its not clear where the OUT is targetted to.

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.

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

Sorry but I'm not following? What's "interface orientation"?

Also, what's BPSS?

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

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? Which interpretation do you have for them: event,
callback or something else? How do you propose clarifying them if
we were to retain 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 asssembling names
> that would seem more neutral.

I didn't confuse them, but you're right that it could certainly
confuse folks.

Sanjiva.

Received on Wednesday, 1 May 2002 16:29:58 UTC