Table of contents 

• Introduction
• Design time governance
• WSO2 Governance Registry
  • Store and govern artifacts
  • Governance workflows
  • Notifications
  • Authentication and audit features
• Conclusion
• References

Applies to 

1. Introduction

Defining, tracking, and managing SLAs and policies are important in SOA governance. It effectively manages the service lifecycle by governing key processes across the entire lifecycle. Key pieces of a governance solution are dependency management among services/resources, versioning, lifecycle management, and security. The main components in SOA governance are registries, repositories, contracts, and policy management.

A service registry is one of the fundamental pieces for achieving re-use of services. It refers to a place in which service providers can store service metadata and users can discover services. The repository provides storage facility to store governance-related policy records and process details. Most often both registry and repository features are offered as a single governance registry-repository tool.

Contracts and policies are a set of behavioral rules intended to ensure that services remain consistent and do not have any conflicts with each other. Policies also ensure good engineering and architectural practices while designing the service and also at runtime to make sure certain constraints are followed by relevant parties.

Governance is applied in a top-down approach at the service development, deployment, and running stages in SOA architecture. It can be mainly categorized as design and run-time governance to differentiate the aspects of the SOA governance.

2. Design time governance

In the big SOA era (before Jan 1, 2009), design-time governance was king. It fit nicely into the plan-manage-control discipline, underpinning a large enterprise-scale SOA effort. And to support this, tool vendors rushed in and offered applications to facilitate the process. - Scott Morrison

Design time governance can be considered in two stages which are;

• At service development
• At service deployment

At the service development stage, we consider the architect of the service in terms of service interfaces, stability, usages, and the testing, QA procedures. During the deployment stage, considerable facts include how to manage services, how to effectively start and stop services, and maintaining service versioning.

There are certain set of tools to provide various governance features. There are registry-repository tools, policy enforcement, validation tools and so on. Platform vendors offer one tool that has multiple feature support to give better governance for the SOA architecture.

3. WSO2 Governance Registry

The WSO2 Governance Registry provides SOA governance features, including configuration governance, development process governance, design and run-time governance, lifecycle management, and team collaboration. Let's look at the design time governance features and how users can make use of them at the design stage of services.

3.1 Store and govern artifacts

Governance solutions' key feature is the registry repository tool . It is one of the fundamental pieces of SOA to achieve re-use of artifacts and resources of services. Registry feature is further enriched by;

• Dependency management.
• Versioning of resources
• Resource history management.
• Lifecycle management.
• Enforcing policies with service lifecycle.
• Managing community features

3.1.1 Dependency management

G-Reg provides rich tool for dependency management. Information about dependencies helps architects to analyze the impact of binding new consumers to services. This is critical for maintaining service SLAs. G-Reg allows users to add dependencies and associations for a resource and collection. Associations, that have type information, can be created from any resource in the registry pointing to another resource. In general, we use an association if one resource contains another resource in the form of an attribute/property/field.

Dependency typically means that a resource is using another resource, or accepts another resource as a parameter. For example, if a WSDL resource uses a schema resource, there is a dependency for WSDL resource, in terms of a schema resource. But for a schema resource, there is no dependency on the WSDL resource, rather it has an association with the WSDL resource, because WSDL uses the schema. A dependency is implied by an association.

G-Reg stores resources in a structured way, and provides the facility to organize the resources as collections in the available major three registry storage partitions. These three partitions give meaning to the data stored on a particular partition. For instance, if we take how linux filesystem works, there are many types of file systems and media available, each of this control how information is stored and retrieved. These different medias hide the underlying complexity behinds on storing and retrieval of data. Likewise, in G-Reg local, configuration and governance registry spaces are available. Each partition is used for different purposes and expected to be used in a proper manner when storing data.

Local registry is used to store data, which belongs to that particular instance. For instance, if a G-Reg instance uses a property file locally to that G-Reg instance, which can be stored in a local registry space. It is not recommended to share the local registry with other instances. Configuration registry can be used to store configuration data, which are used locally or shared with other instances. For example, if the user has custom CSS files related to UI theming of the enterprise, which can be stored in the configuration registry space. If there are multiple servers running, the same UI theming is applicable for all running instances; so, we can share the configuration registry with other instances to use the same CSS files. Governance registry is used to store resources, which has a means of governance, for example service resources such as WSDL, schema resources. In a clustered environment, it is mandatory to share governance space among all instances, since at runtime, system access governance registry for any required information is stored in the governance registry. The user has to decide what right registry space to use when storing a resource, based on the usage of that resource.

3.1.2 Versioning of resources

Changes in a service implementation is common in real-world practice. The aim would be to improve the reuse of service and to do feature enhancements for existing services. When there are different versions of the same resource, those different versions of the resource will be stored in different paths.

Different versioning strategies address different requirements. The user can enable auto versioning for a resource or he could add his preferred version for a resource. A backward-compatible version refers to the ability to support consumers of older versions of a service.

3.1.3 Resource history management

History of resource is an interesting source of information, which provides all activities that are made on that particular resource; when and where information. G-Reg provides access logs for resource history. The user can generate reports about the resource history in pdf/excel/html format.

3.1.4 Lifecycle management

Lifecycle management focuses on the development and deployment of services that go through different phases, which are the lifecycle states of a service. Lifecycle helps to build and use the right service in a right way. It enforces organizational policies, responsibilities, tools and tasks when developing services. It improves the manageability of service throughout its lifetime. The figure below explains how a development process takes place.

For example, a tour service providing organization is willing to host an online booking service. Initially, the organization comes with an idea, about how they are going to provide that service, the facilities they would like to provide to an online user, and defining ownership for that project. If the initial idea is approved by authorized people, the idea will be taken to the next stage, which is a design phase. Here, design architects will create, enhance, and explain the standards and policies involved in a tour system. Once this is finalized, it can be taken to the development state to develop the online services. If the developer's job is done, service will be promoted to the testing stage, where organization will do initial tests and do a pilot experiment to identify further issues. If there is no any issues found, it will be deployed and allowed to be used. In each stage, the organization has its certain policies to be followed and certain responsible people have to approve each and every stage when it is successfully completed. If there is any violation at any stage, the service can be demoted in order to satisfy defined rules and policies. For example, at the pilot experiment stage, if the online system has messed up the booking information of users, there might be an issue at the development stage. So, the service can be demoted to the development stage to check the logic of the service implementation.

The default lifecycle support available in G-Reg allows user to promote or demote a resource, based on various checklist items. Users can add custom lifecycle states based on their service development requirements and policies. Lifecycle history of a resource will be stored into registry for future analysis.

Customizing the lifecycle

• Adding checklists: Allows the user to add more control checks in each stage of the lifecycle. Users can add role-based permissions and validations for each checklists. For example, at the "Idea" stage of the online tour system, the organization can insist on submitting a budget proposal and can identify profit rates. These initial conditions can be made as checklist items at the "Idea" stage to be satisfied before the project goes to the design stage. Sample checklist configuration;

• Transition validators: Allows user to validate checklist states. We can define validators for check lists and states. For example, before promoting the Tour service to the "Development" stage, authorised people have to check and approve the budget proposal.
• Transition permission: Allows user to add role-based permissions. We can define permissions for checklists and states. For example, before promoting the Tour service to the "Development" stage, "Idea" owner needs permission from authorized person who belongs to the "Finance" role.
• Transition approval: Allows user to vote for approval to do state transition. For example, before promoting the Tour service to the "Development" stage, need 5 votes from people who belong to the "Finance" role.

3.1.5 Enforcing policies with service lifecycle

Users can define custom checklist items as explained above to govern and manage the lifecycle processes. At each stage, architects might want to enforce some rules, constraints to make the design better. G-Reg provides the following options to enforce policies at design time;

• Lifecycle state transition constraints and approval policies can be defined as mentioned in 3.1.4. Define suitable roles and configuration parameters to do the task.
• Integrate business process orchestration or human-task workflow to get approval when state transition happens.
• Define automatic/predefined policy enforcements. This can be achieved by Transition Validators

3.1.6 Managing community features

Public participation may be regarded as a way of empowering governance of a service and it has become to be seen as a vital part of addressing issues at design and runtime and bringing about sustainable development and improvements in service lifecyles.
As you start to enforce governance policies and rules, how does the community respond and how do you dynamically monitor their behavior, because this transitional period is the one of greatest risk. I call this the "danger zone"- Miko Matsumura
An organization connects design time governance to the community that it wants to enforce principles and services and actively drives forward better design outcomes.  This is a more participatory approach, which stress that community participation is a crucial element in governance that contributes to better decision making. Some specific decisions cannot be made by a few people because of the nature of the decision and the organization depends on more input from different background people.

Rating, tagging and commenting are supported in G-Reg. Comments and rates can be used to provide feedback about the design and features of the service. These type community features allow non-technical people to participate in the design of the system to provide their feedbacks on various aspects. Tags can be used for easy search and for categorizing the resources based on their nature.

3.2 Governance workflows

Developers can create governance workflows that enable complex life cycle during run and design time of service artifacts. Moreover, users can govern workflows with a set of governance features such as policies, throttling, so on. Different artifact types require different governance workflows, so where a resource state change may follow a different cycle, a service update may requires a different type handling.
For instance, if a workflow is defined for a bank, which is being governed by a set of organizational security policies and contain a number of services binded together to make decisions. When a customer makes a loan request to the bank, after validating security policies, BPEL process can call the loan service, which is deployed with some governance facts and at runtime loan service gets approval from a human. Before making a final decision at loan service, it can send an  approval request to a human workflow and get back the final decision from the authorized person.

One of the important feature at design time governance is the ability to trigger workflows based on changes detected in the registry. G-Reg supports workflow integration in lifecycles. The user can define a workflow configuration in the lifecycle to trigger an external workflow whenever state transition occurs. Workflow trigger support can be achieved using web service executors that allows the user to call remote web services, which needs to be invoked during lifecycle state transitions. The user can use ws- executors to invoke any web service that is exposed through a WSDL and the response can be saved to a user-defined location. We can use this executor to call BPEL workflow and human tasks to get direct human interaction in a state change.

Creating and deploying workflow configuration

If you have an already running BPEL process, it is a simple executor configuration to be added in your lifecycle configuration to call the running BPEL process instance. Ws-executor can be used to execute both synchronous/asynchronous bpel processes. Detail ws-executor configuration parameters are listed here.

After creating the custom lifecycle with all relevant parameters, save it using the management console and engage it to a resource where you need to manage the state transitions of a resource.

3.3 Notification support

Users can generate notifications whenever there is an update for a resource or when the user tries to delete a resources. Also, it generates notifications for lifecycle's state change. Notifications are sent to configured users in a timely manner. There are different types of notification mechanisms supported.

• REST notification: To send notifications for a REST endpoint.
• SOAP notification: Same like REST endpoint, if user wants to send to SOAP service endpoint.
• Email notification: To send notification for a configured email. This can be useful, where if we want to send notification for an external user who is not in the organization's user base. E.g. If budget proposal is approved by the organization, notification can be sent to board members who are not in the enterprise's user management system.
• User profile notification: To send notifications for a specific user who is a registered user with the system. This would be suitable if we want to notify admin in case of any major changes.
• Role profile notification: To send notification to a group of people by email. E.g. If a service is ready for QA, all people assigned to the QA role will get notifications.
• Management console notification: To get notifications when the user logs in to the system. He/she will be able to view notifications at the "Notification" tab.
• JMX notification: To get notification via a JMX subscription.

3.4 Authentication and audit features

Most modern infrastructure platforms provide simple message auditing mechanisms, for example, by writing messages to a log file or in a proprietary database. User authentication and audit features provide security and enforce governance policies on when, what, and by whom services can be changed.

Role-based permissions can be applied to each resource and collections to restrict the access and actions on a particular resource. Auditing and logging features are available in G-Reg in order to get the entire historical information about resources. The history can be obtained in pdf/html reports as well.

Conclusion

To improve service re-use at an enterprise level, architects must define a strategy for developing, publishing, and providing facilities for services information. To this end, an SOA governance registry is a key tool that should be used. Information about resources and services can be stored at the registry by applying proper security mechanisms. Moreover, you can apply policies to ensure certain conditions are met at development, deployment, and at run time stages. As explained above, users can manage design time governance using WSO2 G-Reg and its key features can be used at design time to ensure better engineering principles are followed when developing services.

References

https://wso2.com/library/articles/soa-governance-wso2-registry-v1-1/
https://docs.wso2.org/display/Governance460
https://blog.cobia.net/cobiacomm/2013/04/09/policy-management-for-apis-services-and-apps/
https://msdn.microsoft.com/en-us/architecture/aa699419.aspx
https://www.ebizq.net/blogs/enterprise/2010/01/the_new_vision_for_soa_governan.php