This book has been written for experienced Java developers wishing to learn how to work with the JBoss Enterprise Service Platform's service registry.
Read this book in order to learn how to develop for and operate the jUDDI Service Registry. Note that this Guide does not show you how to initially configure and secure the product for use in a production environment. For that information, refer to the full Installation and Configuration Guide.
Red Hat recommends that you back up your system settings and data before undertaking any of the configuration tasks mentioned in this book.
The jUDDI (Java Universal Description, Discovery and Integration) Registry is a core component of the JBoss Enterprise SOA Platform. It is the product's default service registry and comes included as part of the product. In it are stored the addresses (end-point references) of all the services connected to the Enterprise Service Bus. It was implemented in JAXR and conforms to the UDDI specifications.
2.5. jUDDI and the JBoss Enterprise SOA Platform
jUDDI and the JBoss Enterprise SOA Platform
The JBoss Enterprise SOA Platform product includes a pre-configured installation of a jUDDI registry. You can use a specific API to access this registry through your custom client. However, any custom client that you build will not covered by your SOA Platform support agreement. You can access the full set of jUDDI examples, documentation and APIs from: http://juddi.apache.org/.
2.6. Other Supported Service Registries
The JBoss Enterprise SOA Platform also supports these other UDDI registries:
SOA Software SMS
A service registry is a central database that stores information about services, notably their end-point references. The default service registry for the JBoss Enterprise SOA Platform is jUDDI (Java Universal Description, Discovery and Integration). Most service registries are designed to adhere to the Universal Description, Discovery and Integration (UDDI) specifications.
From a business analyst’s perspective, the registry is similar to an Internet search engine, albeit one designed to find web services instead of web pages. From a developer's perspective, the registry is used to discover and publish services that match various criteria.
In many ways, the Registry Service can be considered to be the "heart" of the JBoss Enterprise SOA Platform. Services can "self-publish" their end-point references to the Registry when they are activated and then remove them when they are taken out of service. Consumers can consult the registry in order to determine which end-point reference is needed for the current service task.
A service provider gives access to services, creates descriptions of them and publishes them to the service broker.
A service broker hosts the registry of service descriptions. It is responsible for linking a service requester to a service provider.
A service requester is responsible for discovering a service. It does so by searching through the service descriptions given to it by the service broker. A requester is also responsible for binding together services obtained from the service provider.
A web service is a way of making two applications communicate over the web. A web service consists of a set of tools to achieve this aim. There are two types of web service: REST-compliant ones, (the purpose of which is to manipulate XML representations of web resources) and arbitrary Web services (through which the service can expose any operation).
2.12. Web Service End-Point
A web service end-point is software that implements a web service. They are used to implement message-based communication between web services in a service-oriented architectural environment.
The external applications to which these registry entries point can include .NET programs, other external Java-based application servers and LAMP software bundles.
2.13. Web Services Description Language (WSDL)
The Web Services Description Language (WSDL) is an XML-based language that is used to define Web service interfaces. An application that consumes a Web service parses the service’s WSDL document to discover the:
location of the service
the operations that the service supports
the protocol bindings the service supports (SOAP, HTTP, etc)
For each operation, the WSDL describes the interface format to which the client must adhere.
2.14. Universal Description, Discovery and Integration (UDDI) Registry
The Universal Description, Discovery and Integration Registry (UDDI) is a directory for web services. Use it to locate services by running queries through it at design- or run-time. Within an UDDI Registry, information is categorized in Pages. UDDI creates a standard interoperable platform that enables companies and applications to quickly, easily, and dynamically find and use Web services over the Internet. UDDI also allows operational registries to be maintained for different purposes in different contexts.
The UDDI also allows providers to publish descriptions of their services. The typical UDDI Registry will contain a uniform resource locator (URL) that points to both the WSDL document for the web services and the contact information for the service provider.
A business publishes services to the UDDI registry. A client looks up the service in the registry and receives service binding information. The client then uses the binding information to invoke the service. The UDDI APIs are SOAP-based for interoperability reasons.
2.15. UDDI Application Programming Interfaces
The UDDI v3 specification defines nine APIs:
This defines the API to obtain a security token. With a valid security token a publisher can publish to the registry. A security token can be used for the entire session.
This defines the API to publish business and service information to the UDDI registry.
This defines the API to query the UDDI registry. This API does not normally require a security token.
This API can be used to transfer the custody of a business from one UDDI node to another.
This defines the API to register for updates on a particular business of service.
This defines the API a client must implement to receive subscription notifications from a UDDI node.
This defines the API to replicate registry data between UDDI nodes.
This is used by nodes to allow external providers of value set the validation. Web services to assess whether keyedReferences or keyedReferenceGroups are valid.
UDDI nodes may perform validation of publisher references themselves using the cached values obtained from such a Web service.
- Green Pages
Green Pages provide information that enables you to bind a client to the service being provided.
- Yellow Pages
Yellow Pages are used to categorize businesses based upon the industries to which they belong.
- White Pages
White Pages contain general information, such as the name, address and other contact details for the company providing the service.
2.17. The Service Registry and the JBoss Enterprise SOA Platform
The Service Registry is a key part of the JBoss Enterprise SOA Platform. When you deploy services to SOA Platform's ESB, their end-point references are stored in it.
The JBoss Enterprise Service Bus directs all interaction with the Registry through the registry interface, the default version of which uses Apache Scout.
2.19. How the Registry Works
The JBoss Enterprise Service Bus funnels all interaction with the Registry through the registry interface.
It then calls a JAXR implementation of this interface.
The JAXR API needs to utilize a JAXR implementation. (By default, this is Apache Scout.)
Apache Scout, in turn, calls the Registry.
Apache Scout is an open source implementation of JAXR, created by the Apache Project.
There are currently four implementations of the
org.jboss.soa.esb.scout.proxy.transportClass class, one each for SOAP, SAAJ, RMI and Embedded Java (Local).
2.21. Java API for XML Registries (JAXR)
Java API for XML Registries (JAXR) is an API that provides a standard way to develop for service registries.
The Registry Interface is the means by which the ESB communicates with the Service Registry.
2.23. Variable Name: SOA_ROOT Directory
SOA Root (often written as SOA_ROOT) is the term given to the directory that contains the application server files. In the standard version of the JBoss Enterprise SOA Platform package, SOA root is the
jboss-soa-p-5 directory. In the Standalone edition, though, it is the
Throughout the documentation, this directory is frequently referred to as
SOA_ROOT. Substitute either
jboss-soa-p-standalone-5 as appropriate whenever you see this name.
2.24. Variable Name: PROFILE
PROFILE can be any one of the server profiles that come with the JBoss Enterprise SOA Platform product: default, production, all, minimal, standard or web. Substitute one of these that you are using whenever you see "PROFILE" in a file path in this documentation.