Service Registry overview

Storing non-functional aspects of services such as security and reliability policies within each Container, or even within each application, poses several maintenance challenges:

• Distributing several copies of one and the same artifact, such as service descriptions and policies, over different runtimes.

• Enabling reuse of artifacts, especially policy assertions, across services.

• Keeping a consistent version of configurations and policies over all runtimes.

• Getting an overview of current settings in the different runtimes.

• Enforcing consistent authorization policies for the changing artifacts in the runtimes.

For larger deployments, a central registry becomes an increasingly important component. The purpose of the registry is to serve as a runtime directory advertising service descriptions, policies, and configuration. To manage the artifacts, the registry provides an administrative user interface which also enables browsing through the artifacts. For a lookup of the artifacts required by the runtime, the registry provides a corresponding service for the different artifact types. Instead of a pull style service, a push style may be offered to simplify updates of artifacts when the runtime is already active.

With a central registry being in place, a security architect for example would now be able to specify standard policy assertions for the different security aspects, authentication, signatures, and so on, and deploy them to the registry. The security assertions can then be reused to define a uniform policy for multiple services ensuring that security aspects are applied consistently.

Common use cases supported by the Service Registry:

• Service Lookup - When a CXF service or a client is created, it needs to retrieve the corresponding WSDL, either to make it accessible using HTTP GET requests via the '?wsdl' mechanism or to generate a suitable client proxy. Instead of retrieving it from a fixed location, the service or client will now look up the description from the registry. To lookup a service description, the component (service or client) needs to specify the fully qualified name of the service. In case of success, the registry returns a WSDL containing the service with the requested name, otherwise an error is returned.

• Initial Policy Lookup - When a CXF service or a client is created and the WSDL already retrieved, the component next needs to know what policies are to be applied for the service. Besides applying policies embedded in the service description or referenced from within the service description, the component needs to consult potential policy attachment documents bound to the service description. Instead of retrieving the policy attachment documents from a fixed location configured locally, the component looks up the policy attachment from the registry. To lookup a policy attachment, the component needs to specify the fully qualified name of the service for which to get the policy attachment. In case of success, the registry returns a policy attachment and the component further follows the references in the attachment, otherwise the registry returns an empty response.

The list below describes the domain model for the Service Registry in order to provide a structural view of the system:

• Registry - a component that provides centralized storage for service metadata (WSDL, policy, policy attachment) and a possibility to work with it (upload, update, delete, lookup). It contains three layers: Persistence layer, Server layer, and Service layer.

• Registry client - a component that can use the Registry Service to request resources from Registry storage. There are two registry clients that can be used in TESB Runtime to provide metadata for CXF services: WSDL Registry client and Policy Registry client. Also browser, soapUI or any custom clients can be used to work with Registry.

• Resource - an entity that can be stored in the Registry.

• Service metadata - Carries customer-specific information related to the stored services, usually targeted rather to human readers than to machines. This information may cover aspects of service development, business aspects of service provision and consuming, or similar issues. The Service Registry expects XML documents as metadata resources where the root element, the ServiceName element, and the metadata element are defined, but not the content of the metadata element. It is up to you to provide a schema (XSD) which is used by the Service Registry to validate the metadata documents. Service metadata can be fed into ElasticSearch for full-text search and other advanced queries.

• Service Description - Specifies the interface of the service and corresponding data structures. Represented by WSDL and XML Schema documents.

• WSDL - a Service Description Resource providing the operations exposed by a web service provider, as well as binding and endpoint information.

• Policy - a Resource providing assertions about non-functional characteristics of a service, such as security aspects.

• Policy Attachment - A Resource used to bind policies to a service description.

• Persistence layer - a functional layer that consists of JCR (Java Content Repository), or more precisely Apache Jackrabbit, and wrapped Jackrabbit API for convenient usage of repository (PersistencyManagerFactory and PersistencyManager classes).

• Server layer - a functional layer that operates with higher-level abstractions then Persistence layer. The main abstractions on this level are resource, WSDL, policy and operations to work with these entities: upload, update, delete, lookup. This layer is presented by RegistryServer class.

• Service layer - a Registry frontend that can be presented by different service types (REST, SOAP, and so on). By default TESB Registry uses a REST service to expose the Registry API.

The Talend Service Registry consists of server and registry clients that can be used by CXF-based web-services to retrieve resources from the repository (for example: WSDL, policies, and so on). Please see the graphic model of the general Registry structure below:

The Registry clients shown above are used to gain and process registry data. Two kinds of clients are provided as features in the Talend Runtime Container: WSDL Client and Policy Client. These clients allow CXF services to dynamically change their WSDLs and policies, avoiding a need to manually alter the services. User can also implement custom clients to work with one of existing frontends of the registry. Also SOAP UI or a browser can be used to make various manipulations with registry data.

The main components of the Server part of the Registry are:

• Java Content Repository (JCR), using the Apache Jackrabbit repository to store registry data.

• Backend, which has two layers: persistence and server layer, both of which have APIs to work with them.

• Frontend, that can be REST, SOAP or some other kind of service, which will expose the registry API to the clients.

The registry backend is kept independent of the frontend. The next picture shows this in more detail:

The Persistence layer API is a wrapper for the Jackrabbit API to manipulate resources in form of repository nodes, properties and relations between them (in JSR notions). The Server layer API provides the possibility to manipulate WSDLs and policy files.

The main interface of the domain model is RegistryServer. It contains a set of operations that can be used to manipulate Resources. Every resource has a ResourceIdentity and Content (for example, PolicyContent in case of policies). ResourceIdentity can be of one predefined ResourceTypes and contains a unique resourceID. RegistryServer provides just a contract for registry operations and these operations can be implemented using various technologies. For example, instead of the JCR repository, a database can be used to store registry data. In this case, an implementation that works with database API should be provided and this approach ensures independence of domain model from underlying data access layer or backend. For more information on how to change the repository from the default file-based storage to a database-based one, see Backend configuration.

Another advantage of this API is related to the well-defined contract and strict set of entities from the registry domain. Objects specific for some technology or architectural style are not used (for example: REST or SOAP), which provides the possibility to make an independent service layer. The only thing needed is to use the domain model API from whatever specific technology context chosen.

Below is the domain model with an example of policy upload and lookup operations:

As you can see from the image, these operations can be split into several steps.

First, if the consumer (Consumer1) wants to upload the policy to the Registry:

1. It collects information about certain policies (Step 1),

2. It instantiates the ResourceIdentity and Resource classes (Steps 2 and 3),

3. It can use the Resource object to upload a policy by methods from the RegistryServer interface. (Step 4).

Second, if another consumer (Consumer2) tries to look up policies from the Registry:

1. It will also have to use RegistryServer, by setting the service name (Step 5),

2. The Resource object that the consumer gets from the RegistryServer (Step 6), can easily get the policy content to the consumer (Step 7).

No classes specific to a particular frontend interface are used for these operations, keeping this scheme valid for different possible frontend implementations. In addition, by using the RegistryServer interface the domain model does not depend on any specific backend implementation.