Curated on 08th March 2012.
This article is obsolete. WSO2 Registry now called as WSO2 Governance Registry.
A "service" is the basic building block of Service Oriented Architecture (SOA). A service is a self-contained software module that performs a pre-determined task, such as "ATM Service". SOA provided numerous advantages compared to earlier architectures. For example, SOA solves the integration problem, adapts for changing technologies, leverages existing investments in legacy applications and eases the creation of a business process from exsiting services. However, SOA could still end up in failure, if not steered properly. The steering process is known as "SOA Governance".
To enable SOA governance, software industry responded with two different categories of tools, 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 data duplication.
As mentioned in, following are a list of Registry and Repository features assisting SOA Governance.
- 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 Registry is an open source, feature rich and extensible, integrated registry and repository. This article discusses more about "how to" record information on services in WSO2 Registry.
Record Information on Services
It is important to understand that recording a service information in registry-repository can be done in many ways. Most of the registry-repositories available in the industry adapt completely different ways. On the other hand, even in the same registry-repository one can record information on services differently. Service information recorded on registry-repository, could further divide in to three categories.
- General Information
- Functional Information
- Organizational Information
It is important to record a detailed service description in the registry-repository targeting not only developers or architects but also business analysts. In addition to the general service information, it is essential to record provider information along with the service. An existing user or a potential new user can contact the provider of the service for further clarification. Typically provider information includes provider name, email address, telephone number(s) and avatar/photo.
Services undergo constant change. These change notifications to users can help them perform impact analysis of a service, in order to make accurate early decisions.
To provide the functional details of a service, an organization could use a WSDL document. WSDL stands for Web Services Description (or "Definition" for Version 1.0) Language. Following is an extraction taken from WSDL 1.1 specification. 
"WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings described in this document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME."
In simple terms, the WSDL document is a XML document that defines everything from the protocol to service parameters.
In addition to service configuration details, a service should contain dependency information. In other words, it is important to "know" how services relate to each other. Dependency information helps an organization perform impact analysis on a service before performing any changes on that service.
One of the most important features of a registry-repository is the facility to discover resources (in our case, services). Service discovery promotes service re-use. Business Taxonomy is a custom categorization scheme for classifying services. Once a service is stored in the registry, tagging with business taxonomy helps users find it much easier by narrowing down search results.
According to the OASIS SOA reference model, policy is a representation of some constraint or condition on the use, deployment or description of an owned entity as defined by any participant.
In essence, a policy is a rule that describes accurate behavior. Policies can be categorized into two areas: Design time policies and Run time policies. Design time policies defines the behavior of a service during design time while the other defines the behavior during run time. For example, a given service might be required to provide WS-Security to secure its business transactions. So the organization could enforce a design time security policy on business transaction related services. Now, there could be another policy, where a set of privileged users should be served using faster servers. So the organization now enforces a run-time policy to enforce the use of the servers depending on the user category. The registry-repository records service associated policies, organization enforced policies on a given service.
Using WSO2 Registry to Record Information on Services
The WSO2 Registry is an integrated registry-repository. Users may use the registry to store services information in many ways. Let's discuss on using a WSDL file as the primary resource to represent a service in the registry.
By defualt the following advantages are apparent, since these are true for any resource stored in the WSO2 Registry.
- Automatic service versioning
- Availability of different versions of the same service, using permlink feature.
- User access control
Let's discuss a service "LibraryService" implemented in a university. LibraryService depends on the following services.
- ManagePaymentsService - To manage fines and other payments
- ManageUsersService - To manage users and user authentication
- SearchCatalogService - To search library items.
The LibraryService provides following operations:
Since operations payFine and authenticateUser should be secured, FinePayPolicy and AuthenticationPolicy are enforced.
Now, let's see how these information can be recorded in the Registry according to our WSDL based model.
LibraryService in The WSO2 Registry..
This screen shot from the WSO2 Registry shows, how the library service is represented on the user interface. As you can see in this screen shot, there are many aspects that are associated with a service. The following sections would describe all those aspects and how they relate to a service.
The WSO2 Registry provides a description field for each resource. In this case, the WSDL file representing a service can keep a brief description about the service. Altenatively, one can store more detailed documents, with descriptions of the service, in the registry, and "associate" them with the service (i.e WSDL file). You might refer the WSO2 Registry 1.1 User Guide for further details on associating resources. As discussed earlier, it is important to provide description targeting both techies and business analysts.
Following description is used to describe our LibraryService. Since this is a simple service, default description facility of WSO2 registry is used.
LibraryService provides following functionality.
authenticateUser, findBooks, payFine, reserveBook
These web services are implemented on WSAS.
Though the current version of WSO2 Registry 1.1 does not support providing information on resource ownership (other than created by and modified by users), it will be a feature in the next WSO2 Registry release. In the mean time users may store details like provider name, email address, telephone number in a XML file and associate it to the service.
Interested parties can subscribe to the comments RSS feed of any service. Once the owner (or any responsible user) comments on the service, every user subscribed to the service get notified. In this way, users of this service and developers who developed services based this service, can get important updates from the Registry.
As shown in the screenshot above, users who are subscribed in the comments RSS will get change information.
Since the service is represented by a WSDL file, service itself contains the functional description.
Registry allows you to define dependencies among resources. It is a matter of using the dependency option in the UI to add or retrieve dependencies among services. Internally in WSO2 Registry, a dependency is a special form of association. Given the powerful nature of the architecture, one can easily use association to show dependencies too. In our LibraryService example, since it depends on ManagePaymentsService, ManageUsersService and SearchCatalogService correctly they are listed under "Dependencies" section of WSO2 Registry web interface.
Tags feature of the registry can be used to define business taxonomy. The advanced search of the Registry allows you to narrow down the result by searching through tags, thus business taxonomies.
"library", "university", "students" and "payments" are the tags used in our "LibraryService" example.
Depending on the organizational requirement, a policy could be described by a XML file. These policies could be associated to the service using association feature of the WSO2 Registry.
Similar to Dependencies, "AuthenticationPolicy" and "FinePayPolicy" are listed under "Associations" in LibraryService.
This article mainly discusses on recording information about services in the WSO2 Registry. A WSDL document is used as the primary resource to represent a service in the registry. Furthermore, SOA governance related aspects of a service are implemented using features like, tags, description, association, dependencies, comments and RSS subscriptions.
Ruwan Janapriya, Technical Lead, WSO2 Inc. janapriya at wso2 dot com