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

"Patil, Sanjay" <sanjay.patil@sap.com> wrote on 03/03/2005 10:18:05 PM: > 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.
Ah ok, sorry for the misunderstanding. Would you imagine this could be accomplished
by use of wsdl:import, or do you suggest the SubscriptionManager interface be defined
in the WS-Brokered Notification namespace as well?

<Sanjay> I thought the imports area available only to the importing WSDL and not beyond. That is, an implementer of WS-BrokeredN WSDL will not see the SubscriptionManager interface and therefore will have to separately obtain WS-BaseN. Which is not a problem to me.</Sanjay>

>
> 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?
Good question. To me, the motivation for the aggregation is that it is exactly
the combination of the consumer (for publish) and producer (for subscribe etc.) that
is the essence of what it means to be a broker, hence it seems to make sense to combine
these into one interface.
<Sanjay> Agree. But that should not necessarily pose the restriction that the same broker endpoint must provide both the functions of receiving notifications and sending them out (creating subscriptions in reality). Why not allow a broker to structure its implementation say in a distributed manner where by two separate endpoints are used for it producer and consumer roles.

>
> 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

wsn message