Re: Follow up on output ops + MEPs

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