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: Tue, 17 Dec 2002 16:18:37 -0800
Message-ID: <3DFFBEDD.5030800@webmethods.com>
To: Don Mullen <donmullen@tibco.com>
CC: FABLET Youenn <fablet@crf.canon.fr>, www-ws-desc@w3.org, Sanjiva Weerawarana <sanjiva@watson.ibm.com>, Jean-Jacques Moreau <moreau@crf.canon.fr>
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 
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?

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


    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>

    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 name="Event-Out"
>>        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...

Received on Tuesday, 17 December 2002 19:17:42 UTC

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