|Author:Balan Subramanian, Mark Weitzel||
Last updated: 05/24/2006 12:47:15
Rough workload estimate for design/code/test in person weeks: 3pw
Rough workload estimate for doc in person days: 1pw
Rough workload estimate for build and infrastructure in person days: 1pw
The proposal is to add a stack within the workbench that will allow for event notifications to be sent to the workbench over WS-N. This will allow workbench components like the managed agent explorer and existing event views to register for event notifications from resources (typically WSDM instrumented) that they are interested in. Only WE-Notifications containing, WEF (WSDM Event Format) events, WSDM Property Change notifications, WSDM Lifetime event notifications and WSDM Advertisements will be supported. This notification listener will use the HTTP bundle available in Equinox to receive WS-N notifications and convert it into objects that can be used by event exploiters in TPTP.
This component by itself does not provide any user interfaces. However the events received by this component will be shown in other existing TPTP views including the LTA Log View. User defined subscriptions to selected topics from particular event producers will also be allowed by other UIs including the Managed Agent Explorer.
The interface org.eclipse.tptp.monitoring.wsdm.notifications.NotificationListener will define the various methods interested parties will call to register, unregister subscriptions. We will follow the simple Java listener mechanism to register for and receive events. However registration is implicitly done by the Eclipse extension point mechanism .i.e. interested plugins must extend the specified extension point(see below) and as part of the plugin discovery this plugin will register them as listeners. The method signatures within this interface will allow interested TPTP components to register for all notifications from an event producer by specifying the Endpoint Reference of that producer and optionally specifying the fully qualified topic names they are interested in. Overloaded methods will be provided to allow subscriptions by property name, capability (collection of properties/operations/event topics) name. By default, a listener will be subscribed to all topics.
This component will provide two extension points:
Plugins interested in receiving notifications will extend this extension point. The interface for this extension point is specified in the previous section.
This extension point is provided to handle different versions of WS-Notifications. In the case of co-existence of multiple WSDM runtime supporting multiple versions of the specifications, this allows this component to use them at the same time. When a subscription is requested by other plugins, this plugin will first query the resource (through metadata Exchange) to find out what version of WS-N is being used and invoke the corresponding notification provider with the subscription.
In addition, extension points provided by the Equinox framework will be extended to register a new bundle containing the WSDM runtime.
This plugin uses the code available in Apache Muse for consuming events and packages it into an OSGi bundle that can be deployed into Equinox. This OSGi bundle will require the HTTP bundle available for Equinox. This notification subsystem allows other plugins to express their interest in events of certain types from certain resources. It will consolidate all subscriptions and maintain internal tables that map listeners to subscriptions. It will optimize subscriptions so that duplicate subscriptions can be avoided. It will also ensure that when listeners unsubscribe, actual unsubscription on the resource happens only when all listeners have unsubscribed.
The received WS-Notifications are parsed and converted to object form using the factories available in Apache Muse for WEF events, Property change notifications, WS-Lifetime notifications and Advertisements. Listeners can selectively subscribe to any one of these types or to all of them.