Show TOC

Background documentationService Consumption with the Services Registry Locate this document in the navigation structure

 

Services Registry is the central entry point for service consumers. Each consumption tool implements the Services Registry to find the entities needed and to use the reference provided by the Services Registry to retrieve the concrete metadata from a separate location.

The high-level process flow of service consumption can be described as follows:

  1. The consumer queries the Services Registry using taxonomies to find the services to use.

  2. The Services Registry delivers the reference to the metadata.

  3. The consumer or consumption tool retrieves the metadata using this reference from the following destinations:

    • Enterprise Services Repository for modeled design time entities.

    • Back ends for service definitions (service implementations).

    • Back ends for service endpoints (configured services).

Development Cycle

The following diagram depicts the lifecycle of a client application and its interaction with Services Registry. Each step in the diagram corresponds to the steps in the development cycle below.

This graphic is explained in the accompanying text.

Development Cycle with the Services Registry

The prerequisite for consumer application developers for finding a service is that service provider developers have published them in the Services Registry.

  1. A developer in the provider system publishes a service to the Services Registry.

  2. The consumer application developer starts searching for services in the Services Registry.

    All relevant classification systems and their values and grouped classification systems are retrieved. The developer can use them as value helps in search criteria so that the developer can filter or browse through service definitions based on a process component, for example.

  3. After the developer has entered the search criteria, a search request is executed and a result list is displayed.

    The developer can choose the service they would like to use. If the service is available in several provider systems, the developer can choose from which provider systems and deployment unit to obtain it.

  4. The system retrieves the URLs for the WSDL and WS Policy documents in the provider system.

    The developer creates or chooses an existing logical destination.

  5. The documents required for generation of a WS proxy definition are downloaded directly from the provider system through a separate metadata connection.

    The developer creates the WS proxy.

    Information about the service is retained in the proxy definition metadata for future references.