- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Fri, 13 Dec 2002 06:58:48 -0500
- To: "FABLET Youenn" <fablet@crf.canon.fr>, <www-ws-desc@w3.org>, "Jean-Jacques Moreau" <moreau@crf.canon.fr>
"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. 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. 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 .. Sanjiva.
Received on Friday, 13 December 2002 07:01:22 UTC