RE: [wsn] New Issue: SubscriptionManager Interface in BrokeredNotification

["Patil, Sanjay" <sanjay.patil@sap.com>]

Title: Message

Hi Steve,

 

I wasn't suggesting to merge the SubscriptionManager interface into the NotificationBroker interface. Rather I was thinking if it makes sense to include the SubscriptionManager interface definition in the WS-NotificationBroker WSDL file for the sake of completeness.

 

Regarding the net effect of introducing a broker intermediary ... I agree that we should allow the NotificationBroker to delegate the SubcriptionManager functionality. Taking the same line of argument, should we then also allow the broker to delegate the NotificationConsumer as well as NotificationProducer behaviors. Why should  we require that there be a single aggregate NotificationBroker interface (and therefore a single endpoint!) that supports operations from the NotificationConsumer and the NotificationProducer interfaces?

 

Thanks,

Sanjay

-----Original Message-----
From: Steve Graham [mailto:sggraham@us.ibm.com]
Sent: Wednesday, Mar 02, 2005 4:28 AM
To: Patil, Sanjay
Cc: Lily Liu; wsn@lists.oasis-open.org
Subject: RE: [wsn] New Issue: SubscriptionManager Interface in BrokeredNotification

"Patil, Sanjay" <sanjay.patil@sap.com> wrote on 03/01/2005 10:15:14 PM:

> I believe the intent here may have been to point out that the broker role is a
> composition of producer and consumer roles. However, I am with you in that we
> should clarify whether and how this role composition translates to assuming support
> for WSDL Interfaces.
With respect to the composition of the producer and consumer roles, this is
captured in the NotificationBroker portType.  What is missing from that?

>  
> In addition to clarification text in the spec, the WSDL/Schema for the  BrokeredN
> should perhaps also include a copy of the SubscriptionManager PortType from the
> BaseN. Or should there be a wsdl:include of BaseN WSDL in the BrokeredN WSDL?
I am not sure we should increase the size of the WSDL/Schema for BrokeredN.  Why
is it not sufficient for the Broker to delegate to another SM service?
Another alternative to this issue is to modify the requirement text:

(starting line 100 of the 21 July 2004 draft of BrokeredN):
Must allow for a notification broker as an intermediary. A
NotificationBroker is an intermediary Web service that decouples
NotificationConsumers from Publishers. A notification broker can relieve a
Publisher from having to implement message exchanges associated with
NotificationProducer; the NotificationBroker takes on the duties of a
SubscriptionManager (managing subscriptions) and NotificationProducer
(distributing NotificationMessages) on behalf of the Publisher.

Perhaps it is the "takes on the duties of a SubscriptionManager" that is the
text in concern?  We could rephrase that to include the notion that
a NB could implement SM or it could delegate the behavior.  The net result is
that the responsibility of managing subscriptions is removed from the publisher
by the Broker.

>  
> Thanks,
> Sanjay
> -----Original Message-----
> From: Lily Liu [mailto:lily.liu@webmethods.com]
> Sent: Tuesday, Mar 01, 2005 9:43 AM
> To: wsn@lists.oasis-open.org
> Subject: [wsn] New Issue: SubscriptionManager Interface in BrokeredNotification

> In the WS-BrokeredNotification specification, it states that a broker should take
> on subscription manager duties in the Requirement section. However, it only lists
> out two interfaces that a NotificationBroker inherits: NotificationProducer and
> NotificationConsumer. I think we should add SubscriptionManager to that list.
>  
> Lily