Using JAXR for Registry Access
The Java API for XML Registries (JAXR) is an attempt to provide a unified model of access to XML-based information stored in registries and repositories. The intent is that this will provide a standard API for such access to ease the development of applications that depend on this information.
A Generic Approach
Some registry APIs, such as IBM's UDDI4J, are specifically targeted at UDDI access. As you know, UDDI is not the only XML-based Web Service registry; the ebXML Registry and Repository also fills this role. In addition, there are various other XML-based registries that are used in different e-commerce frameworks. JAXR provides a set of generic APIs that work on a generic registry information model. Existing registries can then be mapped onto this generic framework, giving developers the ability to access information in different registries using the same API. This should bring the level of consistency to XML-based registry access that JNDI and JDBC have brought to directory services and databases, respectively.
The overall JAXR architecture is shown in Figure 21.6. The client interacts with the JAXR Pluggable Provider layer that acts as a standard interface and rendezvous point. Underneath the Pluggable Provider, a particular registry-specific provider will be used to obtain information from a particular type of registry. This style of architecture has much in common with those of JDBC and JNDI. In fact, it is anticipated that many JAXR providers will, at least initially, be developed as bridges to existing registry providers, in a similar style to the JDBC-ODBC bridge.
Figure 21.12. JAXR architecture.
JAXR defines its own information model onto which other information models (such as UDDI or ebXML) can be mapped. The JAXR information model (defined in the package javax.xml.registry.infomodel) contains interfaces for some concepts which you encountered earlier, including the following:
Service— Similar to the UDDI businessService and tModel, containing interface and category information for a service
ServiceBinding— Similar to the UDDI bindingTemplate, containing location information for a service instance
Concept— Similar to UDDI categories, used for classifying organizations and services
Collections of such interfaces are passed to and returned from JAXR query and manipulation methods.
The class javax.xml.registry.RegistryService represents the registry service. After the client has obtained a RegistryService reference, it can discover the capabilities of the registry service. Capabilities can be generic or business related. The capabilities are defined in levels, and there are currently two levels—0 and 1. Every JAXR Provider must implement the level 0 capabilities. More advanced providers will also implement the level 1 capabilities. The capability interfaces are
The BusinessLifeCycleManager interface— Enables you to create, update, and delete organizations, services, ServiceBindings, and concepts. Each method returns a BulkResponse that contains a collection either of keys identifying individual registry entries or of exceptions indicating that a save or delete operation failed. This is a level 0 capability.
The GenericLifeCycleManager— Enables you to save or delete any form of registry entry. This is a level 1 capability.
The BusinessQueryManager— Enables you to find organizations, services, or concepts based on names, concepts, and binding information. This is a level 0 capability.
The SQLQueryManager— Enables you to submit a SQL query that is executed against the registry data. This treats interface types (for example, Organization) as if they were database table names. This is a level 1 capability.
Because the principal registries for Web Services are the ebXML Registry and Repository and the UDDI Registry, the JAXR specification defines bindings for UDDI and ebXML. These bindings detail the mappings between the different registry information models.