Programming UDDI
Two APIs are described by the UDDI specification: the inquiry API and the
Publishing API. They are accessed using the same techniques but use different
XML documents, data structures, and access points. The inquiry API locates
information about a business, the services a business offers, the
specifications of those services, and information about what to do in a
failure situation. Any read operation from a UDDI registry uses one of the
inquiry API's messages. The inquiry API does not require authenticated access
and is subsequently accessed using HTTP.
The Publishing API is used to create, store, or update information located
in a UDDI registry. All functions in this API require authenticated access to
a UDDI registry; the UDDI registry must have a logon identity, and the
security credentials for this identity must be passed as a parameter of the
XML document for each UDDI invocation. Because publishing requires
authenticated access, it is accessed over HTTPS, with a different URL than the
one used with the inquiry access point. Table
6-1 lists the inquiry and publishing access point URLs for some major
operator nodes.
Several primary information types construct the XML documents used as input
and output to UDDI invocations. This section shows these data structures along
with the major APIs as defined by the UDDI specifications.
UDDI APIs are designed to be simple. All operations that a UDDI registry
performs are synchronous, meaning that the requesting client blocks and waits
until it receives a response message. Additionally, all operations have a
simple request/response mechanism that gives them a stateless behavior.
Therefore, using the UDDI APIs doesn't require a lot of complex ordering.
UDDI Data Structures
To understand the structure of the messages that are part of the API, you
need a basic appreciation for the different data structures and XML formats
that are used. This section discusses the major data structures that are
passed as input and output parameters for major API messages. Figure
6-3 shows the relationships between the primary UDDI data structures.
Figure 6-3. Relationship of primary
UDDI data structures
|
|
A <businessEntity> structure represents a business's
basic information. This information includes contact information,
categorization, identifiers, descriptions, and relationships to other
businesses. UDDI allows companies to establish relationships with one another.
Many different types of relationships are possible. For example, a
conglomerate can reference a subsidiary, or two companies can declare a
partnership. In either case, each company must establish a unique
<businessEntity> and separately establish its relationships
to other companies that have their own <businessEntity>
structures.
The <publisherAssertion> structure is used to establish
public relationships between two <businessEntity>
structures. A relationship between two <businessEntity>
structures is visible only to the "public" when both companies have created
the same assertion with two separate <publisherAssertion>
documents independently. Thus, a company can claim a business relationship
only if its partner asserts the same relationship. One company's assertion
about a business relationship isn't visible to the public until its partner
creates a similar, but separate, <publisherAssertion>
document for its own <businessEntity> structure. Thus, if
Company A asserts a relationship with Company B (fromKey=A, toKey=B), then the
relationship will become public when Company B asserts a relationship with
Company A (fromKey=B, toKey=A).
A <businessEntity> contains one or more
<businessService> structures. A
<businessService> represents a single, logical service
classification. A <businessService> element is used to
describe a set of services provided by the business. These services can be web
services or manual services such as a nonelectronic service. A
<businessService> document is reusable (i.e., a
<businessService> element can be used by several
<businessEntity> elements). For example, GE might create an
HR web service and publish that service as part of an "HR web service"
<businessService> structure. Additionally, GE might choose
to list each of its subsidiaries as a separate
<businessEntity>, since each subsidiary has its own IT
infrastructure. Doing so would allow the <businessEntity>
structure for the Plastics division to reference the same "HR web service"
<businessService> as the Chemicals division.
A <businessService> contains one or more
<bindingTemplate> structures. A
<bindingTemplate> contains pointers to technical
descriptions and the access point URL, but does not contain the details of the
service's specifications. A <bindingTemplate> contains an
optional text description of the web service, the URL of its access point, and
a reference to one or more <tModel> structures. A
<tModel> is an abstract description of a particular
specification or behavior to which the web service adheres. A
<tModel> is a type of digital "fingerprint" for determining
the specifics of how to interact with a particular web service. The
<tModel> structure does not provide the web service's
specification directly. Instead, it contains pointers to the locations of the
actual specifications. Companies can use the information pointed to by a
<tModel> to determine whether a web service is compatible
with their business requirements.
UUID
Instances of these data structures are identified and referenced by
a universally unique identifier, known as a UUID. UUIDs are assigned
when the data structure is first inserted into the UUID registry. They
are hexadecimal strings whose structure and generation algorithm is
defined by the ISO/IEC 11578:1996 standard. This standard virtually
guarantees the generation of a unique identifier by concatenating the
current time, hardware address, IP address, and random number in a
specific fashion. The Inquiry API uses the UUID to request a
particular structure on demand.
<publisherAssertion> documents do not have
UUIDs, however.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
