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

[Pub-Sub-Task] Re: Some thoughts on wsdl pub/sub

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Fri, 1 Nov 2002 06:16:50 +0600
Message-ID: <01c601c2813b$fae32940$6900a8c0@lankabook2>
To: "WS-Desc WG \(Public\)" <www-ws-desc@w3.org>

On Thu, 2002-10-31 at 13:52, Joyce Yang wrote:
> I'm not a fan of existing outbound operations, but I do see
> them make the pub/sub modeling much easier and maybe
> more close to the original idea of outbound operations. The
> syntax Sanjiva proposed is very attractive (inline below),
>
>       <portType name="pt1">
>             <operation name="normal-op1"> ... </operation>*
>             <event name="event-1">
>                   <subscription message="subscription-message"/>
>                   <notification message="notification-message"/>
>             </event>
>       </portType>
>
> however, it's not sufficient, we will have to invent many more
> constructs to catch the concepts on whether the "subscription"
> is with ack, and the "notification" is with ack or not. We
> definitely can add a new "ack" attribute to <subscription>
> and <notification> to serve the needs, but aren't they modeled
> very naturally by two outbound operations as mentioned in my
> proposal? But overall, I'm glad we are conceptually trying
> to solve the same problem.

I agree there are different variations possible as you noted.
My approach to this kind of stuff is to take the most simple
scenario and address that and see whether its enough. We can of
course add whatever cases we want, but IMHO we should go for the
80-20 case only and live with that. Other more complicatated 
scenarios are left to extensibility.

So my preference would be to pick the following choices:
    - subscriptions are not ack'ed by the event source
    - notifications are not ack'ed by the event sync

Sanjiva.
Received on Thursday, 31 October 2002 19:19:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:21 GMT