Unified Service Description Language Incubator Group Charter

Scope

Motivation

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.