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

Re: Follow up on output ops + MEPs

From: Prasad Yendluri <pyendluri@webmethods.com>
Date: Thu, 19 Dec 2002 13:13:36 -0800
Message-ID: <3E023680.4060400@webmethods.com>
To: Sanjiva Weerawarana <sanjiva@watson.ibm.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>
Hi Sanjiva,

It seems you are proposing that we retain the <operation> construct of 
portType to define the Web service interface (in WSDL 1.1 way) esp. for 
input-output and input-only type operations and allow use of the new 
<interaction> construct for (these plus) other patterns? Kind of like 
the element/type option we have in messages? That seems like a 
reasonable approach to me, which also permits backward compatibility 
with WSDL 1.1 (in this area anyhow).  Also I take the "pattern" is the 
equivalent (or higher level) abstraction to MEPs.

Is that correct?

Regards, Prasad

-------- Original Message --------
Subject: Re: Follow up on output ops + MEPs
Date: 19 Dec 2002 06:09:25 -0500
From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
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>


+1.

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
patterns:

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

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. 

Sanjiva.

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 
>                                To: 
> "'Prasad Yendluri'"
> , FABLET
> Youenn 
>                                CC: 
> www-ws-desc@w3.org, Sanjiva
> Weerawarana
> ,
> Jean-Jacques Moreau
> 
> 
> 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"
>         
>                          Organization: 
>         Canon Research Centre France
>                                    To: 
>         Sanjiva Weerawarana
>         
>                                    CC: 
>         www-ws-desc@w3.org,
>         Jean-Jacques Moreau
>         
>                            References: 
>         <3DF9A94D.5060506@crf.canon.fr>
>         <043701c2a29f$02482ee0$7f00a8c0@lankabook2>
>         
>         Sanjiva Weerawarana wrote:
>         > "FABLET Youenn"  writes:
>         >   
>         > > Following on example 2 (event notification) of Don's proposal (for 
>         > > illustration purposes only):
>         > >          > >         mep="http://www.example.org/mep/event-notification/"
>         > >         myRole="event:notifier"
>         > >         xmlns:event="http://www.example.org/mep/event-notification/">
>         > > ...
>         > > 
>         > >          > >         mep="http://www.example.org/mep/event-notification/"
>         > >         myRole="event:subscriber"
>         > >         xmlns:event="http://www.example.org/mep/event-notification/">
>         > > ...
>         > > 
>         > >     
>         > 
>         > 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 
IBM Research



Sanjiva Weerawarana wrote:

>+1.
>
>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
>patterns:
>
>	<interaction name="xyz" pattern="uri">
>		<message name="m1" role="..."/>
>		...
>	</interaction>
>
>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. 
>
>Sanjiva.
>
>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. 
>>    
>>
Received on Thursday, 19 December 2002 16:12:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:22 GMT