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

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

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Fri, 1 Nov 2002 07:06:50 +0600
Message-ID: <01f301c28143$01a75290$6900a8c0@lankabook2>
To: "Joyce Yang" <joyce.yang@oracle.com>
Cc: "WS-Desc WG \(Public\)" <www-ws-desc@w3.org>

OK that's cool .. one way the other what I'm arguing for is
picking one combination of the 4 ack/nack scenarios as the
80-20 case.

Sanjiva.

----- Original Message ----- 
From: "Joyce Yang" <joyce.yang@oracle.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
Cc: "WS-Desc WG (Public)" <www-ws-desc@w3.org>
Sent: Friday, November 01, 2002 6:46 AM
Subject: Re: [Pub-Sub-Task] Re: Some thoughts on wsdl pub/sub


> n the 80-20 rule, I'm not sure the "80" is on the no-ack case.
> I think most subscription will need an ack.
> 
> -Joyce
> Sanjiva Weerawarana wrote:
> 
> > 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 20:09:24 GMT

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