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 19:58:54 UTC