RE: Follow up on output ops + MEPs

I don't understand the different between your 'WSDL-Operation-Type' and an
abstract MEP.  Perhaps you can explain further on the call today?
 
Don

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
Sent: Friday, December 13, 2002 4:32 PM
To: FABLET Youenn
Cc: www-ws-desc@w3.org; Sanjiva Weerawarana; Jean-Jacques Moreau
Subject: 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 <mailto:www-ws-desc@w3.org> 	
Date: 	Fri, 13 Dec 2002 13:40:52 +0100	
From: 	"FABLET Youenn"  <mailto:fablet@crf.canon.fr> <fablet@crf.canon.fr>

Organization: 	Canon Research Centre France	
To: 	Sanjiva Weerawarana  <mailto:sanjiva@watson.ibm.com>
<sanjiva@watson.ibm.com>	
CC: 	www-ws-desc@w3.org <mailto:www-ws-desc@w3.org> , Jean-Jacques Moreau
<mailto:moreau@crf.canon.fr> <moreau@crf.canon.fr>	
References: 	 <mailto:3DF9A94D.5060506@crf.canon.fr>
<3DF9A94D.5060506@crf.canon.fr> <043701c2a29f$02482ee0$7f00a8c0@lankabook2>



Sanjiva Weerawarana wrote:


"FABLET Youenn"   <mailto:fablet@crf.canon.fr> <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/"
<http://www.example.org/mep/event-notification/> 

        myRole="event:notifier"

        xmlns:event= "http://www.example.org/mep/event-notification/"
<http://www.example.org/mep/event-notification/> >

...

</operation>

<operation name="Event-Out"

        mep= "http://www.example.org/mep/event-notification/"
<http://www.example.org/mep/event-notification/> 

        myRole="event:subscriber"

        xmlns:event= "http://www.example.org/mep/event-notification/"
<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.