Re: Follow up on output ops + MEPs

Prasad Yendluri wrote:

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

yes, exactly :-)

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

IMHO, "operation types" resemble a lot to MEPs (at least they have a lot 
in common), hence the idea of reusing MEPS within WSDL (more below...).

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

At now I would agree that SOAP MEP might not be reused as is. 
Nevertheless, I think the XMLP WG made a good job defining the 
request-response mep, and I think we should reuse their work as much as 
possible. If I remember correctly, Glen was suggesting to extract MEPs 
from a SOAP area to a Web Service area...

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

Yes, I think we agreed on that idea during the call. That is why both 
event-subscribe-in and event-subscribe-out operations are useful IMHO, 
if we continue to proceed with this "service's POV philosophy".

    Youenn

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