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

+1 to Sanjiva's proposal at the top-level.
There is one small "but" from me. I believe that passing service reference is not a mandatory part of the subscription message defined at the top level, but rather a business of the binding.

In my view binding of an event (notification) needs to define:
 * for a "producer role"
  - subscription/ack sequence and message layout with "consumer" reference (and/or binding) place in it
  - subscription update/removal sequence, frequency and message layout
 * for a "consumer role"
  - notification/ack sequence and message layout
  - keep-alive/solicit-update notification acceptance, sequence, message layout and optimal frequency


-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788


-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] 
Sent: Thursday, October 31, 2002 6:34 PM
To: WS-Desc WG (Public)
Subject: [Pub-Sub-Task] initial half-baked proposal from me



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.

Sanjiva.

========================

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

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

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 Monday, 4 November 2002 12:02:05 UTC