Re: Follow up on output ops + MEPs

Youenn,

This is very much on the right track IMHO.

I did not think they were two sides of the same operation, though the 
names of the operations did throw me off a bit.  Thought they were 
describing Event-In and Event-Out operations that actually receive and 
send out the Event-notifications (messages) respectively, where as the 
intent seems to be event-subscribe-in and event-subscribe-out type of 
operations.  

Given scope for such confusion exists, it seems we would be better 
positioned, if we move the details of these definitions from individual  
operation level to common set of abstractions of 
"WSDL-Operation-Types".  I mean, WSDL could define a number of these 
Operation-Types (identified by a URI), each of which specifies the full 
details of the subject operation type and the semantics of it. Then at 
the operation definition level, the operation type is simply referenced 
say via an attribute ("type=URI") on the operation, conveying the full 
nature of the operation as specified by the operation-type definition. 
We might still need to spec certain things at the input/output message 
level, as Don's has shown before but, at least all common details are 
consolidated out..

This offers the level of optimization that is currently missing from the 
binding level IMO, where things are repeated over and again.

BTW, since operation definitions (portTypes) are at the abstract level, 
these types (and the dependent MEPs) need to be independent of a 
specific binding protocol (e.g. SOAP).

I think Jacek correctly pointed earlier the subtle distinction between 
SOAP MEPs and WSDL operation (message exchange) types..

Another point that I perhaps failed to make clearly during the call 
yesterday was the need, not to assume the target for out-bound 
operations to be another Web service and describe such operations (as) 
fully (as possible) from the originating Web service's POV.

Regards, Prasad

-------- Original Message --------
Subject: Re: Follow up on output ops + MEPs
Resent-Date: Fri, 13 Dec 2002 07:41:32 -0500 (EST)
Resent-From: www-ws-desc@w3.org
Date: Fri, 13 Dec 2002 13:40:52 +0100
From: "FABLET Youenn" <fablet@crf.canon.fr>
Organization: Canon Research Centre France
To: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
CC: www-ws-desc@w3.org, Jean-Jacques Moreau <moreau@crf.canon.fr>
References: <3DF9A94D.5060506@crf.canon.fr> 
<043701c2a29f$02482ee0$7f00a8c0@lankabook2>



Sanjiva Weerawarana wrote:

>"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. 
>
There is not two operations that describe an event subscription, but 
just one. The example presents two operations:
    - operation "EventIn" says: me as a server allows you client to 
subscribe events;  this is the classic event operation
    - operation "EventOut" says: me as a server requires you as a client 
to implement a subscription type function; the server can subscribe to 
some events from the client.
In your scenario of a service provider of events, the service would only 
include the first op in its WSDL and does not care at all about the 
second op...
The request-response mep engages two entities A and B exactly like the 
event mep.
Then, saying that the server is A leads to WSDL request-response 
operation type.
Saying that the server is B leads to one interpretation of the WSDL 
sollicit-response operation type.
You can apply the same mechanism to the event mep.

>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.
>
I agree and that is precisely the goal of Don's proposal (at least from 
my understanding).
My event example was in fact two examples and not one...
Hence some confusion maybe...

>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 ..
>  
>
IMO, my usage of "role" is also within an operation...
I think that the mep proposal + my addition lie somewhere in the 
frontier with orchestration.
This can be a simple hook that will ease orchestration languages's use 
of  WSDL.
Anyway, we will talk about this on tuesday...
    Youenn

>Sanjiva. 
>