- 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>
+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.
--
Sanjiva Weerawarana <sanjiva@watson.ibm.com>
IBM Research
Received on Thursday, 19 December 2002 06:10:38 UTC