org.apache.juddi.v3.client.transport.wrapper

Class Publish3to2

java.lang.Object

org.apache.juddi.v3.client.transport.wrapper.Publish3to2

All Implemented Interfaces:

Remote, BindingProvider, UDDIPublicationPortType

public class Publish3to2
extends Object
implements UDDIPublicationPortType, BindingProvider

This class provides a wrapper to enable UDDIv3 clients to talk to UDDIv2 servers via JAXWS Transport. It handles all translations for Publish service methods.

Since:

3.2

Author:

Alex O'Ree

Field Summary

Fields inherited from interface javax.xml.ws.BindingProvider

ENDPOINT_ADDRESS_PROPERTY, PASSWORD_PROPERTY, SESSION_MAINTAIN_PROPERTY, SOAPACTION_URI_PROPERTY, SOAPACTION_USE_PROPERTY, USERNAME_PROPERTY

Constructor Summary

Constructors

Constructor and Description
Publish3to2()

Method Summary

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.
Binding	getBinding()
EndpointReference	getEndpointReference()
<T extends EndpointReference> T	getEndpointReference(Class<T> clazz)
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.
Map<String,Object>	getRequestContext()
Map<String,Object>	getResponseContext()
Publish	getUDDIv2PublishWebServiceClient()
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.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

Publish3to2

public Publish3to2()

Method Detail

getUDDIv2PublishWebServiceClient

public Publish getUDDIv2PublishWebServiceClient()

addPublisherAssertions

public void addPublisherAssertions(AddPublisherAssertions body)
                            throws DispositionReportFaultMessage,
                                   RemoteException

Description copied from interface: UDDIPublicationPortType

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.

Specified by:

addPublisherAssertions in interface UDDIPublicationPortType

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

deleteBinding

public void deleteBinding(DeleteBinding body)
                   throws DispositionReportFaultMessage,
                          RemoteException

Description copied from interface: UDDIPublicationPortType

The delete_binding API call causes one or more instances of bindingTemplate data to be deleted from the UDDI registry.

Specified by:

deleteBinding in interface UDDIPublicationPortType

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

deleteBusiness

public void deleteBusiness(DeleteBusiness body)
                    throws DispositionReportFaultMessage,
                           RemoteException

Description copied from interface: UDDIPublicationPortType

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.

Specified by:

deleteBusiness in interface UDDIPublicationPortType

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

deletePublisherAssertions

public void deletePublisherAssertions(DeletePublisherAssertions body)
                               throws DispositionReportFaultMessage,
                                      RemoteException

Description copied from interface: UDDIPublicationPortType

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.

Specified by:

deletePublisherAssertions in interface UDDIPublicationPortType

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

deleteService

public void deleteService(DeleteService body)
                   throws DispositionReportFaultMessage,
                          RemoteException

Description copied from interface: UDDIPublicationPortType

The delete_service API call is used to remove one or more businessService elements from the UDDI registry and from its containing businessEntity parent.

Specified by:

deleteService in interface UDDIPublicationPortType

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

deleteTModel

public void deleteTModel(DeleteTModel body)
                  throws DispositionReportFaultMessage,
                         RemoteException

Description copied from interface: UDDIPublicationPortType

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.

Specified by:

deleteTModel in interface UDDIPublicationPortType

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

getAssertionStatusReport

public List<AssertionStatusItem> getAssertionStatusReport(String authInfo,
                                                          CompletionStatus completionStatus)
                                                   throws DispositionReportFaultMessage,
                                                          RemoteException

Description copied from interface: UDDIPublicationPortType

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.

Specified by:

getAssertionStatusReport in interface UDDIPublicationPortType

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.

· 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

getPublisherAssertions

public List<PublisherAssertion> getPublisherAssertions(String authInfo)
                                                throws DispositionReportFaultMessage,
                                                       RemoteException

Description copied from interface: UDDIPublicationPortType

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.

Specified by:

getPublisherAssertions in interface UDDIPublicationPortType

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

getRegisteredInfo

public RegisteredInfo getRegisteredInfo(GetRegisteredInfo body)
                                 throws DispositionReportFaultMessage,
                                        RemoteException

Description copied from interface: UDDIPublicationPortType

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.

Specified by:

getRegisteredInfo in interface UDDIPublicationPortType

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

saveBinding

public BindingDetail saveBinding(SaveBinding body)
                          throws DispositionReportFaultMessage,
                                 RemoteException

Description copied from interface: UDDIPublicationPortType

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.

Specified by:

saveBinding in interface UDDIPublicationPortType

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

saveBusiness

public BusinessDetail saveBusiness(SaveBusiness body)
                            throws DispositionReportFaultMessage,
                                   RemoteException

Description copied from interface: UDDIPublicationPortType

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.

Specified by:

saveBusiness in interface UDDIPublicationPortType

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

saveService

public ServiceDetail saveService(SaveService body)
                          throws DispositionReportFaultMessage,
                                 RemoteException

Description copied from interface: UDDIPublicationPortType

The save_service API call adds or updates one or more businessService elements. Each businessService MAY be signed and MAY have publisher-assigned keys.

Specified by:

saveService in interface UDDIPublicationPortType

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

saveTModel

public TModelDetail saveTModel(SaveTModel body)
                        throws DispositionReportFaultMessage,
                               RemoteException

Description copied from interface: UDDIPublicationPortType

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.

Specified by:

saveTModel in interface UDDIPublicationPortType

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

setPublisherAssertions

public void setPublisherAssertions(String authInfo,
                                   Holder<List<PublisherAssertion>> publisherAssertion)
                            throws DispositionReportFaultMessage,
                                   RemoteException

Description copied from interface: UDDIPublicationPortType

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.

Specified by:

setPublisherAssertions in interface UDDIPublicationPortType

Parameters:

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.

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.

Throws:

DispositionReportFaultMessage

RemoteException

getRequestContext

public Map<String,Object> getRequestContext()

Specified by:

getRequestContext in interface BindingProvider

getResponseContext

public Map<String,Object> getResponseContext()

Specified by:

getResponseContext in interface BindingProvider

getBinding

public Binding getBinding()

Specified by:

getBinding in interface BindingProvider

getEndpointReference

public EndpointReference getEndpointReference()

Specified by:

getEndpointReference in interface BindingProvider

getEndpointReference

public <T extends EndpointReference> T getEndpointReference(Class<T> clazz)

Specified by:

getEndpointReference in interface BindingProvider