UDDI Publish API

The messages in this section represent commands that require authenticated access to an UDDI Operator Site, and are used to publish and update information contained in a UDDI compatible registry. Each business should initially select one Operator Site to host their information. Once chosen, information can only be updated at the site originally selected. UDDI provides no automated means to reconcile multiple or duplicate registrations. The messages defined in this section all behave synchronously and are callable via HTTP-POST only. HTTPS is used exclusively for all of the calls defined in this publisher's API.

The publish API define the operations which UDDI operators support. The operations are categoried as the following:

• Authentication/Authorization Operations
• Save Operations
• Delete Operations
• Get Operations

Authentication/Authorization Operations

Before you can publish anything to a UDDI registry, you have to enroll with a specific UDDI operator. Once you’ve enrolled, you can use your user-id and password to log in, then use the Publishing APIs to add, modify, and delete data in the UDDI registry.

• <get_authToken>: The API call is used to request an authentication token from an Operator Site. Authentication tokens are required when using all other API’s defined in the publishers API. This function serves as the program's equivalent of a login request. The response from UDDI server is a authToken type of response message.

• <discard_authToken>: The API call is used to inform a node that passed authentiction token is to be terminate and effectively end the session when you are finished accessing the UDDI Publishing endpoint. The registry will then invalidate your authentication token and end the session. Further access with that token will cause an error, so your session is effectively end. If the discard_authToken is never sent, the session will simple time out, which also invalidates the authentication token.  The response from UDDI server is a dispositionReport type of res[onse message.

Save Operations

The save operations allow you to add or update information in the UDDI registy.

The SOAP request and response messages used for the save operations all take the same basic form: The request message carries one or more primary data structures to be add or update, while the response message returns the data structures that were successfully added or updated. To update any part of a data structure, you HAVE TO submit the whole thing; you cannot update a single field.

• <save_binding>: The API call is used to register new bindingTemplate information or update existing bindingTemplate information. 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. Use this to control information about technical capabilities exposed by a registered business.  The repsonse from UDDI server is a bindingDetail type of  response message.

• <save_business>: The API call is used to register new businessEntity information or update existing businessEntity information. Use this to control the overall information about the entire business. This API has the broadest scope of all of the save_XXX 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. The response from UDDI server is a businessDetail type of response message.

• <save_service>: The API call is used to register or update complete information about a businessService exposed by a specified businessEntity. The API call adds or updates one or more <businessService> elements. Each <businessService> may be signed and may have publisher-assigned keys. The response from UDDI server is a serviceDetail type of response message.

• <save_tModel>: The API call is used to register or update complete information about a tModel. The API call adds or updates one or more registered <tModel> elements. <tModel> elements may be signed and saved with publisher-assigned keys, including those <tModel> elements that establish the domain partition of publisher-assigned keys, known as domain key generator tModels. The response from UDDI server is a tModelDetail type of response message.

• <add_publisherAssertions>: The API call causes one or more <publishAssertions> to be added to an individual publisher’s assertion collection. The response from UDDI server is a dispositionReport type of response message. Remember, a publishAssertion is not valid and visoble until both parties submit assertions with the same relationship.

• <set_publisherAssertions>: The API call is used to update the complete set of existing publisher assertions for an individual publisher account. Replaces any existing assertions, and causes any old assertions that are not reasserted to be removed from the registry. Publisher assertions are used to control publicly visible business relationships. The response from UDDI server is a publishAssertions type of response message

Delete Operations

The delete operations allow you to remove information from the UDDI registry. The SOAP request and response messages used for the delete operations all take the same basic form: The request message carries keys to one or more primary data structures to be deleted. The response from UDDI server is a dispositionReport type of response message unless it’s reporting a fault.

• <delete_binding>: The API call is used to removes one or more existing instances of <bindingTemplate> data from the bindingTemplates collection that is part of a specified businessService data structure in the UDDI registry. tModels referred to by bindingTemplates being deleted are not affected, they must be deleted explicitly using the delete_tModel operation.

• <delete_business>: The API call is used to remove one or more registered businessEntity entries and all elements (such as, all businessServices, bindingTemplates, and publisherAssertions) that correspond to the natural content of the corresponding <businessEntity> elements from a UDDI registry. The exceptions are

• bindingTemplates, that other bindingTemplates refer to as hosting redirectors.
• Project references,data types referred to by the bussinessEntity being deleted, but owneed by some other businessEntity
• tModels, which must be deleted explicitly using the delete_tModel opeation

• <delete_publisherAssertions>: The API call is used to delete specific publisher assertions from the assertion collection controlled by a particular publisher account. Deleting assertions from the assertion collection will affect the visibility of business relationships. Deleting an assertion will cause any relationships based on that assertion to be invalidated. This delete operation isdifferent from others because a publisherAssertion doesn’t have a UUID key;  you delete a publisherAssertion using its to and from keys as a compound key.

• <delete_service>: The API call is used to delete one or more existing businessService data from UDDI registry and from the businessServices collection contained by its businessEntity parent. All bindingTemplates owned by the deleted businessService will also be removed from the UDDI registry. The exceptions are the same as for delete_business; projected references, hosting redirectors, and tModels.

• <delete_tModel>: The API call is used to HIDE registered information about a tModel. Any tModel hidden in this way is still usable for reference purposes and accessible via the get_tModelDetail message, but is simply hidden from find_tModel result sets. There is no way to actually cause a tModel to be deleted, except by administrative petition.

Get Operations

The publishing API calls defined that UDDI operators support are:

• <get_assertionStatusReport>: The API call is used to get a status report containing publisher assertions and status information. This report is useful to help an administrator manage active and tentative publisher assertions. Publisher assertions are used in UDDI to manage publicly visible relationships between businessEntity structures. Relationships are a feature introduced in generic 2.0 that help manage complex business structures that require more than one businessEntity or more than one publisher account to manage parts of a businessEntity. Returns an assertionStatusReport that includes the status of all assertions made involving any businessEntity controlled by the requesting publisher account.

• <get_publisherAssertions>: The API call is used to get a list of active publisher assertions that are controlled by an individual publisher account. Returns a publisherAssertions message containing all publisher assertions associated with a specific publisher account. Publisher assertions are used to control publicly visible business relationships.  It complements the <get_registeredInfo> API which returns information about businesses, services, bindings, and tModels managed by a publisher. The SOAP response message is publisherAssertions including contains zero or more (visible or invisible) publisherAssertioin data structure that you have submitted in the past.

• <get_registeredInfo>: The API call is used to request an abbreviated synopsis of all information currently managed by a given individual. 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. The response from UDDI server is registeredInfo (contains businessInfos and tModelInfos data structures) type of response message.