Subscription Arguments Subscriptions in Oracle Service Registry

• 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

1.4.2. Subscription Notification

Notification is the mechanism by which subscribers learn about changes. Notifications inform subscribers about entities that: 1. 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 businessListbusinessInfo form. If the brief switch is toggled on, only the entity keys in the keyBag are included. 2. 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 Developers Guide, Section 3.5, 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, Section 2.3, Subscription for details.

1.4.3. XSLT Over Notification

To improve the readability of notifications sent to users via email, Oracle Service Registry provides the ability to process the XSL transformation before the notification is sent. To enable this feature: 1. Register the XSL transformation in UDDI as a tModel that refers to XSL transformation in its first overviewDoc. 2. Modify the bindingTemplate with the bindingKey specified in the subscription to refer to the XSLT tModel by its tModelInstanceInfo. 3. Tag the XSLT tModel by a keyedReference to uddi:uddi.org:resource:type with the keyValue=xslt.

1.4.4. Suppressing Empty Notifications

Another Oracle 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. Page 159

1.4.4. Suppressing Empty Notifications

1.4.5. Related Links

• To manage subscriptions via the Business Service Control, see the section Business Service Control Subscriptions . • To manage subscriptions via the Registry Control, see the Registry Control Reference . • To use and manage subscriptions, see the Subscription API . • More details about subscriptions can be found in the Subscription API [http:uddi.orgpubsuddi-v3.00-published- 20020719.htm_Toc42047327] chapter of the UDDI v3 Specification.

1.5. Approval Process in Oracle Service Registry

The approval process provides functionality to ensure consistency and quality of data stored in Oracle Service Registry. There are two registries in the approval process: • a publication registry is used for testing and verification of data; • a discovery registry only contains data that has been approved and promoted from the publication registry. See Section 5, Approval Process Registry Installation in the Installation Guide for details of how to install and configure these registries. The approval process includes two types of users: • A requestor is a user of the publication registry who can request approval of data for promotion to the discovery registry; • An approver is a user who can approve or reject requests for promotion of data. Administrators can specify: • the users or groups of users who are approvers; • the users or groups of users whose requests they can approve; Every user can ask for approval, but to have data considered for promotion, a user must have an administrator-assigned approver. For more information see Section 1.7, Approval Process Management in the Administrators Guide . Page 160

1.5. Approval Process in Oracle Service Registry