View Javadoc
1   /*
2    * Copyright 2001-2008 The Apache Software Foundation.
3    * 
4    * Licensed under the Apache License, Version 2.0 (the "License");
5    * you may not use this file except in compliance with the License.
6    * You may obtain a copy of the License at
7    * 
8    *      http://www.apache.org/licenses/LICENSE-2.0
9    * 
10   * Unless required by applicable law or agreed to in writing, software
11   * distributed under the License is distributed on an "AS IS" BASIS,
12   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13   * See the License for the specific language governing permissions and
14   * limitations under the License.
15   *
16   */
17  package org.uddi.v3_service;
18  
19  import java.rmi.Remote;
20  import java.rmi.RemoteException;
21  
22  import javax.jws.WebMethod;
23  import javax.jws.WebParam;
24  import javax.jws.WebService;
25  import javax.jws.soap.SOAPBinding;
26  import javax.xml.bind.annotation.XmlSeeAlso;
27  import javax.xml.datatype.XMLGregorianCalendar;
28  import javax.xml.ws.Holder;
29  import javax.xml.ws.RequestWrapper;
30  import javax.xml.ws.ResponseWrapper;
31  import org.uddi.custody_v3.DiscardTransferToken;
32  import org.uddi.custody_v3.KeyBag;
33  import org.uddi.custody_v3.TransferEntities;
34  
35  /**
36   * This portType defines all of the UDDI custody transfer operations. This
37   * section defines the UDDI Custody and Ownership Transfer API Set[28]. Data
38   * custody is introduced in Section 1.5.6 Data Custody. Ownership transfer is
39   * introduced in Section 1.5.7 Transfer of Ownership. By virtue of having
40   * created an entity, a publisher has ownership of the entity and is said to be
41   * the owner of the entity. A custodial node MUST maintain a relationship of
42   * ownership between an entity and its publisher by means of authorization
43   * mechanisms. Every node of a multi-node registry MUST guarantee the integrity
44   * of an entity's custody. As such, a node MUST not permit changes to an entity
45   * unless it has custody of it.
46   *
47   * The Custody and Ownership Transfer API Set enables any nodes of a registry to
48   * cooperatively transfer custody of one or more businessEntity or tModel
49   * structures from one node to another, as well as allowing the transfer of
50   * ownership of these structures from one publisher to another. Associated
51   * entities of a businessEntity such as its businessService, bindingTemplate,
52   * and publisherAssertion structures are transferred as part of the custody
53   * transfer of the business entity. * From a custody transfer point of view, the
54   * publishers are always distinct, though it may be the case that the publishers
55   * are the same person. Also, the two nodes may or may not be distinct;
56   * intra-node transfer between two publishers is simply a degenerate case in
57   * which node custody does not change. Thus, in the case of an inter-node
58   * transfer, ownership transfer is implied. In the case of an intra-node
59   * transfer the behavior results in the transfer of ownership between two
60   * publishers.
61   *
62   * For example, one UDDI registry, UDDI-1, MAY allow each node in UDDI-1
63   * (composed of nodes 1A, 1B and 1C) to define its own policies for
64   * registration, authentication and authorization. In this case, a "person",
65   * (P1) would need to review the policies of all 3 nodes and decide upon the
66   * node with which it chooses to register with. P1 may choose to register with
67   * more than one node. P1 registers with node1A . Node1A also specifies how P1
68   * is authenticated. If P1 successfully authenticates and publishes a business
69   * entity (BE1) then P1 becomes the "owner" of BE1. Node1A is said to be the
70   * "custodian" of BE1. P1 can also register at node1B. If P1 successfully
71   * authenticates and publishes a business entity (BE2) then P1 becomes the
72   * "owner" of BE2. Node1B is said to be the "custodian" of BE2. There is no
73   * assumption that the registry UDDI-1 or its nodes (node1A and node1B) are
74   * aware that P1 is the same "person". P1 is responsible for maintaining the
75   * appropriate identity and authenticating correctly to each node within a
76   * registry.
77   *
78   * Another UDDI registry, UDDI-2, MAY require each of its nodes (node2-1,
79   * node2-2 and node2-3) to use the same registration, authentication and
80   * authorization mechanisms. In this case, the policies are the same across all
81   * nodes. The relationship of registration, publication and ownership remains
82   * the same. If P1 wants to register with different nodes in UDDI-2, then it
83   * needs to differentiate its registration with the different nodes, since an
84   * attempt to register at node2-2 after registering at node2-1, would fail as
85   * "already registered" (since by policy the nodes all share the same
86   * registration, authentication and authorization).
87   *
88   * 5.4.1 Overview There are a number of scenarios where a publisher may choose
89   * to transfer custodianship or ownership of one or more entities. These are
90   * described in this section.
91   *
92   * 5.4.1.1 Intra-Node Ownership Transfer Intra-node ownership transfer involves
93   * transferring entity ownership from one publisher to another within the same
94   * UDDI node. Usage scenarios for this type of transfer include the following:
95   *
96   * · Businesses or organizational merges: Multiple organizations need to be
97   * consolidated under the control of a single publisher.
98   *
99   * · Domain key generators: One use of ownership transfer is the transfer of
100  * ownership of a derived key generator from one publisher to another to enable
101  * her or him to publish entities using keys in that domain.
102  *
103  * The save_xx APIs can also be used to move entities between parent entities
104  * that are owned by the same publisher. The save_service API, for example, can
105  * be used to move services (and binding templates) between one business entity
106  * and another as described in Section 5.2.17.3 Behavior of the save_service
107  * API. Changing the parent relationship in this way causes two businessEntity
108  * structures to be changed. Doing so enables the following scenarios:
109  *
110  * · Divestitures: An organization needs to reassign the control of a set of
111  * services to two or more publishers.
112  *
113  * · Consolidation of registry entities: There are multiple entities for a given
114  * business that are to be consolidated under a single publisher.
115  *
116  * 5.4.1.2 Inter-Node Custody Transfer Inter-node custody transfer involves the
117  * custody transfer of a set of entities across nodes of a UDDI registry. A
118  * transfer of ownership ensues as a consequence of this custody transfer. In
119  * addition to the intra-node scenarios described above, inter-node custody
120  * transfer may be used to address the following use cases:
121  *
122  * · Unsatisfactory service level: The functionality or service level provided
123  * by a given node operator is insufficient, and the publisher wishes to move
124  * their UDDI data to another node.
125  *
126  * · Change in availability for a UDDI node: A node is no longer providing UDDI
127  * services, and all publishers need to be migrated to one or more nodes of the
128  * registry.
129  *
130  * · Organizational Mergers, Divestitures or Consolidations: Changes in
131  * organizational structure may result in the need to make changes to the set of
132  * publishers used to manage the entities at various nodes of a registry.
133  *
134  * For any of these intra and inter-node scenarios, a mechanism is specified to
135  * facilitate the transfer the custody of businessEntity and tModel entities
136  * between nodes whether the entity is being transferred within a single node or
137  * whether a custody transfer occurs between nodes of a registry.
138  *
139  * 5.4.2 Custody Transfer Considerations When a businessEntity is transferred,
140  * all related businessService and bindingTemplate elements are transferred as
141  * well. In addition, any publisherAssertion elements that reference the
142  * businessEntity element’s businessKey that are owned by the publisher are also
143  * transferred.
144  *
145  * Note that the relinquishing publisher is not required to transfer all of its
146  * UDDI entities (i.e. businessEntity and/or tModel entities) in a single
147  * custody transfer request, nor is it required to transfer all of its entities
148  * to the same target publisher or target node. Any combination or subset of
149  * UDDI registry entities may be transferred to any number of target publishers
150  * or nodes.
151  *
152  * 5.4.3 Transfer Execution The Custody and Ownership Transfer API Set enables
153  * two publishers P1 and P2 and two nodes, N1 and N2, in a registry to
154  * cooperatively transfer custody of one or more existing businessEntity or
155  * tModel structures, E1…En, from N1 to N2 and, and by extension to transfer
156  * ownership of the entities from P1 to P2. Related businessService,
157  * bindingTemplate, and publisherAssertion structures are transferred with their
158  * related businessEntities. From the registry’s point of view, the publishers
159  * are always distinct, though it may be the case that P1 and P2 are the same
160  * party. The two nodes may or may not be distinct; intra-node transfer of
161  * ownership from P1 to P2 is simply a degenerate case in which node custody
162  * does not change.
163  *
164  * The Custody and Ownership Transfer API Set is divided into two parts, a set
165  * of two client APIs and a single inter-node API. These client APIs are
166  * get_transferToken and transfer_entities; in short, this constitutes the
167  * Ownership Transfer API portion of this API set. The inter-node-API is
168  * transfer_ custody which when combined with replication makes up the Custody
169  * Transfer API portion of this API set. * The overall flow of custody and
170  * ownership transfer is as follows:
171  *
172  * Publisher P1 invokes get_transferToken on N1, specifying the keys K1…Kn of
173  * the entities E1…En that are to be transferred. If P1 is authorized to do this
174  * (i.e., if P1 has ownership of E1…En), N1 returns a structure T, called a
175  * transfer token, that represents authority to transfer the entities, including
176  * all of the naturally contained children and publisher assertions related to
177  * business entities involved in the transfer that are owned by P1. The
178  * transferToken is a structure that consists of an opaque string that is
179  * meaningful only to the node that issued it, an expiration time, and a node
180  * identifier.
181  *
182  * P1 then gives T to P2 (typically by some secure means since T is valuable).
183  * The publisher obtaining the custody information needs to have previously
184  * obtained a publishers account on the node accepting custody of the entity
185  * before he/she can complete the custody transfer. P2 then invokes
186  * transfer_entities on N2, passing K1…Kn and T. If transfer_entities completes
187  * successfully, the entities E1…En and their related structures
188  * (businessService, bindingTemplate, and publisherAssertion) are in the custody
189  * of N2 and are owned by P2. If the operation fails, nothing happens to the
190  * entities. The actual transfer proceeds as follows, in the processing of
191  * transfer_entities.
192  *
193  * If N1 and N2 are not distinct nodes, the ownership transfer from P1 to P2 is
194  * an operation that is purely internal to the node – how it happens is up to
195  * the implementation. If N1 and N2 are distinct, the following protocol occurs
196  * while processing the transfer_entities request on N2.
197  *
198  * Upon receipt of a transfer_entities request, N2 checks that K1…Kn are valid
199  * keys. There is the possibility that P1 might transfer more data than P2 can
200  * accept due to policy-based restrictions on the limit of entities allowed to
201  * be owned by P2 at N2. As is described below, replication is used to complete
202  * the custody transfer process. A question that arises is at the time of
203  * accepting the datum related to the transfer, could N2 throw a replication
204  * error because the data being transferred exceeds the limits of user P2? Such
205  * limits can not be enforced during replication because they are node-local
206  * policy decisions from the perspective of enforcement. Thus, it is therefore
207  * possible that as a result of a custody transfer a publisher may be caused to
208  * hold more data that he/she would have been able to publish. Should this
209  * situation occur, P2 MUST not be allowed to publish any additional data unless
210  * P2 first reduces the number of entries it owns to an allowable limit.
211  *
212  * If all is well, N2 invokes the inter-node API transfer_custody on N1,
213  * presenting the keys of top-level entities to be transferred, K1…Kn, P2’s
214  * identity (using the publisher’s authorizedName), N2’s node identifier (as
215  * known in the Replication Configuration structure, see Section 7.5.2
216  * Configuration of a UDDI Node – operator element), and T. The transferToken,
217  * T, implies permission to transfer the entire content of the entities it
218  * identifies, including all of the contained entities and related
219  * publisherAssertions, if any. N1 checks to see whether T is a valid
220  * transferToken that it issued and that T represents the authority to transfer
221  * E1…En. If the validation is successful, N1 prevents further changes to
222  * entities E1…En. N1 then updates the authorizedName and nodeID of the
223  * operationalInfo of E1…En and related entities so that they are shown to be in
224  * the custody of N2 and owned by P2. Finally, N1 responds to N2 which triggers
225  * N2 to respond to the transfer_entities caller. This completes the processing
226  * for the transfer_entities request.
227  *
228  * In the case that the datum being transferred is a key generator tModel, N1
229  * will disallow further generation of keys associated with this key partition
230  * at its node.
231  *
232  * Following the issue of the empty message by N1 to the transfer_custody call,
233  * N1 will submit into the replication stream a changeRecordNewData providing in
234  * the operationalInfo, N2’s nodeID identifying it as the node where the datum
235  * is being transferred to, and the authorizedName of P2. The
236  * acknowledgmentRequested attribute of this change record MUST be set to
237  * "true".
238  *
239  * The last modified date timestamp in the operationalInfo must change to
240  * reflect the custody transfer. Figure 2 depicts the flow of a custody transfer
241  * between P1 and P2. This class was generated by the JAX-WS RI. JAX-WS RI
242  * 2.1.5-b03- Generated source version: 2.1
243  *
244  */
245 @WebService(name = "UDDI_CustodyTransfer_PortType", targetNamespace = "urn:uddi-org:api_v3_portType")
246 @XmlSeeAlso({
247     org.uddi.custody_v3.ObjectFactory.class,
248     org.uddi.repl_v3.ObjectFactory.class,
249     org.uddi.subr_v3.ObjectFactory.class,
250     org.uddi.api_v3.ObjectFactory.class,
251     org.uddi.vscache_v3.ObjectFactory.class,
252     org.uddi.vs_v3.ObjectFactory.class,
253     org.uddi.sub_v3.ObjectFactory.class,
254     org.w3._2000._09.xmldsig_.ObjectFactory.class,
255     org.uddi.policy_v3.ObjectFactory.class,
256     org.uddi.policy_v3_instanceparms.ObjectFactory.class
257 })
258 public interface UDDICustodyTransferPortType extends Remote {
259 
260     /**
261      * The discard_transferToken API is a client API used to discard a
262      * transferToken obtained through the get_transferToken API at the same
263      * node. This API accepts either a transferToken or a keyBag as parameters
264      * to remove the permission to transfer data associated with a particular
265      * transferToken. If a keyBag is provided, all tokens corresponding to the
266      * keys in the keyBag will be discarded and will no longer be valid for
267      * custody or ownership transfer after the discard_transferToken is
268      * processed, irrespective of whether the keys match any known business or
269      * tmodelKey values. In the event that the keyBag represents a subset of the
270      * keyBag for one or more transferToken elements, the transferToken is
271      * discarded and will no longer be valid for transferring any entity. If the
272      * token passed in the transferToken argument does not match an existing
273      * token known to the system, no action is taken and success is reported.
274      * Keys in the keyBag argument that do not have a corresponding token are
275      * ignored.
276      *
277      * @param body <p class="MsoBodyText"
278      * style="margin-left:1.0in;text-indent:-.25in"><span
279      * style="font-family:Symbol">·<span style="font:7.0pt &quot;Times New
280      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
281      * </span></span><b><i>authInfo</i></b>: This OPTIONAL argument is an
282      * element that contains an authentication token.&nbsp; Authentication
283      * tokens are obtained using the get_authToken API call or through some
284      * other means external to this specification, and represent the identity of
285      * the publisher at a UDDI node.</p>
286      *
287      * <p class="MsoBodyText" style="margin-left:1.0in;text-indent:-.25in"><span
288      * style="font-family:Symbol">·<span style="font:7.0pt &quot;Times New
289      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
290      * </span></span><b><i>transferToken</i></b>: This is a known transferToken
291      * obtained by a publisher at the node where the get_transferToken API was
292      * invoked.</p>
293      *
294      * <p class="MsoBodyText" style="margin-left:1.0in;text-indent:-.25in"><span
295      * style="font-family:Symbol">·<span style="font:7.0pt &quot;Times New
296      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
297      * </span></span><b><i>keyBag</i></b>: One or more uddiKeys associated
298      * either with businessEntity or tModel entities owned by the publisher that
299      * were to be transferred to some other publisher and/or node in the
300      * registry as the result of invocation of get_transferToken.&nbsp; At least
301      * one businessKey or tModelKey must be provided in a keyBag.</p>
302      * <Br>
303      * Upon successful completion, an empty message is returned. See
304      * section 4.8 Success and Error Reporting.
305      *
306      * No error will be reported if the transferToken provided in the call does
307      * not match an existing token. No error will be reported if a token is not
308      * found for a particular key in the keyBag.
309      * @throws DispositionReportFaultMessage
310      * @throws RemoteException <p class="MsoBodyText">If an error occurs in
311      * processing this API call, a dispositionReport structure MUST be returned
312      * to the caller in a SOAP Fault. See Section <a href="#_Ref8979716
313      * ">4.8</a> <i>Success and Error Reporting.&nbsp; </i>In addition to the
314      * errors common to all APIs, the following error information is relevant
315      * here: </p>
316      *
317      * <p class="MsoBodyText" style="margin-left:1.0in;text-indent:-.25in"><span
318      * style="font-family:Symbol">·</span><span
319      * style="font-size:7.0pt;font-family: &quot;Times New
320      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
321      * </span><b>E_invalidKeyPassed</b>: signifies that one of the
322      * <i>uddiKey</i> values passed for entities to be transferred did not match
323      * with any known businessKey or tModelKey values.&nbsp; The key and element
324      * or attribute that caused the problem SHOULD be clearly indicated in the
325      * error text.</p>
326      */
327     @WebMethod(operationName = "discard_transferToken", action = "discard_transferToken")
328     @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
329     public void discardTransferToken(
330             @WebParam(name = "discard_transferToken", targetNamespace = "urn:uddi-org:custody_v3", partName = "body") DiscardTransferToken body)
331             throws DispositionReportFaultMessage, RemoteException;
332 
333     /**
334      * The get_transferToken API is a client API used to initiate the transfer
335      * of custody of one or more businessEntity or tModel entities from one node
336      * to another. As previously stated, the two nodes may or may not be
337      * distinct; intra-node transfer between two publishers is simply a
338      * degenerate case in which node custody does not change. No actual transfer
339      * takes place with the invocation of this API. Instead, this API obtains
340      * permission from the custodial node, in the form of a transferToken, to
341      * perform the transfer. The publisher who will be recipient of the
342      * transferToken returned by this API must invoke the transfer_entities API
343      * on the target custodial node to actually transfer the entities.
344      *
345      * @param authInfo · authInfo: This OPTIONAL argument is an element that
346      * contains an authentication token. Authentication tokens are obtained
347      * using the get_authToken API call or through some other means external to
348      * this specification and represent the identity of the publisher at a UDDI
349      * node.
350      * @param keyBag keyBag: One or more key (of type uddi:uddiKey) associated
351      * either with businessEntity or tModel entities owned by the publisher that
352      * are to be transferred to some other publisher and/or node in the
353      * registry. At least one businessKey or tModelKey must be provided.
354      * @param nodeID this is a return value. The transfer token consists of a
355      * nodeID, an expirationTime and an opaqueToken. The nodeID is used during
356      * the transfer_entities API by the recipient node to confirm with the
357      * relinquishing custodial node that the custody transfer is authorized and
358      * still valid. The nodeID of the transferToken is the value of the nodeID
359      * element of the Replication Configuration Structure. Refer to Section
360      * 7.5.2 Configuration of a UDDI Node – operator Element.
361      * @param expirationTime this is a return value. The expirationTime, defined
362      * as xsd:dateTime, represents the time at which the transfer token is no
363      * longer valid.
364      * @param opaqueToken this is a return value. The opaqueToken is only
365      * meaningful to the node that issues it. The opaqueToken is defined as
366      * xsd:base64Binary to allow for a RECOMMENDED encryption of the token under
367      * the relinquishing custody node’s own encryption key.
368      * @throws DispositionReportFaultMessage
369      * @throws RemoteException <p class="MsoBodyText">If an error occurs in
370      * processing this API call, a dispositionReport structure MUST be returned
371      * to the caller in a SOAP Fault. See section <a href="#_Ref8979716
372      * ">4.8</a> <i>Success and Error Reporting.&nbsp; </i>In addition to the
373      * errors common to all APIs, the following error information is relevant
374      * here: </p>
375      *
376      * <p class="MsoBodyText" style="margin-left:1.0in;text-indent:-.25in"><span
377      * style="font-family:Symbol">·<span style="font:7.0pt &quot;Times New
378      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
379      * </span></span><b>E_invalidKeyPassed</b>: signifies that one of the
380      * <i>uddiKey</i> values passed for entities to be transferred did not match
381      * with any known businessKey or tModelKey values.&nbsp; The key and element
382      * or attribute that caused the problem SHOULD be clearly indicated in the
383      * error text.</p>
384      *
385      * <p class="MsoBodyText" style="margin-left:1.0in;text-indent:-.25in"><span
386      * style="font-family:Symbol">·<span style="font:7.0pt &quot;Times New
387      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
388      * </span></span><b>E_tokenAlreadyExists</b>: signifies that one or more of
389      * the businessKey or tModelKey elements that identify entities to be
390      * transferred are associated with a transferToken that is still valid and
391      * has not been discarded, used or expired.&nbsp; The error text SHOULD
392      * clearly indicate which entity keys caused the error.</p>
393      *
394      * <p class="MsoBodyText" style="margin-left:1.0in;text-indent:-.25in"><span
395      * style="font-family:Symbol">·<span style="font:7.0pt &quot;Times New
396      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
397      * </span></span><b>E_userMismatch</b>: signifies that one or more of the
398      * businessKey or tModelKey elements that identify entities to be
399      * transferred are not owned by the publisher identified by the
400      * <i>authInfo</i> element.&nbsp; The error text SHOULD clearly indicate
401      * which entity keys caused the error</p>
402      */
403     @WebMethod(operationName = "get_transferToken", action = "get_transferToken")
404     @RequestWrapper(localName = "get_transferToken", targetNamespace = "urn:uddi-org:custody_v3", className = "org.uddi.custody_v3.GetTransferToken")
405     @ResponseWrapper(localName = "transferToken", targetNamespace = "urn:uddi-org:custody_v3", className = "org.uddi.custody_v3.TransferToken")
406     public void getTransferToken(
407             @WebParam(name = "authInfo", targetNamespace = "urn:uddi-org:api_v3") String authInfo,
408             @WebParam(name = "keyBag", targetNamespace = "urn:uddi-org:custody_v3") KeyBag keyBag,
409             @WebParam(name = "nodeID", targetNamespace = "urn:uddi-org:api_v3", mode = WebParam.Mode.OUT) Holder<String> nodeID,
410             @WebParam(name = "expirationTime", targetNamespace = "urn:uddi-org:custody_v3", mode = WebParam.Mode.OUT) Holder<XMLGregorianCalendar> expirationTime,
411             @WebParam(name = "opaqueToken", targetNamespace = "urn:uddi-org:custody_v3", mode = WebParam.Mode.OUT) Holder<byte[]> opaqueToken)
412             throws DispositionReportFaultMessage, RemoteException;
413 
414     /**
415      * The transfer_entities API is used by publishers to whom custody is being
416      * transferred to actually perform the transfer. The recipient publisher
417      * must have an unexpired transferToken that was issued by the custodial
418      * node for the entities being transferred.
419      *
420      * @param body authInfo: This OPTIONAL argument is an element that contains
421      * an authentication token. Authentication tokens are obtained using the
422      * get_authToken API call or through some other means external to this
423      * specification, and represent the identity of the publisher at a UDDI
424      * node, in this case, the new owner of the entities being transferred.
425      *
426      * · transferToken: Required argument obtained from the custodial node via a
427      * call to get_transferToken by the publisher requesting a transfer of
428      * custody. The transferToken contains an opaque token, an expiration date,
429      * and the identity of the custodial node. The transferToken represents
430      * permission to transfer the entities that have been identified via a prior
431      * call to the get_transferToken API.
432      *
433      * · keyBag: One or more uddiKeys associated with businessEntity or tModel
434      * entities that are to be transferred to this publisher at the target node
435      * in the registry. The set of keys must be the same as the set of keys in
436      * the keyBag of the get_transferToken API call from which the given
437      * transferToken was once obtained.
438      * <br>
439      * <p class="MsoBodyText">The target node responds to this API by
440      * performing the transfer operation.&nbsp; This operation is comprised of
441      * four steps:</p>
442      *
443      * <p class="MsoBodyText" style="margin-left:1.0in;text-indent:-.25in"><span
444      * style="font-family:Symbol">·<span style="font:7.0pt &quot;Times New
445      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
446      * </span></span>Verification that the entity keys are valid.</p>
447      *
448      * <p class="MsoBodyText" style="margin-left:1.0in;text-indent:-.25in"><span
449      * style="font-family:Symbol">·<span style="font:7.0pt &quot;Times New
450      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
451      * </span></span>Verification that ownership of the entities by the
452      * recipient publisher is allowed and would not violate any policies at the
453      * target node related to publisher limits.</p>
454      *
455      * <p class="MsoBodyText" style="margin-left:1.0in;text-indent:-.25in"><span
456      * style="font-family:Symbol">·<span style="font:7.0pt &quot;Times New
457      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
458      * </span></span>Verification with the custodial node that the transfer of
459      * the designated entities is allowed.&nbsp; This is accomplished by
460      * invoking transfer_custody on the custodial node that is identified by the
461      * nodeID element in the transferToken.&nbsp; Any errors returned by the
462      * custodial node cause this API to fail and are propagated to the
463      * caller.</p>
464      *
465      * <p class="MsoBodyText" style="margin-left:1.0in;text-indent:-.25in"><span
466      * style="font-family:Symbol">·<span style="font:7.0pt &quot;Times New
467      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
468      * </span></span>Changing custody and ownership of the designated entities
469      * and entering these changes into the replication stream.</p>
470      *
471      * <p class="MsoBodyText">Upon successful completion, an empty message is
472      * returned indicating the success of the transfer operation. In the case of
473      * an inter-node custody transfer, while the transfer is in process, the
474      * entities being transferred are not available for modification. To
475      * determine the state of the data, UDDI clients can use the
476      * get_operationalInfo API to determine when custody and ownership transfer
477      * has taken place. A change in the nodeID of the operationalInfo provides
478      * such an indication.</p>
479      * @throws DispositionReportFaultMessage, RemoteException <p
480      * class="MsoBodyText">If an error occurs in processing this API call, a
481      * dispositionReport structure MUST be returned to the caller in a SOAP
482      * Fault. See Section <a href="#_Ref8979732 ">4.8</a> <i>Success and Error
483      * Reporting.&nbsp; </i>In addition to the errors common to all APIs, the
484      * following error information is relevant here:</p>
485      *
486      * <p class="MsoBodyText" style="margin-left:1.0in;text-indent:-.25in"><span
487      * style="font-family:Symbol">·<span style="font:7.0pt &quot;Times New
488      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
489      * </span></span><b>E_accountLimitExceeded</b>: signifies that the target
490      * node has determined that the transfer of custody of the identified
491      * entities would result in the target publisher exceeding policy limits for
492      * the number of owned entities.&nbsp; The error text SHOULD clearly
493      * indicate which entities cause the publishers limits to be exceeded. It is
494      * possible for a publisher to come into possession of more data than the
495      * target node’s policy allows. The condition and node behavior under these
496      * circumstances are described in Section <a href="#_Ref11680087
497      * ">5.4.3</a><i>Transfer Execution.</i></p>
498      *
499      * <p class="MsoBodyText" style="margin-left:1.0in;text-indent:-.25in"><span
500      * style="font-family:Symbol">·<span style="font:7.0pt &quot;Times New
501      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
502      * </span></span><b>E_invalidKeyPassed</b>: signifies that one of the
503      * <i>uddiKey</i> values passed for entities to be transferred did not match
504      * with any known businessKey or tModelKey values.&nbsp; The key and element
505      * or attribute that caused the problem SHOULD be clearly indicated in the
506      * error text.</p>
507      *
508      * <p class="MsoBodyText" style="margin-left:1.0in;text-indent:-.25in"><span
509      * style="font-family:Symbol">·<span style="font:7.0pt &quot;Times New
510      * Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
511      * </span></span><b>E_transferNotAllowed</b>: signifies that the transfer of
512      * one or more entities has been rejected by the target node or the
513      * custodial node.&nbsp; Reasons for rejection include expiration of the
514      * transferToken, use of an invalid transferToken, and attempts to transfer
515      * a set of entities that does not match the one represented by the
516      * transferToken. The reason for rejecting the custody transfer SHOULD be
517      * clearly indicated in the error text.</p>
518      *
519      * <span
520      * style="font-size:10.0pt;font-family:Arial;letter-spacing:-.25pt"></span>
521      */
522     @WebMethod(operationName = "transfer_entities", action = "transfer_entities")
523     @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
524     public void transferEntities(
525             @WebParam(name = "transfer_entities", targetNamespace = "urn:uddi-org:custody_v3", partName = "body") TransferEntities body)
526             throws DispositionReportFaultMessage, RemoteException;
527 }