UDDI APIs Basic Concepts of the UDDI Specification

1.3.7. Technical Notes

Technical Notes TN are non-normative documents accompanying the UDDI Specification that provide guidance on how to use UDDI registries. Technical Notes can be found at http:www.oasis-open.orgcommitteesuddi-specdoctns.htm . One of the most important TNs is Using WSDL in a UDDI Registry.

1.3.8. Benefits of UDDI Version 3

The most important features include: • User-friendly identifiers facilitate reuse of service descriptions among registries. • Support for digital signatures allows UDDI to deliver a higher degree of data integrity and authenticity. • Extended discovery features can combine previous, multi-step queries into a single-step, complex query. UDDI now also provides the ability to nest sub-queries within a single query, letting clients narrow their searches much more efficiently.

1.4. Subscriptions in Oracle Service Registry

Subscriptions are used to alert interested users in changes made to structures in Oracle Service Registry. The Oracle 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 Control, 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.

1.4.1. Subscription Arguments

A subscription is the subscribers 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 Administrators Guide, Section 2, 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. Page 158

1.4.1. Subscription Arguments

• 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