- From: Prasad Yendluri <pyendluri@webmethods.com>
- Date: Tue, 17 Dec 2002 16:18:37 -0800
- 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>
- Message-ID: <3DFFBEDD.5030800@webmethods.com>
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 Tuesday, 17 December 2002 19:17:42 UTC