java.rmi.server.RemoteObject
java.rmi.server.RemoteServer
java.rmi.server.UnicastRemoteObject
org.apache.juddi.rmi.UDDIPublicationService
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | |||||||||
java.lang.Object
public class UDDIPublicationService
UDDIPublicationPortType wrapper so it can be exposed as a service over RMI.
| Field Summary |
|---|
| Fields inherited from class java.rmi.server.RemoteObject |
|---|
ref |
| Constructor Summary | |
|---|---|
protected |
UDDIPublicationService(int port)
|
| Method Summary | |
|---|---|
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,
javax.xml.ws.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.rmi.server.UnicastRemoteObject |
|---|
clone, exportObject, exportObject, exportObject, unexportObject |
| Methods inherited from class java.rmi.server.RemoteServer |
|---|
getClientHost, getLog, setLog |
| Methods inherited from class java.rmi.server.RemoteObject |
|---|
equals, getRef, hashCode, toString, toStub |
| Methods inherited from class java.lang.Object |
|---|
finalize, getClass, notify, notifyAll, wait, wait, wait |
| Constructor Detail |
|---|
protected UDDIPublicationService(int port)
throws RemoteException
RemoteException| Method Detail |
|---|
public void addPublisherAssertions(AddPublisherAssertions body)
throws RemoteException
UDDIPublicationPortTypeThe 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.
addPublisherAssertions in interface UDDIPublicationPortTypebody - · 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.RemoteException
public void deleteBinding(DeleteBinding body)
throws RemoteException
UDDIPublicationPortType
deleteBinding in interface UDDIPublicationPortTypebody - · 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.RemoteException
public void deleteBusiness(DeleteBusiness body)
throws RemoteException
UDDIPublicationPortType
deleteBusiness in interface UDDIPublicationPortTypebody - · 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.RemoteException
public void deletePublisherAssertions(DeletePublisherAssertions body)
throws RemoteException
UDDIPublicationPortType
deletePublisherAssertions in interface UDDIPublicationPortTypebody - · 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.RemoteException
public void deleteService(DeleteService body)
throws RemoteException
UDDIPublicationPortType
deleteService in interface UDDIPublicationPortTypebody - · 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.
RemoteException
public void deleteTModel(DeleteTModel body)
throws RemoteException
UDDIPublicationPortType
deleteTModel in interface UDDIPublicationPortTypebody - · 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.RemoteException
public List<AssertionStatusItem> getAssertionStatusReport(String authInfo,
CompletionStatus completionStatus)
throws RemoteException
UDDIPublicationPortType
getAssertionStatusReport in interface UDDIPublicationPortTypeauthInfo - · 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.
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.
RemoteException
public List<PublisherAssertion> getPublisherAssertions(String authInfo)
throws RemoteException
UDDIPublicationPortType
getPublisherAssertions in interface UDDIPublicationPortTypeauthInfo - · 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.
RemoteException
public RegisteredInfo getRegisteredInfo(GetRegisteredInfo body)
throws RemoteException
UDDIPublicationPortType
getRegisteredInfo in interface UDDIPublicationPortTypebody - 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.
RemoteException
public BindingDetail saveBinding(SaveBinding body)
throws RemoteException
UDDIPublicationPortType
saveBinding in interface UDDIPublicationPortTypebody - · 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.
RemoteException
public BusinessDetail saveBusiness(SaveBusiness body)
throws RemoteException
UDDIPublicationPortTypeThe 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.
saveBusiness in interface UDDIPublicationPortTypebody - · 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.
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:
RemoteException
public ServiceDetail saveService(SaveService body)
throws RemoteException
UDDIPublicationPortType
saveService in interface UDDIPublicationPortTypebody - · 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.
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:
RemoteException
public TModelDetail saveTModel(SaveTModel body)
throws RemoteException
UDDIPublicationPortType
saveTModel in interface UDDIPublicationPortTypebody - · 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.
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" />
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:
RemoteException
public void setPublisherAssertions(String authInfo,
javax.xml.ws.Holder<List<PublisherAssertion>> publisherAssertion)
throws RemoteException
UDDIPublicationPortType
setPublisherAssertions in interface UDDIPublicationPortTypeauthInfo - · 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.
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.
RemoteException
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | |||||||||