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 "Times New 280 * Roman""> 281 * </span></span><b><i>authInfo</i></b>: This OPTIONAL argument is an 282 * element that contains an authentication token. 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 "Times New 289 * Roman""> 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 "Times New 296 * Roman""> 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. 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. </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: "Times New 320 * Roman""> 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. 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. </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 "Times New 378 * Roman""> 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. 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 "Times New 387 * Roman""> 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. 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 "Times New 396 * Roman""> 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. 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. 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 "Times New 445 * Roman""> 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 "Times New 450 * Roman""> 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 "Times New 457 * Roman""> 458 * </span></span>Verification with the custodial node that the transfer of 459 * the designated entities is allowed. This is accomplished by 460 * invoking transfer_custody on the custodial node that is identified by the 461 * nodeID element in the transferToken. 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 "Times New 467 * Roman""> 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. </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 "Times New 488 * Roman""> 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. 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 "Times New 501 * Roman""> 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. 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 "Times New 510 * Roman""> 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. 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 }