W3C home > Mailing lists > Public > www-ws-desc@w3.org > October 2002

[Pub-Sub-Task] initial half-baked proposal from me

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Fri, 1 Nov 2002 05:34:28 +0600
Message-ID: <019a01c28136$18ebaa30$6900a8c0@lankabook2>
To: "WS-Desc WG \(Public\)" <www-ws-desc@w3.org>

Since this discussion is moving to the public list let me re-post
the very rough proposal strawman I threw out. Joyce, please send
your thoughts as well.



I was thinking of something a bit more direct than what you've
written Joyce - same basic concept, but a bit more first class

    <portType name="pt1">
        <operation name="normal-op1"> ... </operation>*
        <event name="event-1">
            <subscription message="subscription-message"/>
            <notification message="notification-message"/>

So event definitions say that they are an event and indicate
what subscription message needs to be sent and what 
notification needs to be sent. A port for this portType would
have an address and that address is where the subscription
message would have to be sent. How that message flows on 
the wire is of course (as usual) a matter of the binding.
So we need to define a binding .. probably something that 
wraps the subscription message in a wrapper element named 
event-1, but we can work that out later.

Now the question is what's in the subscription message? 
Basically, it needs to indicate a service reference to a 
service that has a portType with the operation via which
the service will deliver the notification message to the
subscribers. The service reference in the subscription 
message is of course a reference to the subscriber. The
notification message itself is just a regular data 
message - contents are up to the service designer.

What's a service reference? In BPEL we published a service
ref format which can be the basis of a more thorough 
service reference. In fact we're finalizing such a beast
now and hope to make that available to the WG shortly. I 
believe such a mechanism will be sufficient to capture 
this scenario (details TBD ;-)).
Received on Thursday, 31 October 2002 18:36:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:40 UTC