Discoverability

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Discoverability is the ability of something, especially a piece of content or information, to be found. Discoverability is a concern in library and information science, many aspects of software and web development, and in marketing, since a thing cannot be used if people cannot find it or don't understand what it's for. Metadata, or "information about information," such as a book's title, a product's description, or a website's keywords, can make something more discoverable. Organizing information by putting it into alphabetical order or including it in a search engine can also make it easier to find. Discoverability is related to, but different from, accessibility and usability, other qualities that affect the usefulness of a piece of information.

Purpose[edit]

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[edit]

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 context[1] and 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.[2] The OASIS SOA-RM standard specifies service description as an artifact that represents service meta-data.[3]

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'[4] or by simply placing this information in a 'shared directory'.[5] In case of a 'service registry', the repository can also be used to include QoS, SLA and the current state of a service.[6]

Meta-data types[edit]

Functional[edit]

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[7] of the service e.g. when publishing information to a service registry.[8]

Quality of service[edit]

To know about the service behavior and its limitations,[9] 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[edit]

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[edit]

  1. ^ The overall purpose of the service
  2. ^ Service Contract
  3. ^ Michael Poulin. Evolution of principles of Service Orientation: Service Composability and Discoverability, part 7. Date accessed: 20 April 2010.
  4. ^ Reddy, et al. Evaluating legacy assets in the context of migration to SOA. pp 58. Date accessed: 20 April 2010.
  5. ^ Dennis Wisnosky.Principles and Patterns at the U.S. Department of Defense. Date Accessed: 20 April 2010.
  6. ^ .Vinod Sarma, Srinivas Rao Bhagavatula. Freeway patterns for SOA systems. Date accessed: 28 April 2010.
  7. ^ technical contract
  8. ^ A repository that contains meta-data about services in a specific format e.g. classification of service, its location, etc.
  9. ^ Jim Murphy. Essential Components of an SOA Quality Foundation. Date accessed: 20 April 2010.

Further reading[edit]

External links[edit]