7.2 JAXR Architecture

Aside from the fact that they both provide an XML-based interface to application clients (in addition to the browser interface offered by the UDDI public registry), from a developer's point of view, the UDDI and ebXML registries have little in common. In particular, the structure of information within the registry and the programming interface are very different. As a result, applications written to use the native facilities provided by the UDDI registry cannot be used with an ebXML registry and vice versa. The Java API for XML Registries (JAXR) solves this problem by providing a common interface that allows a Java application to access a registry without needing to be aware of its implementation details. Figure 7-5 shows the JAXR software architecture. The JAXR specification was developed under the Java Community Process and can be downloaded from http://jcp.org/jsr/detail/93.jsp.

Figure 7-5. JAXR architecture

The first thing to note is that, unlike SAAJ and JAX-RPC, JAXR is a client-side only API � the implementation details of the registry service itself are of no concern, except insofar as the registry service provides the XML-based interface and information model required by its specification. Furthermore, although the internal information models defined for the UDDI and ebXML registries are quite different, a JAXR application can extract business and service information from either of them, since the JAXR API transparently maps them both to its own information model, which happens to be based upon and very similar to that of the ebXML registry.^[1]

^[1] You can obtain the specifications for the UDDI registry from http://uddi.org and for the ebXML registry/repository from http://www.ebxml.org. Although you don't need to read these specifications in order to use JAXR, it is sometimes useful to know how JAXR operations affect the registry. Also, a knowledge of the internals of the registry may occasionally be helpful when debugging JAXR applications.

A JAXR application client (such as a registry browser, a development tool, or a web services client that needs to fetch registry-based information at runtime) uses the classes and interfaces in the javax.xml.registry and javax.xml.registry.infomodel packages to make requests of the target registry service. The mapping to the programming interface and information model of a specific registry is performed by a JAXR provider that is specific to a particular type of registry. The JAXR reference implementation includes a UDDI registry provider and a registry server that is useful for development and testing purposes. A free, open source implementation of a JAXR provider for ebXML, together with an ebXML registry/repository, can be downloaded from http://ebxmlrr.sourceforge.net. We'll use both of these JAXR implementations in this chapter.

If you leave aside the details, the UDDI and ebXML registries have much in common. These common facilities are mapped by the JAXR provider to the corresponding JAXR API. However, the ebXML registry has some features that do not exist in UDDI and that cannot reasonably be emulated by the UDDI JAXR provider. Rather than opt for a lowest common denominator API, which in this case would have omitted the additional ebXML facilities, the JAXR expert group chose to introduce the concept of capability levels. Each method within every JAXR class and interface is assigned a capability level, and a JAXR provider also has an associated capability level. The following rules apply:

• A JAXR provider must fully implement all of the methods that are assigned to its capability level and to all lower capability levels.

• A JAXR provider must not provide a meaningful implementation of any of the methods assigned to higher capability levels. If an application invokes one of these methods, then it must throw a javax.xml.registry.UnsupportedCapabilityException.

The current JAXR specification defines two capability levels:

Level 0

Level 0 methods must be implemented by all JAXR providers and therefore represent the common core functionality that all JAXR client applications can rely on. The UDDI provider is a level 0 provider.

Level 1

Level 1 methods include additional functionality that covers the features of the ebXML registry/repository that cannot be mapped so that they also appear to work with a UDDI provider. An ebXML provider must be a level 1 provider.

It is important to note that the JAXR specification does not officially assign capability levels to classes or interfaces, so that all providers must include an implementation of the whole API. However, in practice, some interfaces are entirely composed of level 1 methods and are therefore effectively level 1-only facilities. The reference documentation in this book for the javax.xml.registry and javax.xml.registry.infomodel packages indicates the capability level of each method.

The capability level of a provider is available at runtime for the benefit of application clients that can tailor their behavior according to the available functionality.

Although every provider is required to implement JAXR level 0 functionality, unfortunately they cannot all do this to the same degree. As an example of this, the level 0 API includes the ability to define private classification schemes, but, as we'll see later in this chapter, even though this feature exists, an application client cannot programmatically construct such a scheme when connected to a UDDI registry.[2] Instead, the classification scheme has to be defined and supplied to the JAXR provider at initialization time. As a consequence, the classification scheme does not actually appear in the registry itself. [2] Note also that an application client that attempts to define a private classification scheme using the level 0 API for doing so would appear to succeed. However, the classification scheme would not be properly defined in the case of a UDDI registry, and an attempt to use it by another client would fail. By contrast, the ebXML registry provides everything necessary to allow user-defined classification schemes to be set up dynamically by application clients.