org.uddi.v3_service.UDDISubscriptionPortType Maven / Gradle / Ivy
/*
* Copyright 2001-2008 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
package org.uddi.v3_service;
import java.rmi.Remote;
import java.rmi.RemoteException;
import java.util.List;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.xml.bind.annotation.XmlSeeAlso;
import javax.xml.ws.Holder;
import javax.xml.ws.RequestWrapper;
import javax.xml.ws.ResponseWrapper;
import org.uddi.sub_v3.DeleteSubscription;
import org.uddi.sub_v3.GetSubscriptionResults;
import org.uddi.sub_v3.Subscription;
import org.uddi.sub_v3.SubscriptionResultsList;
/**
* 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.
*/
@WebService(name = "UDDI_Subscription_PortType", targetNamespace = "urn:uddi-org:api_v3_portType")
@XmlSeeAlso({
org.uddi.custody_v3.ObjectFactory.class,
org.uddi.repl_v3.ObjectFactory.class,
org.uddi.subr_v3.ObjectFactory.class,
org.uddi.api_v3.ObjectFactory.class,
org.uddi.vscache_v3.ObjectFactory.class,
org.uddi.vs_v3.ObjectFactory.class,
org.uddi.sub_v3.ObjectFactory.class,
org.w3._2000._09.xmldsig_.ObjectFactory.class,
org.uddi.policy_v3.ObjectFactory.class,
org.uddi.policy_v3_instanceparms.ObjectFactory.class
})
public interface UDDISubscriptionPortType extends Remote {
/**
*Cancels an existing subscription.
*
* @param 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.
*/
@WebMethod(operationName = "delete_subscription", action = "delete_subscription")
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
public void deleteSubscription(
@WebParam(name = "delete_subscription", targetNamespace = "urn:uddi-org:sub_v3", partName = "body") DeleteSubscription 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.
* @param 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.
* 
* @return 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.
*/
@WebMethod(operationName = "get_subscriptionResults", action = "get_subscriptionResults")
@WebResult(name = "subscriptionResultsList", targetNamespace = "urn:uddi-org:sub_v3", partName = "body")
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
public SubscriptionResultsList getSubscriptionResults(
@WebParam(name = "get_subscriptionResults", targetNamespace = "urn:uddi-org:sub_v3", partName = "body") GetSubscriptionResults body)
throws DispositionReportFaultMessage, RemoteException;
/**
* Returns the complete list of existing subscriptions owned by the
* subscriber.
*
* @param 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.
* @return 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
*/
@WebMethod(operationName = "get_subscriptions", action = "get_subscriptions")
@WebResult(name = "subscription", targetNamespace = "urn:uddi-org:sub_v3")
@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")
public List getSubscriptions(
@WebParam(name = "authInfo", targetNamespace = "urn:uddi-org:api_v3") String authInfo)
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:
* @param 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.
* @param 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.
*/
@WebMethod(operationName = "save_subscription", action = "save_subscription")
@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")
public void saveSubscription(
@WebParam(name = "authInfo", targetNamespace = "urn:uddi-org:api_v3") String authInfo,
@WebParam(name = "subscription", targetNamespace = "urn:uddi-org:sub_v3", mode = WebParam.Mode.INOUT) Holder> subscription)
throws DispositionReportFaultMessage, RemoteException;
}