W3C home > Mailing lists > Public > www-ws-desc@w3.org > December 2002

Re: Follow up on output ops + MEPs

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: 19 Dec 2002 06:09:25 -0500
To: Prasad Yendluri <pyendluri@webmethods.com>
Cc: Don Mullen <donmullen@tibco.com>, FABLET Youenn <fablet@crf.canon.fr>, www-ws-desc@w3.org, Jean-Jacques Moreau <moreau@crf.canon.fr>
Message-Id: <1040296165.26637.6.camel@lankabook>


I like the idea of calling them operationType rather than MEP to
avoid confusion with SOAP MEPs. Another possibility is to consider
<operation> to be a syntax that's good for certain kind of 
interactions and then use a different syntax for the more general

	<interaction name="xyz" pattern="uri">
		<message name="m1" role="..."/>

We can use <operation> for the simple input-output and input-only
patterns (but define its semantics in terms of a specific pattern 
(URI) that's predefined by us. We can use something else for the
two outbound patterns we are aware of and one for events. 


On Tue, 2002-12-17 at 19:18, Prasad Yendluri wrote:
> Sorry could not join the call due to a conflict ...
> I don't think MEPs (as defined by SOAP anyhow) are specific enough to
> describe the semantics difference the message exchanges. E.g. same
> MEPs could fundamentally represent both Pub/Sub and
> Notification/One-way type operations. We could define a separate MEP
> for each semantic interpretation possible but, I think it is more
> natural to leave message exchange patterns at the message exchange
> level and build upper level abstractions that are tailored to WSDL
> operations, in a way that incorporate both "direction" and "semantic"
> aspects. E.g. Solict-Response (out/in) is based on Request/Response
> MEP with Request going out of the operation (service) first and
> response where as in/out type operation is also based on the same
> fundamental MEP with request coming into the operation (service) and
> then response going out etc.
> By operation types I meant the formalization of these MEPs by WSDL
> with the semantics associated with them (from a WSDL
> portType/operation perspective), clearly defined. We can also
> consolidate other operation specific attributes at this common level
> (e.g. myRole  and other AIIs that Youenn shows below)..
> If we still want to call them (WSDL) MEPs that works fine also but,
> operationType conveys the proper meaning to me..
> Regards, Prasad
> -------- Original Message -------- 
>                           Subject: 
> RE: Follow up on output ops + MEPs
>                              Date: 
> Tue, 17 Dec 2002 09:56:32 -0500
>                              From: 
> Don Mullen <donmullen@tibco.com>
>                                To: 
> "'Prasad Yendluri'"
> <pyendluri@webmethods.com>, FABLET
> Youenn <fablet@crf.canon.fr>
>                                CC: 
> www-ws-desc@w3.org, Sanjiva
> Weerawarana
> <sanjiva@watson.ibm.com>,
> Jean-Jacques Moreau
> <moreau@crf.canon.fr>
> 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
>                                  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. 
Sanjiva Weerawarana <sanjiva@watson.ibm.com>
IBM Research
Received on Thursday, 19 December 2002 06:10:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:26 UTC