org.uddi.v3_service
Interface UDDIPublicationPortType
- All Superinterfaces:
- Remote
- All Known Implementing Classes:
- UDDIPublicationImpl, UDDIPublicationService
public interface UDDIPublicationPortType
- extends Remote
This portType defines all of the UDDI publication operations.
This class was generated by the JAX-WS RI. JAX-WS RI 2.1.5-b03- Generated
source version: 2.1
The API calls in this section are used to publish and
update information contained in a UDDI registry. According to the
policy of the UDDI registry, a publisher selects a UDDI node where it will
publish the information.
API calls in this section MUST all be implemented as
synchronous and "atomic" from the point of view of the caller. That is, each
call MUST either succeed completely or fail completely. Partial results MUST
NOT be returned.
When a publisher does not provide keys for new
entities, the UDDI node will assign keys in accordance with registry policy.
Node-assigned keys MUST use keys that conform to the grammar in Section 4.4 About uddiKeys.
The registry keying policy MAY allow an entity’s key
to be proposed by the publisher. If the publisher does not propose a key for
an entity, the registry MUST assign one.
Since entity keys MUST be unique in a registry without
regard to the type of entity and since registries MUST define to impose
policies concerning which publishers may publish which keys,
publisher-assigned keys are subject to rules that UDDI registries enforce.
Behavior that ensures uniqueness across entity types (businessEntity,
businessService, bindingTemplate, tModel and subscription) is REQUIRED for
all registries. In this section we discuss the behavior of registries that
use the recommended "uddi:" key structure. This behavior provides uniqueness
and promotes interoperability among registries, while allowing various
registry-specific policies to be built. Practical guidance for the use of
this facility may be found in Section 9.4.2
General Keying Policy and Section 9.4.3
Policy Abstractions for the UDDI keying scheme.
To ensure that publisher-generated keys do not
conflict with one another, registries assign the authority to generate keys
to publishers in the following manner:
1. The conceptual space
of uddiKeys is divided into non-overlapping, hierarchically arranged
partitions, each of which can be associated with a publisher.
2. Only the publisher
associated with a particular partition is given the authority to assign keys
within the partition.
3. The publisher with
authority for a given partition may designate any publisher it chooses for
any partition directly below the partition it manages, provided it has not
already designated a publisher to that partition.
4. The publisher with
authority for a partition may transfer its authority to another
publisher.
5. Initially, the
registry itself has authority for the root partition of the hierarchy.
The specific mechanisms that enforce these rules are
explained below.
Each node of a registry is a generator of keys.
This is required to enable the node to generate keys not provided by
publishers. In addition, the policies of a registry MAY allow individual
publishers to obtain the authority to be generators of keys for specific
partitions within the space of uddiKeys. Publishers obtain this authority by
owning a particular tModel called a key generator tModel. The key
generator tModel contains a key generator key, and it specifies the partition
for which the publisher may assign keys.
The subset of
derivedKeys called key generator keys consists of all the keys of the
form:
keyGeneratorKey
=
uddiKey ":keygenerator"
As described in Section 4.4.1, a derivedKey is one
that is formed from another key by appending a non-empty, colon-prefixed
string to another uddiKey. A derivedKey is said to be "based on" this
uddiKey. With this in mind, the complete partition of a given keyGeneratorKey
is the set of keys consisting of:
1. The set of
derivedKeys based on the same uddiKey that the keyGeneratorKey is based
upon.
2. The set of
keyGeneratorKeys based on a key that is in the partition.
3. The domainKey, if
the keyGeneratorKey is based upon that domainKey.
Note that the partition's keyGeneratorKey itself is
exluded from the partition.
A rootKeyGeneratorKey is a keyGeneratorKey that is not
based on a derivedKey. That is:
rootKeyGeneratorKey
= (uuidKey /
domainKey) ":keygenerator"
5.2.2.1.1 Examples
Based on the rules above, it is possible to construct
the keyGeneratorKey for any key by manipulating the string representation of
the key. To illustrate, suppose the key is x, then the following pseudo-code
will determine the keyGeneratoryKey:
If x is a keyGeneratorKey, and y is that key minus the
":keygenerator" suffix,
then if y is a domainKey
then x is a top-level keyGenerator, and
has no keyGeneratorKey (1.a)
else y is a derivedKey, based on z,
and x’s
keyGeneratorKey is z:keyGenerator (1.b)
else
If x is a domainKey
then x’s keyGeneratorkey is
x:keyGenerator (2)
else x is based on a key y, and x’s keyGenerator is
y:keyGenerator (3)
Using this pseudo-code illustration, the following
table provides examples of legal URI’s and their associated key generators
for each of the four cases noted:
| Key | keyGeneratorKey
| Case in pseudo-code |
| uddi:tempuri.com | uddi:tempuri.com:keygenerator | 2 |
| uddi:tempuri.com:keygenerator | <none> | 1.a |
| uddi:tempuri.com:xxx:keygenerator | uddi:tempuri.com:keygenerator | 1.b |
| uddi:tempuri.com:xxx | uddi:tempuri.com:keygenerator | 3 |
| uddi:tempuri.com:xxx:yyy | uddi:tempuri.com:xxx:keygenerator | 3 |
The following keys do NOT belong to the partition of
the key generator key "uddi:tempuri.com:keygenerator".
|
"uddi:tempuri.com:keygenerator" | The keyGeneratorKey does not belong to the partition it
designates. |
|
"uddi:tempuri.com:xxx:yyy" | This key belongs to the partition of the keyGeneratorKey
"uddi:tempuri.com:xxx:keygenerator", not this one. |
|
"uddi:tempuri.com:keygenerator:zzz" | This key does not belong in any partition – it is an
invalid key. |
To successfully publish a new entity with a proposed
key, the publisher needs to own the key generator tModel for the partition in
which the key lies. Typically, a publisher gets ownership by publishing the
tModel in question, but publishers can also get ownership in other ways, for
example by having another publisher transfer ownership.
Once a publisher owns a key generator tModel that
publisher MAY publish new entities
and assign them keys within the key generator tModel’s partition. New keys
can only be generated from keyGenerator tModels that are not hidden.
Publishers are responsible for managing the uniqueness of the keys in the
partition they own. If a publisher fails to do so, and generates an already
used key, a publish operation could inadvertently replace an entity
previously published by that publisher.
If a publisher owns key generator tModels with the
same key in multiple registries – for example one in the publisher’s private
test registry and one in the UDDI Business Registry – that publisher MAY
publish the entities with identical keys in those registries. This enables
many interesting capabilities. For example, publishers may choose to develop
their UDDI entities by publishing them into test registries and then, at
appropriate times, "promote" them to the UDDI Business Registry.
To ensure that publisher-assigned keys work correctly
all UDDI implementations behave as follows.
5.2.2.3.1 "New" and "existing"
entities defined
During a publish operation, the entity or entities
being published are either "new" or "existing". An existing entity is one
that has a key that matches the key of an entity already in the registry. A
new entity is one that does not. If a new entity has a key, this key is the
key proposed for that entity by its publisher.
5.2.2.3.2 Behavior with respect
to entities for which no key is proposed.
A UDDI node MUST generate and assign a key to each
entity for which the publisher proposes no key. It may generate uuidKeys for
use as the keys of new entities for which no key is proposed or it may
generate keys in the partition of a key generator tModel it owns.
A registry whose nodes assign uddiKeys to new entities
is called a root registry. The UDDI Business Registry is a root registry. A
registry whose nodes gain ownership of their key generator tModels by
publishing them in the UDDI Business Registry are affiliates of the UDDI
Business Registry. See Section 1.5.5
Affiliations of Registries.
5.2.2.3.3 Behavior with respect
to uuidKeys
A UDDI node SHOULD accept a uuidKey as the key for a
new entity during a publish operation if the publisher is a trusted publisher
of such keys, according to the policies of the registry. UDDI nodes MUST NOT
allow other publishers to generate uuidKeys.
5.2.2.3.4 Behavior with respect
to key generator keys
A UDDI node MUST NOT publish any non-tModel entity
whose proposed key is a key generator key. A tModel whose proposed key
is a key generator key MUST include a category bag with a keyed reference
with the tModelKey set to "uddi:uddi.org:categorization:types" and the
keyValue set to "keyGenerator".
5.2.2.3.5 Behavior with respect
to root key generator keys
During a publish operation a UDDI node SHOULD accept a
root key generator key as the key for a new tModel if it is proposed by a
publisher authorized to publish the key, according to the policies of the
registry. The policy MUST prevent more than one publisher from publishing
tModels with the same root key generator key.
An appropriate policy for root and for affiliated
registries is given in Chapter 9
Policy.
5.2.2.3.6 Behavior with respect
to other proposed keys
A UDDI node SHOULD accept keys proposed for new
entities during publishing operations if they meet both of the following
criteria.
·
The proposed key lies in
the partition of the key of an existing key generator tModel and the key
generator tModel is not hidden.
·
The same publisher who is proposing the new key owns the key
generator tModel referred to in the previous bullet.[21]
5.2.2.4 Affiliations of
registries
A set of registries may cooperate in managing a single
multi-registry key space by designating one of the registries in the group to
be the "root registry" and assigning it to be the authority for the root
partition. Other registries in the set are said to be affiliate
registries. See Section 1.5.5
Affiliations of Registries for more information
The UDDI Business Registry is a root registry. Its
policies and procedures are designed to make it simple for any UDDI registry
to be affiliated with it.
Designating new authorities is done by publishing key
generator tModels in the root registry, in one or more of the registries
affiliated with the root registry or both. The owner of a key generator
tModel is the naming authority for the partition the tModel represents.
Several of the APIs defined in this section allow
publishers to save category and identifier information in support of searches
that use category and identifier system references. The save_business,
save_service, save_binding and save_tModel APIs allow designation of these
value set references. Categorization is specified using the element
named categoryBag, which contains namespace-qualified references to
categories and descriptions. categoryBags can also contain groups of
these references to categories and descriptions. Identifiers are
specified using the identifierBag element, which contains namespace-qualified
references to identifiers and descriptions.
Similarly, the add_publisherAssertions and
set_publisherAssertions APIs allow publisherAssertion elements to be
saved. These publisherAssertion elements contain a characterization of
the relationship being established using a keyedReference element that refers
to a relationship type system.
Identifier, category and relationship type systems
taken together are referred to as "value sets." UDDI allows value sets
to be checked or unchecked. References to checked value sets that are
registered in UDDI can be checked internally by the UDDI nodes where
publishing takes place, or externally by a provider of a validation Web
service. The UDDI node can also choose to not support some or all
checked value sets.
When a UDDI node encounters a reference to a checked
value set in a keyedReference it will either ensure the reference is
validated or fail the save. Such references to supported checked value
sets are verified for validity according to the validation algorithm defined
for the value set and described by its tModel. When all checks succeed,
the save is permitted. An E_unvalidatable error indicates the checked
value set is supported but its validation algorithm is not available.
An E_unsupported indicates the checked value set is not supported by the
node. E_invalidValue or E_valueNotAllowed indicate one or more
references failed validation. When the checked value set is not
supported, the value set’s validation algorithm is unavailable, or any of the
references fail validation, the save operation MUST fail.
When the UDDI node supports a checked value set it may
check the references itself, or consult a validation Web service. For
cached checked value sets, the UDDI node verifies that referenced keyValues
are in the set of valid values for the value set. The selection of an
algorithm for verifying a checked value set is a matter of registry policy as
detailed in Chapter 9 Policy.
A category group system is portrayed by a
keyedRefererenceGroup element. Each keyedReferenceGroup has a tModelKey
that references the category group system, and a set of contained
keyedReference elements that make up the actual group of categories.
Similar to references to checked value sets, validation is carried out for a
keyedReferenceGroup if the referenced category group system is checked.
Such validation entails verification that the keyedReferenceGroup is valid
according to the validation algorithm described by the tModel for the
category group system. Validation for a keyedReferenceGroup that
references a cached checked category group system involves verification that
the tModels referenced by the contained keyedReference elements are valid for
the category group system. The set of valid values for such a cacheable
checked category group system is defined by the tModelKeys for the set of
tModels that can participate in the group.
No validation is performed on references to unchecked
value sets
5.2.4 Special considerations for the xml:lang
attribute
During save_xx API calls, the name, description,
address, and personName UDDI elements MAY be adorned with the xml:lang
attribute to indicate the language in which their content is expressed. (See
Chapter 3 UDDI Registry Data
Structures.) When an optional xml:lang attribute is omitted from an
element, no xml:lang attribute will be saved for that element.
Name elements in UDDI core data structures are
frequently the main targets for sorts during UDDI inquiries. When a
UDDI data structure has multiple names, sorting occurs on the first
name. Care should be taken to list the primary name first when the
entity is saved to ensure the proper placement of the entity in a sorted
result set.
Values which can be passed in the language supplied in
a save_xx API call MUST obey the recommended rules and syntax governing the
xml:lang data type as defined in Section 3.3.2.3
name.
The publishing API calls are:
·
add_publisherAssertions: Used to add
relationship assertions to the existing set of assertions. See Appendix
A Relationships and Publisher Assertions.
·
delete_binding: Used to remove an
existing bindingTemplate from the registry.
·
delete_business: Used to delete existing
businessEntity information from the registry.
·
delete_publisherAssertions:
Used to delete specific publisher assertions from the assertion collection
controlled by a particular publisher. Deleting assertions from the
assertion collection affects the visibility of business relationships.
Deleting an assertion causes any relationships based on that assertion to
become incomplete.
·
delete_service: Used to delete an
existing businessService from the registry.
·
delete_tModel: Used to hide existing
information about a tModel. Any tModel hidden in this way is still
usable for reference purposes and accessible via the get_tModelDetail API,
but is hidden from find_tModel result sets. There is no specified way
to delete a tModel.
·
get_assertionStatusReport: Used to get a
status report containing publisher assertions and status information.
This report is useful to help an administrator manage publisher assertions.
Returns an assertionStatusReport that includes the status of all assertions
made involving any businessEntity controlled by the requesting publisher.
·
get_publisherAssertions: Used to get a
list of publisher assertions that are controlled by an individual
publisher. Returns a publisherAssertions structure containing all
publisher assertions associated with a specific publisher.
·
get_registeredInfo: Used to request an
abbreviated list of businesses and tModels currently managed by a given
publisher.
·
save_binding: Used to register new
bindingTemplate information or to update existing bindingTemplate
information. Use this to control information about technical
capabilities exposed by a registered business.
·
save_business: Used to register new
businessEntity information or update existing businessEntity
information. Use this to control the full set of information about the
entire business, including its businessService and bindingTemplate
structures. This API has the broadest effect of all of the save_xx
APIs.
·
save_service: Used to register or
update complete information about a businessService.
·
save_tModel: Used to register or
update information about a tModel.
·
set_publisherAssertions: Used to save
the complete set of publisher assertions for an individual publisher.
Replaces any existing assertions, and causes any old assertions that are not
reasserted to be removed from the registry.
addPublisherAssertions
void addPublisherAssertions(AddPublisherAssertions body)
throws DispositionReportFaultMessage,
RemoteException
- The add_publisherAssertions API call causes one or more
publisherAssertions to be added to an individual publisher’s assertion
collection. See Appendix A Relationships and Publisher Assertions
describing relationships and the API get_publisherAssertions for more
information on this collection.
The publisher must
own the businessEntity referenced in the fromKey, the toKey, or
both. If both of the businessKey values passed within an assertion
are owned by the publisher, then the assertion is automatically complete
and the relationship described in the assertion is visible via the
find_relatedBusinesses API. To form a relationship when the
publisher only owns one of the two keys passed, the assertion MUST be
matched exactly by an assertion made by the publisher who owns the other
business referenced. Assertions exactly match if and only if they:
1.
refer to the same businessEntity in their fromKeys;
2.
refer to the same businessEntity in their toKeys;
3.
refer to the same tModel in their tModelKeys;
4.
have identical keyNames; and
5.
have identical keyValues.
When a publisherAssertion being added references a
checked relationship system using the tModelKey in the contained
keyedReference, the reference MUST be checked for validity prior to
completion of the add, or the node must return E_unsupported, indicating
it does not support the referenced checked relationship system.
Validation of a relationship system reference entails verification that
the reference is valid according to the validation algorithm defined for
the relationship system and described by its tModel. For cached
checked relationship systems, the validation algorithm verifies that
referenced keyValues are in the set of valid values for the relationship
system.
For registries supporting the subscription APIs at
any node, it is necessary to track a modified date for publisherAssertion
elements so that nodes have the necessary information for responding to
subscription requests involving find_relatedBusinesses and
get_assertionStatusReport filters.
- Parameters:
body - ·
authInfo: This optional argument is an
element that contains an authentication token. Authentication
tokens are obtained using the get_authToken API call or through some
other method external to this specification. Registries that serve
multiple publishers and registries that restrict who can publish in them
typically require authInfo for this call.
·
publisherAssertion: This required repeating
element holds the relationship assertions that are being added.
Relationship assertions consist of a reference to two businessEntity key
values as designated by the fromKey and toKey elements, as well as a
REQUIRED expression of directional relationship within the contained
keyedReference element. See Appendix A Relationships and
PublisherAssertions on managing relationships. The fromKey, the
toKey, and all three parts of the keyedReference – the tModelKey, the
keyName, and the keyValue MUST be specified or the call will fail with
the error E_fatalError. Empty (zero length) keyNames and keyValues are
permitted.
Upon successful completion, an empty message is returned.
See section 4.8 Success and Error Reporting.
- Throws:
DispositionReportFaultMessage, - RemoteException
If an error occurs in processing this API call, a
dispositionReport structure MUST be returned to the caller in a SOAP
Fault. See Section 4.8 Success and Error
Reporting. In addition to the errors common to all APIs, the
following error information is relevant here:
·
E_invalidKeyPassed: signifies that one of the
uddiKey values passed did not match with any known businessKey or
tModelKey values. The key and element or attribute that caused the
problem SHOULD be clearly indicated in the error text.
·
E_userMismatch: signifies that neither of the
businessKey values passed in the embedded fromKey and toKey elements is
owned by the publisher associated with the authentication token.
The error text SHOULD clearly indicate which assertion caused the
error.
DispositionReportFaultMessage
RemoteException
deleteBinding
void deleteBinding(DeleteBinding body)
throws DispositionReportFaultMessage,
RemoteException
- The delete_binding API call causes one or more instances of
bindingTemplate data to be deleted from the UDDI registry.
- Parameters:
body - ·
authInfo: This optional argument is an
element that contains an authentication token. Authentication
tokens are obtained using the get_authToken API call or through some
other method external to this specification. Registries that serve
multiple publishers and registries that restrict who can publish in them
typically require authInfo for this call.
·
bindingKey: One or more required
uddiKey values that represent specific instances of known
bindingTemplate data.
Upon successful completion, an empty message is returned. See section 4.8
Success and Error Reporting.
- Throws:
DispositionReportFaultMessage, - RemoteException If an error occurs in processing this API call, a
dispositionReport structure MUST be returned to the caller in a SOAP
Fault. See Section 4.8 Success and
Error Reporting. In addition to the errors common to all APIs,
the following error information is relevant here:
·
E_invalidKeyPassed: Signifies that one of the
uddiKey values passed did not match with any known bindingKey
values or multiple instances of the same bindingKey values were
passed. No partial results are returned – if any bindingKey values
passed are not valid, this error is returned. The key that caused
the problem SHOULD clearly be indicated in the error text.
·
E_userMismatch: Signifies that one or more of the
bindingKey values passed refers to a bindingTemplate that is not owned by
the individual publisher associated with the authentication token.
DispositionReportFaultMessage
RemoteException
deleteBusiness
void deleteBusiness(DeleteBusiness body)
throws DispositionReportFaultMessage,
RemoteException
- The delete_business API call is used to remove one or more business
registrations and all elements that correspond to the natural content of
the corresponding businessEntity elements from a UDDI registry.
- Parameters:
body - · authInfo: This optional argument is an element that
contains an authentication token. Authentication tokens are obtained
using the get_authToken API call or through some other means external to
this specification. Registries that serve multiple publishers and
registries that restrict who can publish in them typically require
authInfo for this call.
· businessKey: One or more required uddiKey values that represent
specific instances of known businessEntity data. The UDDI registry MUST permanently remove all of the
natural contents
of the passed businessEntity elements, including any currently nested
businessService and bindingTemplate data, from the UDDI registry.
If there are service projections
that reference businessService elements deleted in this way, they are
left untouched. Such "broken" service projections appear in their
businessEntity as businessService elements containing the businessKey and
serviceKey attributes as their only content. For this reason, it is a
best practice to coordinate references to businessService data published
under another businessEntity with the party who manages that data.
All publisher assertions that reference the
businessKey of the businessEntity being deleted in either the fromKey or
toKey of the publisherAssertion MUST be automatically deleted. A
deleted business MUST not be returned in the find_relatedBusinesses
API.
Any transferToken referring to the business entity
being deleted becomes invalid and can no longer be used to transfer any
entities.
Upon successful completion, an empty message is returned.
See section 4.8 Success and Error Reporting.
- Throws:
DispositionReportFaultMessage, - RemoteException If an error occurs in processing this API call, a
dispositionReport element MUST be returned to the caller within a SOAP
Fault. See Section 4.8 Success and
Error Reporting. In addition to the errors common to all APIs,
the following error information is relevant here:
·
E_invalidKeyPassed: Signifies that one of the
uddiKey values passed did not match with any known businessKey
values or multiple instances of the same businessKey values were passed.
The key that caused the error SHOULD be clearly indicated in the error
text.
·
E_userMismatch: Signifies that one or more of the
businessKey values passed refers to data that is not owned by the
individual publisher who is represented by the authentication token.
DispositionReportFaultMessage
RemoteException
deletePublisherAssertions
void deletePublisherAssertions(DeletePublisherAssertions body)
throws DispositionReportFaultMessage,
RemoteException
- The delete_publisherAssertions API call causes one or more
publisherAssertion elements to be removed from a publisher’s assertion
collection. See Appendix A Relationships and Publisher Assertions and the
API get_publisherAssertions for more information on this collection.
- Parameters:
body - ·
authInfo: This optional argument is an
element that contains an authentication token. Authentication
tokens are obtained using the get_authToken API call or through some
other means external to this specification. Registries that serve
multiple publishers and registries that restrict who can publish in them
typically require authInfo for this call.
·
publisherAssertion: One or more required
publisher assertion structures exactly matching an existing assertion in
the publisher’s assertion collection.
The UDDI
registry scans the assertion collection associated with the publisher,
and removes any assertions that exactly match all parts of each
publisherAssertion passed. Any assertions described that cannot be
located result in an error. The removal of assertions in this API
causes the corresponding relationships to no longer be visible via the
find_relatedBusinesses API.
For registries supporting the subscription APIs at
any node, it is necessary to track a modified date for publisherAssertion
elements so that nodes have the necessary information for responding to
subscription requests involving find_relatedBusinesses and
get_assertionStatusReport filters.
Upon successful completion, an
empty message is returned. See section 4.8 Success and Error Reporting.
- Throws:
DispositionReportFaultMessage, - RemoteException If an error occurs in processing this API call, a
dispositionReport structure MUST be returned to the caller in a SOAP
Fault. See Section 4.8 Success and
Error Reporting. In addition to the errors common to all APIs,
the following error information is relevant here:
·
E_assertionNotFound: Signifies that one of the
assertion structures passed does not have any corresponding match in the
publisher’s assertion collection or multiple instances of the same
publisherAssertions elements were passed. The assertion that caused
the problem SHOULD be clearly indicated in the error text.
DispositionReportFaultMessage
RemoteException
deleteService
void deleteService(DeleteService body)
throws DispositionReportFaultMessage,
RemoteException
- The delete_service API call is used to remove one or more businessService
elements from the UDDI registry and from its containing businessEntity
parent.
- Parameters:
body - ·
authInfo: This optional argument is an
element that contains an authentication token. Authentication
tokens are obtained using the get_authToken API call or through some
other means external to this specification. Registries that serve
multiple publishers and registries that restrict who can publish in them
typically require authInfo for this call.
·
serviceKey: One or more required
uddiKey values that represent specific instances of known
businessService data.
All contained
bindingTemplate data MUST also be removed from the registry as a result
of this call.
If a business service being deleted is the target
of a business service projection associated with another businessEntity,
the referencing businessService elements are left untouched. Such
"broken" service projections appear in their businessEntity and
businessService elements containing the businessKey and serviceKey
attributes as their only content. For this reason, it is
recommended that references to businessService data published under
another businessEntity be coordinated with the party that manages that
data.
- Throws:
DispositionReportFaultMessage, - RemoteException If an error occurs
in processing this API call, a dispositionReport structure MUST be
returned to the caller in a SOAP Fault. See Section 4.8 Success and Error
Reporting. In addition to the errors common to all APIs, the following
error information is relevant here:
· E_invalidKeyPassed: Signifies that one of the uddiKey values passed did
not match with any known serviceKey values or multiple instances of the
same serviceKey values were passed. The key causing the error SHOULD be
clearly indicated in the error text.
· E_userMismatch: Signifies that one or more of the serviceKey values
passed refers to data that is not owned by the individual publisher who
is represented by the authentication token.
DispositionReportFaultMessage
RemoteException
deleteTModel
void deleteTModel(DeleteTModel body)
throws DispositionReportFaultMessage,
RemoteException
- The delete_tModel API call is used to logically delete one or more tModel
structures. Logical deletion hides the deleted tModels from find_tModel
result sets but does not physically delete them. New references to
deleted (hidden) tModels can be established by publishers that know their
keys. Deleting an already deleted tModel has no effect.
- Parameters:
body - ·
authInfo: This optional argument is an
element that contains an authentication token. Authentication
tokens are obtained using the get_authToken API call or through some
other means external to this specification. Registries that serve
multiple publishers and registries that restrict who can publish in them
typically require authInfo for this call.
·
tModelKey: One or more required
uddiKey values that represent specific instances of known tModel
data.
If a tModel is hidden in this way it
MUST not be physically deleted as a result of this call. Any tModels
hidden in this way are still accessible, via the get_registeredInfo and
get_tModelDetail APIs, but are omitted from any results returned by calls
to find_tModel. All other inquiry APIs may include references to
tModelKeys of deleted tModelKeys, and UDDI data structures that reference
these tModels are found and retrieved.
The purpose of the delete_tModel behavior is to
ensure that the details associated with a hidden tModel are still
available to anyone currently using the tModel. A hidden tModel can
be restored and made visible to search results by invoking the
save_tModel API at a later time, passing the original data and the
tModelKey value of the hidden tModel.
It is not an error to transfer a hidden tModel
(i.e. deleted attribute set to TRUE).
Upon successful completion, an
empty message is returned. See section 4.8 Success and Error Reporting.
- Throws:
DispositionReportFaultMessage, - RemoteException If an error occurs
in processing this API call, a dispositionReport element MUST be returned
to the caller within a SOAP Fault. See Section 4.8 Success and Error
Reporting. In addition to the errors common to all APIs, the following
error information is relevant here:
· E_invalidKeyPassed: Signifies that one of the uddiKey values passed did
not match with any known tModelKey values or multiple instances of the
same tModelKey values were passed. The invalid key references SHOULD be
clearly indicated in the error text.
· E_userMismatch: Signifies that one or more of the tModelKey values
passed refers to data that is not owned by the individual publisher who
is represented by the authentication token.
DispositionReportFaultMessage
RemoteException
getAssertionStatusReport
@RequestWrapper(localName="get_assertionStatusReport",
targetNamespace="urn:uddi-org:api_v3",
className="org.uddi.api_v3.GetAssertionStatusReport")
@ResponseWrapper(localName="assertionStatusReport",
targetNamespace="urn:uddi-org:api_v3",
className="org.uddi.api_v3.AssertionStatusReport")
List<AssertionStatusItem> getAssertionStatusReport(String authInfo,
CompletionStatus completionStatus)
throws DispositionReportFaultMessage,
RemoteException
- The get_assertionStatusReport API call provides administrative support
for determining the status of current and outstanding publisher
assertions that involve any of the business registrations managed by the
individual publisher. Using this API, a publisher can see the status of
assertions that they have made, as well as see assertions that others
have made that involve businessEntity structures controlled by the
requesting publisher. See Appendix A Relationships and Publisher
Assertions for more information.
- Parameters:
completionStatus - authInfo - ·
authInfo: This optional argument is an
element that contains an authentication token. Authentication
tokens are obtained using the get_authToken API call or through some
other means external to this specification. Registries that serve
multiple publishers and registries that restrict who can publish in them
typically require authInfo for this call.
·
completionStatus: This optional argument lets
the publisher restrict the result set to only those relationships that
have the specified status value. Assertion status is a calculated
result based on the sum total of assertions made by the individuals that
control specific business registrations. When no completionStatus
element is provided, all assertions involving the businesses that the
publisher owns are retrieved, without regard to the completeness of the
relationship. completionStatus MUST contain one of the following
values
o
status:complete: Passing this value causes only the
publisher assertions that are complete to be returned. Each
businessEntity listed in assertions that are complete has a visible
relationship that directly reflects the data in a complete assertion (as
described in the find_relatedBusinesses API).
o
status:toKey_incomplete: Passing this value causes
only those publisher assertions where the party who controls the
businessEntity referenced by the toKey value in an assertion, has not
made a matching assertion, to be listed.
o
status:fromKey_incomplete: Passing this value causes
only those publisher assertions where the party who controls the
businessEntity referenced by the fromKey value in an assertion, has not
made a matching assertion, to be listed.
o
status:both_incomplete. This status value, however,
is only applicable to the context of UDDI subscription and SHOULD not be
present as part of a response to a get_assertionStatusReport request.
- Returns:
- returns java.util.List Upon
successful completion, an assertionStatusReport structure is returned
containing zero or more assertionStatusItem structures. Elements will be
sorted by last date change in ascending order.
The assertionStatusReport has the form:
The assertionStatusReport reports all complete and
incomplete assertions and serves an administrative use for determining if
there are any outstanding, incomplete assertions pertaining to
relationships involving businesses with which the publisher is
associated.
Since the publisher who was authenticated by the
get_assertionStatusReport API may own several businesses, the
assertionStatusReport structure shows the assertions made for all
businesses owned by the publisher.
The assertion status report is composed of a set
of assertionStatusItem elements that describe the assertions in which the
publisher’s businesses participate. The assertionStatusItem element
has the form:
The assertionStatusItem structure has the
following attribute:
| Name |
Use |
| completionStatus
| required |
While the elements fromKey, toKey and
keyedReference together identify the assertion on whose status a report
is being provided, the keysOwned element designates those businessKeys
the publisher manages. The keysOwned element has the form:
An assertion is part of a reciprocal relationship
only if the completionStatus attribute has a value "status:complete". If
completionStatus has a value "status:toKey_incomplete" or
"status:fromKey_incomplete", the party who controls the businessEntity
referenced by the toKey or the fromKey has not yet made a matching
assertion.
- Throws:
DispositionReportFaultMessage, - RemoteException If an error occurs
in processing this API call, a dispositionReport element MUST be returned
to the caller within a SOAP Fault. See Section 4.8 Success and Error
Reporting. In addition to the errors common to all APIs, the following
error information is relevant here:
· E_invalidCompletionStatus: Signifies that the completionStatus value
passed is unrecognized. The completion status that caused the problem
SHOULD be clearly indicated in the error text.
DispositionReportFaultMessage
RemoteException
getPublisherAssertions
@RequestWrapper(localName="get_publisherAssertions",
targetNamespace="urn:uddi-org:api_v3",
className="org.uddi.api_v3.GetPublisherAssertions")
@ResponseWrapper(localName="publisherAssertionsResponse",
targetNamespace="urn:uddi-org:api_v3",
className="org.uddi.api_v3.PublisherAssertionsResponse")
List<PublisherAssertion> getPublisherAssertions(String authInfo)
throws DispositionReportFaultMessage,
RemoteException
- The get_publisherAssertions API call is used to obtain the full set of
publisher assertions that is associated with an individual publisher. It
complements the get_registeredInfo API which returns information about
businesses, services, bindings, and tModels managed by a publisher.
- Parameters:
authInfo - · authInfo: This optional argument is an element that
contains an authentication token. Authentication tokens are obtained
using the get_authToken API call or through some other means external to
this specification. Registries that serve multiple publishers and
registries that restrict who can publish in them typically require
authInfo for this call.
- Returns:
- returns java.util.List This
API call returns a publisherAssertions structure that contains a
publisherAssertion element for each publisher assertion registered by the
publisher. When the registry distinguishes between publishers, this
information is associated with the authentication information. Only
assertions made by the publisher are returned. Elements will be sorted by
last date change in ascending order. See get_assertionStatusReport and
Appendix A Relationships and Publisher Assertions for more details.
The publisherAssertions structure has the form:
- Throws:
DispositionReportFaultMessage, - RemoteException None, other than
those common to all UDDI APIs. See Section 12.1 Common Error Codes.
DispositionReportFaultMessage
RemoteException
getRegisteredInfo
RegisteredInfo getRegisteredInfo(GetRegisteredInfo body)
throws DispositionReportFaultMessage,
RemoteException
- The get_registeredInfo API call is used to get an abbreviated list of all
businessEntity and tModel data that are controlled by a publisher. When
the registry distinguishes between publishers, this is the individual
associated with the credentials passed in the authInfo element. This
returned information is intended, for example, for driving tools that
display lists of registered information and then provide drill-down
features. This is the recommended API to use after a network problem
results in an unknown status of saved information.
- Parameters:
body - authInfo: This optional argument is an element that contains
an authentication token. Authentication tokens are obtained using the
get_authToken API call or through some other means external to this
specification. Registries that serve multiple publishers and registries
that restrict who can publish in them typically require authInfo for this
call.
· infoSelection: This required argument represents an enumerated choice
that determines which tModels are returned. "all" indicates all visible
and hidden tModels owned by the publisher are to be returned (this is the
default). "visible" indicates only visible tModels owned by the publisher
are to be returned. "hidden" indicates only hidden (logically deleted)
tModels owned by the publisher are to be returned.
- Returns:
- returns org.uddi.api_v3.RegisteredInfo Upon successful
completion, a registeredInfo structure MUST be returned, listing
abbreviated business information in one or more businessInfo elements,
and tModel information in one or more tModelInfo elements. This API is
useful for determining the full extent of registered business and tModel
information owned by a single publisher in a single call. This structure
complements the get_publisherAssertions API call, which returns
information about assertions owned by an individual publisher.
businessInfos and/or tModelInfos will be sorted case-sensitively on the
primary name in ascending order, using the collation sequence determined
by node policy.
- Throws:
DispositionReportFaultMessage, - RemoteException
DispositionReportFaultMessage
RemoteException
saveBinding
BindingDetail saveBinding(SaveBinding body)
throws DispositionReportFaultMessage,
RemoteException
- The save_binding API call is used to save or update a complete
bindingTemplate element. It can be used to add or update one or more
bindingTemplate elements as well as the container/contained relationship
that each bindingTemplate has with one or more existing businessService
elements. Each bindingTemplate MAY be signed and MAY have
publisher-assigned keys.
- Parameters:
body - ·
authInfo: This optional argument is an
element that contains an authentication token. Authentication
tokens are obtained using the get_authToken API call or through some
other means external to this specification. Registries that serve
multiple publishers and registries that restrict who can publish in them
typically require authInfo for this call.
·
bindingTemplate: Required repeating element
containing one or more complete bindingTemplate structures. To save a new
bindingTemplate, a bindingTemplate element is passed with either an empty
bindingKey attribute value, or with a publisher-assigned bindingKey. See
Section 5.2.2.2 Behavior of
Publishers.
Each new
bindingTemplate passed MUST contain a serviceKey value that corresponds
to a registered businessService controlled by the same publisher. An
existing binding template MAY contain a serviceKey value that corresponds
to a registered businessService controlled by the same
publisher. The net effect of this call is to determine the
containing parent businessService for each bindingTemplate affected by
this call. If the same bindingTemplate (determined by matching bindingKey
value) is listed more than once, any relationship to the containing
businessService is determined by processing order, which is determined by
the position of the bindingTemplate data in first to last order.
If the bindingKey within a bindingTemplate element
is missing or is passed with an empty value, this is a signal that the
bindingTemplate is being inserted for the first time. When this
occurs, the node MUST automatically generate a new key for the
bindingTemplate that is without an associated key. New bindingTemplate
structures can also be added with publisher-assigned keys. See Section 5.2.2.2 Behavior of Publishers.
Using this API call it is possible to move an
existing bindingTemplate from one businessService to another by simply
specifying a different parent businessService relationship along with the
complete bindingTemplate. Changing a parent relationship in this
way causes two businessService structures to be affected. The net
result of such a move is that the bindingTemplate still resides within
one, and only one businessService based on the value of the serviceKey
passed. An attempt to move a bindingTemplate in this manner by a party
who is not the publisher of the businessService that is specified by the
serviceKey MUST be rejected with an error E_userMismatch.
When a bindingTemplate is saved with a categoryBag
content that is associated with a checked value set or category group
system tModel, the references MUST be checked for validity prior to
completion of the save, or the node must return E_unsupported, indicating
it does not support the referenced checked value set or category group
system. See Section 5.2.3 Special
considerations for validated value sets and Appendix F Using
Categorization for additional details.
- Returns:
- returns org.uddi.api_v3.BindingDetail This API returns a
bindingDetail structure containing the results of the call that reflects
the newly registered information for the effected bindingTemplate
elements. If more than one bindingTemplate is saved in a single
save_binding call, the resulting bindingDetail MUST return results in the
same order that they appeared in the save_binding call. If the same
bindingTemplate (determined by matching bindingKey) is listed more than
once in the save_binding call, it MAY be listed once in the result for
each appearance in the save_binding call. If the same bindingTemplate
appears more than once in the response, the last occurrence of the
bindingTemplate in the results represents the state stored in the
registry. Any bindingKeys that were assigned as a result of processing
the save_binding call are included in the bindingTemplate data.
The bindingDetail structure has the form:
- Throws:
DispositionReportFaultMessage, - RemoteException If an error occurs in processing this API call, a
dispositionReport element MUST be returned to the caller in a SOAP
Fault. See Section 4.8 Success and
Error Reporting. In addition to the errors common to all APIs,
the following error information is relevant here:
·
E_accountLimitExceeded: Signifies that user account
limits have been exceeded.
·
E_invalidKeyPassed: Signifies that the request
cannot be satisfied because one or more uddiKey values specified
are not valid key values for the entities being published. tModelKey,
serviceKey, or bindingKey values that either do not exist, or exist with
a different entity type, or are not authorized to be proposed by the
publisher are considered to be invalid values. The key causing the error
SHOULD be clearly indicated in the error text. This error code will also
be returned in the event that the serviceKey is not provided and the
bindingKey is either absent or has a value not registered in the
registry. In this case, the error text SHOULD clearly indicate the use of
an incomplete bindingTemplate.
·
E_invalidValue: A value that was passed in a
keyValue attribute did not pass validation. This applies to checked
value sets that are referenced using keyedReferences. The error text
SHOULD clearly indicate the key and value combination that failed
validation.
·
E_keyUnavailable: Indicates that the proposed key has
already been assigned to some other publisher or is not within the
partition defined by a key generator tModel that the publisher
owns.
·
E_requestTimeout: Signifies that the request could
not be carried out because a needed validate_values service did not
respond in a reasonable amount of time. Details identifying the failing
Web service SHOULD be included in the dispositionReport element.
·
E_userMismatch: Signifies that one or more of the
uddiKey values passed refers to data that is not owned by the
individual publisher who is represented by the authentication token.
·
E_valueNotAllowed: Restrictions have been placed by
the value set provider on the types of information that should be
included at that location within a specific value set. A validate_values
Web service chosen by the UDDI node has rejected this businessEntity for
at least one specified keyedReference. The error text SHOULD
clearly indicate the keyedReference that was not successfully
validated.
DispositionReportFaultMessage
RemoteException
saveBusiness
BusinessDetail saveBusiness(SaveBusiness body)
throws DispositionReportFaultMessage,
RemoteException
The save_business API call is used to save or
update information about a complete businessEntity structure. This
API has the broadest scope of all of the save_xx API calls, and can be
used to make sweeping changes to the published information for one or
more businessEntity elements controlled by an individual.
This API call can be used to establish a reference
relationship to businessService structures that are managed as the
contents of another businessEntity. In this way, a businessService
that is a natural part of one businessEntity can appear as a projected
service of another businessEntity. The content of a
businessService projected in this way (by way of a reference established
by this API) are not managed as a part of the referencing entity.
businessEntity structures MAY be signed and MAY
have publisher-assigned keys.
- Parameters:
body - ·
authInfo: This optional argument is an
element that contains an authentication token. Authentication
tokens are obtained using the get_authToken API call or through some
other means external to this specification. Registries that serve
multiple publishers and registries that restrict who can publish in them
typically require authInfo for this call.
·
businessEntity: Required repeating
element containing one or more businessEntity structures. These can
be obtained in advance by using the get_businessDetail API call or by any
other means.
If any of the uddiKey
values within a businessEntity element (e.g. any data with a key value
regulated by a businessKey, serviceKey or bindingKey) is missing or is
passed with an empty value, this is a signal that the data that is so
keyed is being inserted for the first time.
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.
For this reason, it is good practice to coordinate references to
businessService data published under another businessEntity with the
party who manages that data
When saving a businessEntity containing a service
projection, all of the content of the businessService provided in the
save_business, with the exception of the serviceKey and businessKey, is
ignored. The businessKey and serviceKey of the businessService
being referenced are used to determine if the businessService is for a
service projection or not. If the businessService identified by the
serviceKey is not part of the businessEntity identified by the
businessKey, the error E_invalidProjection will be returned.
When a businessEntity is saved with identifierBag
or categoryBag contents that is associated with a checked value set or
category group system tModel, the references MUST be checked for validity
prior to completion of the save or the node must return E_unsupported,
indicating it does not support the referenced checked value set or
category group system. See Section 5.2.3 Special considerations for validated value sets,
Appendix E Using Identifiers and Appendix F Using
Categorization for additional details.
- Returns:
- returns org.uddi.api_v3.BusinessDetail
This API returns a businessDetail structure
containing the final results of the call that reflects the new registered
information for the businessEntity information provided. Any businessKey,
serviceKey, or bindingKey attributes that were assigned as a result of
processing the save_business are included in the returned data. For
businessService elements that are service projections, the response
includes either the businessService elements as provided by the publisher
or the full contents of the real businessService elements. These results
include any businessService elements that are contained by reference. If
the same entity (businessEntity, businessService, or bindingTemplate),
determined by matching key, is listed more than once in the save_business
call, it MAY be listed once in the result for each appearance in the
call. If the same entity appears more than once in the response, the last
appearance occurrence of the entity in the results represents either the
final saved state stored in the registry or the last occurrence of the
entity provided by the publisher within the request.
The businessDetail has the form:
- Throws:
DispositionReportFaultMessage, - RemoteException If an error occurs in processing this API call, a
dispositionReport element MUST be returned to the caller in a SOAP
Fault. See Section 4.8 Success and
Error Reporting. In addition to the errors common to all APIs,
the following error information is relevant here:
·
E_accountLimitExceeded: Signifies that user account
limits have been exceeded.
·
E_invalidKeyPassed: Signifies that the request
cannot be satisfied because one or more uddiKey values specified
are not valid key values for the entities being published. tModelKey,
businessKey, serviceKey, or bindingKey values that either do not exist,
or exist with a different entity type, or are not authorized to be
proposed by the publisher are considered to be invalid values. The key
causing the error SHOULD be clearly indicated in the error text.
·
E_invalidProjection: Signifies that an attempt was
made to save a businessEntity containing a service projection where the
businessService being projected is not a part of the businessEntity that
is identified by the businessKey in the businessService. The serviceKey
of at least one such businessService SHOULD be included in the
dispositionReport.
·
E_userMismatch: Signifies that one or more of the
uddiKey values passed refers to data that is not owned by the
individual publisher who is represented by the authentication
token. The key causing the error SHOULD be clearly indicated in the
error text.
·
E_invalidValue: A value that was passed in a
keyValue attribute did not pass validation. This applies to checked
value sets that are referenced using keyedReferences. The error text
SHOULD clearly indicate the key and value combination that failed
validation.
·
E_keyUnavailable: Indicates that the proposed key has
already been assigned to some other publisher or is not within the
partition defined by a key generator tModel that the publisher
owns.
·
E_requestTimeout: Signifies that the request could
not be carried out because a needed validate_values service did not
respond in a reasonable amount of time. Details identifying the failing
Web service SHOULD be included in the dispositionReport element.
·
E_unsupported: A keyedReference in a categoryBag or an
identifierBag that references a checked value set cannot be validated by
the UDDI node because the node does not support the referenced checked
value set. The error text should clearly indicate the
keyedReference that cannot be validated.
·
E_unvalidatable: A keyedReference in a categoryBag or an
identifierBag that references a checked value set cannot be validated by
the UDDI node because the referenced tModel has been marked
unvalidatable. The error text should clearly indicate the
keyedReference that cannot be validated.
·
E_valueNotAllowed: Restrictions have been placed by
the value set provider on the types of information that should be
included at that location within a specific value set. A validate_values
Web service chosen by the UDDI node has rejected this businessEntity for
at least one specified keyedReference. The error text SHOULD
clearly indicate the keyedReference that was not successfully
validated.
DispositionReportFaultMessage
RemoteException
saveService
ServiceDetail saveService(SaveService body)
throws DispositionReportFaultMessage,
RemoteException
- The save_service API call adds or updates one or more businessService
elements. Each businessService MAY be signed and MAY have
publisher-assigned keys.
- Parameters:
body - ·
authInfo: This optional argument is an
element that contains an authentication token. Authentication
tokens are obtained using the get_authToken API call or through some
other means external to this specification. Registries that serve
multiple publishers and registries that restrict who can publish in them
typically require authInfo for this call.
·
businessService: Required repeating
element containing one or more complete businessService elements.
For the purpose of performing round trip updates, this data can be
obtained in advance by using the get_serviceDetail API call or by any
other means.
Each new businessService passed
MUST contain a businessKey value that corresponds to a registered
businessEntity controlled by the same publisher. An existing business
service MAY contain a businessKey value that corresponds to a registered
businessEntity controlled by the same publisher.
If any of the uddiKey values within a
businessService element (i.e., any data with a key value regulated by a
serviceKey or bindingKey) is passed with an empty value, this is a signal
that the data that is so keyed is being inserted for the first time.
In this case, a new key value MUST be automatically generated for the
data which was passed without an associated key value. New entities can
also be added with publisher-assigned keys. See Section 5.2.2.2 Behavior of Publishers.
If the same businessService is contained in more
than one businessService argument, the final relationship to the
containing businessEntity is determined by processing order – which is
determined by first to last order of the information passed in the
request. Analogously, if the same bindingTemplate is specified in the
call as being in more than one businessService, the businessService that
is its container at the conclusion of the call is last one listed.
Using this API call it is possible to move an
existing bindingTemplate element from one businessService element to
another, or move an existing businessService element from one
businessEntity to another by simply specifying a different parent
businessEntity relationship. Changing a parent relationship in this
way causes two businessEntity or two businessService structures to be
changed. An attempt to move a bindingTemplate or a businessService in
this manner by a party who is not the publisher of the businessService
that is specified by the serviceKey or the businessEntity that is
specified by the businessKey MUST be rejected with an error
E_userMismatch.
When a businessService is saved with categoryBag
contents that is associated with a checked value set or category group
system tModel, the references MUST be checked for validity prior to
completion of the save or the node MUST return E_unsupported, indicating
it does not support the referenced checked value set or category group
system. See Section 5.2.3 Special
considerations for validated value sets and Appendix F Using
Categorization for additional details.
- Returns:
- returns org.uddi.api_v3.ServiceDetail
This
API call returns a serviceDetail containing the final results of the call
that reflects the newly registered information for the affected
businessService elements. In cases where multiple businessService
elements are passed in the request, the result contains the final results
for each businessService passed and these appear in the same order as
found in the request. Any serviceKey and bindingKey values that were
assigned as a result of processing the save_service API are included in
the businessService data.
If the same entity (businessService, or
bindingTemplate), determined by matching key, is listed more than once in
the save_service API, it MAY be listed once in the result for each
appearance in the save_service API. If the same entity appears more than
once in the response, the last occurrence of the entity in the results
represents the state stored in the registry.
The serviceDetail has the form:
- Throws:
DispositionReportFaultMessage, - RemoteException If an error occurs in processing this API call, a
dispositionReport element MUST be returned to the caller within a SOAP
Fault. See Section 4.8 Success and
Error Reporting. In addition to the errors common to all APIs,
the following error information is relevant here:
·
E_accountLimitExceeded: Signifies that user account
limits have been exceeded.
·
E_invalidKeyPassed: Signifies that the request
cannot be satisfied because one or more uddiKey values specified
are not valid key values for the entities being published. tModelKey,
businessKey, serviceKey, or bindingKey values that either do not exist,
or exist with a different entity type, or are not authorized to be
proposed by the publisher are considered to be invalid values. The key
causing the error SHOULD be clearly indicated in the error text. This
error code will also be returned in the event that the businessKey is not
provided and the serviceKey is either absent or has a value not
registered in the registry. In this case, the error text SHOULD
clearly indicate the use of an incomplete businessService.
·
E_invalidValue: A value that was passed in a
keyValue attribute did not pass validation. This applies to checked
value sets referenced using keyedReferences. The error text SHOULD
clearly indicate the key and value combination that failed
validation.
·
E_keyUnavailable: Indicates that the proposed key has
already been assigned to some other publisher or is not within the
partition defined by a key generator tModel that the publisher
owns.
·
E_requestTimeout: Signifies that the request could
not be carried out because a needed validate_values service did not
respond in a reasonable amount of time. Details identifying the failing
Web service SHOULD be included in the dispositionReport element.
·
E_userMismatch: Signifies that one or more of the
uddiKey values passed refers to data that is not owned by the
individual publisher who is represented by the authentication token.
·
E_unsupported: A keyedReference in a categoryBag that
references a checked value set cannot be validated by the UDDI node
because the node does not support the referenced checked value set.
The error text SHOULD clearly indicate the keyedReference that cannot be
validated.
·
E_unvalidatable: A keyedReference in a categoryBag that
references a checked value set cannot be validated by the UDDI node
because the referenced tModel has been marked unvalidatable. The
error text SHOULD clearly indicate the keyedReference that cannot be
validated.
·
E_valueNotAllowed: The value set validation routine
chosen by the UDDI node has rejected the businessService data
provided. The error text SHOULD clearly indicate the keyedReference
that was not successfully validated.
DispositionReportFaultMessage
RemoteException
saveTModel
TModelDetail saveTModel(SaveTModel body)
throws DispositionReportFaultMessage,
RemoteException
- The save_tModel API call adds or updates one or more registered tModel
elements. tModels MAY be signed and tModels MAY be saved with
publisher-assigned keys, including those tModels that establish the
domain partition of publisher-assigned keys, known as domain key
generator tModels.
- Parameters:
body - ·
authInfo: This optional argument is an
element that contains an authentication token. Authentication
tokens are obtained using the get_authToken API call or through some
other means external to this specification. Registries that serve
multiple publishers and registries that restrict who can publish in them
typically require authInfo for this call.
·
tModel: Required repeating element
containing one or more required repeating complete tModel elements.
For the purpose of performing round-trip updates, this data can be
obtained in advance by using the get_tModel API call or by other
means.
If the uddiKey value within a
tModel (i.e., tModelKey) is missing or is passed with an empty value,
this is a signal that a new tModel is being inserted and that the UDDI
registry MUST assign a new tModelKey identifier to this data. If
the new tModel is categorized with the keyGenerator value from the
uddi:uddi.org:categorization:types category system, any publisher
assigned key MUST end with the string ":keygenerator" , making the
tModel a key generator tModel. If the new tModel is categorized
with the keyGenerator value from the
uddi:uddi.org:categorization:types category, an empty uddiKey signifies
that the tModelKey generated by the node will end with the string
":keygenerator", making the tModel a key generator tModel.
New tModels can also be added with publisher-assigned keys. See
Section 5.2.2.2 Behavior of Publishers
and Section 5.2.18.3.1 Domain Key
Generator tModels.
This API call performs an update to existing
registered data when the tModelKey values have uddiKey values that
correspond to already registered data.
If a tModelKey value is passed that corresponds to
a tModel that was previously hidden via the delete_tModel API call, the
save_tModel service restores the tModel to full visibility, making it
available for return in find_tModel results.
The value of the deleted attribute in the tModel
is set to false in all saves.
Multiple representations of the overview document
MAY be registered for a tModel allowing, for example, both technical and
human readable representations of the technical overview to be provided.
When a tModel is saved with keyedReferences, all
tModelKeys used in keyedReferences must refer to tModels that existed
prior to processing the tModel containing the references. A save_tModel
API call may contain a sequence of tModels, in which case a
keyedReference in a tModel may refer to tModelKeys created earlier but
not later in the sequence. A tModel being created must not refer to
itself. Self-referencing tModels can be created by using two subsequent
save_tModel API calls, the first one without the reference, and the
second one with the reference (to the already saved tModel). If these
conditions are not met, the node MUST return E_invalidKeyPassed.
When a tModel is saved with identifierBag or
categoryBag contents that is associated with a checked value set or
category group system tModel, the references MUST be checked for validity
prior to completion of the save, or the node MUST return E_unsupported,
indicating it does not support the referenced checked value set or
category group system. See Section 5.2.3 Special considerations for validated value sets,
Appendix E Using Identifiers and Appendix F Using
Categorization for additional details.
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.
See Section 7.3.9
changeRecordNewDataConditional for more information. If
multiple tModel elements are passed in the save_tModel request, the order
of the response MUST exactly match the order that the elements appeared
in the save. If the same tModel, determined by matching key, is listed
more than once in the save_tModel API, it MAY be listed only once in the
result for each appearance in the save_tModel API. If the same tModel
appears more than once in the response, the last occurrence of the tModel
in the results represents the state stored in the registry.
The tModelDetail has the form:
- Throws:
DispositionReportFaultMessage, - RemoteException If an error occurs in processing this API call, a
dispositionReport element MUST be returned to the caller in a SOAP
Fault. See Section 4.8 Success and
Error Reporting. In addition to the errors common to all APIs,
the following error information is relevant here:
·
E_accountLimitExceeded: Signifies that user account
limits have been exceeded.
·
E_invalidKeyPassed: Signifies that the request
cannot be satisfied because one or more uddiKey values specified
are not valid key values for the entities being published. tModelKey
values that either do not exist, or exist with a different entity type,
or are not authorized to be proposed by the publisher are considered to
be invalid values. The key causing the error SHOULD be clearly indicated
in the error text.
·
E_invalidValue: A value that was passed in a
keyValue attribute did not pass validation. This applies to checked
value sets referenced using keyedReferences. The error text SHOULD
clearly indicate the key and value combination that failed
validation.
·
E_keyUnavailable: Indicates that the proposed key
has already been assigned to some other publisher, is not within the
partition defined by a key generator tModel that the publisher owns, or,
in the case of a domain key generator tModel being saved for the first
time, is assigned to some other publisher or is still pending its first
save.
·
E_requestTimeout: Signifies that the request could
not be carried out because a needed validate_values Web service did not
respond in a reasonable amount of time. Details identifying the failing
Web service SHOULD be included in the dispositionReport element.
·
E_unacceptableSignature: Indicates that the digital
signature in the tModel is missing or does not meet the requirements of
the registry. The errInfo element provides additional details.
·
E_userMismatch: Signifies that one or more of the
uddiKey values passed refers to data that is not owned by the individual
publisher who is represented by the authentication token.
·
E_unsupported: A keyedReference in a categoryBag or
an identifierBag that references a checked value set cannot be validated
by the UDDI node because the node does not support the referenced checked
value set. The error text SHOULD clearly indicate the
keyedReference that cannot be validated.
·
E_unvalidatable: A keyedReference in a categoryBag
or an identifierBag that references a checked value set cannot be
validated by the UDDI node because the referenced tModel has been marked
unvalidatable. The error text SHOULD clearly indicate the
keyedReference that cannot be validated.
·
E_valueNotAllowed: Restrictions have been placed by
the value set provider on the types of information that should be
included at that location within a specific value set. The
validation routine chosen by the UDDI node has rejected this tModel for
at least one specified keyedReference. The error text SHOULD
clearly indicate the keyedReference that was not successfully
validated.
DispositionReportFaultMessage
RemoteException
setPublisherAssertions
@RequestWrapper(localName="set_publisherAssertions",
targetNamespace="urn:uddi-org:api_v3",
className="org.uddi.api_v3.SetPublisherAssertions")
@ResponseWrapper(localName="publisherAssertions",
targetNamespace="urn:uddi-org:api_v3",
className="org.uddi.api_v3.PublisherAssertions")
void setPublisherAssertions(String authInfo,
javax.xml.ws.Holder<List<PublisherAssertion>> publisherAssertion)
throws DispositionReportFaultMessage,
RemoteException
- The set_publisherAssertions API call is used to manage all of the tracked
relationship assertions associated with an individual publisher. See
Appendix A Relationships and Publisher Assertions for more information.
- Parameters:
publisherAssertion - ·
authInfo: This optional argument is an element that
contains an authentication token. Authentication tokens are obtained using the
get_authToken API call or through some other means external to this
specification. Registries that serve multiple publishers and registries that
restrict who can publish in them typically require authInfo for this call.
authInfo - ·
publisherAssertion: Optional repeating element asserting
a relationship. Relationship assertions consist of a reference to two
businessEntity key values as designated by the fromKey and toKey elements, as
well as a REQUIRED expression of the directional relationship within the
contained keyedReference element. See Appendix A Relationships and
Publisher Assertions. The fromKey, the toKey, and all three parts of the
keyedReference – the tModelKey, the keyName, and the keyValue – MUST be
specified. E_fatalError is returned if any of these elements are missing in any
of the publisherAssertion elements. Empty (zero length) keyNames and keyValues
are permitted.
The full set of assertions associated with a publisher is
effectively replaced whenever this API is used. When this API call is processed, the publisher assertions that exist prior to this API call for a given
publisher are examined by the UDDI registry. Any new assertions not present
prior to the call are added to the assertions attributed to the publisher. Any
existing assertions not present in the call are deleted. As a result, new
relationships may be completed (e.g. determined to have a completed status),
and existing relationships may be dissolved. Invoking this API with no publisherAssertion elements deletes all assertions associated with the publisher.
Any relationships attributed to assertions previously
present but not present in the data provided in this call are deactivated and
are no longer visible via the find_relatedBusinesses API. For the sake of
determining uniqueness within an assertion set, the fromKey, toKey, and the
entire keyedReference within the publisherAssertion element are significant.
Any differences in any of the individual publisherAssertion element contents
constitute a new unique assertion for purposes of detecting new assertions.
The direction of the relationship, as indicated by the two businessKey values
in the fromKey and toKey elements, is also relevant in determining assertion
uniqueness.
The publisher must own the businessEntity referenced in the
fromKey, the toKey, or both. If both of the businessKey values passed within
an assertion are owned by the publisher, then the assertion is automatically
complete and the relationship described in the assertion is visible via the
find_relatedBusinesses API. To form a relationship when the publisher only owns
one of the two keys passed, the assertion MUST be matched exactly by an
assertion made by the publisher who owns the other business referenced.
Assertions exactly match if and only if they:
1. refer
to the same businessEntity in their fromKeys;
2. refer
to the same businessEntity in their toKeys;
3. refer
to the same tModel in their tModelKeys;
4. have
identical keyNames; and
5. have
identical keyValues.
When a publisherAssertion that is being saved references a
checked relationship system using the tModelKey in the contained
keyedReference, the reference MUST be checked for validity prior to completion
of the save, or the node must return E_unsupported, indicating it does not
support the referenced checked relationship system. Validation of a
relationship system reference entails verification that the reference is valid
according to the validation algorithm defined for the relationship system and
described by its tModel. For cached checked relationship system, the
validation algorithm verifies that referenced keyedReferences are valid for the
relationship system.
For registries supporting the subscription APIs at any
node, it is necessary to track a modified date for publisherAssertion elements
so that nodes have the necessary information for responding to subscription
requests involving find_relatedBusinesses and get_assertionStatusReport
filters.
- Throws:
DispositionReportFaultMessage, - RemoteException
If an error occurs in processing this API call, a dispositionReport element MUST be returned to the caller in a SOAP Fault. See
Section 4.8 Success and Error Reporting. In
addition to the errors common to all APIs, the following error information is
relevant here:
·
E_invalidKeyPassed: Signifies that one of the uddiKey
values passed did not match with any known businessKey or tModelKey values.
The assertion element and the key that caused the problem SHOULD be clearly
indicated in the error text.
·
E_userMismatch: Signifies that neither of the businessKey
values passed in the embedded fromKey and toKey elements is controlled by the
publisher associated with the authentication token. The error text SHOULD
clearly indicate which assertion caused the error.
DispositionReportFaultMessage
RemoteException
Copyright © 2004-2013 The Apache Software Foundation. All Rights Reserved.