RE: Follow up on output ops + MEPs

I agree with Sanjiva.  I don't understand the need to call out the
'serviceRole' of an operation, and I think it could lead to a good deal of
confusion.

Right now, everything in the WSDL is from the 'service' point of view.
Clients of input-output operations need to send their *output* as the
*input* of the operation.  This is a bit of a hurdle already for people to
understand that are new to WSDL.  If then add 'serviceRole', then some
input-output operations would be status-quo -- where clients send their
output as the input message of the service, but in a 'RequestingNode'
operation, the input-output is reversed -- the client then accepts incoming
messages on the input.  This can currently be sufficiently described using
output-input.

I understand the argument that Jacek makes about the service acting in
different roles -- but this does cross into choreography space, and I would
like to see specific example use-cases where it would be important to
designate a service roles as other than 'sending' or 'receiving'
information.

I have never really like the names 'input' and 'output' but changing these
now would be a fairly drastic change.

Don

-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Friday, December 13, 2002 6:59 AM
To: FABLET Youenn; www-ws-desc@w3.org; Jean-Jacques Moreau
Subject: Re: Follow up on output ops + MEPs



"FABLET Youenn" <fablet@crf.canon.fr> writes:
> 
> Following on example 2 (event notification) of Don's proposal (for 
> illustration purposes only):
> <operation name="Event-In"
>         mep="http://www.example.org/mep/event-notification/"
>         myRole="event:notifier"
>         xmlns:event="http://www.example.org/mep/event-notification/">
> ...
> </operation>
> <operation name="Event-Out"
>         mep="http://www.example.org/mep/event-notification/"
>         myRole="event:subscriber"
>         xmlns:event="http://www.example.org/mep/event-notification/">
> ...
> </operation>

To me using two operations to describe an event is akin to how
JavaBeans is built on top of Java: as a second-class set of conventions
that some post-processing (the introspector) applies. The C# way
of making things like properties first-class concepts of the language
is the right way to go IMHO. 

That translates to saying have one operation which points to the event
MEP and which has as many messages as needed for the message roles 
of that mep (subscription, notification, unsubscription, acknowledgement).
IMHO the event pattern is common enough to justify our giving that 
pattern specific syntax and thereby imply the semantics directly rather
than point to a MEP, but really that's just syntax.

Note that my usage of "role" was *within* an operation. I still haven't
grok'ed the role concept you have done above .. it seems like you 
have a multi-party state machine and you're identifying roles ..
that's sort of what BPEL's service link type do .. so that approach
seems dangerously close to orchestration and seems far more capable
than needed to describe a service from the point of view of the service.
I have to think about it more though to be sure ..

Sanjiva.

Received on Tuesday, 17 December 2002 10:08:22 UTC