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 into three categories:
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.
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. Alternatively, one can store more detailed documents, with descriptions of the service, in the registry, and "associate" them with the service (for example, WSDL file).
The users may store such details as 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.
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 to perform impact analysis on a service before performing any changes on that service.
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.
One of the most important features of a registry-repository is the facility to discover resources (in our case, services). Service discovery promotes service reuse.
Business Taxonomy is a custom categorization scheme for classifying services. Once a service is stored in the registry, tagging with business taxonomy helps users to 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
- Run time policies
Design time policies define the behavior of a service during design time while the other define 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.
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.
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.