Unified Service Description Language Incubator Group Charter

The mission of the Unified Service Description Language (USDL) Incubator Group, part of the Incubator Activity, is to define a language for describing general and generic parts of technical and business services to allow services to become tradable and consumable. Technical services are considered electronic services based on WSDL, REST or other technical specifications. Business services are defined as business activities that are provided by a service provider to a service consumer to create value for the consumer. Thus, the business services are more general and comprise manual and technical services. This enables new business models in the field of service brokerage because services can automatically be offered, delivered, executed, and composed from services of different providers.

The language is usable for any purpose and implementation scenario of future business services on a general level. However, it will be extendable for industry-specific aspects. The specification aims at complementing the technical language stack by adding required business and operational information. The targeted groups for USDL are service providers, hosting providers, gateways, and service consumption channels. Industry-specific and general-purpose attributes of a service will be derived based on these use cases and their target groups. In the end, the initiating and contributing members will define a language that enables its users to model arbitrary services and to integrate with existing standards. The Unified Service Description Language Incubator Group will derive best practices and learning from testing cycles that will then be deployed in a number of use cases. These use cases serve as references and proof-of-concept of USDL.

Join the Unified Service Description Language Incubator Group.

End date 18 September 2011
Confidentiality Proceedings are public
Initial Chairs Daniel Oberle (until 23 Nov. 2010), Kay Kadner (starting 23 Nov. 2010)
Initiating Members
Usual Meeting Schedule Teleconferences: Every two weeks
Face-to-face:  2-3 per year



Any organization that manufactures, promotes, sells and applies services in its business environment is urged to use the internet for its purposes. Hence, the internet could serve as an accelerator and stimulator to trade service regardless of the geographical and industrial surroundings of an organization. The Internet of Services creates easy access to services for automation, trading and consumption of services between industries, businesses and consumers. For this purpose, complex integration between applications on different levels (e.g., industries, agencies, portals) and the choreography of different business processes will be enabled.

What is missing to date?

Past work in various projects and a gap analysis delivered the following results. A service description language is missing, which emphasizes the business-related aspects when defining a service. Service description languages such as WSDL concentrate on the proposition of technical interfaces to get services exchanged. Stakeholders from small, medium and large sized businesses as well as representatives from various industries expressed the need of an open and accessible service description language that is able to describe their business needs based on the following aspects (modules)
-    Core (general information about the service)
-    Interaction (how the service can be consumed)
-    Participant (roles of businesses and / individuals that become involved in the provision and consumption of a service)
-    Functional (what business functions are provided by the service)
-    Pricing (how much does the service cost)
-    Legal (legal terms and conditions under which the service may be consumed)
-    Service Level Agreements (levels of service provided, e.g. availability, response time, etc.)

To date, service description languages lack the inclusion of business and operational attributes to describe a service in its whole because they mostly target technical services instead of services as such. For instance, the description of a Web Service that provides weather data includes the technical interface but no information about how much the user has to pay for calling the service. Moreover, the use of services must not be limited to a specific application, interaction protocol, service type or deployment in certain technical infrastructures. Existing offers of pre-defined service descriptions are often bound to a dedicated service or application provider as for example Salesforce.com. Further initiatives such as APS Standard focus on specific application areas of services, software-as-a-service in this case.

Moreover, the study of business needs revealed the need to enable any stakeholder to describe, publish and consume the described service. There is a demand of an easy-to-use and consume service regardless of the position of the service provider or consumer in the service supply chain. The service needs to be configured, i.e., the service is allowed to mature, for instance from a regional to an international use. Other forms of allowing a service to mature relate to:
-    The publication of services on distinct service marketplaces
-    The discovery of services with similar attributes through search engines
-    A direct consumption of a service via hosting functions: it will be taken into account within the specification analysis, if certain services require a download support. The user will get in direct interaction with the service provider or a service broker.
-    Business processing contains a number of services that are attached to a business purpose as for example IT installation services covered in an ERP implementation project, repair services in a production environment or health care at-home services in combination with medical treatments. Thus, a service can be consumed via the Internet and be connected with further activities of a business process. Therefore, it should be executed via mash-up tools or process engines.
-    Very often, the service is being bundled with other services (composite services) and being sold to the consumer as a service package

The description of business aspects of a service is closely related to the technical interface by which a service is made available. Since the description is based on well-known modeling languages like Eclipse Modeling Framework (EMF)  or XSD, the description can be the outcome of a transformation from a higher-level language (like the Service oriented architecture Modeling Language (SoaML) ). Additionally, USDL can be the basis for generating other technical artifacts like WSDL documents, price rules for business rule engines and similar artifacts. Our observations concluded that such a model driven approach would serve best the various stakeholders involved in the provision and consumption of services. However, the technical interface might also be directly included in USDL by some reference mechanism so that the transformation is obsolete. EMF and XSD are supported by various freely available tools like Eclipse and associated projects, which allows the meta models to be extended according to specific requirements. By using EMF for creating the USDL meta model, according editors can be created without much effort.

USDL in a nutshell

The Unified Service Description Language now aims at aligning business services by unifying them using a common description format. USDL is one of the final artifacts of the service engineering process and - as such - complements existing documents and standards for describing the service interface (e.g., WSDL). Herein, USDL composes activities and functions of these stakeholders together based on commonly shared or traded services. This is done regardless of organization’s size, industry, or position in the service lifecycle. The USDL services can easily be created by extending concrete representations from pre-defined abstract services. Furthermore, USDL can also be made available with a minimal set of elements to allow for simple and fast description of new services. The benefits of USDL result from a context-independent design. USDL provides a frame that is then being filled by the context. The context results then from the business or user-driven purpose of providing and consuming services. Moreover, the proposition of USDL is driven by the overall need that services require openness to be spread and composability among applications, infrastructures and consumption channels. The Incubator Group will incorporate a staged approach that allows a versioned USDL development and delivery. Even more, the staged approach will deliver in a foreseeable timeframe the USDL artifacts. The USDL standard will be ready to use with least possible barriers. The stakeholders that are involved in the design, build and consumption of a USDL-based service are able to consider a versioning of the service and offer distinct versions for different regions for example. The versioning of USDL and the further above-described design approach will be incorporated in the work plan of the Incubator Group.
The work plan foresees the phases of assessing input (beyond the existing inputs from the described projects involved), designing, building and delivering. Any of these phases contains documentation, trial and feedback as well as quality assurance activities.

The Unified Service Description Language Incubator Group is proposed by members of the THESEUS research program, which provides experience in foundations and practice of the Internet of Services. The XG builds on substantial scientific work which has already been carried out within the THESEUS-program and European and Australian research projects such as SOA4ALL, Premium Services, Smart Services CRC, ACTOR, FAST, ITAIDE, MASTER, MODELPLEX, MORE, PICTURE, RESERVOIR, Secure SCM, ServFace, SHAPE, SLA@SOI, SoKNOS, VIRTEX, XtreemOS. In particular, the research initiatives already created iterations of the Unified Service Description Language in THESEUS / TEXO and SOA4ALL and further to-be-announced project contributions. Hence, the XG can be expected to produce tangible results within one year.

To sum up, the XG will concentrate on the specification and further development of USDL as an open standard. The XG members will target a broad dissemination of USDL, an ease of use by multiple stakeholders involved in service provision and consumption. Beyond the core focus of the specification work, the XG members will draft recommendations for possible tools and editorial support. In addition, the XG members will outline mapping scenarios to represent USDL in UML and how the meta model in UML will look like.

Success Criteria

The fulfillment of the targeted mission of the Incubator Group can be measured against the following two success criteria:
-    Firstly, the Unified Service Description Language Incubator Group will report on the landscapes of existing service technologies and examine their compatibility and inter-relationships with respect to the USDL specification. The report will be based on a gap analysis that is being conducted beforehand in our research activities within THESEUS and further above-mentioned projects.
-    Secondly, the Incubator Group efforts will target the development of a formal draft specification of the language. The specification covers the above-described modules. USDL and its modules will make use of existing standards for describing specific types of information wherever possible. A consequence to that is that USDL will be the glue between specifications and languages that bind them together and provide benefit through their composition. The concept of separating different aspects in different modules makes it easy to create new modules and link them to USDL in order to create extensions for further use cases or other industries. It is possible to create transformations, which provide mappings from existing description languages to and from USDL. First prototypes exist for the transformation from SoaML to USDL.

In addition, after having completed and delivered the two above-referenced success criteria, it is planned to conduct a proof-of-concept phase. This activity will be conducted based on available resources and the remaining timeframe. The proof-of-concept phase could encompass an implementation of four pre-selected reference cases that test the USDL specification from distinct viewpoints: service consumer, service provider concerning the provision of service marketplaces and service provider concerning the service engineering, as well as the service hosting.

Out of Scope

USDL is not meant to replace existing standards, e.g. for WebService-Descriptions (WS-*). Moreover, USDL will complement these with business related aspects and further allow integrating existing specifications for specific parts of the description. USDL does also not claim to be complete with respect to the required attributes and elements for describing each and every service. There will be the possibility and necessity to extend USDL by use case or industry-specific requirements (like insurance, banking). Furthermore, USDL is not intended to semantically describe existing Web Services or other services.


A report describing the work performed in the group. The report will provide:
-    A state-of-the-art document that assesses the existing landscape of service description languages. It covers the identification of existing standards that feed technical aspects into the Unified Service Description Language; it delineates needed, existing and required parameters and architectural concepts of service description language to allow a generic use of a service in multiple technical and business environments. The document will point to the benefits of existing standards and the benefit of inclusion of the Unified Service Description Language.
-    A formal draft specification for a Unified Service Description Language;

In case the existing timeline and resources are made available to conduct a proof-of-concept phase, the report will be extended by four reference cases described earlier.

Through consultation with potential users, technology and business partners as well as experts on service science and service engineering, the XG will investigate whether a sufficient degree of normalization can be achieved at this stage, and whether the resulting specification can add value to other markup languages, e.g. in the form of a specialized plug-in language. Accordingly, the group will propose to either terminate its activity after its lifetime or continue in the more formal Recommendation Track. The formal decision is left to the relevant W3C entities.

Dependencies and Liaisons

W3C Groups

Contexts, which may benefit from the Unified Service Description Language, can already be found in current W3C activities, such as the W3C Recommendations WSDL , SAWSDL  and SML.

External Groups

The work of the group will also be coordinated with the activities of the Internet-of-Services Community. The activities of the OASIS  TGs operating on so called WS-* have to be taken into account.

The work of the group will assess and use the integration potential of the Unified Service Description Language into existing service engineering concept and equivalents wherever possible. The deliverables will point out the correlations where feasible and necessary.


Members should be expected to introduce themselves and participate over the public list-serv. Members should attend teleconferences, and send regrets if unable to. While participation from all is welcome on the public list-serv, editors of XG deliverables will be W3C members or invited experts. The face-to-face meeting will be strongly recommended.


This group primarily conducts its work on the public mailing list public-xg-usdl@w3.org (archive) . The group's Member-only list is member-xg-usdl@w3.org (archive)

Information about the group (deliverables, participants, face-to-face meetings, teleconferences, etc.) is available from the Unified Service Description Language Incubator Group home page.

Decision Policy

As explained in the Process Document (section 3.3), this group will seek to make decisions when there is consensus. When the Chair puts a question and observes dissent, after due consideration of different opinions, the Chair should record a decision (possibly after a formal vote) and any objections, and move on.

Patent Policy

This Incubator Group provides an opportunity to share perspectives on the topic addressed by this charter. W3C reminds Incubator Group participants of their obligation to comply with patent disclosure obligations as set out in Section 6 of the W3C Patent Policy. While the Incubator Group does not produce Recommendation-track documents, when Incubator Group participants review Recommendation-track specifications from Working Groups, the patent disclosure obligations do apply.

Incubator Groups have as a goal to produce work that can be implemented on a Royalty Free basis, as defined in the W3C Patent Policy.

For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.

About this Charter

This charter for the Unified Service Description Language Incubator Group has been created according to the Incubator Group Procedures documentation. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Barbara Flügge (SAP AG), Kay Kadner (SAP AG), Massimo Romanelli (DFKI GmbH), Holger Last (Siemens AG), Hans Holger Rath (Attensity Europe GmbH)

$Date: 2010/11/23 15:32:19 $