The Publishers API describes the messages that are used to control the content contained within a UDDI-enabled server, and can be used by compliant non-operator implementations that adhere to the behaviors described in this programmer's reference specification.
All calls made to UDDI-enabled servers that use the messages
defined in the publisher's API will be transported using SSL
encryption. UDDI-enabled servers will each provide a service
description that exposes a
bindingTemplate that makes use of
HTTPS and SSL to secure the transmission of data.
Each of the calls in the publisher's API that change information
at a given UDDI-enabled server requires the use of an opaque
authentication token. These tokens are generated by or provided by
each UDDI-enabled server independently, and are passed from the
caller to the UDDI-enabled server in the element named
These tokens are meaningful only to the UDDI-enabled server that provided them and are to be used according to the published policies of a given UDDI-enabled server.
Each party that has been granted publication access to a given UDDI-enabled server will be provided a token by the site. The methods for obtaining this token are specific to each UDDI-enabled server.
Before any party can publish data within a UDDI-enabled server, credentials and permission to publish must be supplied with the individual operator. Generally, you will only need to interact with one UDDI-enabled server because all data published at any UDDI-enabled server are replicated automatically to all other such servers. Establishing publishing credentials involves providing some verifiable identification information, contact information, and establishing security credentials with the individual server. The specifics of these establishing credentials is server-dependent, and all valid UDDI-enabled servers provide a Web-based user interface through which you can establish an identity and secure permission to publish data.
Every registry implementation that adheres to these
specifications establishes its own mechanism for token generation
and authentication. The only requirement placed on token generation
for use with the publisher's API is that the tokens themselves must
be valid string text that can be placed within the
authInfo XML element. Given that
binary-to-string translations are well-understood and in common
use, this requirement will not introduce hardships.
Authentication tokens are not required to be valid except at the UDDI-enabled server or implementation from which they originated. These tokens need only have meaning at a single UDDI-enabled server or implementation, and should not be expected to work across sites.
Many implementations are expected to require a login step. The
get_authToken message is
provided to accommodate implementations that desire a login step.
Security schemes based on exchanging User ID and password
credentials fall into this category. For implementations that
desire this kind of security, the
get_authToken API is provided as a
means of generating a temporary authentication token.
Certificate-based authentication and similar security mechanisms
do not require this additional step of logging in. Instead, they
can pass compatible authentication token information such as a
certificate value within the
authInfo element provided on each of
the publisher's API messages. If certificate-based authentication
or similar security is employed the use of the
discard_authToken messages is