Re: Follow up on output ops + MEPs

"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