Difference between revisions of "IS-Notifier"
Lucio.lelii (Talk | contribs) (→Resources and Properties) |
|||
| Line 3: | Line 3: | ||
It is important to notice that the design of such a service does not implement the classical brokered notification schema since the IS-Notifier subscribes the consumer directly to the notification producer. In this way, there is no single service that is in charge to receive notifications from producers and then dispatch them to the subscribed client(s). However, the IS-Notifier plays a mediator role because of the subscriptions brokerage. In fact, the IS-Notifier automatically manages the relocation of notification producers by forwarding the client subscription requests to the new instances of the producers. Moreover, the service supports the transparent subscription/re-subscription of the client to the new producer instances that comes up after the initial request of subscription. | It is important to notice that the design of such a service does not implement the classical brokered notification schema since the IS-Notifier subscribes the consumer directly to the notification producer. In this way, there is no single service that is in charge to receive notifications from producers and then dispatch them to the subscribed client(s). However, the IS-Notifier plays a mediator role because of the subscriptions brokerage. In fact, the IS-Notifier automatically manages the relocation of notification producers by forwarding the client subscription requests to the new instances of the producers. Moreover, the service supports the transparent subscription/re-subscription of the client to the new producer instances that comes up after the initial request of subscription. | ||
| − | + | == Resources and Properties == | |
The service adopts the singleton pattern. The managed resource represents the operational status of the service by exposing a set of properties, e.g. number of topics currently published, the number of subscriptions managed, the number of pending subscriptions. | The service adopts the singleton pattern. The managed resource represents the operational status of the service by exposing a set of properties, e.g. number of topics currently published, the number of subscriptions managed, the number of pending subscriptions. | ||
Revision as of 16:50, 13 April 2011
The IS-Notifier is the gCube Service dedicated to manage subscriptions with respect to Topics, i.e. organised items of interest for publishing/subscription . It acts as a subscriptions broker since allows its client to subscribe to a topic while freeing them from the need to know the location of the notifications producer (i.e. its EPR). It also supports subscriptions to Topics that are not yet exposed by their producers. In this case, the IS-Notifier maintains a subscription in a pending state until the notification producer registers the related Topic.
It is important to notice that the design of such a service does not implement the classical brokered notification schema since the IS-Notifier subscribes the consumer directly to the notification producer. In this way, there is no single service that is in charge to receive notifications from producers and then dispatch them to the subscribed client(s). However, the IS-Notifier plays a mediator role because of the subscriptions brokerage. In fact, the IS-Notifier automatically manages the relocation of notification producers by forwarding the client subscription requests to the new instances of the producers. Moreover, the service supports the transparent subscription/re-subscription of the client to the new producer instances that comes up after the initial request of subscription.
Resources and Properties
The service adopts the singleton pattern. The managed resource represents the operational status of the service by exposing a set of properties, e.g. number of topics currently published, the number of subscriptions managed, the number of pending subscriptions.
Functions
The main functions supported by the IS-Notifier are:
- registerTopic() – which takes as input parameter a message containing the EPR of the topics produced and the list of Topics consumers can subscribe and accordingly enriches the pool of managed Topics;
- unregisterTopic() – which takes as input parameter a message containing the EPR of the topics producer and the list of Topics to be removed and accordingly revise the pool of managed Topics;
- subscribeToTopic() – which takes as input parameter a message containing the request for subscription (i.e. the EPR of the subscriber and the topic of interest) and subscribes the subscriber to the appropriate producer(s) according to the WS-BaseNotification specification .
- listTopics() – which returns all the Topics managed by the IS-Notifier instance;
- listTopicForNotifiers() – which takes as input parameter a message containing the EPR and returns ;
- getSubscribersForTopic() – which takes as input parameter a message containing the target Topic and returns the list of current subscribers (actually their EPRs);
- removeSubscription() – which takes as input parameter a message containing the request for un-subscription (i.e. the EPR of the subscriber and the Topic to be unsubscribed) and manages the subscription removal;
