Java API for XML Registries (JAXR)

Java API for XML Registries (JAXR)

Q. What is the Java 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 Jav API for XML-Based RPC (JAX-RPC) 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.