Q. What is the JavaTM API for XML Registries
(JAXR)?
A. The Java API
for XML Registries (JAXR) API provides a uniform and
standard Java API for accessing different kinds of XML
Registries. XML registries are an enabling
infrastructure for building, deployment, and discovery
of Web services.
Q. What is the
relationship between the JAXR API and other XML
APIs?
A. Implementations of JAXR providers may use the
Java API for XML-based RPC (JAX-RPC) API for communication between JAXR providers
and registry providers that export a SOAP based
RPC-like interface (for example, UDDI).
Implementations of JAXR providers may use the Java API for XML Messaging (JAXM)
API for communication between JAXR providers and
registry providers that export an XML Messaging-based
interface (for example, ebXML TRP).
The Java API for XML Processing (JAXP) and Java Architecture for XML Binding (JAXB) may be used by implementers
of JAXR providers and JAXR clients for processing XML
content that is submitted to or retrieved from the
Registry.
Q. Why do we need a new
JAXR API when we have the Java Naming and Directory
Interface (JNDI)?
A. The JNDI API
was designed with a very different set of requirements
from the JAXR API. Both are abstraction APIs over
existing specifications. However, the abstraction in
directory services differs considerably from that of
XML Registries used for publishing and discovery of
Web services. The JAXR API needs richer metadata
capabilities for classification and association, as
well as richer query capabilities.
Q. Would it not
be better to have enhanced the JNDI API with the added
functionality of the JAXR API?
A. That option was considered. Meeting the
additional requirements of XML Registries requires an
elaborate information model. The JNDI API has an
existing information model that is constrained by
design to address the requirements for directory
services. Extending the JNDI API would overly
constrain the JAXR API and would create backward
compatibility issues for the JNDI API.
Q. What is the purpose
of Association in the JAXR information model? It is
not used anywhere in the API.
A. An Association relates two RegistryObjects to
each other. An Association may be defined between two
objects in the registry and submitted using the
GenericLifeCycleManager's saveObjects method.
Q. What is the
purpose of Classification in the JAXR information
model? It is not used anywhere in the API.
A. A Classification classifies a RegistryObject. A
Classification may be defined for a RegistryObject and
submitted using the GenericLifeCycleManager's
saveObjects method.
Q. Why is JAXR an
abstraction API and not targeted to a specific
registry such as UDDI or ebXML?
A. An abstraction-based JAXR API gives developers
the ability to write registry client programs that are
portable across different target registries. This is
consistent with the Java philosophy of Write Once, Run
Anywhere. It also
enables value-added capabilities beyond what the
underlying registries are capable of. For example, a
non-JAXR UDDI client does not have the ability to do
taxonomy browsing and taxonomy-aware smart queries,
which are available to a JAXR client for UDDI.
Q. Why does the JAXR
API not use UDDI terms and concepts?
A. The JAXR API is not specific to UDDI or any
other registry specification. It is an abstraction API
that covers multiple specifications. It is designed to
enable developer choice in the use of a Web service
registry and/or repository. The JAXR API uses UDDI
terms and concepts when they fit the JAXR information
model (for example, Service, ServiceBinding, and
method names in BusinessQueryManager and
BusinessLifeCycleManager).
Q. Why did the JAXR
information model use the ebXML Registry Information
Model as its basis rather than the UDDI data
structures?
A. The JAXR API is designed to support multiple
registries. The ebXML Registry Information Model is
more generic and extensible than the UDDI data
structures. Because of this characteristic, it was
possible to extend the ebXML Registry Information
Model to satisfy the needs of UDDI and other
registries.
Q. Why was the
JAXR information model not designed from the ground
up?
A. Information models take time to develop. It was
easier to start with an existing information model and
improve upon it.
Print-friendly Version
