Governance Service¶
A governance service is a specialized connector that implements a specific function.
There are ten types of governance services. Related governance services are packaged together in a specific type of governance engine and enabled in one or more Engine Host OMAG Servers. They run in the appropriate Open Metadata Engine Service (OMES) as shown in the table below.
| Governance Service | Description | Governance Engine type | Engine Service |
|---|---|---|---|
| Survey Action Service | Analyses the content of an Asset's real-world counterpart (digital resource) in the digital landscape. (For example, if the asset describes a file, the survey action service analyses the data stored in the file). Results of the analysis are stored in a Survey Report | Survey Action Engine | Survey Action OMES |
| Watchdog Governance Service | Monitors changes to open metadata elements and when certain changes occur (such as the creation of a new Asset) the watchdog service requests action from other governance services by creating Notifications that are passed to subscribers. | Watchdog Action Engine | Watchdog Action OMES |
| Verification Governance Service | Tests the properties of specific open metadata elements to ensure they are set up correctly or do not indicate a situation where governance activity is required. The results returned from the verification service can be used to trigger other governance services as part of a Governance Action Process. | Governance Action Engine | Governance Action OMES |
| Triage Governance Service | Makes decisions on how to handle a specific situation or incident. Often this involves a human decision maker. | Governance Action Engine | Governance Action OMES |
| Remediation Governance Service | Corrects errors in open metadata or the digital landscape it represents. | Governance Action Engine | Governance Action OMES |
| Provisioning Governance Service | Configuring, enabling, provisioning resources in the digital landscape. Often these provisioning services manage the cataloguing of new assets and the lineage between them. | Governance Action Engine | Governance Action OMES |
| General Governance Action Service | Some form of governance activity. | Governance Action Engine | Governance Action OMES |
| Context Event Service | Event management around Context Event. | Context Event Engine | Context Event OMES |
| Repository Governance Service | Performs governance for open metadata repositories such as dynamically maintaining open metadata archives. | Repository Governance Engine | Repository Governance OMES |
Inputs and Outputs¶
When a governance service is called, it is passed up to three types of input:
- The first is the request type that indicates the type of request to perform. Most governance services perform a single function and so ignore the requested type passed to it; however, if the governance service performs multiple functions, the request type is used to determine the function to perform.
- Next are the optional request parameters. These are named properties that can be used to configure the behaviour of the governance service.
- Finally, are the optional action targets which are named links to metadata elements that the governance service should process.
Then the governance service completes, it outputs:
- One or more guards that indicate the results of the processing.
- Optionally some additional request parameters and/or additional action targets that are passed on to any follow-on processing. For example, a governance service may create a new metadata element and nominate it as a new action target.
Handoff between governance services¶
This next picture shows two governance services that are steps in a governance action process flow. The governance services do not call one another directly. They operate in isolation just with the request type, request parameters and action targets they are passed. When a governance service complete, it supplies one or more guards and optionally, some additional request parameters. Egeria's open governance services reads the governance action process flow to determine the governance service to call next. This next governance service is passed the request type defined in the governance action process flow and the accumulated request parameters and action targets from earlier steps.
Governance service specification¶
The names of request parameters and action targets passed to a governance service must match the names expected by its implementation. In addition, if the governance service used the request type to determine which function to run, it is important to know the names of these request types in order to successfully call the governance service. It would be awkward to have to review the code of the governance service to find out the names of the request type, request parameters and actions targets to use. Similarly, when building a governance action process, it is necessary to understand the names of the guards that the governance service may produce and any additional request parameters and action targets.
To avoid users having to review its code, a governance service has a specification that defines the names used in its implementation. The specification defines lists of the following properties:
- Supported Request Types
- Supported Request Parameters
- Supported Action Targets
- Supported Templates
- Supported Configuration Properties
- Produced Guards
- Produced Request Parameters
- Produced Action Targets
The diagram maps these specification properties to the inputs and outputs of the governance service. In addition, because the governance service is a special type of connector it may also use configuration properties and templates.
The specification is typically implemented in the governance service's connector provider so that it can be read by automated processes that are consuming the connectors. For example, Egeria's build process reads the specifications of all of the governance services implemented in Egeria and creates open metadata elements for the specification that are linked to the metadata element for the governance service. These metadata elements are loaded via the content packs and can be reviewed and used through the Automated Curation API and Valid Metadata API.
Mapping and filtering¶
It is possible that the names used in the implementations of the governance services that are to be linked together in a governance action process flow are inconsistent. Therefore the governance action process flow may include maps and filters to allow the open governance services to map the names from one governance service to appropriate names for the next governance services. These maps and filters are specified in the GovernanceActionExecutor relationship.
Implementing your own governance services¶
Instructions for implementing your own governance services are in the developer guide under the following sections:
- Writing Governance Action Services
- Writing Survey Action Services
- Writing Watchdog Action Services
- Writing Repository Governance Services
Support for running governance services¶
A governance service can be called directly by creating an engine action. A governance action type can be used to "wrap" a call to a governance service. The governance action type identifies the request type and can pre-define certain request parameters and action targets to simplify the call to run the governance service. The governance service can be "wrapped" in a step in a governance action process.
The API to create governance action types and governance action processes (collectively referred to a governance actions) is called the Action Author API.
The API to initiate a call to a governance service, either through an engine action, governance action type or governance action process, is called the Automated Curation API.
Raise an issue or comment below