Re: Follow up on output ops + MEPs

So, what about making the "pattern" and "role" attributes 
optional, i.e. one could simply write for request-response:

   <interaction name="xyz">
       <message name="m1"/>
       <message name="m2"/>
   </interaction>

and for a more complex interaction:

   <interaction name="tuv" pattern=".../double-req-resp">
       <message name="m1" role=".../receiving"/>
       <message name="m2" role=".../responding"/>
       <message name="m3" role=".../receiving"/>
       <message name="m4" role=".../responding"/>
   </interaction>

Comments?

Jean-Jacques.

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 10:50:21 UTC