- From: Prasad Yendluri <pyendluri@webmethods.com>
- Date: Thu, 19 Dec 2002 13:13:36 -0800
- 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>
- Message-ID: <3E023680.4060400@webmethods.com>
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 UTC