SOA Governance with WSO2 Governance Registry v3.0.0

Archived Content
This article is provided for historical perspective only, and may not reflect current conditions. Please refer to relevant product page for more up-to-date product information and resources.
  • By Ruwan Janapriya
  • 16 Jul, 2009

This article was first published on 06th August 2008. This is a republication with adaptations necessary for the WSO2 Governance Registry v3.0.0 release.

Table of Contents


In the modern day, information technology (IT) systems of the enterprise are continuously challenged with demands to serve ever changing requirements. In order to get more out of existing investments, rather than developing new applications to serve such demands, IT companies are moving towards the service-oriented paradigm. In the service oriented architecture, a service is a well-defined and self-contained function, one that would not depend on the context or state of other services. Developing services and deploying them using a Service-Oriented Architecture (SOA) is the best way to utilize existing IT systems to meet new challenges. SOA represents a new generation of distributed computing architecture.

According to the OASIS SOA Reference Model definition[1], "SOA is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations".

In simple terms, Service-oriented Architecture is a collection of services. Services in a SOA can communicate with each other. This communication could take the shape of either simple data processing, or, it could even involve two or more services coordinating some activity. The combination of services, both internal and external to an organization, makes up a service-oriented architecture.

SOA is mostly popular because it promises interoperability between heterogeneous applications and technologies with least hassle in application integration. A service's loose coupling to host applications gives it the ability to share data across enterprises more easily. Using SOA's increase reusability, overall costs could be minimized with increased response times to ITs change requests. This results in rapit evolvement of IT systems, for both old and new.

However, as the organization matures, they tend to face the following challenges with SOA:

  • Number of new services increases
  • Number of dependencies among services increases
  • Number of service users (both internal and external to the organization) increases
  • Users develop interest in different versions of the same service
  • Users sign up for different service level agreements, e.g. John's request will go through high performance servers, while Jennifer's requests go through regular servers.

If not properly handled, and organization's SOA could transform into a complex unmanageable mesh. To avoid this situation, an organization should (but not limited to) perform the following  throughout the entire lifecycle of services:

  • Properly manage services creation, adhering to rules laid down by an organization
  • Increase reuse of services, by "socializing" existing services
  • Properly analyze dependencies of a given service, before changing it
  • Provide service versioning and allow users to consume different versions of a given service
  • Properly validate services for standard compliance
  • Properly test services to assure quality of services
  • Document both technical and business aspects of services to help consumers and providers
  • Properly define who accesses what services
  • Measure service behavior at runtime. (e.g. How many times this service is called, by how many consumers, etc..)

In other words, SOA should properly "steer" its enterprise IT system. This process is called "SOA Governance". Governance is derived from the Latin term for steering.

SOA Governance

It is hard to find a concrete definition for SOA Governance, as the term heavily depends on a multitude of factors. People tend to define SOA Governance differently, such as:

SOA Governance is processes that an enterprise puts in place to ensure that things are done, in accordance with best practices, architectural principles, government regulations, laws, and other determining factors. SOA governance refers to the processes used to govern adoption and implementation of SOA. - Anne Thomas Manes, Burton Group.

Governance establishes the alignment in SOA. This involves understanding organizational business value drivers and business processes, aligning them to IT policies and establishing a process model to implement the alignment. - Nikhil Kumar, CXO Magazine.

SOA Governance is about having discipline and making sure that the very important decisions go through to appropriate people and that these people have the appropriate input to make those decisions. That is half of the SOA governance problem. The second half is whenever these decisions are made, SOA governance needs to make sure that those decisions are actually followed. It's not only about setting a speed limit, it is about enforcing it too and eventually giving people tickets or sending them to jail. That is what SOA governance really is about. - Paolo Malinverno, Gartner.

In simple terms, SOA governance is a set of processes, responsibilities and tools that reinforces good behavior and help avoid bad behaviors. It is all about control. If you design a service for a specific purpose and for a set of consumers, you will want to have assurance that it will only be used for that purpose and by that set of consumers. You also want the service to be available, performing as it was intended for, and secured. Transactions must have integrity, at least to the degree that you originally specified. Most Importantly, you need to make sure defined processes and responsibilities are followed properly. For this you need to adapt proper measurement techniques (to measure effectiveness on the actions taken) in your SOA.

SOA Governance can be divided to two distinct phases, namely design-time governance and run-time governance.

Design-time governance spans over the entire service development cycle. For example, lets say a requirement analyst is gathering information to create a new service. Design-time governance makes the analyst's job easier by providing all related information on the requirement. Furthermore, it avoids service duplication, providing enough information on existing services and promoting service reuse. Upon properly defining service level agreements, the service will be properly tested and documented.

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.

To enable governance, software industry responded with two different categories of tools, registries and repositories.

Registries and Repositories

A registry is a tool that keeps a list of services with their locations. On the other hand a repository functions as a tool that keeps information on how the services are used, how they interact, who is using the services and why they are used. These tools are considered as key enablers of SOA Governance. Usually these two technologies come together as an "Integrated" Registry-Repository, thus avoiding the need of duplicated data entry and the need to synchronize information. Additionally, it decreases the risk of inconsistencies that may exist between a registry and repository.

In a registry-repository, you can publish information on services that you already use, planning to use and those services that you need to be aware of. Information related to both internal and external services (to you/your organization) can be stored in this way.

Service reuse is the heart of SOA. Before implementing a new service, you can search in the registry-repository for existing implementations. This helps you to use an existing service either as it is or by developing a new service associating the existing service. Furthermore, registry-repositories help you discover associations among services. This helps you to get a better idea of any impacts on changing a particular service.

In SOA Governance, it is important to enforce organizational and domain specific business rules (policies) to validate artifacts before they are published on a registry-repository. Usually most of these policies can be described in (machine-readable) documents such as XML documents. Registry-repository can read such documents to interpret rules found in them to validate against artifacts as needed. Such validations can easily go beyond simple syntax validations. For example, there can be a policy enforced so that WSDL artifacts must only be using "Document/Literal" style for communication. Validation usually improves overall quality of artifacts stored in a registry-repository.

Typically, artifacts in a registry-repository undergoes lifecycle states of create, test, deploy and deprecate. A registry-repository should allow enforcing policies during transitions of these states. A registry-repository should define "who can access what?" of services. Access to certain services may differ depending on the user, user group or state of the service lifecycle. Also registry-repository can send notifications to relevant users once a change to a service artifact has been made.

As more and more services are introduces and reused, it is necessary to keep track of dependencies of each service in an organization. SOA registry-repository makes life easier by in this context, keeping inter-service dependency information as relationships among service information artifacts. For example, such relationships includes but not limited to Contains, Implements, Uses, Depends, etc.. A registry-repository should allow defining custom relationships to cater organization-specific requirements.

Service artifacts evolve over time due to reasons such as fulfilling new requirements, yielding to different versions of the same service. A registry-repository should provide versioning capabilities that can enable automatic version control of artifacts stored. Additionally, a registry-repository also should keep older versions of artifacts to allow users migrate smoothly from one version to another.

A SOA registry-repository also need to seamlessly integrate its services with those in other SOA deployments. In other words, a registry-repository should federate with other SOA registries-repositories using open standards, and possibly appear as a single virtual registry-repository.

To implement SOA Governance in service run-time, a SOA registry-repository should provide a software development toolkit (SDK) to develop custom registry client applications and services. In this case the registry-repository acts as a source of operational and configuration data during runtime.

In summary, a registry-repository should provide following features:

  • 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

WSO2 Governance Registry

WSO2 Governance registry is an open source SOA integrated registry-repository. It provides capability for storing and managing meta data related to service artifacts as well as artifacts themselves. There are two broad categories of artifacts found in the WSO2 Governance Registry, namely "resources" and "collections". A resource (an artifact) can be "anything" from  WSDL documents, XML documents, Word/Excel documents, JPEG Images, etc. Within the WSO2 Governance Registry, resources under a logical entity can be grouped into a 'collection' and stored.

Let's have a look at how the WSO2 Governance Registry addresses the following issues related to SOA governance:

  • How to publish and discover a service?
  • How to figure out dependencies and associations?
  • How to control user access?
  • How to manage service lifecycle?
  • How to extend the registry for custom use?

Publish Services

The WSO2 Governance Registry allows you to add services through its Web-based user interface. User can choose either to enter service details manully through metadata->add->service menu or to import service information through metadata->add->wsdl menu using a WSDL url.

Figure: Adding service information manually.

Figure: Importing service information from a WSDL.

Services added to WSO2 Governance Registry are listed under metadata->list->service menu.

Figure: Services in WSO2 Governance Registry.

It is also possible to validate a resource's compliance with standards such as WSDL, XSD and Web Services Interoperability (WS-I). Validation capabilities help improve the quality of resources. Validation tools are also an important aspect of policy enforcement, where you can enforce resources validation at specific points of a resource life cycle.


Figure: Registry can validate certain resources. In this case, validity of the WSDL and its complicance with WS-I standards.

Discover Services

The WSO2 Governance Registry offers configurations options such as tags, comments, properties, ratings and descriptions for a resource. It is important to plan the use of these configurations, to allow them help in discovering services and enabling correct SOA Governance.

Resrouces for service discovering tremendously helps in service reuse. In fact, it is one of the major funtions of a registry-repository product. The WSO2 Governance Registry provides enhanced search capabilities to facilitate search based on tags and other advanced criteria.

Figure: Advanced search options in WSO2 Governance Registry

Dependencies and Associations

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.

Figure: Dependencies and Associations

Access Control

The WSO2 Governance Registry offers user authentication and authorization capabilities over all resources stored in the Registry. Easily configurable role based user management allows define, "who can accessing what?" within the Registry. Furthermore, the Registry provides activity logs that shows user activities over resources. You can apply filters on top of activity logs to extract customized data to suite your information needs.

Figure: Permissions

Lifecycle Management

Typically many resources in your Registry, such as service descriptions, should progress through a series of "lifecycle stages". For instance, a service may start off as "created", then after quality assurance has confirmed that the service works as expected should be moved to "tested" stage. Upon testing, the service can then move to a "deployed" stage at which point it is released to production. Eventually the service will be taken down or replaced with another as it moves to a "deprecated" state. Furthermore, registry allows users to define a checklist for stage transitions.

The WSO2 Governance Registry makes using and managing state-based lifecycle easy. Out of the box, the Registry comes with a default lifecycle that implements the state transitions explained earlier. You can define your own custom lifecycles with conditional state transitions, inorder to match you/your organization's very specific requirements.

Figure: Promote/Demote the lifecycle state of a resource.


The Dashboard in WSO2 Governance Registry offers a "Bird's Eye" view of both run-time and design-time aspects in a SOA enabled organization. In this way the organization could measure and monitor these aspects, which is really important in SOA Governance. Users can either use the default "gadgets" or develop their own gadgets depending on the requirement. Following is the list of default gadgets shipped with WSO2 Governance Registry.

  • Life Cycle Stage Monitor - shows a pie chart, number of services per each life-cycle stage.
  • Messages Received in Last Minute
  • Calls for the Last 24hrs
  • Average Processing Time/Trans (ms)
  • Min Max Average Response Times
  • User Logins and Failed Attempts
  • Failed Login Attempts by User

Figure: WSO2 Governance Registry dashboard.


The WSO2 Governance Registry provides three extension points that provide a flexible, plug-in approach to link resources and to allow users to encode their own governance rules and policies. These include:

  • "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 (e.g. by clicking a button in the user interface)

Additionally, with the enhanced WSO2 Governance Registry API, you can embed the Registry in a runtime system (e.g. in Enterprise Service Bus) and support automated run-time governance.

For additional details on the WSO2 Governance Registry product, please refer the Registry documentation and engage with the active developer/user community on WSO2 Oxygen Tank. [4][5][6]


This article discussed SOA and the need for SOA Governance. Furthermore it also discussed how you can implement a SOA Governance in your organization using the following features of WSO2 Governance Registry,

  • Publish and discover services
  • Define dependencies and associations among services
  • Manage user access control to services
  • Service lifecycle management
  • Extensibility features to define, customize and manage behaviors
  • Automated run-time governance through embedding


Ruwan Janapriya, Technical Lead, WSO2 Inc. janapriya at wso2 dot com


[3] Business Optimization Through SOA, The role of governance in unlocking SOA business value. By: Hugh Taylor
[4] WSO2 Governance Registry:
[5] Mailing Lists, WSO2 Governance Registry:
[6] Community Forum, WSO2 Governance Registry:

About Author

  • Ruwan Janapriya
  • Tech Lead
  • WSO2 Inc.