Subscriptions in BEA AquaLogic Service Registry

Subscriptions in BEA AquaLogic Service Registry ^Locate

Subscriptions are used to alert interested users in changes made to structures in BEA AquaLogic Service Registry. The BEA AquaLogic Service Registry Subscription API provides users the ability to manage (save and delete) subscriptions and evaluate notification. Notifications are lists of changes made within a specified time interval. The Subscription mechanism allows the user to monitor new, changed, and deleted entries for businessEntities, businessServices, bindingTemplates, tModels or publisherAssertions. The set of entities in which a user is interested is expressed by a SubscriptionFilter, which can be any one of the following UDDI v3 API queries:

find_business, find_relatedBusinesses, find_services, find_bindings, find_tmodel
get_businessDetail, get_serviceDetail, get_bindingDetail, get_tModelDetail, get_assertionStatusReport

	Note
	In Business Service Console, users can also create subscriptions also resources (WSDL, XML, XSD and XSLT) without a detailed knowledge of how resources are mapped to UDDI data structures.

Subscription Arguments ^Locate

A subscription is the subscriber's interest in changes made to entities as defined by the following arguments:

SubscriptionKey - The identifier of the subscription, as generated by the server when the subscription is registered.
Subscription Filter - Specifies the set of entities in which the user is interested. This field is required. Note that once the subscription filter is set, it cannot be changed.
Expires After - The time after which the subscription is invalid (optional).
Notification Interval - How often the client will be notified (optional). The server can extend it to the minimum supported notification interval supported by the server as configured by the administrator.
For more information, please see Administrator's Guide, Registry Configuration.
Max Entities - how many entities can be listed in a notification (optional). When the number of entities in a notification exceeds max entities, the notification will contain only the number of entities specified here or in the registry configuration. A chunkToken different from "0" will be specified in the notification. This chunkToken can be used to retrieve trailing entities.
BindingKey - points to the bindingTemplate that includes the endpoint of the notification handling service (optional). Only http and mail transports are currently supported. If this bindingKey is not specified, the notification can be retrieved only by synchronous calls.
Brief - By default, notifications contain results corresponding to the type of the Subscription Filter. For example, when the subscription filter is find_business, notifications contain Business Entities in the businessInfos form. If brief is toggled on, notifications will contain only the keys of entities. (optional)

Subscription Notification ^Locate

Notification is the mechanism by which subscribers learn about changes. Notifications inform subscribers about entities that:

Satisfy the Subscription Filter now and were last changed, or created, within a given time period. The entities are included in a list of the appropriate data type by default. For example, when find_business represents the Subscription Filter, notifications contain Business Entities in the businessList/businessInfo form. (If the brief switch is toggled on, only the entity keys in the keyBag are included.)
Were changed or deleted in the given time period and no longer satisfy the Subscription Filter. Only the keys of the appropriate entities are included in the keyBag structure and the deleted flag is toggled on.

There are two types of notifications:

Asynchronous notification - Using asynchronous notification, the server periodically checks for changes and offers them to the client via HTTP or SMTP. HTTP is suitable for services listening to UDDI changes. SMTP (that is, mail notification) is suitable for both services and users. With this transport, the user is notified at each notification interval by email. To perform asynchronous notification, the subscription must be populated with notification interval and bindingKey. See Developer's Guide, Writing a Subscription Notification Service for details.
Synchronous notification - Using synchronous notification, the server checks for changes and offers them when the client explicitly asks for them outside of periodical asynchronous notifications. It is useful for client applications which cannot listen for notifications, and for services that want to manage the time of notification by themselves. See Demos, Subscription for details.

XSLT Over Notification ^Locate

To improve the readability of notifications sent to users via email, BEA AquaLogic Service Registry provides the ability to process the XSL transformation before the notification is sent. To enable this feature:

Register the XSL transformation in UDDI as a tModel that refers to XSL transformation in its first overviewDoc.
Modify the bindingTemplate (with the bindingKey specified in the subscription) to refer to the XSLT tModel by its tModelInstanceInfo.
Tag the XSLT tModel by a keyedReference to uddi:uddi.org:resource:type with the keyValue="xslt".

Suppressing Empty Notifications ^Locate

Another BEA AquaLogic Service Registry extension to the specification is the ability to suppress empty notifications. To do this, tag the bindingTemplate referenced from the subscription with a keyedReference to the tModel uddi:uddi.org:categorization:general_keywords with keyValue="suppressEmptyNotification" and keyName="suppressEmptyNotification".