Discoverability

Service Discoverability is a design principle, applied within the service-orientation design paradigm, which emphasizes making services discoverable by adding interpretable meta-data to increase service reuse and decrease the chance of developing services that overlap in function. By making services easily discoverable, this design principle indirectly makes services more interoperable.

Purpose

The use of any piece of information directly relates to how discoverable it is. Extending the same concept to software development, the reuse potential of a software program cannot be achieved if no one knows even if it exists or not. Secondly, this information is only good if someone can properly understand it, i.e., it depends upon the quality of the meta-information as well to make the best use of the software program.
In case of a service-oriented solution, because of the emphasis placed on service reusability, it stands very clear that opportunities should exist for their reuse, which is only possible if they are discoverable in the first place. To make services discoverable, following set of activities need to be performed:

1. Document the information about the service in a consistent manner.
2. Store the documented information in a searchable repository.
3. Enable others to search for the documented information in an efficient manner.

Apart from increasing the reuse potential of the services, discoverability is also required to avoid development of solution logic that is already contained in an existing service. To design services that are not only discoverable but also provide interpretable information about their capabilities, the Service Discoverability principle provides guidelines that could be applied during the service-oriented analysis phase of the service delivery process.

Application

The application of this principle requires collecting information about the service during the service analysis phase as during this phase; maximum information is available about the service’s functional contextand the capabilities of the service. At this stage, the domain knowledge of the business experts could also be enlisted to document meta-data about the service. In the service-oriented design phase, the already gathered meta-data could be made part of the service contract. The OASIS SOA-RM standard specifies service description as an artifact that represents service meta-data.
To make the service meta-data accessible to interested parties, it must be centrally accessible. This could either be done by publishing the service-meta to a dedicated 'service registry' or by simply placing this information in a 'shared directory'. In case of a 'service registry', the repository can also be used to include QoS, SLA and the current state of a service.

Meta-data Types

Functional

This is the basic type of meta-information that expresses the functional context of the service and the details about the service’s capabilities. The application of the Standardized Service Contract principle helps to create the basic functional meta-data in a consistent manner. The same standardization should be applied when the same meta-information is being outside the technical contract of the service e.g. when publishing information to a service registry.

Quality of Service

To know about the service behavior and its limitations, all of this information needs to be documented within the service registry so that the potential consumers can use this meta-information by comparing it against their performance requirements.

Considerations

The effective application of this design principle requires that the meta-information recorded against each service needs to be consistent and meaningful. This is only possible if organization-wide standards exist that enforce service developers to record the required meta-data in a consistent way. The information recorded as the meta-data for the service needs to be presented in a way so that both technical and non-technical IT experts can understand the purpose and the capabilities of the service, as an evaluation of the service may be required by the business people before the service is authorized to be used.
This principle is best applied during the service-oriented analysis phase as during this time, all the details about the service’s purpose and functionality are available.
Although most of the service design principles support each other in a positive manner, however, in case of Service Abstraction and Service discoverability principle, there exists an inversely proportional relationship. This is because as more and more details about the service are hidden away from the service consumers, less discoverable information is available for discovering the service. This could be addressed by carefully recording the service meta-information so that the inner workings of the service are not documented within this meta-information.

References

• Kevin Liu.A Look at WSDL 2.0[Online].Date accessed: 20 April 2010.
• Mauro. et al. Service Oriented Device Integration - An Analysis of SOA Design Patterns. [Online], pp.1-10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 8 April 2010.
• Benjamincarlyle.WADL for REST-style SOA[Online].Date accessed: 20 April 2010.
• Thomas Erl (2008).SOA Principles of Service Design. Prentice Hall. ISBN 0-13-234482-3
• Cyrille Thilloy.Service Elicitation:Defining the Conceptual Service[Online].Date accessed: 20 April 2010.
• Tost. et al.Anatomy of a Web Service Contract[Online].Date accessed: 20 April 2010.

External links

• SOA Concepts
• SOA Terms Glossary
• SOA Methodology
• SOA Principles
• Reference Model for Service Oriented Architecture 1.0