SCDJWS Study Guide: JAXR
The high-level architecture of JAXR consists of the following parts:
A registry provider implements an existing registry standard, such as the OASIS (Organization for the Advancement of Structured Information)/ebXML Registry Services Specification 2.0.
A JAXR provider offers an implementation of the JAXR specification approved by the Java Community Process (JCP) in May 2002.This is an implementation of the JAXR API that provides access to a specific registry provider or to a class of registry providers that are based on a common specification. You can implement a JAXR provider as its own JAXR-compliant registry provider. However, you would more likely implement a JAXR provider as a façade around an existing registry provider, such as a UDDI or ebXML registry provider. Currently, the JAXR reference implementation 1.0 offers a JAXR UDDI provider implementation. A group of developers are developing an open source JAXR ebXML provider implementation at www.sourceforge.com.
A JAXR client is a Java program that uses JAXR to access the registry provider via a JAXR provider. A JAXR client can be either a standalone J2SE (Java 2 Platform, Standard Edition) application or J2EE components, such as EJBs (Enterprise JavaBeans), Java Servlets, or JSPs (JavaServer Pages). The JAXR reference implementation also supplies one form of a JAXR client, a Swing-based registry browser application.
Figure 1 illustrates how diverse JAXR clients interoperate with diverse registries using JAXR. Architecturally, JAXR clients use the API to perform registry operations, while JAXR providers implement the API. Because JAXR offers a standard API for accessing diverse registry providers and a unified information model to describe registry contents, JAXR clients, whether HTML browsers, J2EE components, or standalone J2SE applications, can uniformly perform registry operations over various registry providers.
Figure 1. JAXR interoperability with any client to any registry. (This figure is from Sun Microsystems)
Figure 2 shows a high-level view of the JAXR architecture. The JAXR provider shown is a JAXR pluggable provider with underlying implementations of a UDDI-specific JAXR provider and an ebXML-specific provider. The JAXR provider exposes capability-specific methods to the JAXR client via the RegistryService interface. The JAXR client queries the RegistryService and discovers the provider capability level via the CapabilityProfile interface. The capabilities are discussed in the following section.
Figure 2. JAXR architecture. (This figure is from Sun Microsystems)
Before a JAXR client can invoke capability-level methods on the JAXR provider, it must connect to the provider. First the client obtains a ConnectionFactory instance using the static method ConnectionFactory.newInstance(). The ConnectionFactory interface lets the client create the Connection using its createConnection() method. Note that the JAXR client connects with the JAXR provider, not the registry provider. The JAXR provider acts as a proxy on the client's behalf, directing and invoking methods on the appropriate registry provider. The connection maintains client state. In addition, the JAXR client dynamically sets its authentication information and communication preference on the connection any time during the connection's lifetime. Please refer to the code demonstrating how a JAXR client connects to a JAXR provider in the development examples later in the article.
After the JAXR client invokes JAXR capability-level methods, the JAXR provider transforms these methods into registry-specific methods and executes requests to the underlying registry providers. After the registry providers process the requests and return registry-specific results to the JAXR provider, the JAXR provider transforms the information into JAXR information model RegistryObjects and returns them to the JAXR client. The RegistryObject interface is an abstract interface that provides the common information such as key, name, and description for the more specialized JAXR information model interfaces. Note that the communication protocol between a JAXR provider and a registry provider is registry provider-specific and transparent to the JAXR client. For example, a JAXR provider communicates with the UDDI registry provider by exchanging basic SOAP messages, while the JAXR provider communicates with the ebXML registry provider through SOAP messaging or ebXML message service.
Roles of JAXR Interacts follow chart:
A JAXR client uses JAXR interfaces and classes to request access to a registry. The client sends the request to a JAXR provider.
When a JAXR provider receives a request from a JAXR client, it transforms the request into an equivalent request that is based on the specifications of the target registry. The JAXR provider then passes this transformed request to a registry provider.
The registry provider receives a request from a JAXR provider and processes it. The process is then reversed ...
The registry provider returns a response to the JAXR provider, which transforms it to an equivalent JAXR response.
The JAXR provider sends the JAXR response to the JAXR client.