Return-Path: X-Original-To: apmail-juddi-commits-archive@www.apache.org Delivered-To: apmail-juddi-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7CE1FFBF8 for ; Mon, 29 Apr 2013 02:49:40 +0000 (UTC) Received: (qmail 48927 invoked by uid 500); 29 Apr 2013 02:49:40 -0000 Delivered-To: apmail-juddi-commits-archive@juddi.apache.org Received: (qmail 48891 invoked by uid 500); 29 Apr 2013 02:49:40 -0000 Mailing-List: contact commits-help@juddi.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list commits@juddi.apache.org Received: (qmail 48884 invoked by uid 99); 29 Apr 2013 02:49:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Apr 2013 02:49:40 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Apr 2013 02:49:34 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id 623282388A6C; Mon, 29 Apr 2013 02:49:12 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: svn commit: r1476880 [3/3] - in /juddi/branches/juddi-3.2.x: juddi-gui-dsig/ juddi-gui/ juddi-gui/license/ juddi-gui/src/java/org/apache/juddi/webconsole/hub/ juddi-gui/src/java/org/apache/juddi/webconsole/hub/builders/ juddi-gui/src/java/org/apache/ju... Date: Mon, 29 Apr 2013 02:49:10 -0000 To: commits@juddi.apache.org From: alexoree@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20130429024912.623282388A6C@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Modified: juddi/branches/juddi-3.2.x/uddi-ws/src/main/java/org/uddi/v3_service/UDDICustodyTransferPortType.java URL: http://svn.apache.org/viewvc/juddi/branches/juddi-3.2.x/uddi-ws/src/main/java/org/uddi/v3_service/UDDICustodyTransferPortType.java?rev=1476880&r1=1476879&r2=1476880&view=diff ============================================================================== --- juddi/branches/juddi-3.2.x/uddi-ws/src/main/java/org/uddi/v3_service/UDDICustodyTransferPortType.java (original) +++ juddi/branches/juddi-3.2.x/uddi-ws/src/main/java/org/uddi/v3_service/UDDICustodyTransferPortType.java Mon Apr 29 02:49:09 2013 @@ -14,8 +14,6 @@ * limitations under the License. * */ - - package org.uddi.v3_service; import java.rmi.Remote; @@ -34,14 +32,215 @@ import org.uddi.custody_v3.DiscardTransf import org.uddi.custody_v3.KeyBag; import org.uddi.custody_v3.TransferEntities; - /** - * This portType defines all of the UDDI custody transfer operations. - * - * This class was generated by the JAX-WS RI. - * JAX-WS RI 2.1.5-b03- - * Generated source version: 2.1 - * + * This portType defines all of the UDDI custody transfer operations. This + * section defines the UDDI Custody and Ownership Transfer API Set[28]. Data + * custody is introduced in Section 1.5.6 Data Custody. Ownership transfer is + * introduced in Section 1.5.7 Transfer of Ownership. By virtue of having + * created an entity, a publisher has ownership of the entity and is said to be + * the owner of the entity. A custodial node MUST maintain a relationship of + * ownership between an entity and its publisher by means of authorization + * mechanisms. Every node of a multi-node registry MUST guarantee the integrity + * of an entity's custody. As such, a node MUST not permit changes to an entity + * unless it has custody of it. + * + * The Custody and Ownership Transfer API Set enables any nodes of a registry to + * cooperatively transfer custody of one or more businessEntity or tModel + * structures from one node to another, as well as allowing the transfer of + * ownership of these structures from one publisher to another. Associated + * entities of a businessEntity such as its businessService, bindingTemplate, + * and publisherAssertion structures are transferred as part of the custody + * transfer of the business entity. * + * From a custody transfer point of view, the publishers are always distinct, + * though it may be the case that the publishers are the same person. Also, the + * two nodes may or may not be distinct; intra-node transfer between two + * publishers is simply a degenerate case in which node custody does not change. + * Thus, in the case of an inter-node transfer, ownership transfer is implied. + * In the case of an intra-node transfer the behavior results in the transfer of + * ownership between two publishers. + * + * For example, one UDDI registry, UDDI-1, MAY allow each node in UDDI-1 + * (composed of nodes 1A, 1B and 1C) to define its own policies for + * registration, authentication and authorization. In this case, a "person", + * (P1) would need to review the policies of all 3 nodes and decide upon the + * node with which it chooses to register with. P1 may choose to register with + * more than one node. P1 registers with node1A . Node1A also specifies how P1 + * is authenticated. If P1 successfully authenticates and publishes a business + * entity (BE1) then P1 becomes the "owner" of BE1. Node1A is said to be the + * "custodian" of BE1. P1 can also register at node1B. If P1 successfully + * authenticates and publishes a business entity (BE2) then P1 becomes the + * "owner" of BE2. Node1B is said to be the "custodian" of BE2. There is no + * assumption that the registry UDDI-1 or its nodes (node1A and node1B) are + * aware that P1 is the same "person". P1 is responsible for maintaining the + * appropriate identity and authenticating correctly to each node within a + * registry. + * + * Another UDDI registry, UDDI-2, MAY require each of its nodes (node2-1, + * node2-2 and node2-3) to use the same registration, authentication and + * authorization mechanisms. In this case, the policies are the same across all + * nodes. The relationship of registration, publication and ownership remains + * the same. If P1 wants to register with different nodes in UDDI-2, then it + * needs to differentiate its registration with the different nodes, since an + * attempt to register at node2-2 after registering at node2-1, would fail as + * "already registered" (since by policy the nodes all share the same + * registration, authentication and authorization). + * + * 5.4.1 Overview There are a number of scenarios where a publisher may choose + * to transfer custodianship or ownership of one or more entities. These are + * described in this section. + * + * 5.4.1.1 Intra-Node Ownership Transfer Intra-node ownership transfer involves + * transferring entity ownership from one publisher to another within the same + * UDDI node. Usage scenarios for this type of transfer include the following: + * + * · Businesses or organizational merges: Multiple organizations need to be + * consolidated under the control of a single publisher. + * + * · Domain key generators: One use of ownership transfer is the transfer of + * ownership of a derived key generator from one publisher to another to enable + * her or him to publish entities using keys in that domain. + * + * The save_xx APIs can also be used to move entities between parent entities + * that are owned by the same publisher. The save_service API, for example, can + * be used to move services (and binding templates) between one business entity + * and another as described in Section 5.2.17.3 Behavior of the save_service + * API. Changing the parent relationship in this way causes two businessEntity + * structures to be changed. Doing so enables the following scenarios: + * + * · Divestitures: An organization needs to reassign the control of a set of + * services to two or more publishers. + * + * · Consolidation of registry entities: There are multiple entities for a given + * business that are to be consolidated under a single publisher. + * + * 5.4.1.2 Inter-Node Custody Transfer Inter-node custody transfer involves the + * custody transfer of a set of entities across nodes of a UDDI registry. A + * transfer of ownership ensues as a consequence of this custody transfer. In + * addition to the intra-node scenarios described above, inter-node custody + * transfer may be used to address the following use cases: + * + * · Unsatisfactory service level: The functionality or service level provided + * by a given node operator is insufficient, and the publisher wishes to move + * their UDDI data to another node. + * + * · Change in availability for a UDDI node: A node is no longer providing UDDI + * services, and all publishers need to be migrated to one or more nodes of the + * registry. + * + * · Organizational Mergers, Divestitures or Consolidations: Changes in + * organizational structure may result in the need to make changes to the set of + * publishers used to manage the entities at various nodes of a registry. + * + * For any of these intra and inter-node scenarios, a mechanism is specified to + * facilitate the transfer the custody of businessEntity and tModel entities + * between nodes whether the entity is being transferred within a single node or + * whether a custody transfer occurs between nodes of a registry. + * + * 5.4.2 Custody Transfer Considerations When a businessEntity is transferred, + * all related businessService and bindingTemplate elements are transferred as + * well. In addition, any publisherAssertion elements that reference the + * businessEntity element’s businessKey that are owned by the publisher are also + * transferred. + * + * Note that the relinquishing publisher is not required to transfer all of its + * UDDI entities (i.e. businessEntity and/or tModel entities) in a single + * custody transfer request, nor is it required to transfer all of its entities + * to the same target publisher or target node. Any combination or subset of + * UDDI registry entities may be transferred to any number of target publishers + * or nodes. + * + * 5.4.3 Transfer Execution The Custody and Ownership Transfer API Set enables + * two publishers P1 and P2 and two nodes, N1 and N2, in a registry to + * cooperatively transfer custody of one or more existing businessEntity or + * tModel structures, E1…En, from N1 to N2 and, and by extension to transfer + * ownership of the entities from P1 to P2. Related businessService, + * bindingTemplate, and publisherAssertion structures are transferred with their + * related businessEntities. From the registry’s point of view, the publishers + * are always distinct, though it may be the case that P1 and P2 are the same + * party. The two nodes may or may not be distinct; intra-node transfer of + * ownership from P1 to P2 is simply a degenerate case in which node custody + * does not change. + * + * The Custody and Ownership Transfer API Set is divided into two parts, a set + * of two client APIs and a single inter-node API. These client APIs are + * get_transferToken and transfer_entities; in short, this constitutes the + * Ownership Transfer API portion of this API set. The inter-node-API is + * transfer_ custody which when combined with replication makes up the Custody + * Transfer API portion of this API set. * + * The overall flow of custody and ownership transfer is as follows: + * + * Publisher P1 invokes get_transferToken on N1, specifying the keys K1…Kn of + * the entities E1…En that are to be transferred. If P1 is authorized to do this + * (i.e., if P1 has ownership of E1…En), N1 returns a structure T, called a + * transfer token, that represents authority to transfer the entities, including + * all of the naturally contained children and publisher assertions related to + * business entities involved in the transfer that are owned by P1. The + * transferToken is a structure that consists of an opaque string that is + * meaningful only to the node that issued it, an expiration time, and a node + * identifier. + * + * P1 then gives T to P2 (typically by some secure means since T is valuable). + * The publisher obtaining the custody information needs to have previously + * obtained a publishers account on the node accepting custody of the entity + * before he/she can complete the custody transfer. P2 then invokes + * transfer_entities on N2, passing K1…Kn and T. If transfer_entities completes + * successfully, the entities E1…En and their related structures + * (businessService, bindingTemplate, and publisherAssertion) are in the custody + * of N2 and are owned by P2. If the operation fails, nothing happens to the + * entities. The actual transfer proceeds as follows, in the processing of + * transfer_entities. + * + * If N1 and N2 are not distinct nodes, the ownership transfer from P1 to P2 is + * an operation that is purely internal to the node – how it happens is up to + * the implementation. If N1 and N2 are distinct, the following protocol occurs + * while processing the transfer_entities request on N2. + * + * Upon receipt of a transfer_entities request, N2 checks that K1…Kn are valid + * keys. There is the possibility that P1 might transfer more data than P2 can + * accept due to policy-based restrictions on the limit of entities allowed to + * be owned by P2 at N2. As is described below, replication is used to complete + * the custody transfer process. A question that arises is at the time of + * accepting the datum related to the transfer, could N2 throw a replication + * error because the data being transferred exceeds the limits of user P2? Such + * limits can not be enforced during replication because they are node-local + * policy decisions from the perspective of enforcement. Thus, it is therefore + * possible that as a result of a custody transfer a publisher may be caused to + * hold more data that he/she would have been able to publish. Should this + * situation occur, P2 MUST not be allowed to publish any additional data unless + * P2 first reduces the number of entries it owns to an allowable limit. + * + * If all is well, N2 invokes the inter-node API transfer_custody on N1, + * presenting the keys of top-level entities to be transferred, K1…Kn, P2’s + * identity (using the publisher’s authorizedName), N2’s node identifier (as + * known in the Replication Configuration structure, see Section 7.5.2 + * Configuration of a UDDI Node – operator element), and T. The transferToken, + * T, implies permission to transfer the entire content of the entities it + * identifies, including all of the contained entities and related + * publisherAssertions, if any. N1 checks to see whether T is a valid + * transferToken that it issued and that T represents the authority to transfer + * E1…En. If the validation is successful, N1 prevents further changes to + * entities E1…En. N1 then updates the authorizedName and nodeID of the + * operationalInfo of E1…En and related entities so that they are shown to be in + * the custody of N2 and owned by P2. Finally, N1 responds to N2 which triggers + * N2 to respond to the transfer_entities caller. This completes the processing + * for the transfer_entities request. + * + * In the case that the datum being transferred is a key generator tModel, N1 + * will disallow further generation of keys associated with this key partition + * at its node. + * + * Following the issue of the empty message by N1 to the transfer_custody call, + * N1 will submit into the replication stream a changeRecordNewData providing in + * the operationalInfo, N2’s nodeID identifying it as the node where the datum + * is being transferred to, and the authorizedName of P2. The + * acknowledgmentRequested attribute of this change record MUST be set to + * "true". + * + * The last modified date timestamp in the operationalInfo must change to + * reflect the custody transfer. Figure 2 depicts the flow of a custody transfer + * between P1 and P2. This class was generated by the JAX-WS RI. JAX-WS RI + * 2.1.5-b03- Generated source version: 2.1 + * */ @WebService(name = "UDDI_CustodyTransfer_PortType", targetNamespace = "urn:uddi-org:v3_service") @XmlSeeAlso({ @@ -56,62 +255,85 @@ import org.uddi.custody_v3.TransferEntit org.uddi.policy_v3.ObjectFactory.class, org.uddi.policy_v3_instanceparms.ObjectFactory.class }) -public interface UDDICustodyTransferPortType extends Remote{ - +public interface UDDICustodyTransferPortType extends Remote { /** - * + * The discard_transferToken API is a client API used to discard a + * transferToken obtained through the get_transferToken API at the same + * node. This API accepts either a transferToken or a keyBag as parameters + * to remove the permission to transfer data associated with a particular + * transferToken. If a keyBag is provided, all tokens corresponding to the + * keys in the keyBag will be discarded and will no longer be valid for + * custody or ownership transfer after the discard_transferToken is + * processed, irrespective of whether the keys match any known business or + * tmodelKey values. In the event that the keyBag represents a subset of the + * keyBag for one or more transferToken elements, the transferToken is + * discarded and will no longer be valid for transferring any entity. If the + * token passed in the transferToken argument does not match an existing + * token known to the system, no action is taken and success is reported. + * Keys in the keyBag argument that do not have a corresponding token are + * ignored. + * * @param body * @throws DispositionReportFaultMessage, RemoteException */ @WebMethod(operationName = "discard_transferToken", action = "discard_transferToken") @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE) public void discardTransferToken( - @WebParam(name = "discard_transferToken", targetNamespace = "urn:uddi-org:custody_v3", partName = "body") - DiscardTransferToken body) - throws DispositionReportFaultMessage, RemoteException - ; + @WebParam(name = "discard_transferToken", targetNamespace = "urn:uddi-org:custody_v3", partName = "body") DiscardTransferToken body) + throws DispositionReportFaultMessage, RemoteException; - /** - * + * * @param authInfo * @param keyBag * @param nodeID * @param expirationTime * @param opaqueToken * @throws DispositionReportFaultMessage - * @throws RemoteException + * @throws RemoteException */ @WebMethod(operationName = "get_transferToken", action = "get_transferToken") @RequestWrapper(localName = "get_transferToken", targetNamespace = "urn:uddi-org:custody_v3", className = "org.uddi.custody_v3.GetTransferToken") @ResponseWrapper(localName = "transferToken", targetNamespace = "urn:uddi-org:custody_v3", className = "org.uddi.custody_v3.TransferToken") public void getTransferToken( - @WebParam(name = "authInfo", targetNamespace = "urn:uddi-org:api_v3") - String authInfo, - @WebParam(name = "keyBag", targetNamespace = "urn:uddi-org:custody_v3") - KeyBag keyBag, - @WebParam(name = "nodeID", targetNamespace = "urn:uddi-org:api_v3", mode = WebParam.Mode.OUT) - Holder nodeID, - @WebParam(name = "expirationTime", targetNamespace = "urn:uddi-org:custody_v3", mode = WebParam.Mode.OUT) - Holder expirationTime, - @WebParam(name = "opaqueToken", targetNamespace = "urn:uddi-org:custody_v3", mode = WebParam.Mode.OUT) - Holder opaqueToken) - throws DispositionReportFaultMessage, RemoteException - ; + @WebParam(name = "authInfo", targetNamespace = "urn:uddi-org:api_v3") String authInfo, + @WebParam(name = "keyBag", targetNamespace = "urn:uddi-org:custody_v3") KeyBag keyBag, + @WebParam(name = "nodeID", targetNamespace = "urn:uddi-org:api_v3", mode = WebParam.Mode.OUT) Holder nodeID, + @WebParam(name = "expirationTime", targetNamespace = "urn:uddi-org:custody_v3", mode = WebParam.Mode.OUT) Holder expirationTime, + @WebParam(name = "opaqueToken", targetNamespace = "urn:uddi-org:custody_v3", mode = WebParam.Mode.OUT) Holder opaqueToken) + throws DispositionReportFaultMessage, RemoteException; /** - * - * @param body + * The transfer_entities API is used by publishers to whom custody is being + * transferred to actually perform the transfer. The recipient publisher + * must have an unexpired transferToken that was issued by the custodial + * node for the entities being transferred. + * + * @param body authInfo: This OPTIONAL argument is an element that contains + * an authentication token. Authentication tokens are obtained using the + * get_authToken API call or through some other means external to this + * specification, and represent the identity of the publisher at a UDDI + * node, in this case, the new owner of the entities being transferred. + * + * · transferToken: Required argument obtained from the custodial node via a + * call to get_transferToken by the publisher requesting a transfer of + * custody. The transferToken contains an opaque token, an expiration date, + * and the identity of the custodial node. The transferToken represents + * permission to transfer the entities that have been identified via a prior + * call to the get_transferToken API. + * + * · keyBag: One or more uddiKeys associated with businessEntity or tModel + * entities that are to be transferred to this publisher at the target node + * in the registry. The set of keys must be the same as the set of keys in + * the keyBag of the get_transferToken API call from which the given + * transferToken was once obtained. * @throws DispositionReportFaultMessage, RemoteException */ @WebMethod(operationName = "transfer_entities", action = "transfer_entities") @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE) public void transferEntities( - @WebParam(name = "transfer_entities", targetNamespace = "urn:uddi-org:custody_v3", partName = "body") - TransferEntities body) - throws DispositionReportFaultMessage, RemoteException - ; - + @WebParam(name = "transfer_entities", targetNamespace = "urn:uddi-org:custody_v3", partName = "body") TransferEntities body) + throws DispositionReportFaultMessage, RemoteException; }  \ No newline at end of file Modified: juddi/branches/juddi-3.2.x/uddi-ws/src/main/java/org/uddi/v3_service/UDDISubscriptionPortType.java URL: http://svn.apache.org/viewvc/juddi/branches/juddi-3.2.x/uddi-ws/src/main/java/org/uddi/v3_service/UDDISubscriptionPortType.java?rev=1476880&r1=1476879&r2=1476880&view=diff ============================================================================== --- juddi/branches/juddi-3.2.x/uddi-ws/src/main/java/org/uddi/v3_service/UDDISubscriptionPortType.java (original) +++ juddi/branches/juddi-3.2.x/uddi-ws/src/main/java/org/uddi/v3_service/UDDISubscriptionPortType.java Mon Apr 29 02:49:09 2013 @@ -14,8 +14,6 @@ * limitations under the License. * */ - - package org.uddi.v3_service; import java.rmi.Remote; @@ -35,14 +33,35 @@ import org.uddi.sub_v3.GetSubscriptionRe 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 - * + * + * This class was generated by the JAX-WS RI. JAX-WS RI 2.1.5-b03- Generated + * source version: 2.1 + * + * 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:v3_service") @XmlSeeAlso({ @@ -57,43 +76,55 @@ import org.uddi.sub_v3.SubscriptionResul org.uddi.policy_v3.ObjectFactory.class, org.uddi.policy_v3_instanceparms.ObjectFactory.class }) -public interface UDDISubscriptionPortType extends Remote{ - +public interface UDDISubscriptionPortType extends Remote { /** - * + * + * Cancels an existing subscription. 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. + * * @param body * @throws DispositionReportFaultMessage, RemoteException */ @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 - ; + @WebParam(name = "delete_subscription", targetNamespace = "urn:uddi-org:sub_v3", partName = "body") DeleteSubscription body) + throws DispositionReportFaultMessage, RemoteException; /** - * + * * @param body - * @return - * returns org.uddi.sub_v3.SubscriptionResultsList + * @return returns org.uddi.sub_v3.SubscriptionResultsList * @throws DispositionReportFaultMessage, RemoteException */ @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 - ; + @WebParam(name = "get_subscriptionResults", targetNamespace = "urn:uddi-org:sub_v3", partName = "body") GetSubscriptionResults body) + throws DispositionReportFaultMessage, RemoteException; /** - * - * @param authInfo - * @return - * returns java.util.List + * 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") @@ -101,13 +132,124 @@ public interface UDDISubscriptionPortTyp @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 - ; + @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. + * +* 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. + * + * · 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 subscription * @param authInfo * @throws DispositionReportFaultMessage, RemoteException @@ -116,12 +258,8 @@ public interface UDDISubscriptionPortTyp @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 - ; - + @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; }  \ No newline at end of file --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscribe@juddi.apache.org For additional commands, e-mail: commits-help@juddi.apache.org