Component Registry Service API Specification

What is the Component Registry Service?

The component registry service is one of the key services in the vRealize Automation distributed architecture. It manages all services (including out-of-the-box services and services from third party solution providers) and serves as the central view for all service lookups. Clients of the component registry service interact with it to obtain service information and related endpoint data.

The component registry service provides:

• A central location for services to publish their service information and endpoints (for both out-of-the-box services and third party services).
• A central location for clients to query services information and endpoints.
• An endpoint configuration capability for services not directly integrated in the application. The external services are treated in the same way as out-of-the-box services.

Key Concepts

Service

A service provides a set of related functionalities/features. A service may use functions (i.e., endpoints) provided by other services. For example, the shell-ui-app service uses some features of the catalog service. Most of the services use the SSO service for authentication.

Service Endpoint

A service endpoint provides a specific function or subfeature of a service. A service generally has many endpoints.

Service Provider

A provider of services via endpoints. For example, the catalog service provides catalog features for the shell-ui-app service to consume.

Service Consumer

A service that uses functions provided by other services. For example, a pure service consumer such as the vRA UI (shell-ui-app) only consumes services without providing services of its own. But a mixed service consumer such as the event log service provides its own services as well as consuming other services.

How the Component Registry Service Works

Understanding the Relationships

The component registry stores details on all services and their associated endpoints. Before interacting with the component registry, it's helpful to grasp the relationships that come into play.

• A service type identifies a deployable product or common service that can be connected to the application; for example, "catalog service," "composition service," or "software service."
• A service identifies a deployed instance of that product or common service; for example, the instance of "composition service" installed on machine X. In most cases, there is a single service instance for a given service type.
• A service can have multiple endpoints, but can have only one endpoint instance per endpoint type. Each endpoint points to a URL that provides a specific API to that service.
• The exact API provided by an endpoint is identified by an endpoint type. Endpoint types enable consumers of a service to obtain the endpoint corresponding to the interface they require.

Here's a hypothetical example that hopefully makes things a little clearer:

Suppose there is a monitoring service (MS) to report on and remediate issues with the health of services in the application. This might require each compliant service in the product to register an endpoint that exposes an API for the MS to periodically query the health of that service.

In this scenario, the MS would define an endpoint type "Service Health" associated with a published API standard. Each compliant service would register an endpoint referencing that endpoint type and implementing that standard. To survey the health of components in the application, the MS iterates through the services, looks up the "Service Health" endpoint for each service, and then queries that endpoint to retrieve the health status.

Here is a programming analogy:

• An endpoint type is like an "interface" defining a set of methods that can be invoked.
• An endpoint is an actual "object" that implements that interface.

Important Note: A service endpoint lets a service consumer know where to access the endpoint. However, the endpoint does not provide automatic service binding. The service consumer needs to know how to use the API provided by the service provider endpoint without any assistance from the component registry.

Viewing Services and Their Endpoints

All GET methods are available to any authenticated user. Below are some quick examples of common component-registry HTTP GET commands:

• View all service types: GET https://vcac-url/component-registry/services/types
• View all services: GET https://vcac-url/component-registry/services
• View all endpoints associated to a specific service: GET https://vcac-url/component-registry/services/{id}/endpoints
• View all endpoints: GET https://vcac-url/component-registry/endpoints
• View all endpoint types: GET https://vcac-url/component-registry/endpoints/types

Drill down into the documentation to find more information on how to query the component registry.

Registering New Services to the Component Registry

Most write operations in the component registry are only available to solution users (users registered to the SSO server). To register a new solution user to the SSO server, one must use the vRA SDK or the SSO API/SDK. A non-solution user can use the /component-registry/registration API to do this. Below are some quick examples of component registry HTTP commands that manage the component registry:

• Add/Register a new service as a solution user: POST https://vcac-url/component-registry/services
• Register a new solution user and a new service (performed as a non-solution user): POST https://vcac-url/component-registry/registration
• Unregister a service: DELETE https://vcac-url/component-registry/services/{id}
• Register endpoint: POST https://vcac-url/component-registry/endpoints

Drill down into the documentation to find more detailed information on how register services with the component registry.

Other Resources Provided by the Component Registry

The component registry also provides helpful REST resources such as ServiceStatus and LinkResolver.