org.uddi.v3_service

Interface UDDISubscriptionPortType

All Superinterfaces:

Remote

public interface UDDISubscriptionPortType
extends Remote

This portType defines all of the UDDI subscription operations. This class was generated by the JAX-WS RI. JAX-WS RI 2.1.5-b03- Generated source version: 2.1 Subscription provides clients, known as subscribers, with the ability to register their interest in receiving information concerning changes made in a UDDI registry. These changes can be scoped based on preferences provided with the request. The APIs described below support this capability. Usage scenarios and examples are provided in Appendix C Supporting Subscribers. Each of the subscription APIs described here are OPTIONAL for UDDI implementations and MAY be implemented entirely at the discretion of a Node.

The subscription API set satisfies a variety of requirements. The flexibility of the subscription API allows monitoring of activity in a registry by registering to track new, changed and deleted entries for each of these entities:

· businessEntity

· businessService

· bindingTemplate

· tModel

· related businessEntity

· publisherAssertion (limited to those publisherAssertions for which the subscriber owns at least one of the businesses referenced)

With the exception of single publisher registries subscription typically is limited to authorized clients as a matter of node policy. Therefore, subscribers MUST typically authenticate with the node before saving subscription requests. Individual nodes, including those in the UDDI Business Registry, MAY establish policies concerning the use of the subscription APIs they choose to offer. Such policies might include restricting the use of subscription, defining which APIs are supported, establishing whether subscriptions require authentication, defining special rules affecting different classes of subscriptions, or even imposing fees for the use of these services. The use of the authInfo argument is OPTIONAL throughout the subscription APIs, although registries which support multiple users or which require authentication for publishing operations typically require it.

Subscription allows subscribers to "monitor" a particular subset of data within a registry. Two patterns are defined. Nodes MAY support either or both:

· Asynchronous notification – subscribers choose to be asynchronously notified by the node when registry data of interest changes via calls to the notify_subscriptionListener API, which they implement as a "subscription listener" service.

· Synchronous change tracking – subscribers issue a synchronous request using the get_subscriptionResults API to obtain information on activity in the registry which matches their subscription preferences.

A subscription request establishes criteria for the subscription and specifies how and if the subscriber is to be notified of changes matching the specified criteria. Any of the existing standard inquiry APIs (find_xx and get_xx) may be used within a subscription request to define the criteria, although nodes are free to restrict which inquiry APIs are supported in subscription as a matter of policy. The duration, or life of a subscription is also a matter of node policy, but subscribers can renew existing subscriptions periodically instead of having to create new ones. Subscribers may also create multiple subscriptions. Each subscription request is treated independently. The level of detail provided for the data returned is controlled by the subscription request.

When asynchronous notifications are requested, subscriptions provide information on new, changed or deleted entities within a registry that occur after the point in time that the subscription is registered. A node notifies subscribers based upon its identification of data matching the requested subscription criteria. Subscribers can choose to have these notifications provided via email or an HTTP/SOAP-based Web service, which the subscriber MAY implement. Such services are called "subscription listeners." Notifications are made periodically rather than in response to the continuous stream of changes that normally occur within the registry. This means that subscription results provided via notifications pertain only to the current state of the entities at the time they are reported – intermediate state changes are not provided. While subscribers can specify a frequency for these notifications, nodes MAY choose to restrict this as a matter of policy.

When synchronous requests are made for subscription results, the current state of the registry data, which matches the subscription criteria, is returned for entries that were last created, changed or deleted within a specified date range. Prior states of the registry data are not available and are not returned.

Subscriptions are owned by the subscriber who creates them. A subscriptionKey, which distinguishes each individual subscription, is not visible to anyone except the subscriber. While node policy MAY permit others besides the subscription’s owner to receive or retrieve subscription results, such interested parties require knowledge of the relevant subscriptionKey from the subscription owner in order to do so.

5.5.1.1 Definition of Changed Entities

As stated above, the subscription API allows monitoring of new, changed and deleted entities. This section provides the definition of changed entities. The following are the criteria for considering an entity to have been "changed":

· For businessEntity, businessService, bindingTemplate, and tModel:
The entity is considered to be changed if the modifiedIncludingChildren element of the operationalInfo element of the entity has been changed.

· For publisherAssertion:
A publisherAssertion is considered to be changed if the publisher has updated the publisherAssertion via the set_publisherAssertions, or add_publisherAssertions APIs.

· For related businessEntity:
A related businessEntity (related to the business specified in the businessKey argument of find_relatedBusinesses API) is considered to be changed if either:

1. the related businessEntity is changed, or

2. at least one of the two reciprocal publisherAssertions that represents the relationship is changed.

5.5.2 Specifying Durations

Time durations used in the subscription APIs are of type xsd:duration defined in XML Schema from [ISO 8601]. Any form supported by this data type is permitted. For example, the lexical representation extended format can be used, which is of the form PnYnMnDTnHnMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The "P" identifies the field as duration. The number of seconds can include decimal digits to arbitrary precision.

5.5.3 Specifying Points in Time

Points in time used in the subscription APIs are all of the XML Schema type, xsd:dateTime. Two points in time are used to specify a period of time.

5.5.4 Subscription Coverage Period

The APIs, which support each of the patterns previously described for obtaining subscription results, accept a coveragePeriod argument, which is composed of two points in time. Each of these corresponds to the last point in time which any given entity in the registry was modified (i.e., created, deleted or changed). The syntax of this element is:

Where:

· startPoint: Signifies the point in time after which subscription results are to be collected and/or returned. The startPoint is optional. If it is not specified, this indicates that all available results are to be returned from the beginning of the registry.

· endPoint: Signifies the point in time corresponding to the last activity date for entities matching subscription results. No activity among matching entities, which occurred after this point in time, is returned. The endPoint is optional. If not provided, it signifies that the latest changes available, which match the subscription criterions that are to be returned.

With respect to notifications, the startPoint of a given notification SHOULD align with the endPoint of the previous notification. If this is not the case, the subscriber SHOULD assume a notification was missed, or lost. The subscriber can then take corrective action by using the get_subscriptionResults API. Note that it is permissible for nodes to send the same data more than once, depending on overlaps in these times.

5.5.5 Chunking of Returned Subscription Data

If a subscriber specifies a maximum number of entries to be returned with a subscription and the amount of data to be returned exceeds this limit, or if the node determines based on its policy that there are too many entries to be returned in a single group, then the node SHOULD provide a chunkToken with results. The chunkToken is a string based token which is used by the node to maintain the state of the subscription results for a particular caller, when these results are chunked across multiple responses. The format and content of the chunkToken is a matter of implementation choice by individual nodes. The chunkToken returned with a particular subscription result set SHOULD be used to retrieve subsequent results when subscription results are requested in a synchronous manor. If no more results are pending, the value of the chunkToken MUST be "0".

A chunkToken is intended as a short-term aid in obtaining contiguous results across multiple API calls and is therefore likely to remain valid for only a short time. Nodes MAY establish policies on how long a chunkToken remains valid.

5.5.6 Use of keyBag in Subscription

The subscription results returned by the subscription APIs allow for the use of a structure called a keyBag. A keyBag contains a list of entity keys, which correspond to any of the core data structures (businessEntity, businessService, bindingTemplate or tModel). The keyBag has two uses.

· Returning results when a "brief" format is selected, which minimizes returned information.

· Indicating entities which have been deleted, or which no longer match the subscription criteria provided with the subscription. This later situation is referred to as a "virtual delete", in that the entity in question may not actually have be deleted from the registry, but it no longer matches the criterion which the subscriber defined in the subscription for tracking registry changes. It should be noted that nodes MUST maintain information pertaining to registry changes for both forms of deletion, to be reported with subscription results for applicable subscriptions, although they MAY establish policies on how long such information is retained. Further details on the use of this structure are discussed in the relevant API sections that follow. When the keyBag is used for deleted entities, the deleted element is set to "true," and all entities listed in such a keyBag are assumed to represent deletions.

A UDDI node MUST never inform the subscriber of an entity that temporarily matched the subscription criteria but was removed or modified to no longer match the subscription criteria before the subscriber was informed of the match.

A UDDI node MAY inform a subscriber about the real or virtual deletion of an entity multiple times.

The syntax of a keyBag is shown here:

5.5.7 Subscription API functions

The APIs in this section describe how to interact with a UDDI node implementation to create and manage requests for the tracking of new and changed registry content. These APIs are synchronous and are exposed via SOAP, although the notifications they may generate are not.

The subscription APIs are:

· delete_subscription: Cancels one or more specified subscriptions.

· get_subscriptionResults: Synchronously returns registry data pertaining to a particular subscription within a specified time period.

· get_subscriptions: Returns a list of existing subscriptions previously saved by the subscriber.

· save_subscription: Establishes a new subscription or changes an existing one. Also used to renew existing subscriptions.

The OPTIONAL client API is:

· notify_subscriptionListener: A node invoked API which the client implements as a subscription listener service to accept notifications containing the data that changed since notify_subscriptionListener was last invoked for a particular subscription.

Method Summary

Methods

Modifier and Type	Method and Description
void	deleteSubscription(DeleteSubscription body) Cancels an existing subscription.
SubscriptionResultsList	getSubscriptionResults(GetSubscriptionResults body) This API allows a subscriber to request that the information pertaining to an existing subscription be returned. This is useful, for example, to obtain historical data when a subscription is first set up or when a subscriber misses the notification normally provided by the registry. The results are returned synchronously as the response to this call. The get_subscriptionResults API can also be used as an alternative to notifications for obtaining subscription data.
List<Subscription>	getSubscriptions(String authInfo) Returns the complete list of existing subscriptions owned by the subscriber.
void	saveSubscription(String authInfo, Holder<List<Subscription>> subscription) The save_subscription API registers a request to monitor specific registry content and to have the node periodically notify the subscriber when changes are available.

Method Detail

deleteSubscription

void deleteSubscription(DeleteSubscription body)
                        throws DispositionReportFaultMessage,
                               RemoteException

Cancels an existing subscription.

Parameters:

body -

· authInfo: This optional argument is an element that contains an authentication token. Registries that wish to restrict who can delete a subscription typically require authInfo for this call, though this is a matter of node policy.

· subscriptionKey: This required argument specifies, using anyURIs, the subscription or subscriptions to be deleted.

If no errors occur then an empty message is returned.

Throws:

DispositionReportFaultMessage, - RemoteException

If an error occurs in processing this API call, a dispositionReport structure is returned to the caller in a SOAP Fault. In addition to the errors common to all APIs, the following error information is relevant here:

· E_userMismatch: signifies that an attempt has been made to use the subscription API to delete a subscription that is controlled by another party.

· E_invalidKeyPassed: signifies that the subscriptionKey is invalid or that the subscription has expired.

DispositionReportFaultMessage

RemoteException

getSubscriptionResults

SubscriptionResultsList getSubscriptionResults(GetSubscriptionResults body)
                                               throws DispositionReportFaultMessage,
                                                      RemoteException

This API allows a subscriber to request that the information pertaining to an existing subscription be returned. This is useful, for example, to obtain historical data when a subscription is first set up or when a subscriber misses the notification normally provided by the registry. The results are returned synchronously as the response to this call. The get_subscriptionResults API can also be used as an alternative to notifications for obtaining subscription data. If this is the preference, then the subscriber SHOULD not provide a bindingKey when saving the associated subscription. See Section 5.5.8 save_subscription. This API is not affected by the value of the notificationInterval in the subscription.

Parameters:

body -

· authInfo: This optional argument is an element that contains an authentication token. Registries that wish to restrict who can retrieve subscription data typically require authInfo for this call, though this is a matter of node policy.

· chunkToken: This optional argument is used to retrieve subsequent groups of data when the first call to this API indicates more data is available. This occurs when a chunkToken is returned whose value is not "0" in the subscriptionResultsList structure described in the next section. To retrieve the next chunk of data, the value returned should be used as an argument to the next invocation of this API.

· coveragePeriod: This structure defines the time period over which the most recent changes in node data are compared with the subscription criteria in order to produce the result set. It provides start and end date/time information according to the format described in Section 5.5.4 Subscription Coverage Period. The "current" state of registry entries pertaining to the subscription referenced by the subscriptionKey provided are returned if they were last created, changed or deleted during the specified time period.

· subscriptionKey: This required argument of type anyURI identifies the subscription for which non-recurring synchronous results are being sought.

Returns:

returns org.uddi.sub_v3.SubscriptionResultsList

A subscriptionResultsList is returned whose content is determined by the coveragePeriod and the criteria in the subscription:

Attributes

Name	Use
someResultsUnavailable	optional

Subscription results MAY be chunked. See Section 5.5.5 Chunking of Returned Subscription Data, for more information on chunking of results. If results are chunked, then subsequent "chunks" can be retrieved using the chunkToken returned as an argument in a subsequent invocation of this API.

Note that the results returned in the subscriptionResultsList represent a snapshot of the current state of relevant entries in the registry. They are non-transactional in nature and prior states cannot be returned. Deleted entities and virtual deletes of entities, which have been changed in such a way that they no longer match the subscription criterion saved with the subscription, are returned only in the form of a keyBag structure, for which the deleted element is set to "true". A UDDI node MAY inform a subscriber about the real or virtual deletion of an entity multiple times.

The someResultsUnavailable attribute is set to "true" whenever the node has found it necessary to flush subscription results information pertaining to entity deletions (either actual or virtual) which pertain to this subscription, which have not yet been reported through prior calls to this API, or through use of the notify_subscriptionListener API described below. The period of time which a node retains information on deletions for a given subscription is a matter of node policy.

The API used in the subscription filter determines the sort order for returned entities. By default, they will be sorted according to the behavior specified in the "returns" section of that API.

Throws:

DispositionReportFaultMessage, - RemoteException

If an error occurs in processing this API call, a dispositionReport structure is returned to the caller in a SOAP Fault. In addition to the errors common to all APIs, the following error information is relevant here:

· E_invalidKeyPassed: signifies that the subscriptionKey is invalid or that the subscription has expired.

· E_invalidValue: signifies that the chunkToken value supplied is either invalid or has expired.

· E_unsupported: signifies that one of the argument values was not supported by this implementation. The offending argument is clearly indicated in the error text.

· E_userMismatch: signifies that, in a violation of node policy, an attempt has been made to use the subscription API to change a subscription that is controlled by another party.

· E_invalidTime: signifies that one or both of the values provided in the coveragePeriod range is invalid or does not define a range. The error structure signifies the condition that occurred and the error text clearly calls out the cause of the problem.

DispositionReportFaultMessage

RemoteException

getSubscriptions

@RequestWrapper(localName="get_subscriptions",
                targetNamespace="urn:uddi-org:sub_v3",
                className="org.uddi.sub_v3.GetSubscriptions")
@ResponseWrapper(localName="subscriptions",
                 targetNamespace="urn:uddi-org:sub_v3",
                 className="org.uddi.sub_v3.Subscriptions")
List<Subscription> getSubscriptions(String authInfo)
                                    throws DispositionReportFaultMessage,
                                           RemoteException

Returns the complete list of existing subscriptions owned by the subscriber.

Parameters:

authInfo - authInfo: This optional argument is an element that contains an authentication token. Registries that wish to restrict who can obtain information on subscriptions typically require authInfo for this call, though this is a matter of node policy.

Returns:

returns java.util.List This API call returns information on all of the subscriptions owned by the subscriber, together with the expiration date for each. The subscriptions structure returned contains zero or more subscription structures, each pertaining to a subscription. Only subscriptions created by the invoking subscriber are returned. See Section 5.5.8.1, [save_subscription] Syntax, for details on these structures.

Throws:

DispositionReportFaultMessage, - RemoteException

DispositionReportFaultMessage

RemoteException

saveSubscription

@RequestWrapper(localName="save_subscription",
                targetNamespace="urn:uddi-org:sub_v3",
                className="org.uddi.sub_v3.SaveSubscription")
@ResponseWrapper(localName="subscriptions",
                 targetNamespace="urn:uddi-org:sub_v3",
                 className="org.uddi.sub_v3.Subscriptions")
void saveSubscription(String authInfo,
                                                                                                                     Holder<List<Subscription>> subscription)
                      throws DispositionReportFaultMessage,
                             RemoteException

The save_subscription API registers a request to monitor specific registry content and to have the node periodically notify the subscriber when changes are available. Notifications are not returned synchronously with results for this API. Only data that matches the requested subscription criteria and which changes after the point in time that the subscription request is accepted is returned to the subscriber via a notification. This API returns a duration for which this particular subscription is valid. Depending upon the policy of the Node, subscriptions need to be renewed before the expiration date in order to insure that they remain active. Subscriptions can also be redefined or renewed using this API. The subscriptionKey pertaining to the subscription to be renewed must be supplied in the save_subscription invocation in order to accomplish this. This allows both renewal and changes to the subscription. Invoking save_subscription automatically resets the expiration period for the subscription in question to a value based upon the node’s policy.

The syntax of the subscription structure is:

Attributes

Name	Use
brief	optional

The syntax of the subscriptionFilter structure is:

Parameters:

subscription -

· bindingKey: This optional argument of type anyURI specifies the bindingTemplate which the node is to use to deliver notifications to subscription listeners. It is only required when asynchronous notifications are used. This bindingTemplate MUST define either a Web service that implements notify_subscriptionListener (see below), or an email address to receive the notifications. If a notify_subscriptionListener Web service is identified, the node invokes it to deliver notifications. If an email address is identified, the node delivers notifications via email to the address supplied. When notifications are delivered via email, the body of the email contains the body of the SOAP message, which would have been sent to the notify_subscriptionListener service if that option had been chosen.. The publisher making the subscription request MUST own the bindingTemplate. If this argument is not supplied, no notifications are sent, although subscribers may still use the get_subscriptionResults API to obtain subscription results. See Section 5.5.11 get_subscriptionResults for details. If email delivery to the specified address fails, nodes MAY attempt re-delivery, but are not obligated to do so. Depending upon node policy, excessive delivery failures MAY result in cancellation of the corresponding subscription.

· brief: This optional argument controls the level of detail returned to a subscription listener. The default is "false" when omitted. When set to "true," it indicates that the subscription results are to be returned to the subscriber in the form of a keyBag, listing all of the entities that matched the subscriptionFilter. Refer to Section 5.5.6 Use of keyBag in Subscription, for additional information. This option has no effect on the assertionStatusReport structure, which is returned as part of a notification when the subscriptionFilter specifies the get_assertionStatusReport filter criteria. See the explanation of subscriptionFilter below.

· expiresAfter: This optional argument allows subscribers to specify the period of time for which they would like the subscription to exist. It is of the XML Schema type xsd:dateTime. Specifying a value for this argument is no guarantee that the node will accept it without change. Information on the format of expiresAfter can be found in Section 5.5.1.1 Specifying Durations.

· maxEntities: This optional integer specifies the maximum number of entities in a notification returned to a subscription listener. If not specified, the number of entities sent is not limited, unless by node policy.

· subscriptionFilter: This argument specifies the filtering criteria which limits the scope of a subscription to a subset of registry records. It is required except when renewing an existing subscription. The get_xx and find_xx APIs are all valid choices for use as a subscriptionFilter. Only one of these can be chosen for each subscription. Notifications, based on the subscriptionFilter, are sent to the subscriber if and only if there are changes at the node, which match this criterion during a notification period. A subscriptionFilter MUST contain exactly one of the allowed inquiry elements. The authInfo argument of the specified get_xx or find_xx API call is not required here and is ignored if specified. All of the other arguments supported with each of these inquiry APIs are valid for use here.

Specifying find_relatedBusinesses is useful for tracking when reciprocal relationships are formed or dissolved. Specifying get_assertionStatusReport can be used in tracking when reciprocal relationships (which pertain to a business owned by the subscriber) are formed, dissolved, or requested by the owners of some other business.

For a get_assertionStatusReport based subscription, there is a specific status value, status:both_incomplete, defined in the XML schema. When appearing in an assertionStatusItem of a subscriptionResultsList, status:both_incomplete indicates that the publisher assertion embedded in the assertionStatusItem has been deleted from both ends.

Note that the above handling of deleted publisher assertions is different from the case when a business entity, business service, binding template, or tModel is removed. In the latter case, the key to the entity in question is simply put inside a keyBag. A publisher assertion, on the other hand, has no key and therefore the keyBag idea is not applicable.

· subscriptionKey: This optional argument of type anyURI identifies the subscription. To renew or change an existing subscription, a valid subscriptionKey MUST be provided. When establishing a new subscription, the subscriptionKey MAY also be either omitted or specified as an empty string in which case the node MUST assign a unique key. If subscriptionKey is specified for a new subscription, the key MUST conform to the registry’s policy on publisher-assigned keys.

· notificationInterval: This optional argument is only required when asynchronous notifications are used. It is of type xsd:duration and specifies how often change notifications are to be provided to a subscriber. If the notificationInterval specified is not acceptable due to node policy, then the node adjusts the value to match the next longer time period that is supported. The adjusted value is provided with the returns from this API. Also see Section 5.5.1.1 Specifying Durations.

authInfo - authInfo: This optional argument is an element that contains an authentication token. Registries that wish to restrict who can save a subscription typically require authInfo for this call, though this is a matter of node policy.

return

Upon successful completion this API returns a subscriptions structure. Included in the subscription structure(s) it MUST contain is a subscriptionKey (of type anyURI) that is used by the subscriber to manage the subscription. This key is required in order to delete (unsubscribe), modify or renew the subscription. If a subscriber has multiple subscriptions, the subscriptionKey can be used to distinguish between different subscriptions. The subscriptionKey is also part of the data contained in the notifications returned to subscription listeners.

The subscription structure(s) returned from this API, MUST each contain an expiresAfter value, which has been assigned by the node. Nodes SHOULD attempt to honor the value(s) provided with the save_subscription request, but MAY modify them based on node policy. Depending upon the node’s policy, the node MAY delete a subscription after it has expired.

The value of the notificationInterval included in the subscription structure(s) returned MAY be adjusted by the node to the value closest to that requested which is supported by its policies. Depending upon the Registry’s workload a node MAY skip a notification cycle. If a cycle is skipped, the next notification sent SHOULD include information based on registry activity, which has occurred since the last notification was issued.

Throws:

DispositionReportFaultMessage, - RemoteException

If any error occurs in processing this API call, a dispositionReport structure is returned to the caller in a SOAP Fault. In addition to the errors common to all APIs, the following error information is relevant here:

· E_invalidKeyPassed: signifies that an entity key value passed did not match with any known key values. The error structure signifies that the condition occurred and the error text clearly calls out the offending key.

· E_unsupported: signifies that one of the argument values was not supported by this implementation. The offending argument is clearly indicated in the error text.

· E_resultSetTooLarge: signifies that the node refuses to accept the subscription because it deems that result sets associated with the subscription are too large. The subscription criteria that triggered this error should be refined and re-issued.

· E_accountLimitExceeded: signifies that the request exceeded the quantity limits for subscription requests, based on node policy.

· E_userMismatch: signifies that an attempt has been made to use the subscription API to change a subscription that is controlled by another party. Or that the bindingTemplate specified does not belong to the publisher.

· E_requestDenied: signifies that the subscription cannot be renewed. The request has been denied due to either node or registry policy.

DispositionReportFaultMessage

RemoteException