|
|
At present, two dominant industry standards for Web service registries are the registry as defined by the UDDI specifications and the registry and repository as defined by the ebXML specifications. Each of these standards defines its information model and a set of registry services; however, Java developers need a standard API to access these heterogeneous registries from applications and services developed in Java. This is where JAXR plays a significant role. It provides a layer of abstraction and gives architects the ability to design applications with a simple and standard API in Java that can interact with a varied set of business registries (such as UDDI and ebXML). However, this should not be construed to mean that JAXR is a new registry specification or a lowest common denominator API.
 |
JAXR is a simple, rich, and standard Java extension API for accessing diverse business registries. It should not be confused with a new registry specification or as a lowest common denominator API.
|
JAXR architecture is based around the concept of pluggable providers, as Figure 12.2 shows. Developers write applications using a standard JAXR client API and a standard information model (or domain object model) defined by JAXR. JAXR provides a pluggable mechanism for registry-specific providers, to be used by the client. The provider layer under the standard API supplies the API implementation and maps the JAXR information model as well as client invocations to the underlying registry's capabilities. In other words, the registry-specific provider knows how to interact with the specific registry type it supports. It maps the method invocations into the corresponding SOAP message invocations based on the registry's API specification and interacts with the registry over the wire, using a protocol such as HTTP.
Although the concept of pluggable providers is similar to the way JAXP, JAXM, and other APIs enable provider pluggability there is a subtle difference between the JAXR provider and the JAXM providers discussed in Chapter 11, which is that the JAXR provider is accessed locally. The only network communication point in the JAXR architecture is between the provider and the registry server. Everything else is colocated in the same virtual machine.
Earlier, we used the term registry capability, which has a specific meaning in JAXR terminology. JAXR's object model provides a superset of existing registry models; not all registry implementations support every JAXR feature. To logically group these features, each individual method in the JAXR API is assigned a capability level; providers declare what capability level they support.
By definition, JAXR has two capability levels: level 0 and level 1. When a provider declares support for level 0, it means the provider supports all methods in the API marked as level 0. A level 1 provider supports level 0 and level 1 API calls (support for a higher level by a provider also implies support for a lower level). Coincidentally, UDDI providers map to level 0 profile, and ebXML registry providers map to level 1 profile.
|
JAXR is also a part of J2EE 1.4 and application servers will be required to provide a level 0 JAXR registry implementation. In practical terms what this means is that J2EE4 servers will come with a UDDI registry.
|
All JAXR providers are required to support level 0 (and hence UDDI); support for level 1 is optional. In short, a JAXR client for a standard registry specification (e.g., UDDI) is guaranteed to be portable across JAXR providers from any vendor for that capability, and similarly for any vendor's registry implementation that is compliant to the specifications.
|
The JAXR reference implementation comes with a level 0-compliant provider to support UDDI 2.0. The ebXML provider for JAXR and the ebXML registry itself are available in an open source effort for the reference implementation of the OASIS ebXML registry at http://ebxmlrr.sourceforge.net.
|
|
|
