In Chapter 2, we looked at the role of registries in service-oriented architectures. The Java API for XML Registries (JAXR) allows Java applications to communicate and interact with service registries and repositories for Web services. As corporations begin to develop an increasing number of services for consumption by business partners, or even internally within their organizations, they need a standard API to undertake this task of interacting with the registries. Using a vendor-, protocol-, or implementation-specific API for this purpose couples the Web service to the vendor implementation.
JAXR is a standard extension API which, like the other XML APIs, has been developed by the collaborative effort of the community as part of the Java Community Process under JSR-93, which became a final specification in April 2002. The JAXR reference implementation is included in the JAX pack and is also packaged with JWSDP.
Before we look at JAXR, let us revisit some of the concepts regarding registries introduced in Chapter 6. A naming service is a critical building block in an enterprise network. It allows names to be associated with objects and objects to be located by name. For example, a Domain Name Service (DNS) holds a mapping between a domain name and an IP address. When queried for www.webservicesarchitecture.com, it returns the IP address 18.104.22.168. A phone book is an example of a naming service where listings are a little more organized by name and, in the yellow pages, by category (lawyers, movers, restaurants, etc.)
A registry is a special form of naming service. It not only allows such a lookup but also allows entities, objects, and so on to be registered with it. The first registry and lookup API any Java developer comes across are the RMI registry and JNDI API.
Let's examine what happens within an RMI registry. Developers create a remote object and publish it in the registry, by associating it with a name. Other applications use the JNDI API to query that registry for the name and get a remote reference (or stub) back for the object.
A registry in the context of Web services serves essentially the same purpose. It gives applications and businesses a central point to store information about their Web services. It also facilitates consumption of these Web services by giving clients the ability to query and retrieve details about the business, the services offered, and details about the services, such as how and where to invoke them (Figure 12.1).
Every registry has an information model or domain object model that business applications develop. An information model is a detailed schema that lays out the blueprint for the registry. It provides information about the type of data that can be stored and how that data is organized in the registry. It is important to understand that the information model does not represent the actual content stored in the registry but the logical metadata for that content. The content itself (e.g., the WSDL describing the service) is stored in a repository, which serves as an implementation detail under the registry.
A registry for Web services also defines a standard set of services it provides. These services are themselves exposed as Web services. For example, well-defined SOAP requests define the interactions involved in querying and publishing to the registry.