Service Description Techniques

Register in this topic
  • Contact
    • Piero Corte (Engineering) -
  • Overview
    • This call addresses the problem of describing services. The particular challenge is to identify methods for describing and representing services that allow to enhance reuse and automate the composition of services.
  • Problem Statement

    • Adoption of Service Oriented Architecture (SOA) is expected to improve the way how enterprises effectively cope with the ever changing and dynamic businesses of today in a timely way. This relies on the capability provided by SOA to support and accommodate new business solutions dynamically by supporting reuse of functional assets (services). 

      The fundamental principles of the SOA paradigm concern the ability to create and exploit functional assets, organize them and enhance their reuse and composition for the realization of new or modified business processes. Effective methods for describing and representing services are needed to enable and eventually automate all these activities. For this reason, service description is one of the most fundamental characteristic of SOA.
  • Scope

    • The problem of describing and representing services can be analysed from different perspectives. Description languages, methods and tools can be designed specifically for supporting different service related activities, such as service creation, management, discovery, invocation, and composition. Therefore, to fully qualify a solution to service description, it is important to focus on the question “For which activity is a given description useful?” 
      This call focuses on description languages, their expressiveness and their easiness of usage with respect to their primary purpose (that is, discovery, composition, etc), but not on matching or search algorithms, neither on service composition itself which are respectively addressed by the “Service Discovery” and “Service Composition” calls.

      Even if quality of services, policies and usage contracts are commonly and rightly recognized as service descriptions, this call does not specifically address these kinds of descriptions since they are directly addressed by other calls. A similar case are description methods that deal with the deployment and configuration of services.
  • Contributions

    • Contributions to this call should have the form of architectural patterns. These patterns will constitute pieces of designing solutions that will be integrated with other provided patterns to specify the overall design of a SOA-based system.
      The documentation of the proposed design patterns is expected to supply sufficient details about the pattern. In particular, it should contain a description of

      • the problem the pattern solves, its intent, the forces and consequences of its application,
      • its interfaces and usage,
      • a guideline for its implementation,
      • its internal structure or/and implementation,
      • standards to which it is related.
  • Baseline
    • In the following we list some of the major and widely adopted models and standards for service description and position them with respect to the perspective previously introduced.
      Creation Service Discovery (querying, matching, browsing) Service Invocation (message delivery and mediation) Service Composition (process creation)
      UML UDDI WSMO SAWSDL WSDL WSMO SAWSDL BPEL WSMO UML

      Please keep in mind that the standards specified in the above table are only examples and the contribution can concern any other standard or language.
      The approach of a contribution can support more than one activity.
      Classifying the contributions according to the activities is very valuable, since it helps to distinguish alternative or complementary approaches and allows us to select the ones that are most suitable in a given case.
      Thus any approach should be classified accordingly the activities it is specifically conceived for. For instance, WSDL is mainly conceived to enable Service Invocation and although it may be used for Service Discovery it should probably not be advocated for such an activity. While the activities mentioned above are coarse grained, finer distinctions are encouraged. For example, both, WSDL and WSMO, are useful for Service Invocation, but while WSDL can be used for the delivery of messages and does not specifically address protocol mediation or semantic mediation, WSMO addresses them.

      Each proposal should compare the proposed approach to other competitive approaches, using the same perspectives.