UDDIPublicationPortType (jUDDI_v3 Parent 3.3.10 API)

All Superinterfaces:: Remote

All Known Implementing Classes:: Publish3to2, UDDIPublicationImpl

public interface UDDIPublicationPortType
extends Remote

This portType defines all of the UDDI publication operations. This class was generated by the JAX-WS RI. JAX-WS RI 2.1.5-b03- Generated source version: 2.1

Publication API Set

The API calls in this section are used to publish and update information contained in a UDDI registry. According to the policy of the UDDI registry, a publisher selects a UDDI node where it will publish the information.

API calls in this section MUST all be implemented as synchronous and "atomic" from the point of view of the caller. That is, each call MUST either succeed completely or fail completely. Partial results MUST NOT be returned.

5.2.1 Publishing entities with node assigned keys

When a publisher does not provide keys for new entities, the UDDI node will assign keys in accordance with registry policy. Node-assigned keys MUST use keys that conform to the grammar in Section 4.4 About uddiKeys.

5.2.2 Publishing entities with publisher-assigned keys

The registry keying policy MAY allow an entity’s key to be proposed by the publisher. If the publisher does not propose a key for an entity, the registry MUST assign one.

Since entity keys MUST be unique in a registry without regard to the type of entity and since registries MUST define to impose policies concerning which publishers may publish which keys, publisher-assigned keys are subject to rules that UDDI registries enforce. Behavior that ensures uniqueness across entity types (businessEntity, businessService, bindingTemplate, tModel and subscription) is REQUIRED for all registries. In this section we discuss the behavior of registries that use the recommended "uddi:" key structure. This behavior provides uniqueness and promotes interoperability among registries, while allowing various registry-specific policies to be built. Practical guidance for the use of this facility may be found in Section 9.4.2 General Keying Policy and Section 9.4.3 Policy Abstractions for the UDDI keying scheme.

5.2.2.1 Key generator keys and their partitions

To ensure that publisher-generated keys do not conflict with one another, registries assign the authority to generate keys to publishers in the following manner:

1. The conceptual space of uddiKeys is divided into non-overlapping, hierarchically arranged partitions, each of which can be associated with a publisher.

2. Only the publisher associated with a particular partition is given the authority to assign keys within the partition.

3. The publisher with authority for a given partition may designate any publisher it chooses for any partition directly below the partition it manages, provided it has not already designated a publisher to that partition.

4. The publisher with authority for a partition may transfer its authority to another publisher.

5. Initially, the registry itself has authority for the root partition of the hierarchy.

The specific mechanisms that enforce these rules are explained below.

Each node of a registry is a generator of keys. This is required to enable the node to generate keys not provided by publishers. In addition, the policies of a registry MAY allow individual publishers to obtain the authority to be generators of keys for specific partitions within the space of uddiKeys. Publishers obtain this authority by owning a particular tModel called a key generator tModel. The key generator tModel contains a key generator key, and it specifies the partition for which the publisher may assign keys.

The subset of derivedKeys called key generator keys consists of all the keys of the form:

keyGeneratorKey = uddiKey ":keygenerator"

As described in Section 4.4.1, a derivedKey is one that is formed from another key by appending a non-empty, colon-prefixed string to another uddiKey. A derivedKey is said to be "based on" this uddiKey. With this in mind, the complete partition of a given keyGeneratorKey is the set of keys consisting of:

1. The set of derivedKeys based on the same uddiKey that the keyGeneratorKey is based upon.

2. The set of keyGeneratorKeys based on a key that is in the partition.

3. The domainKey, if the keyGeneratorKey is based upon that domainKey.

Note that the partition's keyGeneratorKey itself is exluded from the partition.

A rootKeyGeneratorKey is a keyGeneratorKey that is not based on a derivedKey. That is:

rootKeyGeneratorKey = (uuidKey / domainKey) ":keygenerator"

5.2.2.1.1 Examples

Based on the rules above, it is possible to construct the keyGeneratorKey for any key by manipulating the string representation of the key. To illustrate, suppose the key is x, then the following pseudo-code will determine the keyGeneratoryKey:

If x is a keyGeneratorKey, and y is that key minus the ":keygenerator" suffix,

then if y is a domainKey

then x is a top-level keyGenerator, and has no keyGeneratorKey (1.a)

else y is a derivedKey, based on z,

and x’s keyGeneratorKey is z:keyGenerator (1.b)

else

If x is a domainKey

then x’s keyGeneratorkey is x:keyGenerator (2)
else x is based on a key y, and x’s keyGenerator is y:keyGenerator (3)

Using this pseudo-code illustration, the following table provides examples of legal URI’s and their associated key generators for each of the four cases noted:

Key	keyGeneratorKey	Case in pseudo-code
uddi:tempuri.com	uddi:tempuri.com:keygenerator	2
uddi:tempuri.com:keygenerator	<none>	1.a
uddi:tempuri.com:xxx:keygenerator	uddi:tempuri.com:keygenerator	1.b
uddi:tempuri.com:xxx	uddi:tempuri.com:keygenerator	3
uddi:tempuri.com:xxx:yyy	uddi:tempuri.com:xxx:keygenerator	3

The following keys do NOT belong to the partition of the key generator key "uddi:tempuri.com:keygenerator".

"uddi:tempuri.com:keygenerator"

The keyGeneratorKey does not belong to the partition it designates.

"uddi:tempuri.com:xxx:yyy"

This key belongs to the partition of the keyGeneratorKey "uddi:tempuri.com:xxx:keygenerator", not this one.

"uddi:tempuri.com:keygenerator:zzz"

This key does not belong in any partition – it is an invalid key.

5.2.2.2 Behavior of publishers

To successfully publish a new entity with a proposed key, the publisher needs to own the key generator tModel for the partition in which the key lies. Typically, a publisher gets ownership by publishing the tModel in question, but publishers can also get ownership in other ways, for example by having another publisher transfer ownership.

Once a publisher owns a key generator tModel that publisher MAY publish new entities[20] and assign them keys within the key generator tModel’s partition. New keys can only be generated from keyGenerator tModels that are not hidden. Publishers are responsible for managing the uniqueness of the keys in the partition they own. If a publisher fails to do so, and generates an already used key, a publish operation could inadvertently replace an entity previously published by that publisher.

If a publisher owns key generator tModels with the same key in multiple registries – for example one in the publisher’s private test registry and one in the UDDI Business Registry – that publisher MAY publish the entities with identical keys in those registries. This enables many interesting capabilities. For example, publishers may choose to develop their UDDI entities by publishing them into test registries and then, at appropriate times, "promote" them to the UDDI Business Registry.

5.2.2.3 Behavior of UDDI nodes

To ensure that publisher-assigned keys work correctly all UDDI implementations behave as follows.

5.2.2.3.1 "New" and "existing" entities defined

During a publish operation, the entity or entities being published are either "new" or "existing". An existing entity is one that has a key that matches the key of an entity already in the registry. A new entity is one that does not. If a new entity has a key, this key is the key proposed for that entity by its publisher.

5.2.2.3.2 Behavior with respect to entities for which no key is proposed.

A UDDI node MUST generate and assign a key to each entity for which the publisher proposes no key. It may generate uuidKeys for use as the keys of new entities for which no key is proposed or it may generate keys in the partition of a key generator tModel it owns.

A registry whose nodes assign uddiKeys to new entities is called a root registry. The UDDI Business Registry is a root registry. A registry whose nodes gain ownership of their key generator tModels by publishing them in the UDDI Business Registry are affiliates of the UDDI Business Registry. See Section 1.5.5 Affiliations of Registries.

5.2.2.3.3 Behavior with respect to uuidKeys

A UDDI node SHOULD accept a uuidKey as the key for a new entity during a publish operation if the publisher is a trusted publisher of such keys, according to the policies of the registry. UDDI nodes MUST NOT allow other publishers to generate uuidKeys.

5.2.2.3.4 Behavior with respect to key generator keys

A UDDI node MUST NOT publish any non-tModel entity whose proposed key is a key generator key. A tModel whose proposed key is a key generator key MUST include a category bag with a keyed reference with the tModelKey set to "uddi:uddi.org:categorization:types" and the keyValue set to "keyGenerator".

5.2.2.3.5 Behavior with respect to root key generator keys

During a publish operation a UDDI node SHOULD accept a root key generator key as the key for a new tModel if it is proposed by a publisher authorized to publish the key, according to the policies of the registry. The policy MUST prevent more than one publisher from publishing tModels with the same root key generator key.

An appropriate policy for root and for affiliated registries is given in Chapter 9 Policy.

5.2.2.3.6 Behavior with respect to other proposed keys

A UDDI node SHOULD accept keys proposed for new entities during publishing operations if they meet both of the following criteria.

· The proposed key lies in the partition of the key of an existing key generator tModel and the key generator tModel is not hidden.

· The same publisher who is proposing the new key owns the key generator tModel referred to in the previous bullet. [21]

5.2.2.4 Affiliations of registries

A set of registries may cooperate in managing a single multi-registry key space by designating one of the registries in the group to be the "root registry" and assigning it to be the authority for the root partition. Other registries in the set are said to be affiliate registries. See Section 1.5.5 Affiliations of Registries for more information

The UDDI Business Registry is a root registry. Its policies and procedures are designed to make it simple for any UDDI registry to be affiliated with it.

Designating new authorities is done by publishing key generator tModels in the root registry, in one or more of the registries affiliated with the root registry or both. The owner of a key generator tModel is the naming authority for the partition the tModel represents.

5.2.3 Special considerations for validated value sets

Several of the APIs defined in this section allow publishers to save category and identifier information in support of searches that use category and identifier system references. The save_business, save_service, save_binding and save_tModel APIs allow designation of these value set references. Categorization is specified using the element named categoryBag, which contains namespace-qualified references to categories and descriptions. categoryBags can also contain groups of these references to categories and descriptions. Identifiers are specified using the identifierBag element, which contains namespace-qualified references to identifiers and descriptions.

Similarly, the add_publisherAssertions and set_publisherAssertions APIs allow publisherAssertion elements to be saved. These publisherAssertion elements contain a characterization of the relationship being established using a keyedReference element that refers to a relationship type system.

Identifier, category and relationship type systems taken together are referred to as "value sets." UDDI allows value sets to be checked or unchecked. References to checked value sets that are registered in UDDI can be checked internally by the UDDI nodes where publishing takes place, or externally by a provider of a validation Web service. The UDDI node can also choose to not support some or all checked value sets.

When a UDDI node encounters a reference to a checked value set in a keyedReference it will either ensure the reference is validated or fail the save. Such references to supported checked value sets are verified for validity according to the validation algorithm defined for the value set and described by its tModel. When all checks succeed, the save is permitted. An E_unvalidatable error indicates the checked value set is supported but its validation algorithm is not available. An E_unsupported indicates the checked value set is not supported by the node. E_invalidValue or E_valueNotAllowed indicate one or more references failed validation. When the checked value set is not supported, the value set’s validation algorithm is unavailable, or any of the references fail validation, the save operation MUST fail.

When the UDDI node supports a checked value set it may check the references itself, or consult a validation Web service. For cached checked value sets, the UDDI node verifies that referenced keyValues are in the set of valid values for the value set. The selection of an algorithm for verifying a checked value set is a matter of registry policy as detailed in Chapter 9 Policy.

A category group system is portrayed by a keyedRefererenceGroup element. Each keyedReferenceGroup has a tModelKey that references the category group system, and a set of contained keyedReference elements that make up the actual group of categories. Similar to references to checked value sets, validation is carried out for a keyedReferenceGroup if the referenced category group system is checked. Such validation entails verification that the keyedReferenceGroup is valid according to the validation algorithm described by the tModel for the category group system. Validation for a keyedReferenceGroup that references a cached checked category group system involves verification that the tModels referenced by the contained keyedReference elements are valid for the category group system. The set of valid values for such a cacheable checked category group system is defined by the tModelKeys for the set of tModels that can participate in the group.

No validation is performed on references to unchecked value sets

5.2.4 Special considerations for the xml:lang attribute

During save_xx API calls, the name, description, address, and personName UDDI elements MAY be adorned with the xml:lang attribute to indicate the language in which their content is expressed. (See Chapter 3 UDDI Registry Data Structures.) When an optional xml:lang attribute is omitted from an element, no xml:lang attribute will be saved for that element.

Name elements in UDDI core data structures are frequently the main targets for sorts during UDDI inquiries. When a UDDI data structure has multiple names, sorting occurs on the first name. Care should be taken to list the primary name first when the entity is saved to ensure the proper placement of the entity in a sorted result set.

Values which can be passed in the language supplied in a save_xx API call MUST obey the recommended rules and syntax governing the xml:lang data type as defined in Section 3.3.2.3 name.

5.2.5 Publisher API summary

The publishing API calls are:

· add_publisherAssertions: Used to add relationship assertions to the existing set of assertions. See Appendix A Relationships and Publisher Assertions.

· delete_binding: Used to remove an existing bindingTemplate from the registry.

· delete_business: Used to delete existing businessEntity information from the registry.

· delete_publisherAssertions: Used to delete specific publisher assertions from the assertion collection controlled by a particular publisher. Deleting assertions from the assertion collection affects the visibility of business relationships. Deleting an assertion causes any relationships based on that assertion to become incomplete.

· delete_service: Used to delete an existing businessService from the registry.

· delete_tModel: Used to hide existing information about a tModel. Any tModel hidden in this way is still usable for reference purposes and accessible via the get_tModelDetail API, but is hidden from find_tModel result sets. There is no specified way to delete a tModel.

· get_assertionStatusReport: Used to get a status report containing publisher assertions and status information. This report is useful to help an administrator manage publisher assertions. Returns an assertionStatusReport that includes the status of all assertions made involving any businessEntity controlled by the requesting publisher.

· get_publisherAssertions: Used to get a list of publisher assertions that are controlled by an individual publisher. Returns a publisherAssertions structure containing all publisher assertions associated with a specific publisher.

· get_registeredInfo: Used to request an abbreviated list of businesses and tModels currently managed by a given publisher.

· save_binding: Used to register new bindingTemplate information or to update existing bindingTemplate information. Use this to control information about technical capabilities exposed by a registered business.

· save_business: Used to register new businessEntity information or update existing businessEntity information. Use this to control the full set of information about the entire business, including its businessService and bindingTemplate structures. This API has the broadest effect of all of the save_xx APIs.

· save_service: Used to register or update complete information about a businessService.

· save_tModel: Used to register or update information about a tModel.

· set_publisherAssertions: Used to save the complete set of publisher assertions for an individual publisher. Replaces any existing assertions, and causes any old assertions that are not reasserted to be removed from the registry.

Method Summary

All Methods Instance Methods Abstract Methods
Modifier and Type	Method and Description
`void`	`addPublisherAssertions(AddPublisherAssertions body)` The add_publisherAssertions API call causes one or more publisherAssertions to be added to an individual publisher’s assertion collection.
`void`	`deleteBinding(DeleteBinding body)` The delete_binding API call causes one or more instances of bindingTemplate data to be deleted from the UDDI registry.
`void`	`deleteBusiness(DeleteBusiness body)` The delete_business API call is used to remove one or more business registrations and all elements that correspond to the natural content of the corresponding businessEntity elements from a UDDI registry.
`void`	`deletePublisherAssertions(DeletePublisherAssertions body)` The delete_publisherAssertions API call causes one or more publisherAssertion elements to be removed from a publisher’s assertion collection.
`void`	`deleteService(DeleteService body)` The delete_service API call is used to remove one or more businessService elements from the UDDI registry and from its containing businessEntity parent.
`void`	`deleteTModel(DeleteTModel body)` The delete_tModel API call is used to logically delete one or more tModel structures.
`List<AssertionStatusItem>`	`getAssertionStatusReport(String authInfo, CompletionStatus completionStatus)` The get_assertionStatusReport API call provides administrative support for determining the status of current and outstanding publisher assertions that involve any of the business registrations managed by the individual publisher.
`List<PublisherAssertion>`	`getPublisherAssertions(String authInfo)` The get_publisherAssertions API call is used to obtain the full set of publisher assertions that is associated with an individual publisher.
`RegisteredInfo`	`getRegisteredInfo(GetRegisteredInfo body)` The get_registeredInfo API call is used to get an abbreviated list of all businessEntity and tModel data that are controlled by a publisher.
`BindingDetail`	`saveBinding(SaveBinding body)` The save_binding API call is used to save or update a complete bindingTemplate element.
`BusinessDetail`	`saveBusiness(SaveBusiness body)` The save_business API call is used to save or update information about a complete businessEntity structure. This API has the broadest scope of all of the save_xx API calls, and can be used to make sweeping changes to the published information for one or more businessEntity elements controlled by an individual.
`ServiceDetail`	`saveService(SaveService body)` The save_service API call adds or updates one or more businessService elements.
`TModelDetail`	`saveTModel(SaveTModel body)` The save_tModel API call adds or updates one or more registered tModel elements.
`void`	`setPublisherAssertions(String authInfo, Holder<List<PublisherAssertion>> publisherAssertion)` The set_publisherAssertions API call is used to manage all of the tracked relationship assertions associated with an individual publisher.

- Method Detail
  - addPublisherAssertions
```
void addPublisherAssertions(AddPublisherAssertions body)
                     throws DispositionReportFaultMessage,
                            RemoteException
```
    The add_publisherAssertions API call causes one or more publisherAssertions to be added to an individual publisher’s assertion collection. See Appendix A Relationships and Publisher Assertions describing relationships and the API get_publisherAssertions for more information on this collection.
    The publisher must own the businessEntity referenced in the fromKey, the toKey, or both. If both of the businessKey values passed within an assertion are owned by the publisher, then the assertion is automatically complete and the relationship described in the assertion is visible via the find_relatedBusinesses API. To form a relationship when the publisher only owns one of the two keys passed, the assertion MUST be matched exactly by an assertion made by the publisher who owns the other business referenced. Assertions exactly match if and only if they:
    
    1.       refer to the same businessEntity in their fromKeys;
    
    2.       refer to the same businessEntity in their toKeys;
    
    3.       refer to the same tModel in their tModelKeys;
    
    4.       have identical keyNames; and
    
    5.       have identical keyValues.
    
    When a publisherAssertion being added references a checked relationship system using the tModelKey in the contained keyedReference, the reference MUST be checked for validity prior to completion of the add, or the node must return E_unsupported, indicating it does not support the referenced checked relationship system. Validation of a relationship system reference entails verification that the reference is valid according to the validation algorithm defined for the relationship system and described by its tModel. For cached checked relationship systems, the validation algorithm verifies that referenced keyValues are in the set of valid values for the relationship system.
    
    For registries supporting the subscription APIs at any node, it is necessary to track a modified date for publisherAssertion elements so that nodes have the necessary information for responding to subscription requests involving find_relatedBusinesses and get_assertionStatusReport filters.
    
    Parameters:
    
    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 method external to this specification. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call.
    
    ·         publisherAssertion: This required repeating element holds the relationship assertions that are being added. Relationship assertions consist of a reference to two businessEntity key values as designated by the fromKey and toKey elements, as well as a REQUIRED expression of directional relationship within the contained keyedReference element. See Appendix A Relationships and PublisherAssertions on managing relationships. The fromKey, the toKey, and all three parts of the keyedReference – the tModelKey, the keyName, and the keyValue MUST be specified or the call will fail with the error E_fatalError. Empty (zero length) keyNames and keyValues are permitted.
    Upon successful completion, an empty message is returned. See section 4.8 Success and Error Reporting.
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException
    If an error occurs in processing this API call, a dispositionReport structure MUST be returned to the caller in a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the errors common to all APIs, the following error information is relevant here:
    
    ·         E_invalidKeyPassed: signifies that one of the uddiKey values passed did not match with any known businessKey or tModelKey values. The key and element or attribute that caused the problem SHOULD be clearly indicated in the error text.
    
    ·         E_userMismatch: signifies that neither of the businessKey values passed in the embedded fromKey and toKey elements is owned by the publisher associated with the authentication token. The error text SHOULD clearly indicate which assertion caused the error.
    
    DispositionReportFaultMessage
    
    RemoteException
  - deleteBinding
```
void deleteBinding(DeleteBinding body)
            throws DispositionReportFaultMessage,
                   RemoteException
```
    The delete_binding API call causes one or more instances of bindingTemplate data to be deleted from the UDDI registry.
    
    Parameters:
    
    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 method external to this specification. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call.
    
    ·         bindingKey: One or more required uddiKey values that represent specific instances of known bindingTemplate data.
    Upon successful completion, an empty message is returned. See section 4.8 Success and Error Reporting.
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException
    If an error occurs in processing this API call, a dispositionReport structure MUST be returned to the caller in a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the errors common to all APIs, the following error information is relevant here:
    
    ·         E_invalidKeyPassed: Signifies that one of the uddiKey values passed did not match with any known bindingKey values or multiple instances of the same bindingKey values were passed. No partial results are returned – if any bindingKey values passed are not valid, this error is returned. The key that caused the problem SHOULD clearly be indicated in the error text.
    
    ·         E_userMismatch: Signifies that one or more of the bindingKey values passed refers to a bindingTemplate that is not owned by the individual publisher associated with the authentication token.
    
    DispositionReportFaultMessage
    
    RemoteException
  - deleteBusiness
```
void deleteBusiness(DeleteBusiness body)
             throws DispositionReportFaultMessage,
                    RemoteException
```
    The delete_business API call is used to remove one or more business registrations and all elements that correspond to the natural content of the corresponding businessEntity elements from a UDDI registry.
    
    Parameters:
    
    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. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call. · businessKey: One or more required uddiKey values that represent specific instances of known businessEntity data.
    The UDDI registry MUST permanently remove all of the natural contents[22] of the passed businessEntity elements, including any currently nested businessService and bindingTemplate data, from the UDDI registry.
    
    If there are service projections[23] that reference businessService elements deleted in this way, they are left untouched. Such "broken" service projections appear in their businessEntity as businessService elements containing the businessKey and serviceKey attributes as their only content. For this reason, it is a best practice to coordinate references to businessService data published under another businessEntity with the party who manages that data.
    
    All publisher assertions that reference the businessKey of the businessEntity being deleted in either the fromKey or toKey of the publisherAssertion MUST be automatically deleted. A deleted business MUST not be returned in the find_relatedBusinesses API.
    
    Any transferToken referring to the business entity being deleted becomes invalid and can no longer be used to transfer any entities.
    Upon successful completion, an empty message is returned. See section 4.8 Success and Error Reporting.
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException
    If an error occurs in processing this API call, a dispositionReport element MUST be returned to the caller within a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the errors common to all APIs, the following error information is relevant here:
    
    · E_invalidKeyPassed: Signifies that one of the uddiKey values passed did not match with any known businessKey values or multiple instances of the same businessKey values were passed. The key that caused the error SHOULD be clearly indicated in the error text.
    
    · E_userMismatch: Signifies that one or more of the businessKey values passed refers to data that is not owned by the individual publisher who is represented by the authentication token.
    
    DispositionReportFaultMessage
    
    RemoteException
  - deletePublisherAssertions
```
void deletePublisherAssertions(DeletePublisherAssertions body)
                        throws DispositionReportFaultMessage,
                               RemoteException
```
    The delete_publisherAssertions API call causes one or more publisherAssertion elements to be removed from a publisher’s assertion collection. See Appendix A Relationships and Publisher Assertions and the API get_publisherAssertions for more information on this collection.
    
    Parameters:
    
    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. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call.
    
    ·         publisherAssertion: One or more required publisher assertion structures exactly matching an existing assertion in the publisher’s assertion collection.
    
    The UDDI registry scans the assertion collection associated with the publisher, and removes any assertions that exactly match all parts of each publisherAssertion passed. Any assertions described that cannot be located result in an error. The removal of assertions in this API causes the corresponding relationships to no longer be visible via the find_relatedBusinesses API.
    
    For registries supporting the subscription APIs at any node, it is necessary to track a modified date for publisherAssertion elements so that nodes have the necessary information for responding to subscription requests involving find_relatedBusinesses and get_assertionStatusReport filters.
    Upon successful completion, an empty message is returned. See section 4.8 Success and Error Reporting.
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException
    If an error occurs in processing this API call, a dispositionReport structure MUST be returned to the caller in a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the errors common to all APIs, the following error information is relevant here:
    
    ·         E_assertionNotFound: Signifies that one of the assertion structures passed does not have any corresponding match in the publisher’s assertion collection or multiple instances of the same publisherAssertions elements were passed. The assertion that caused the problem SHOULD be clearly indicated in the error text.
    
    DispositionReportFaultMessage
    
    RemoteException
  - deleteService
```
void deleteService(DeleteService body)
            throws DispositionReportFaultMessage,
                   RemoteException
```
    The delete_service API call is used to remove one or more businessService elements from the UDDI registry and from its containing businessEntity parent.
    
    Parameters:
    
    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. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call.
    
    · serviceKey: One or more required uddiKey values that represent specific instances of known businessService data.
    
    All contained bindingTemplate data MUST also be removed from the registry as a result of this call.
    
    If a business service being deleted is the target of a business service projection associated with another businessEntity, the referencing businessService elements are left untouched. Such "broken" service projections appear in their businessEntity and businessService elements containing the businessKey and serviceKey attributes as their only content. For this reason, it is recommended that references to businessService data published under another businessEntity be coordinated with the party that manages that data.
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException If an error occurs in processing this API call, a dispositionReport structure MUST be returned to the caller in a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the errors common to all APIs, the following error information is relevant here: · E_invalidKeyPassed: Signifies that one of the uddiKey values passed did not match with any known serviceKey values or multiple instances of the same serviceKey values were passed. The key causing the error SHOULD be clearly indicated in the error text. · E_userMismatch: Signifies that one or more of the serviceKey values passed refers to data that is not owned by the individual publisher who is represented by the authentication token.
    
    DispositionReportFaultMessage
    
    RemoteException
  - deleteTModel
```
void deleteTModel(DeleteTModel body)
           throws DispositionReportFaultMessage,
                  RemoteException
```
    The delete_tModel API call is used to logically delete one or more tModel structures. Logical deletion hides the deleted tModels from find_tModel result sets but does not physically delete them. New references to deleted (hidden) tModels can be established by publishers that know their keys. Deleting an already deleted tModel has no effect.
    
    Parameters:
    
    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. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call.
    
    · tModelKey: One or more required uddiKey values that represent specific instances of known tModel data.
    
    If a tModel is hidden in this way it MUST not be physically deleted as a result of this call. Any tModels hidden in this way are still accessible, via the get_registeredInfo and get_tModelDetail APIs, but are omitted from any results returned by calls to find_tModel. All other inquiry APIs may include references to tModelKeys of deleted tModelKeys, and UDDI data structures that reference these tModels are found and retrieved.
    
    The purpose of the delete_tModel behavior is to ensure that the details associated with a hidden tModel are still available to anyone currently using the tModel. A hidden tModel can be restored and made visible to search results by invoking the save_tModel API at a later time, passing the original data and the tModelKey value of the hidden tModel.
    
    It is not an error to transfer a hidden tModel (i.e. deleted attribute set to TRUE).
    Upon successful completion, an empty message is returned. See section 4.8 Success and Error Reporting.
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException If an error occurs in processing this API call, a dispositionReport element MUST be returned to the caller within a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the errors common to all APIs, the following error information is relevant here: · E_invalidKeyPassed: Signifies that one of the uddiKey values passed did not match with any known tModelKey values or multiple instances of the same tModelKey values were passed. The invalid key references SHOULD be clearly indicated in the error text. · E_userMismatch: Signifies that one or more of the tModelKey values passed refers to data that is not owned by the individual publisher who is represented by the authentication token.
    
    DispositionReportFaultMessage
    
    RemoteException
  - getAssertionStatusReport
```
@RequestWrapper(localName="get_assertionStatusReport",
                targetNamespace="urn:uddi-org:api_v3",
                className="org.uddi.api_v3.GetAssertionStatusReport")
 @ResponseWrapper(localName="assertionStatusReport",
                 targetNamespace="urn:uddi-org:api_v3",
                 className="org.uddi.api_v3.AssertionStatusReport")
List<AssertionStatusItem> getAssertionStatusReport(String authInfo,
                                                                                                                                                                                                                                                                                                                                                                                                                              CompletionStatus completionStatus)
                                                                                                                                                                                                                                                                                                                                                                                                                       throws DispositionReportFaultMessage,
                                                                                                                                                                                                                                                                                                                                                                                                                              RemoteException
```
    The get_assertionStatusReport API call provides administrative support for determining the status of current and outstanding publisher assertions that involve any of the business registrations managed by the individual publisher. Using this API, a publisher can see the status of assertions that they have made, as well as see assertions that others have made that involve businessEntity structures controlled by the requesting publisher. See Appendix A Relationships and Publisher Assertions for more information.
    
    Parameters:
    
    completionStatus -
    
    authInfo -
    ·         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. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call.
    
    ·         completionStatus: This optional argument lets the publisher restrict the result set to only those relationships that have the specified status value. Assertion status is a calculated result based on the sum total of assertions made by the individuals that control specific business registrations. When no completionStatus element is provided, all assertions involving the businesses that the publisher owns are retrieved, without regard to the completeness of the relationship. completionStatus MUST contain one of the following values
    
    o        status:complete: Passing this value causes only the publisher assertions that are complete to be returned. Each businessEntity listed in assertions that are complete has a visible relationship that directly reflects the data in a complete assertion (as described in the find_relatedBusinesses API).
    
    o        status:toKey_incomplete: Passing this value causes only those publisher assertions where the party who controls the businessEntity referenced by the toKey value in an assertion, has not made a matching assertion, to be listed.
    
    o        status:fromKey_incomplete: Passing this value causes only those publisher assertions where the party who controls the businessEntity referenced by the fromKey value in an assertion, has not made a matching assertion, to be listed.
    
    o        status:both_incomplete. This status value, however, is only applicable to the context of UDDI subscription and SHOULD not be present as part of a response to a get_assertionStatusReport request.
    
    Returns:
    
    returns java.util.List Upon successful completion, an assertionStatusReport structure is returned containing zero or more assertionStatusItem structures. Elements will be sorted by last date change in ascending order. The assertionStatusReport has the form:
    The assertionStatusReport reports all complete and incomplete assertions and serves an administrative use for determining if there are any outstanding, incomplete assertions pertaining to relationships involving businesses with which the publisher is associated.
    
    Since the publisher who was authenticated by the get_assertionStatusReport API may own several businesses, the assertionStatusReport structure shows the assertions made for all businesses owned by the publisher.
    
    The assertion status report is composed of a set of assertionStatusItem elements that describe the assertions in which the publisher’s businesses participate. The assertionStatusItem element has the form:
    
    The assertionStatusItem structure has the following attribute:
    
    Name
    
    Use
    
    completionStatus
    
    required
    
    While the elements fromKey, toKey and keyedReference together identify the assertion on whose status a report is being provided, the keysOwned element designates those businessKeys the publisher manages. The keysOwned element has the form:
    
    An assertion is part of a reciprocal relationship only if the completionStatus attribute has a value "status:complete". If completionStatus has a value "status:toKey_incomplete" or "status:fromKey_incomplete", the party who controls the businessEntity referenced by the toKey or the fromKey has not yet made a matching assertion.
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException If an error occurs in processing this API call, a dispositionReport element MUST be returned to the caller within a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the errors common to all APIs, the following error information is relevant here: · E_invalidCompletionStatus: Signifies that the completionStatus value passed is unrecognized. The completion status that caused the problem SHOULD be clearly indicated in the error text.
    
    DispositionReportFaultMessage
    
    RemoteException
  - getPublisherAssertions
```
@RequestWrapper(localName="get_publisherAssertions",
                targetNamespace="urn:uddi-org:api_v3",
                className="org.uddi.api_v3.GetPublisherAssertions")
 @ResponseWrapper(localName="publisherAssertionsResponse",
                 targetNamespace="urn:uddi-org:api_v3",
                 className="org.uddi.api_v3.PublisherAssertionsResponse")
List<PublisherAssertion> getPublisherAssertions(String authInfo)
                                                                                                                                                                                                                                                                                                                                                                                                                            throws DispositionReportFaultMessage,
                                                                                                                                                                                                                                                                                                                                                                                                                                   RemoteException
```
    The get_publisherAssertions API call is used to obtain the full set of publisher assertions that is associated with an individual publisher. It complements the get_registeredInfo API which returns information about businesses, services, bindings, and tModels managed by a publisher.
    
    Parameters:
    
    authInfo - · 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. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call.
    
    Returns:
    
    returns java.util.List This API call returns a publisherAssertions structure that contains a publisherAssertion element for each publisher assertion registered by the publisher. When the registry distinguishes between publishers, this information is associated with the authentication information. Only assertions made by the publisher are returned. Elements will be sorted by last date change in ascending order. See get_assertionStatusReport and Appendix A Relationships and Publisher Assertions for more details. The publisherAssertions structure has the form:
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException None, other than those common to all UDDI APIs. See Section 12.1 Common Error Codes.
    
    DispositionReportFaultMessage
    
    RemoteException
  - getRegisteredInfo
```
RegisteredInfo getRegisteredInfo(GetRegisteredInfo body)
                          throws DispositionReportFaultMessage,
                                 RemoteException
```
    The get_registeredInfo API call is used to get an abbreviated list of all businessEntity and tModel data that are controlled by a publisher. When the registry distinguishes between publishers, this is the individual associated with the credentials passed in the authInfo element. This returned information is intended, for example, for driving tools that display lists of registered information and then provide drill-down features. This is the recommended API to use after a network problem results in an unknown status of saved information.
    
    Parameters:
    
    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. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call. · infoSelection: This required argument represents an enumerated choice that determines which tModels are returned. "all" indicates all visible and hidden tModels owned by the publisher are to be returned (this is the default). "visible" indicates only visible tModels owned by the publisher are to be returned. "hidden" indicates only hidden (logically deleted) tModels owned by the publisher are to be returned.
    
    Returns:
    
    returns org.uddi.api_v3.RegisteredInfo Upon successful completion, a registeredInfo structure MUST be returned, listing abbreviated business information in one or more businessInfo elements, and tModel information in one or more tModelInfo elements. This API is useful for determining the full extent of registered business and tModel information owned by a single publisher in a single call. This structure complements the get_publisherAssertions API call, which returns information about assertions owned by an individual publisher. businessInfos and/or tModelInfos will be sorted case-sensitively on the primary name in ascending order, using the collation sequence determined by node policy.
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException
    
    DispositionReportFaultMessage
    
    RemoteException
  - saveBinding
```
BindingDetail saveBinding(SaveBinding body)
                   throws DispositionReportFaultMessage,
                          RemoteException
```
    The save_binding API call is used to save or update a complete bindingTemplate element. It can be used to add or update one or more bindingTemplate elements as well as the container/contained relationship that each bindingTemplate has with one or more existing businessService elements. Each bindingTemplate MAY be signed and MAY have publisher-assigned keys.
    
    Parameters:
    
    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. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call.
    
    ·         bindingTemplate: Required repeating element containing one or more complete bindingTemplate structures. To save a new bindingTemplate, a bindingTemplate element is passed with either an empty bindingKey attribute value, or with a publisher-assigned bindingKey. See Section 5.2.2.2 Behavior of Publishers.
    
    Each new bindingTemplate passed MUST contain a serviceKey value that corresponds to a registered businessService controlled by the same publisher. An existing binding template MAY contain a serviceKey value that corresponds to a registered businessService controlled by the same publisher. The net effect of this call is to determine the containing parent businessService for each bindingTemplate affected by this call. If the same bindingTemplate (determined by matching bindingKey value) is listed more than once, any relationship to the containing businessService is determined by processing order, which is determined by the position of the bindingTemplate data in first to last order.
    
    If the bindingKey within a bindingTemplate element is missing or is passed with an empty value, this is a signal that the bindingTemplate is being inserted for the first time. When this occurs, the node MUST automatically generate a new key for the bindingTemplate that is without an associated key. New bindingTemplate structures can also be added with publisher-assigned keys. See Section 5.2.2.2 Behavior of Publishers.
    
    Using this API call it is possible to move an existing bindingTemplate from one businessService to another by simply specifying a different parent businessService relationship along with the complete bindingTemplate. Changing a parent relationship in this way causes two businessService structures to be affected. The net result of such a move is that the bindingTemplate still resides within one, and only one businessService based on the value of the serviceKey passed. An attempt to move a bindingTemplate in this manner by a party who is not the publisher of the businessService that is specified by the serviceKey MUST be rejected with an error E_userMismatch.
    
    When a bindingTemplate is saved with a categoryBag content that is associated with a checked value set or category group system tModel, the references MUST be checked for validity prior to completion of the save, or the node must return E_unsupported, indicating it does not support the referenced checked value set or category group system. See Section 5.2.3 Special considerations for validated value sets and Appendix F Using Categorization for additional details.
    
    Returns:
    
    returns org.uddi.api_v3.BindingDetail This API returns a bindingDetail structure containing the results of the call that reflects the newly registered information for the effected bindingTemplate elements. If more than one bindingTemplate is saved in a single save_binding call, the resulting bindingDetail MUST return results in the same order that they appeared in the save_binding call. If the same bindingTemplate (determined by matching bindingKey) is listed more than once in the save_binding call, it MAY be listed once in the result for each appearance in the save_binding call. If the same bindingTemplate appears more than once in the response, the last occurrence of the bindingTemplate in the results represents the state stored in the registry. Any bindingKeys that were assigned as a result of processing the save_binding call are included in the bindingTemplate data. The bindingDetail structure has the form:
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException
    If an error occurs in processing this API call, a dispositionReport element MUST be returned to the caller in a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the errors common to all APIs, the following error information is relevant here:
    
    ·         E_accountLimitExceeded: Signifies that user account limits have been exceeded.
    
    ·         E_invalidKeyPassed: Signifies that the request cannot be satisfied because one or more uddiKey values specified are not valid key values for the entities being published. tModelKey, serviceKey, or bindingKey values that either do not exist, or exist with a different entity type, or are not authorized to be proposed by the publisher are considered to be invalid values. The key causing the error SHOULD be clearly indicated in the error text. This error code will also be returned in the event that the serviceKey is not provided and the bindingKey is either absent or has a value not registered in the registry. In this case, the error text SHOULD clearly indicate the use of an incomplete bindingTemplate.
    
    ·         E_invalidValue: A value that was passed in a keyValue attribute did not pass validation. This applies to checked value sets that are referenced using keyedReferences. The error text SHOULD clearly indicate the key and value combination that failed validation.
    
    ·         E_keyUnavailable: Indicates that the proposed key has already been assigned to some other publisher or is not within the partition defined by a key generator tModel that the publisher owns.
    
    ·         E_requestTimeout: Signifies that the request could not be carried out because a needed validate_values service did not respond in a reasonable amount of time. Details identifying the failing Web service SHOULD be included in the dispositionReport element.
    
    ·         E_userMismatch: Signifies that one or more of the uddiKey values passed refers to data that is not owned by the individual publisher who is represented by the authentication token.
    
    ·         E_valueNotAllowed: Restrictions have been placed by the value set provider on the types of information that should be included at that location within a specific value set. A validate_values Web service chosen by the UDDI node has rejected this businessEntity for at least one specified keyedReference. The error text SHOULD clearly indicate the keyedReference that was not successfully validated.
    
    DispositionReportFaultMessage
    
    RemoteException
  - saveBusiness
```
BusinessDetail saveBusiness(SaveBusiness body)
                     throws DispositionReportFaultMessage,
                            RemoteException
```
    The save_business API call is used to save or update information about a complete businessEntity structure. This API has the broadest scope of all of the save_xx API calls, and can be used to make sweeping changes to the published information for one or more businessEntity elements controlled by an individual.
    
    This API call can be used to establish a reference relationship to businessService structures that are managed as the contents of another businessEntity. In this way, a businessService that is a natural part of one businessEntity can appear as a projected service of another businessEntity. The content of a businessService projected in this way (by way of a reference established by this API) are not managed as a part of the referencing entity.
    
    businessEntity structures MAY be signed and MAY have publisher-assigned keys.
    
    Parameters:
    
    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. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call.
    
    ·         businessEntity: Required repeating element containing one or more businessEntity structures. These can be obtained in advance by using the get_businessDetail API call or by any other means.
    
    If any of the uddiKey values within a businessEntity element (e.g. any data with a key value regulated by a businessKey, serviceKey or bindingKey) is missing or is passed with an empty value, this is a signal that the data that is so keyed is being inserted for the first time.[24] When this occurs, the node MUST automatically generate a new key for the data passed that is without an associated key. New entities can also be added with publisher-assigned keys. See Section 5.2.2.2 Behavior of Publishers.
    
    To make this API call perform an update to existing registered data, the keyed entities (businessEntity, businessService or bindingTemplate) MUST have uddiKey values that correspond to the registered data to be updated.
    
    Data can be deleted with this API call when registered information is different from the new information provided. Any businessService and bindingTemplate structures found in the custodial UDDI node, but missing from the businessEntity information provided in this call, are deleted from the registry by this call.
    
    Data contained within businessEntity structures can be rearranged with this API call. This can be done by redefining parent container relationships for other registered information. For instance, if a new businessEntity is saved with information about a businessService that is registered already as part of a different businessEntity, this results in the businessService being moved from its current container to the new businessEntity.   This condition occurs when the businessKey of the businessService being saved matches the businessKey of the businessEntity being saved. An attempt to delete or move a businessService in this manner by a party who is not the publisher of the businessService MUST be rejected with an error E_userMismatch.
    
    If the businessEntity being saved contains a businessService that has a businessKey referring to some businessEntity other than the businessEntity being saved, the UDDI registry notes a reference, called a "service projection", to the existing businessService. Subsequent calls to the get_businessDetail API, passing either the businessKey of the businessEntity that contains the referenced businessService or the businessKey of the businessEntity that contains the service projection will result in an identical businessService element being included as part of the result set.
    
    A businessEntity must not contain a businessService and a service projection to this businessService. As a result, a businessService cannot be moved to a businessEntity that already has a service projection to that businessService. Regardless of the order of operation, a businessService and a service projection can never appear under the same businessEntity. Implementations are required to reject and return an E_fatalError during such a save_business operation.
    
    No changes to the referenced businessService are effected by the act of establishing a service projection.   Existing service projections associated with the businessEntity being saved that are not contained in the call to save_business are deleted automatically. This reference deletion does not cause any changes to the referenced businessService. If the referenced businessService is deleted by any means, all references to it associated with other businessEntity structures are left untouched. Such "broken" service projections appear in their businessEntity as businessService elements containing the businessKey and serviceKey attributes as their only content. If the businessService is moved to another business, all projections will be updated to reflect the new businessKey[25]. For this reason, it is good practice to coordinate references to businessService data published under another businessEntity with the party who manages that data
    
    When saving a businessEntity containing a service projection, all of the content of the businessService provided in the save_business, with the exception of the serviceKey and businessKey, is ignored. The businessKey and serviceKey of the businessService being referenced are used to determine if the businessService is for a service projection or not. If the businessService identified by the serviceKey is not part of the businessEntity identified by the businessKey, the error E_invalidProjection will be returned.
    
    When a businessEntity is saved with identifierBag or categoryBag contents that is associated with a checked value set or category group system tModel, the references MUST be checked for validity prior to completion of the save or the node must return E_unsupported, indicating it does not support the referenced checked value set or category group system. See Section 5.2.3 Special considerations for validated value sets, Appendix E Using Identifiers and Appendix F Using Categorization for additional details.
    
    Returns:
    
    returns org.uddi.api_v3.BusinessDetail
    This API returns a businessDetail structure containing the final results of the call that reflects the new registered information for the businessEntity information provided. Any businessKey, serviceKey, or bindingKey attributes that were assigned as a result of processing the save_business are included in the returned data. For businessService elements that are service projections, the response includes either the businessService elements as provided by the publisher or the full contents of the real businessService elements. These results include any businessService elements that are contained by reference. If the same entity (businessEntity, businessService, or bindingTemplate), determined by matching key, is listed more than once in the save_business call, it MAY be listed once in the result for each appearance in the call. If the same entity appears more than once in the response, the last appearance occurrence of the entity in the results represents either the final saved state stored in the registry or the last occurrence of the entity provided by the publisher within the request.
    
    The businessDetail has the form:
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException
    If an error occurs in processing this API call, a dispositionReport element MUST be returned to the caller in a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the errors common to all APIs, the following error information is relevant here:
    
    ·         E_accountLimitExceeded: Signifies that user account limits have been exceeded.
    
    ·         E_invalidKeyPassed: Signifies that the request cannot be satisfied because one or more uddiKey values specified are not valid key values for the entities being published. tModelKey, businessKey, serviceKey, or bindingKey values that either do not exist, or exist with a different entity type, or are not authorized to be proposed by the publisher are considered to be invalid values. The key causing the error SHOULD be clearly indicated in the error text.
    
    ·         E_invalidProjection: Signifies that an attempt was made to save a businessEntity containing a service projection where the businessService being projected is not a part of the businessEntity that is identified by the businessKey in the businessService. The serviceKey of at least one such businessService SHOULD be included in the dispositionReport.
    
    ·         E_userMismatch: Signifies that one or more of the uddiKey values passed refers to data that is not owned by the individual publisher who is represented by the authentication token. The key causing the error SHOULD be clearly indicated in the error text.
    
    ·         E_invalidValue: A value that was passed in a keyValue attribute did not pass validation. This applies to checked value sets that are referenced using keyedReferences. The error text SHOULD clearly indicate the key and value combination that failed validation.
    
    ·         E_keyUnavailable: Indicates that the proposed key has already been assigned to some other publisher or is not within the partition defined by a key generator tModel that the publisher owns.
    
    ·         E_requestTimeout: Signifies that the request could not be carried out because a needed validate_values service did not respond in a reasonable amount of time. Details identifying the failing Web service SHOULD be included in the dispositionReport element.
    
    ·         E_unsupported: A keyedReference in a categoryBag or an identifierBag that references a checked value set cannot be validated by the UDDI node because the node does not support the referenced checked value set. The error text should clearly indicate the keyedReference that cannot be validated.
    
    ·         E_unvalidatable: A keyedReference in a categoryBag or an identifierBag that references a checked value set cannot be validated by the UDDI node because the referenced tModel has been marked unvalidatable. The error text should clearly indicate the keyedReference that cannot be validated.
    
    ·         E_valueNotAllowed: Restrictions have been placed by the value set provider on the types of information that should be included at that location within a specific value set. A validate_values Web service chosen by the UDDI node has rejected this businessEntity for at least one specified keyedReference. The error text SHOULD clearly indicate the keyedReference that was not successfully validated.
    
    DispositionReportFaultMessage
    
    RemoteException
  - saveService
```
ServiceDetail saveService(SaveService body)
                   throws DispositionReportFaultMessage,
                          RemoteException
```
    The save_service API call adds or updates one or more businessService elements. Each businessService MAY be signed and MAY have publisher-assigned keys.
    
    Parameters:
    
    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. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call.
    
    ·         businessService: Required repeating element containing one or more complete businessService elements. For the purpose of performing round trip updates, this data can be obtained in advance by using the get_serviceDetail API call or by any other means.
    
    Each new businessService passed MUST contain a businessKey value that corresponds to a registered businessEntity controlled by the same publisher. An existing business service MAY contain a businessKey value that corresponds to a registered businessEntity controlled by the same publisher.
    
    If any of the uddiKey values within a businessService element (i.e., any data with a key value regulated by a serviceKey or bindingKey) is passed with an empty value, this is a signal that the data that is so keyed is being inserted for the first time. [26] In this case, a new key value MUST be automatically generated for the data which was passed without an associated key value. New entities can also be added with publisher-assigned keys. See Section 5.2.2.2 Behavior of Publishers.
    
    If the same businessService is contained in more than one businessService argument, the final relationship to the containing businessEntity is determined by processing order – which is determined by first to last order of the information passed in the request. Analogously, if the same bindingTemplate is specified in the call as being in more than one businessService, the businessService that is its container at the conclusion of the call is last one listed.
    
    Using this API call it is possible to move an existing bindingTemplate element from one businessService element to another, or move an existing businessService element from one businessEntity to another by simply specifying a different parent businessEntity relationship. Changing a parent relationship in this way causes two businessEntity or two businessService structures to be changed. An attempt to move a bindingTemplate or a businessService in this manner by a party who is not the publisher of the businessService that is specified by the serviceKey or the businessEntity that is specified by the businessKey MUST be rejected with an error E_userMismatch.
    
    When a businessService is saved with categoryBag contents that is associated with a checked value set or category group system tModel, the references MUST be checked for validity prior to completion of the save or the node MUST return E_unsupported, indicating it does not support the referenced checked value set or category group system. See Section 5.2.3 Special considerations for validated value sets and Appendix F Using Categorization for additional details.
    
    Returns:
    
    returns org.uddi.api_v3.ServiceDetail
    This API call returns a serviceDetail containing the final results of the call that reflects the newly registered information for the affected businessService elements. In cases where multiple businessService elements are passed in the request, the result contains the final results for each businessService passed and these appear in the same order as found in the request. Any serviceKey and bindingKey values that were assigned as a result of processing the save_service API are included in the businessService data.
    
    If the same entity (businessService, or bindingTemplate), determined by matching key, is listed more than once in the save_service API, it MAY be listed once in the result for each appearance in the save_service API. If the same entity appears more than once in the response, the last occurrence of the entity in the results represents the state stored in the registry.
    
    The serviceDetail has the form:
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException
    If an error occurs in processing this API call, a dispositionReport element MUST be returned to the caller within a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the errors common to all APIs, the following error information is relevant here:
    
    ·         E_accountLimitExceeded: Signifies that user account limits have been exceeded.
    
    ·         E_invalidKeyPassed: Signifies that the request cannot be satisfied because one or more uddiKey values specified are not valid key values for the entities being published. tModelKey, businessKey, serviceKey, or bindingKey values that either do not exist, or exist with a different entity type, or are not authorized to be proposed by the publisher are considered to be invalid values. The key causing the error SHOULD be clearly indicated in the error text. This error code will also be returned in the event that the businessKey is not provided and the serviceKey is either absent or has a value not registered in the registry. In this case, the error text SHOULD clearly indicate the use of an incomplete businessService.
    
    ·         E_invalidValue: A value that was passed in a keyValue attribute did not pass validation. This applies to checked value sets referenced using keyedReferences. The error text SHOULD clearly indicate the key and value combination that failed validation.
    
    ·         E_keyUnavailable: Indicates that the proposed key has already been assigned to some other publisher or is not within the partition defined by a key generator tModel that the publisher owns.
    
    ·         E_requestTimeout: Signifies that the request could not be carried out because a needed validate_values service did not respond in a reasonable amount of time. Details identifying the failing Web service SHOULD be included in the dispositionReport element.
    
    ·         E_userMismatch: Signifies that one or more of the uddiKey values passed refers to data that is not owned by the individual publisher who is represented by the authentication token.
    
    ·         E_unsupported: A keyedReference in a categoryBag that references a checked value set cannot be validated by the UDDI node because the node does not support the referenced checked value set. The error text SHOULD clearly indicate the keyedReference that cannot be validated.
    
    ·         E_unvalidatable: A keyedReference in a categoryBag that references a checked value set cannot be validated by the UDDI node because the referenced tModel has been marked unvalidatable. The error text SHOULD clearly indicate the keyedReference that cannot be validated.
    
    ·         E_valueNotAllowed: The value set validation routine chosen by the UDDI node has rejected the businessService data provided. The error text SHOULD clearly indicate the keyedReference that was not successfully validated.
    
    DispositionReportFaultMessage
    
    RemoteException
  - saveTModel
```
TModelDetail saveTModel(SaveTModel body)
                 throws DispositionReportFaultMessage,
                        RemoteException
```
    The save_tModel API call adds or updates one or more registered tModel elements. tModels MAY be signed and tModels MAY be saved with publisher-assigned keys, including those tModels that establish the domain partition of publisher-assigned keys, known as domain key generator tModels.
    
    Parameters:
    
    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. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call.
    
    ·         tModel: Required repeating element containing one or more required repeating complete tModel elements. For the purpose of performing round-trip updates, this data can be obtained in advance by using the get_tModel API call or by other means.
    
    If the uddiKey value within a tModel (i.e., tModelKey) is missing or is passed with an empty value, this is a signal that a new tModel is being inserted and that the UDDI registry MUST assign a new tModelKey identifier to this data. If the new tModel is categorized with the keyGenerator value from the uddi:uddi.org:categorization:types category system, any publisher assigned key MUST end with the string ":keygenerator" , making the tModel a key generator tModel. If the new tModel is categorized with the keyGenerator value from the uddi:uddi.org:categorization:types category, an empty uddiKey signifies that the tModelKey generated by the node will end with the string ":keygenerator", making the tModel a key generator tModel. New tModels can also be added with publisher-assigned keys. See Section 5.2.2.2 Behavior of Publishers and Section 5.2.18.3.1 Domain Key Generator tModels.
    
    This API call performs an update to existing registered data when the tModelKey values have uddiKey values that correspond to already registered data.
    
    If a tModelKey value is passed that corresponds to a tModel that was previously hidden via the delete_tModel API call, the save_tModel service restores the tModel to full visibility, making it available for return in find_tModel results.
    
    The value of the deleted attribute in the tModel is set to false in all saves.
    
    Multiple representations of the overview document MAY be registered for a tModel allowing, for example, both technical and human readable representations of the technical overview to be provided.
    
    When a tModel is saved with keyedReferences, all tModelKeys used in keyedReferences must refer to tModels that existed prior to processing the tModel containing the references. A save_tModel API call may contain a sequence of tModels, in which case a keyedReference in a tModel may refer to tModelKeys created earlier but not later in the sequence. A tModel being created must not refer to itself. Self-referencing tModels can be created by using two subsequent save_tModel API calls, the first one without the reference, and the second one with the reference (to the already saved tModel). If these conditions are not met, the node MUST return E_invalidKeyPassed.
    
    When a tModel is saved with identifierBag or categoryBag contents that is associated with a checked value set or category group system tModel, the references MUST be checked for validity prior to completion of the save, or the node MUST return E_unsupported, indicating it does not support the referenced checked value set or category group system. See Section 5.2.3 Special considerations for validated value sets, Appendix E Using Identifiers and Appendix F Using Categorization for additional details.
    
    Domain key generator tModels
    
    For registries that use the recommended key syntax, a domain key generator tModel establishes a key partition from which uddiKeys can be derived and used in other entities controlled by the publisher, as described in Section 4.4.1 Key Syntax. Additional considerations are involved when publishing a domain key generator tModel for the first time.
    
    1.       The tModelKey MUST be in the form of a domain_key and MUST end with the term: keyGenerator.
    
    2.       The tModelKey MUST be categorized with the keyGenerator value from the uddi:uddi.org:categorization:types category system.
    
    3.       Registry policy for establishing key domains MAY require the tModel to be signed.
    
    Also, publishers of key generator tModels MAY use the overviewDoc to describe how the key space is defined.
    
    The save_tModel API call does a first pass check of the tModel to check its suitability and, if it is acceptable according to the policy of the registry for saving domain key generator tModels, returns the tModelDetail for the registry. If it is not acceptable the reason is clearly indicated in the returned dispositionReport and no further processing takes place.
    
    If the registry has multiple nodes, returning the tModelDetail is not an indication that the domain key generator tModel has been published successfully. A registry that allows publisher assigned keys MUST have a policy to ensure domainKey collisions do not occur. The custodial node MUST ensure that the domain key generator tModel is not in the process of being published simultaneously on some other node. If, after the conclusion of a full replication cycle, no UDDI node has already assigned or attempted to assign the partition (e.g., no change record has been received from other nodes), the custodial node completes the publish operation of the domain key generator tModel, assigning it to the publisher. If some other node has already been assigned the partition, the tModel is not published. See Section 7.3.9 changeRecordNewDataConditional for more information on the replication structure, and Section 9.4.2 General Keying Policy and Section 9.4.3 Policy Abstractions for the UDDI keying scheme for the recommended policy that addresses acceptance of a domain key generator.
    
    When the publishing of a domain key generator tModel has completed, the custodial node MAY notify the publisher that the tModel is ready for use. Whether a node does this and the means by which it does so is a node policy. A typical node policy is to notify the publisher by e-mail using an e-mail address gathered at the time the publisher account was set up.
    
    Before the publish operation is complete, the domain key generator tModel will be ignored by find_xx and get_xx API calls, and will return an E_keyUnavailable error to further save_tModel calls.
    
    If after the replication cycle the publisher is in doubt about the outcome, get_tModelDetail may be issued specifying the key of the domain key generator tModel being published. If a tModel is retrieved and the publisher is the owner, the operation succeeded. If a tModel is retrieved and some other publisher is the owner, the operation failed because another publisher published a domain key generator with the chosen domain_key first. If no tModel is retrieved, then either the registry experienced a failure, or two publishers tried to publish tModels with the same key "simultaneously", and neither succeeded. In either of these cases, the save_tModel operation may be retried.
    
    Attempts to remove the following categorization from a successfully published key generator tModel will fail with E_fatalError, since it is this very categorization that distinguishes key generator tModels from other tModels:
    
    <tModelKey="uddi:uddi.org:categorization:types" keyValue="keyGenerator" />
    
    Returns:
    
    returns org.uddi.api_v3.TModelDetail
    In most cases this API returns a tModelDetail containing the final results of the call that reflects the new or pending registered information for the affected tModel structures. Any tModelKey attributes that were assigned as a result of processing the save_tModel API are included in the tModel data. When a domain key generator is saved for the first time, the tModel that is returned in the tModelDetail represents an interim state, until all nodes in the registry have ascertained that the requested key domain does in fact belong to the publisher[27]. See Section 7.3.9 changeRecordNewDataConditional for more information. If multiple tModel elements are passed in the save_tModel request, the order of the response MUST exactly match the order that the elements appeared in the save. If the same tModel, determined by matching key, is listed more than once in the save_tModel API, it MAY be listed only once in the result for each appearance in the save_tModel API. If the same tModel appears more than once in the response, the last occurrence of the tModel in the results represents the state stored in the registry.
    
    The tModelDetail has the form:
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException
    If an error occurs in processing this API call, a dispositionReport element MUST be returned to the caller in a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the errors common to all APIs, the following error information is relevant here:
    
    ·         E_accountLimitExceeded: Signifies that user account limits have been exceeded.
    
    ·         E_invalidKeyPassed: Signifies that the request cannot be satisfied because one or more uddiKey values specified are not valid key values for the entities being published. tModelKey values that either do not exist, or exist with a different entity type, or are not authorized to be proposed by the publisher are considered to be invalid values. The key causing the error SHOULD be clearly indicated in the error text.
    
    ·         E_invalidValue: A value that was passed in a keyValue attribute did not pass validation. This applies to checked value sets referenced using keyedReferences. The error text SHOULD clearly indicate the key and value combination that failed validation.
    
    ·         E_keyUnavailable: Indicates that the proposed key has already been assigned to some other publisher, is not within the partition defined by a key generator tModel that the publisher owns, or, in the case of a domain key generator tModel being saved for the first time, is assigned to some other publisher or is still pending its first save.
    
    ·         E_requestTimeout: Signifies that the request could not be carried out because a needed validate_values Web service did not respond in a reasonable amount of time. Details identifying the failing Web service SHOULD be included in the dispositionReport element.
    
    ·         E_unacceptableSignature: Indicates that the digital signature in the tModel is missing or does not meet the requirements of the registry. The errInfo element provides additional details.
    
    ·         E_userMismatch: Signifies that one or more of the uddiKey values passed refers to data that is not owned by the individual publisher who is represented by the authentication token.
    
    ·         E_unsupported: A keyedReference in a categoryBag or an identifierBag that references a checked value set cannot be validated by the UDDI node because the node does not support the referenced checked value set. The error text SHOULD clearly indicate the keyedReference that cannot be validated.
    
    ·         E_unvalidatable: A keyedReference in a categoryBag or an identifierBag that references a checked value set cannot be validated by the UDDI node because the referenced tModel has been marked unvalidatable. The error text SHOULD clearly indicate the keyedReference that cannot be validated.
    
    ·         E_valueNotAllowed: Restrictions have been placed by the value set provider on the types of information that should be included at that location within a specific value set. The validation routine chosen by the UDDI node has rejected this tModel for at least one specified keyedReference. The error text SHOULD clearly indicate the keyedReference that was not successfully validated.
    
    DispositionReportFaultMessage
    
    RemoteException
  - setPublisherAssertions
```
@RequestWrapper(localName="set_publisherAssertions",
                targetNamespace="urn:uddi-org:api_v3",
                className="org.uddi.api_v3.SetPublisherAssertions")
 @ResponseWrapper(localName="publisherAssertions",
                 targetNamespace="urn:uddi-org:api_v3",
                 className="org.uddi.api_v3.PublisherAssertions")
void setPublisherAssertions(String authInfo,
                                                                                                                                                                                                                                                                                                                                                                                               Holder<List<PublisherAssertion>> publisherAssertion)
                                                                                                                                                                                                                                                                                                                                                                                        throws DispositionReportFaultMessage,
                                                                                                                                                                                                                                                                                                                                                                                               RemoteException
```
    The set_publisherAssertions API call is used to manage all of the tracked relationship assertions associated with an individual publisher. See Appendix A Relationships and Publisher Assertions for more information.
    
    Parameters:
    
    publisherAssertion -
    ·         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. Registries that serve multiple publishers and registries that restrict who can publish in them typically require authInfo for this call.
    
    authInfo -
    ·         publisherAssertion: Optional repeating element asserting a relationship. Relationship assertions consist of a reference to two businessEntity key values as designated by the fromKey and toKey elements, as well as a REQUIRED expression of the directional relationship within the contained keyedReference element. See Appendix A Relationships and Publisher Assertions. The fromKey, the toKey, and all three parts of the keyedReference – the tModelKey, the keyName, and the keyValue – MUST be specified. E_fatalError is returned if any of these elements are missing in any of the publisherAssertion elements. Empty (zero length) keyNames and keyValues are permitted.
    
    The full set of assertions associated with a publisher is effectively replaced whenever this API is used. When this API call is processed, the publisher assertions that exist prior to this API call for a given publisher are examined by the UDDI registry. Any new assertions not present prior to the call are added to the assertions attributed to the publisher. Any existing assertions not present in the call are deleted.   As a result, new relationships may be completed (e.g. determined to have a completed status), and existing relationships may be dissolved. Invoking this API with no publisherAssertion elements deletes all assertions associated with the publisher.
    
    Any relationships attributed to assertions previously present but not present in the data provided in this call are deactivated and are no longer visible via the find_relatedBusinesses API. For the sake of determining uniqueness within an assertion set, the fromKey, toKey, and the entire keyedReference within the publisherAssertion element are significant. Any differences in any of the individual publisherAssertion element contents constitute a new unique assertion for purposes of detecting new assertions. The direction of the relationship, as indicated by the two businessKey values in the fromKey and toKey elements, is also relevant in determining assertion uniqueness.
    
    The publisher must own the businessEntity referenced in the fromKey, the toKey, or both. If both of the businessKey values passed within an assertion are owned by the publisher, then the assertion is automatically complete and the relationship described in the assertion is visible via the find_relatedBusinesses API. To form a relationship when the publisher only owns one of the two keys passed, the assertion MUST be matched exactly by an assertion made by the publisher who owns the other business referenced. Assertions exactly match if and only if they:
    
    1.       refer to the same businessEntity in their fromKeys;
    
    2.       refer to the same businessEntity in their toKeys;
    
    3.       refer to the same tModel in their tModelKeys;
    
    4.       have identical keyNames; and
    
    5.       have identical keyValues.
    
    When a publisherAssertion that is being saved references a checked relationship system using the tModelKey in the contained keyedReference, the reference MUST be checked for validity prior to completion of the save, or the node must return E_unsupported, indicating it does not support the referenced checked relationship system. Validation of a relationship system reference entails verification that the reference is valid according to the validation algorithm defined for the relationship system and described by its tModel. For cached checked relationship system, the validation algorithm verifies that referenced keyedReferences are valid for the relationship system.
    
    For registries supporting the subscription APIs at any node, it is necessary to track a modified date for publisherAssertion elements so that nodes have the necessary information for responding to subscription requests involving find_relatedBusinesses and get_assertionStatusReport filters.
    
    Upon successful completion, a publisherAssertions structure is returned containing all of the relationship assertions currently attributed to the publisher. When registries distinguish between publishers, the structure contains assertion data that is associated with the authInfo passed.
    
    See Section 5.2.13.3 get_publisherAssertions for more information on the publisherAssertions structure and contents.
    
    This API returns all assertions made by the publisher who was authenticated in the set_publisherAssertions API.
    
    Throws:
    
    DispositionReportFaultMessage, - RemoteException
    If an error occurs in processing this API call, a dispositionReport element MUST be returned to the caller in a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the errors common to all APIs, the following error information is relevant here:
    
    ·         E_invalidKeyPassed: Signifies that one of the uddiKey values passed did not match with any known businessKey or tModelKey values. The assertion element and the key that caused the problem SHOULD be clearly indicated in the error text.
    
    ·         E_userMismatch: Signifies that neither of the businessKey values passed in the embedded fromKey and toKey elements is controlled by the publisher associated with the authentication token. The error text SHOULD clearly indicate which assertion caused the error.
    
    DispositionReportFaultMessage
    
    RemoteException

Name	Use
completionStatus	required

Interface UDDIPublicationPortType

Publication API Set

5.2.1 Publishing entities with node assigned keys

5.2.2 Publishing entities with publisher-assigned keys

5.2.2.1 Key generator keys and their partitions

5.2.2.1.1 Examples

5.2.2.2 Behavior of publishers

5.2.2.3 Behavior of UDDI nodes

5.2.2.3.1 "New" and "existing" entities defined

5.2.2.3.2 Behavior with respect to entities for which no key is proposed.

5.2.2.3.3 Behavior with respect to uuidKeys

5.2.2.3.4 Behavior with respect to key generator keys

5.2.2.3.5 Behavior with respect to root key generator keys

5.2.2.3.6 Behavior with respect to other proposed keys

5.2.2.4 Affiliations of registries

5.2.3 Special considerations for validated value sets

5.2.4 Special considerations for the xml:lang attribute

5.2.5 Publisher API summary

Method Summary

Method Detail

addPublisherAssertions

deleteBinding

deleteBusiness

deletePublisherAssertions

deleteService

deleteTModel

getAssertionStatusReport

getPublisherAssertions

getRegisteredInfo

saveBinding

saveBusiness

saveService

saveTModel

Domain key generator tModels

setPublisherAssertions