The following governance concepts are described below.
...
Runtime governance comes into play, soon after the service is deployed. It monitors operational aspects of a service (service performance bottle necks, who is accessing more, etc.). Unlike design-time governance, most runtime governance functions are automated. Reports generated in this phase are important feedback, for the next service design and development iteration.
For more information on SOA Governance, see Registry Life-cycles and Forrester's Major SOA Requirements.
...
Registries and Repositories
...
- Record information on services
- Search for an existing service for reuse
- Discover associations and dependencies of a service
- Enforce policies throughout the service lifecycle
- User access control
- Automatic version control
- An SDK for registry-repository extensibility
Governance Registry components
WSO2 Governance Registry provides three main Web based user interfaces to facilitate the features and functionality as follows. For information on accessing these Web interfaces and on the usage of them, see Running the Product and Architecture.
G-Reg Publisher
The G-Reg Publisher provides an end-user, collaborative Web interface as shown below, for governance artifacts providers to publish artifacts, manage them, show their dependencies, and gather feedback on quality and usage of them.
G-Reg Store
The G-Reg Store provides an end-user, collaborative Web interface as shown below, for consumers to self-register, discover governance artifact functionality, subscribe to artifacts, evaluate them and interact with artifact publishers.
Management Console
...
...
Assets
WSO2 Governance Registry stores governance metadata and information on governance related entities. Registry resources storing this information and/or metadata are known as assets. With Service metadata, you can import most of the information which is separately stored in the WEB in to the Governance Registry, and manage them as Governance Registry Resources.
In WSO2 G-Reg, you can add common Service information through standard Service metadata formats like WSDL (Web Services Description Language) files, Policy files and schema files. You have to give the location of your WSDL, Policy or Schema file from local file system or as a URL. Governance Registry imports those information in to the Registry as resources. All the special resources will have their own Media Type, which will be useful for you to handle them conveniently.
All service assets are stored in the governance directory, based on the metadata type you import. For an example:
- WSDLs are stored in
/_system/governance/wsdls/directory. - Policies are stored in
/_system/governance/policies/directory. - Schemas are stored in
/governance/schemas/directory.
WSO2 Governance Registry facilitates two types of assets: in-built and custom. For more information on these assets, see Adding AssetsAsset is a representation of any physical or digital entity that belong to an organization, which needs to be governed. In WSO2 Governance Registry, a set of predefined attributes compose an asset.
WSO2 Governance Registry provides an XML-based semantic structure called RXT (Registry Extension Types), to define the structure of a given asset type. There are two RXT categories as follows:
- Content RXTs : These are used to represent and maintain assets that have file content as their main attribute. (E.g. WSDLs, WADLs, Swagger files etc.).
- Generic RXTs: These are used to represent assets that are a combination of different types of attributes. (E.g. representation of SOAP services, REST APIs, Project, Enterprise Applications etc.)
WSO2 Governance Registry provides out of the box access to WSDL, WADL, Swagger, WS-Policy and XSD Schema Content RXTs, and SOAP service, REST service Generic RXTs, via WOS2 G-Reg Publisher. Also, you can define your own RXTs as required, and make them available for operations facilitated by the WSO2 G-Reg Publisher and Store interfaces.
For more information on these assets, see Adding Assets.
...
Resources and Collections
In the Registry level, an asset is transformed into one or more Resources, to store it in the configured database. Resource is a concept defined in the Registry.
Resources and Collections (analogous to files and folders on a file-system), are stored in the Repository of WSO2 Governance Registry. A Collection is modeled as a special type of Resource, inside which, you can represent other Resources and Collections. The Resources-layer of the WSO2 Governance Registry provides functionalities such as conducting validations on the storing process, storing associations among Resources, and catering management of the properties of Resources. Resource validations are done through Registry Handlers associated with a particular Resource media type. For more information on this, see Handler Sample and Managing Properties.
...
Categorizing assets
There are two broad categories of artifacts found in the WSO2 Governance Registry as follows.
...
The Registry supports configuring of dependencies and associations for resources. It automatically detects certain dependencies when you publish a resource. For example, a WSDL might use an external XSD that can be automatically detected and imported to the Registry. In addition to dependencies, the Registry provide a way to configure associations among resources. You are free to specify the type of association such as "contains" or "uses" during association configuration. These associations help figure out the possible relationships that may exist among resources and also in analyzing the impact on changing a resource. See also Managing Dependencies and Associations.
...
API management
Subscriptions management
Notifications
Monitoring
...
Services (SOAP or REST) in WSO2 G-Reg are implemented as configurable governance artifacts (RXT files), which you create using the G-Reg Publisher. Usually, in WSO2 APIM service publication is done using the APIM Publisher Web interface. Instead, you can integrate WSO2 APIM with WSO2 G-Reg, to directly publish APIs to APIM Publisher using the services deployed in the WSO2 Governance Registry. For more information on API management, see Integrating with an External WSO2 API Manager.
...
Subscriptions and notifications
The notifications feature can be used to generate notifications for events that occur as a result of performing operations. To receive notifications, create a subscription to a particular event along with a specified notification method (e-mail alert or G-Reg Publisher/Store notification). For more information on subscriptions and notifications, see Adding Subscription Notifications in Publisher and Store.
...
Extensibility
The WSO2 Governance Registry provides three extension points that provide a flexible, plug-in approach to link resources and to allow users you to encode their your own governance rules and policies. These include:
- "Handlers" - To Handlers: To implement custom behaviors to be applied to resources.
- "Filters": - To intercept standard behaviors to make room for custom behaviors; Filters determine which Handlers are to be engaged on a resource.
- "Aspects": - To associate custom behaviors with resources; Aspects differ form handlers, in that handlers are automatically applied to a resource, whereas, aspects are needed to be invoked manually through user action (for example, by clicking a button in the user interface).
There are the three key Registry features that exist at the top of the Repository. You can use these to provide your own customization on top of the base product. Handlers are plug-able components that contain the custom processing logic for handling resources. Handler implementations provide alternative behavior for basic resource-related operations, by overwriting one or more methods in the Handler class.
Each Handler is associated with a Filter. Filters provide the criteria to engage with Handlers. The WSO2 Governance Registry always evaluates the associated Filter before invoking a Handler. If the Filter evaluates to true, it invokes its associated Handler.
Similar to Handlers, Aspects are used to associate custom behaviors with Resources. The difference between Aspects and Handlers is that, you automatically apply Handlers to a resource, whereas, you need to invoke Aspects manually through a user action (e.g. by clicking a button on the UI).
Additionally, with the enhanced WSO2 Governance Registry API, you can embed the Registry in a runtime system (for example, in e.g. in the Enterprise Service Bus), and support automated run-time governance. See For more information, see also Extensions.