Service Discovery

Register in this topic

• Contact
  • Jesús Gorroñogoitia (Atos Origin)
• Overview
  • That services are “discoverable” is one of the key factors for the success of SOA. Services are fully described and these descriptions are published in publicly accessible SOA registries so the services may be later discovered. However, discovering services could be a cumbersome process if it had to be done manually by browsing in distributed registries with a large number of service descriptions, without the aid of semi-automatic integrated searching facilities, especially in the composite service development lifecycle.
• Problem Statement
  • SOA strength is that services can be consumed as many times a particular user requires them. This is possible since services are discoverable. This capacity is based on the ability of services to describe themselves through well-defined formal descriptions that are published on SOA registries, and, once there, are publicly available for retrieval and inspection through browsing or other discovering mechanisms.
    Discovering of services by browsing is not adequate for SOA registries with large content. Therefore, fast and accurate semi-automatic search and selection facilities are required which perform queries within local or remote, centralized or distribute, single or federate SOA registries.
    Service discovery may rely on: a) the user’s ability of precisely describe its request, b) in the algorithms applied to match that user request with the capabilities of candidate services, and c) in the algorithms to rank and select the best candidate among those discovered.
    Service discovery is intensively used by SOA practitioners when they compose other services or when they require invoking an external service from some application or process. Hence, the service discovery process is quite relevant in SOA engineering cycles.
    Even if service discovery is, to some extent, well covered by the SOA techniques and tools, there are still some challenges, especially with techniques to specify user requests, semi-automatic service discovery, and the ranking and selection facilities. Also determining the role of service discovery in the SOA engineering phases like service composition specification, runtime, etc.,  requires still further attention.
• Scope
  • This call focuses on service discovery techniques and strategies and their applicability during certain service development phases (composition, invocation, etc.). It is not concerned with service description specifications, except in those cases where describing user request and services capabilities are relevant for the discovery process.
• Contributions
  • This call expects contributions for a general conceptual and technological framework for service discovery that should be aimed as much complete and self-consistent as possible. Therefore, it is expected: 
    • Techniques and language specifications for representing the user’s request. The technology should also support the creation of consumer’s goals, isolating as much as possible the underlying technological complexity.
    • Strategies, techniques, best practices, etc. for accurate and precise matching between consumers’ goals and services’ capabilities. Most appropriate matching algorithms and guidelines to accommodate then to particular searching scenarios are also expected.
    • Techniques, algorithms, best practices, etc. for semi-automatic service ranking and selection among those service specifications retrieved by the discovery process. As above, guidelines are expected to accommodate selection algorithms to particular searching scenarios.
    • Strategies, techniques for service discovery applied to some frequent service discovery scenarios in composite services: requirement based service discovery (that is, based on stakeholders or analysts requirements elicitation process), architecture based service discovery (that is, based on design patterns and choreography constraints applied to the composite service) and runtime service discovery (that is, postponing concrete binding to services to execution time), among others.

    It is expected to explore other aspects concerning service discovery and selection such as consumers’ and providers’ context, SLA, negotiation, etc 
    an tasks within those compositions.

• Baseline
  • Baseline for this call is the WS technological stack; contributions are assumed to be full compatibility with this technology. There are no other assumptions or constraints.