Runtime Governance with WSO2 Governance Registry
- Waruna Jayaweera
- Senior Software Engineer - WSO2
Table of contents
- Introduction
- WSO2 Governance Registry
- User scenario
- Service runtime governance
- Service discovery with WS-Discovery
- Monitoring with BAM
- Policy enforcement with CEP
- Extensions
- Server runtime governance
- Conclusion
Introduction
Service Oriented Architecture (SOA) plays a significant role in modern IT systems given its ability to meet a greater demand of continuously changing business requirements. SOA can be simply explained as a collection of well-defined and self-contained functions called services. SOA systems should have proper control of service design and development to deliver value to their consumers.
When the services of a company grow, its needs and user base will increase accordingly. Therefore, the organization’s services and metadata will be revised several times during its execution. From time to time, the organization will bring in new policies over running components. Nowadays, runtime has also become a critical controlling area of SOA.
Governance provides proper control of the services and governance artifacts in SOA from service design to execution time. It can be divided into two phases called design-time governance and run-time governance. Design-time governance comes into play with the development cycle of the service artifacts, which is applied in the service registry, life cycle management, and policy management.
This article explains the concept of runtime governance in SOA, the importance of maintaining quality of services and metadata at execution time and how WSO2 Governance Registry can help meet these requirements.
WSO2 Governance Registry
WSO2 Governance Registry is an open-source, SOA integrated registry-repository that stores and manages meta data related to service artifacts. WSO2 Governance Registry mainly focuses on addressing development time governance and is composed with a set of features to perform runtime governance. It also includes business runtime governance requirements through its interoperability with well-known external monitoring and reporting applications.
User scenario
XYZ Computers is a retail company that deals with computer accessories. They offer their customers an online platform to buy different brands of computer-related products. Further, their customers are able to purchase computer accessories, like laptops and personal computers, by making online payments.
The company operates from the USA with sales branches in Europe and Asia. It has around 200 employees and its business model mainly targets on percentage value of each successful transaction.
One approach of XYZ Computers is business to consumer marketing that depends on a productive set of user services. For example, their “Computer4Budget” service provides users the ability to order a personal computer based on the customer’s budget and other needs. They are able to specify the brand, memory, and hard drive capacity. Their online portal combines with many more services like providing IT-related news, repair, support, search, and various download device driver software versions, etc. Their middleware system is incorporated with user-based services as well as services of suppliers and employees.
Moreover, XYZ Computers has a dedicated IT division that is responsible for developing new software services and maintenance of their systems. Currently, all their services are deployed on a cluster of application servers. XYZ Computers has also attempted to enhance their IT services by introducing new services as well as expand their development team.
With their long-term strategy of expanding their user base and assessing current system software, the development division required an SOA governance application. Consequently, the company’s developers mainly focus on proper runtime governance as their service usage and new service development has increased significantly.
Now, let’s examine how they can use WSO2 Governance Registry’s runtime governance features to address their demands.
The runtime governance can be classified into the following two stages:
- Service runtime governance
- Server runtime governance
Service runtime governance
Service is the core of SOA environments. Services and metadata will be deployed, updated, and removed from time to time. Different users will access those services concurrently. An organization needs to apply policies on running components without influencing consumers. Therefore, runtime governance of services and metadata is an important aspect of SOA governance.
Service discovery with WS-Discovery
XYZ Computers had an initial requirement of proper discovery on current services in their application servers. Deploying all their services in the new registry was not a good solution as it is a highly time-consuming and costly task.
WSO2 Governance Registry is able to operate as a WS-Discovery proxy and store discovered services and associated metadata. Any WS-Discovery compliant web services server, such as Axis2, is able to use WSO2 Governance Registry as a WS-Discovery proxy, which would discover any deployed service and store in the registry. For example, WSO2 Governance Registry can discover services published in application servers. Adding tags and searching based on keywords also facilitate the runtime service discovery.
Figure 1 shows the service list that can be listed with WSO2 Governance Registry.
Figure 1: WSO2 Governance Registry service list
Monitoring with WSO2 Business Activity Monitor (BAM)
Knowing which users use each service is a cumbersome task faced by organizations in SOA governance. For example, XYZ Computers’ user base consists of a variety of users, such as customers, suppliers, and employees. Further, they should recognize which clients have been allowed to use their services, and in reality, how their clients utilized the services. Similarly, the organizations should also track any unauthorized users and block access to those services. Companies cannot apply their crucial business, security, and IT policies without a proper understanding of their consumers. The runtime governance tool should address all these issues referred to in service usage.
WSO2 Governance Registry can be integrated with WSO2 BAM to monitor service-level statistics. It can be configured to generate events for each significant registry operation. These events will collect statistics of operation invocations using a registry extension point called statistical collector. The Java plugin program will contain the data streams of attributes that need to be monitored.
In the above service usage scenario, you can obtain the service name, user and operation as attributes of data streams to an event. Later events will publish the data to the external monitoring tool.
WSO2 Governance Registry supports and publishes event data to WSO2 BAM, which is used to monitor SOA business activities with KPIs, like service name and user in our scenario. A WSO2 BAM toolbox is an installable archive that contains stream definitions of KPI, dashboard components, and analytics for WSO2 BAM.
Figure 2 provides a screenshot of statistics shown in WSO2 BAM based on registry operations.
Figure 2: WSO2 BAM statistics with governance registry operations
Policy enforcement with WSO2 Complex Event Processor (CEP)
Business processes are controlled using business policies and rules to achieve company goals. These policies or rules will be applied on service metadata as managing formats and contents, consumers as controlling access to services, and many more business components. These policies change regardless of development, deployment and maintenance of business processes. Therefore, the runtime governance tool should have the capability to enforce business policies at execution time. WSO2 CEP is a middleware tool that processes large number of events, analyzes their impacts, and acts on them in real time to apply that policy on runtime.
WSO2 Governance Registry can be integrated with WSO2 CEP to find out predefined patterns on generated events by deployed servers, and perform task based on events pattern. For example, XYZ Computers discovered that a large number of consumers will call the “Computer4Budget” service mainly based on their testing purposes. The company has decided to apply an automated policy on consumer usage on that particular service.
For runtime policy enforcement, we need statistics on services and policies. Statistics about services are actually published by service hosting products like ESB, AS, etc. WSO2 Governance Registry can define the service-level agreements (SLAs). These are forwarded to WSO2 BAM or WSO2 CEP. Thereafter, the SLA/Rule definition in governance registry and the statistics collected will be evaluated in combination. Figure 3 illustrates the applying throttling policy on service usage in the CEP scenario.
Figure 3: Applying throttling policy on service usage with CEP
The process can be implemented using the following steps:
- Application server that contains the “Computer4Budget” service will publish events to WSO2 CEP when users call the API service
- WSO2 CEP will evaluate both rule definition in governance registry and the statistics collected by WSO2 CEP and fire events to apply any throttling policies
Extensions
WSO2 Governance Registry supports many extension points on registry and repository operations to provide better runtime governance, with user defining, and monitoring approaches, and applying customized policies, etc. These extension points are important in some business cases where we need to combine both development time and runtime governance. They can be written as java classes and deployed into WSO2 Governance Registry as separate jar files. WSO2 Governance Registry provides extension points that provide a flexible, plug-in approach to link resources and to allow users to encode their own governance rules and policies.
Some extensions are as follows:
- Handlers are used to implement custom behaviors that apply on resources.
- Filters are used to decide and select what handlers should apply on resource type.
- Aspects are somewhat equal to handlers that are used to implement custom behaviors with resources. Handlers are automatically applied, but aspects are applied through user action.
Server runtime governance
Governance of services will not be adequate when dealing with some cases. For example, when a service malfunction occurs, XYZ Computers’ developers are required to analyze deep into the message level of service and metadata used for error detection and handling. Therefore, maintenance engineers should keep an eye on system processing, and memory like performance attribute to avoid a sudden breakdown of the system.
WSO2 Governance Registry provides a mix of statistical information on operating processes through system statistics. Detailed data on statistics can be keyed out using a variety of options, like service summary, server information, response time graph, memory graph, and statistics configuration system.
The application logs provide the log files generated by deployed services or web apps. These logs can be summarized and viewed completely, and also can be filtered according to deployed services and the type of the log message. Log files of the current product can be retrieved using system logs. Users can download and view the log files according to the their preference.
The application logs provide the log files generated by deployed services or web apps. These logs can be summarized and viewed completely, and also can be filtered according to deployed services and the type of the log message. Log files of the current product can be retrieved using system logs. Users can download and view the log files according to the their preference. Further, WSO2 Governance Registry can be configured to obtain log files either from remote locations or local file system. WSO2 Governance Registry is developed on WSO2 Carbon. Remote JMX clients like JConsole can be configured with registry to monitoring. WSO2 Governance Registry releases prior to 4.6.0 came up with a rich set of gadgets to offer better runtime governance. Users can also develop their own gadgets and add them to the dashboard based on customized requirements. From WSO2 Governance Registry 4.6.0 onwards, a more user-friendly and attractive dashboard will be integrated with WSO2 User Engagement Server features.
Conclusion
In this day and age, business requirements change in a rapid manner. Therefore, a significant number of services in enterprises will be initiated, while ongoing services will be modified. New policies will be applied on running services. All these changes have to be controlled during service execution, so-called runtime. Hence, SOA runtime governance will be applied with service discovery, monitoring, runtime policy enforcement, and with many runtime operations. WSO2 Governance Registry provides a comprehensive set of features to perform SOA runtime governance and effectively meet these enterprises’ emerging challenges.