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 intention 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

The IBM WSTK classes and code you saw in the previous section 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 intends to provide 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.2. The client will interact 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.

The interaction between the JAXR client and the registry service is performed by a set of Java interfaces defined in the java.xml.registry package. To begin working with a registry using JAXR, you would use the Connection, RegistryService and potentially the RegistryClient interfaces. Listing 21.2 shows some typical initialization code for an interaction.

Listing 21.2. Example JAXR Client Initialization Code (Based on Early JAXR Specification)

 1: import javax.xml.registry.*;
 2: ...
 3: public class JAXRClient implements RegistryClient throws JAXRException
 4: {
 5:   public void init(InitialContext ctxt)
 6:   {
 7:     ConnectionFactory factory = (ConnectionFactory)ctxt.lookup("JAXRConnectionFactory");
 8:
 9:     // Define connection configuration properties
10:     Properties props = new Properties();
11:     props.put("javax.xml.registry.factoryClass",
12:               "com.sun.xml.registry.ConnectionFactory");
13:     props.put("javax.xml.registry.queryManagerURL",
14:               "http://java.sun.com/uddi/inquiry");
15:     props.put("javax.xml.registry.lifeCycleManagerURL",
16:               "http://java.sun.com/uddi/publish");
17:
18:     Connection connection = factory.createConnection(props, this);
19:
20:     Set credentials = new Set();
21:     ...
22:     connection.setCredentials(credentials);
23:     connection.setLocale(locale);
24:     connection.setSynchronous(false);
25:
26:     RegistryService rs = connection.getRegistryService();
27:     ...
28:   }
29:   ...
30: }
						

Obtaining a Connection is very much like any other J2EE resource. A factory is obtained through JNDI, and a connection is created from the factory. As with the UDDI code earlier, the URLs for inquiry and publication are provided when creating the connection (lines 13–16). Authentication credentials are also supplied before the registry service is used. As with UDDI, credentials will almost certainly be required to update information in the registry and may even be required for access to information.

Responses to registry queries can be obtained synchronously or asynchronously. In this case, the client will be using the asynchronous style of interaction with the JAXR provider. Hence, it must implement the RegistryClient interface that allows the provider to deliver information and errors to the client. Implementation of this callback interface is not required for synchronous interaction because all information and errors are returned directly from the JAXR calls made by the client.

Using JAXR to Store and Retrieve Service Information

JAXR defines its own information model onto which other information models (such as UDDI or ebXML) can be mapped. The JAXR information model contains many familiar interfaces, including the following:

• Organization Similar to a UDDI businessEntity

• 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.

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 allows 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 allows you to ave or delete any form of registry entry. This is a level 1 capability.

• The BusinessQueryManager allows you to find organizations, services, or concepts based on names, concepts, and binding information. The methods offered are very similar to those described earlier for the IBM WSTK ServiceRegistryProxy. This is a level 0 capability.

• The SQLQueryManager allows 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.

You have now seen how Web Service information can be stored and retrieved.