We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.ArchitectureDescription.Apps.USDL - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search



USDL (Unified Service Description Language) is a platform-neutral language for describing services. USDL is building a layer on top of technical service descriptions such as WSDL, which captures the information necessary to manage services in the business framework across the whole service lifecycle.

Since USDL is just a data format and a set of vocabulary definition, we introduce it into FI-WARE as an Open Specification. Because of the fundamental role for the business framework, we will outline the rationale and concepts of USDL in this page as part of the architecture description of the Application and Services Ecosystem chapter.

In the section USDL 3.0 Specifications M5 of Materializing Applications/Services Ecosystem and Delivery Framework in FI-WARE we outlined the necessity of a unified service description language, and described the power of USDL. Within FI-WARE we want to achieve adoption of USDL on a new level. In reflection of the work in the W3C USDL Incubator Group and the resulting recommendations, we will focus on easy of use and harmonization as well as integration with a broader range of standards.

Developing of USDL was always a collaborative and interdisciplinary approach. Initiated by SAP Research roughly 2 dozens of researchers from approximately 10 public funded projects and many research locations around the world contributed their expertise from different research areas. Industrial partners such as Siemens, Attensity, HP, and others gave their feedback and recommendations in a W3C Incubator Group. As a next step of evolution the Linked USDL community was founded for broad and worldwide adoption and collaborative further development in an Open Source like community.

The FI-WARE approach will allow comprehensive service descriptions by employing the Unified Service Description Language (USDL) in its registry and repository. USDL builds on standards for the technical description of services, such as WSDL, but adds business and operational information on top. With its ability to describe both human and IT-supported services that not only implement business processes, but also tie in assets linked to contents and the Internet of Things, USDL is set apart from many of the related approaches mentioned above.

USDL is modularized to describe various aspects of services:

  • Foundational Module: This module provides a common set of concepts and properties, such as time, location, organization, etc. that are used in all modules.
  • Service Module: Describes the general information about the service type, nature, titles, taxonomy and descriptions.
  • Participant Module: This module describes the participating organizations, contact persons and their role within the service fulfillment.
  • Functional Module: This module contains information about the specific capabilities of a service, input/output parameters and constraints.
  • Interaction Module: A module that describes the points of interaction and the responsible participants or participant roles in course of the service fulfillment.
  • Technical Module: Describes how functions (capabilities) of a service are mapped to technical realizations of the service (e.g. WSDL operations, parameters, faults, etc.)
  • Pricing Module: Contains information about price plans, price components, fences, etc. for a service.
  • Service Level Module: The module which specifies service level agreements, such as time schedules, locations, and other constraints.
  • Legal Module: Contains information about the terms and conditions, IPR, licenses, and rights of use for the participating parties.

USDL modules and relationships

Necessary extensions to USDL for business, operational and technical perspective of supported front-end mashups and backend composite services will be identified and defined in the context of the FI-WARE project. Furthermore, USDL extensions for artefacts from the chapters listed below will be considered:

  • Internet of Things Service Enablement

Applications and services may have specific requirements of handling access to and management of sensor data and things within the “real” world. In many application scenarios, such as logistics, retail, or manufacturing, these capabilities will have an impaction even on business, as well as operational aspects. It will be necessary to investigate the extension of USDL according to aspects of the service lifecycle, which allows describing the relevant properties and capabilities of the Internet of Things in respect to accessing data as well as managing resources.

  • Security, Privacy, Trust

The future internet platform will heavily depend on security, privacy and trust in any business relevant activity. Especially crowd-sourcing, flexible composition and mashups require adequate mechanisms to maintain security related characteristics. At the business framework level it is necessary to make security-specific information transparent. USDL needs to be extended by modules that allow describing the security related qualities and requirements of services and applications.

  • Cloud Hosting (XaaS monetization)

Many services/apps will rely on specific hosting and cloud services, which will have technical as well as business relevant implications. The service description needs to contain the relevant information on hosting in order to cover these implications. Therefore XaaS description modules for describing various hosting modules need to be provided.

  • Data/Context Management Services

For security monitoring and analytics of activities in the platform it will be necessary to emit and collect events and data for real-time or post-mortem analysis. For the various stakeholders it need to made transparent, when, how, and which data will be collected for which purpose and to whom. So the service description needs to be enriched by data and context information accordingly.

USDL will provide the means for integration of all these areas, FI-Ware generic enablers and the respective platform products. It allows tracing information and processes across the whole service lifecycle.

USDL Design Principles

  • rely on Web standards such as HTML, XML, RDF, …
  • openness integrate into different contexts
  • extensibility for addressing unforeseen or domain specific aspects
  • flexibility to adapt to different domains via module variants
  • harmonized with other information descriptions on the Web (existing schemas)
  • ability to link-up with other information on the Web
  • simplicity, easy to understand
  • expressive power to specify at an appropriate level
  • graceful degradation, keep the platform operational with partially incomplete and inconsistent descriptions


There exists a plethora of existing service description efforts that can be grouped into different strands. Each of the strands has its own motivation and representation needs for capturing service information. The individual efforts can be attributed to the following criteria: (i) whether the scope of the effort lies in capturing IT or business aspects of services or the whole service system. (ii) the purpose of the corresponding effort, e.g., enabling of normative data exchange, facilitation of software engineering, or acting as reference model. (iii) Whether the effort is able to capture business network relationships between services. (iv) Whether the effort is standardized.

The first strand of service description efforts is the field of Service-oriented Architectures (SOA). SOA is a way of thinking about IT assets as service components, i.e., functions in a large application are factorized in stand-alone services that can be accessed separately. Because of their IT focus, most approaches limit their attention to the field of software architecture. Originally, several standards bodies specified roughly two dozens of different aspects which are collectively known as WS-* (incl. WSDL, WS-Policy, Ws-Security, etc.). Since one of the key components of a SOA is a service registry, the OASIS standards body introduced the concept of Universal Description, Discovery and Integration (UDDI), i.e., a specification for a platform-independent registry. UDDI services shall be discovered according to information such as address, contact, known identifiers, or industrial categorizations based on standard taxonomies. However, UDDI does hardly prescribe any schema for such information. As the concept of SOA matured, calls for support in software and service engineering increased. Hence, the OMG standards body dedicated its focus to software engineering for SOA, and, subsequently defined the Service-oriented architecture Modeling Language (SoaML). Finally, the multitude of description efforts and different definitions of SOA led to a Reference Model for Service Oriented Architecture (SOA-RM) from OASIS. Similarly, The Open Group drafts an alternative reference model in form of an ontology for Service-Oriented Architectures (SOA Ontology).

A second strand consists mainly of ontologies in the field of Semantic Web Services. The main goal of Semantic Web Services approaches is automation of discovery, composition, and invocation of services in a SOA by ontology reasoners and planning algorithms. The most prominent efforts are OWL-S and WSMO. Many similar efforts have surfaced in literature. With the many approaches around came the need to specify a reference model for semantic SOAs. Consequently, the OASIS is also about to specify a Reference Ontology for Semantic Service Oriented Architectures (RO-SOA).

The third strand is rooted in the rise of on-demand applications that led to the notion of software-as-a-service (SaaS), covering software applications (e.g., CRM on-demand) and business process outsourcing (e.g., gross-to-payroll processing, insurance claims processing) to cloud and platform services. The emphasis of service here implies that the consumer gets the designated functionality he/she requested together with hosting through a pay-per-use model. Thus, software-as-a-service is not synonymous with SOA. This difference triggered the Software-as-a-Service Description Language (SaaS-DL). SaaS-DL builds on WS-* to capture SaaS specificities in order to support model-driven engineering. The strand of SaaS also contains a standard, namely, the W3C recommendation called SML (Service Modelling Language). One anticipated use for SML is to define a consistent way to express how computer networks, applications, servers, and other IT resources are described or modelled so businesses can more easily manage the services that are built on these resources.

The fourth strand is driven by schools of business administration and focuses on capturing the purely economic aspects of services regardless of their nature (with less or no focus on IT services and software architectures). The German standard DIN PAS 1018 essentially prescribes a form for the description of services for tendering. The structure is specified in a non-machine-readable way by introducing mandatory and optional, non-functional attributes specified in natural language, such as, classification, resources, location, etc. The PhD thesis of (O’Sullivan) adopts a wider scope and contributes a domain independent taxonomy that is capable of representing the non-functional properties of conventional, electronic and web services. The work compiles the non-functional properties into a series of 80 conceptual models that are categorized according to availability (both temporal and locative), payment, price, discounts, obligations, rights, penalties, trust, security, and quality.

The fifth strand is also economic but draws attention mainly to describing Service Networks, i.e., the ecosystem and value chain relationships between services of economic value. The e3Service ontology models services from the perspective of the user needs. This offers constructs for service marketing, but in a computational way, such that automated reasoning support can be developed to match consumer needs with IT-services. The main focus of this work is to generate service bundles under the consideration of customer needs. The Service Network Notation (SNN) captures similar aspects to the e³Service ontology. However, SNN is an UML model that can be analyzed for measurements of added value for each single participant as well as for the whole network optimization of value flows.

Finally, there are overarching efforts that concentrate on the bigger picture of service systems or service science also taking into account socio-economic aspects. Stephen Alter was one of the first to realize that the concept of a service system is not well articulated in the service literature. Therefore, he contributes three informal frameworks as a first attempt to define the fundamentals of service systems. The work of Ferrario and Guarino can be seen as a continuation and formalization of Alter’s approach. Although differing in its main notions, they present a reference ontology for ontological foundations of service science which is founded on the basic principles of ontological analysis. In turn, this reference ontology forms the core part of the TEXO Service Ontology which extends it by ontology modules for pricing, legal, innovation, or rating information.

USDL is the only effort which covers IT and Business aspects, serves both a reference and exchange purpose, considers business network related information and is about to be standardized.

Relations to standards

USDL is dedicated for business aspects of the services business framework and has no means of describing the technical aspects of services. Therefore USDL is meant to be used in conjunction with other Web standards such as WSDL etc. in order to address detailed technical information. In the case of WSDL, USDL refers to a WSDL description and can even map high-level interactions to elements of a technical service description in WSDL.

The standardization of USDL was discussed in the W3C USDL Incubator Group, which published the final report in September 2011. The common understanding and recommendation of the group members, was to keep the alignment with Web standards and go for a W3C standardization process. So the discussion with the W3C has started to establish a new standardization group in 2012. With respect to the W3C policies and processes, we estimate that the group could be in place in spring 2012.

Basic Concepts

Web of Data

"in recent years the Web has evolved from a global information space of linked documents to one where both documents and data are linked. Underpinning this evolution is a set of best practices for publishing and connecting structured data on the Web known as Linked Data." Bizer et al. Linked Data - The Story So Far. International Journal on Semantic Web and Information Systems (IJSWIS)(2009)

Linked USDL is a set of simple Linked Data vocabularies encompassing various modules of USDL for describing and linking all relevant aspects of doing business with services.

The core vocabulary contains fundamental aspects and core properties of services, service composition, interaction, service offerings, participants and legal constraints. Additional vocabularies are available for describing price model, service level profiles and security features. USDL can be complemented with existing vocabularies of the Linked Open Data world to describe various other aspects related to services.

Over the last decade, the service sector has become the biggest and fastest-growing business sector in the world. For the first time ever, it now employs most people worldwide. Various companies and research institutes have started to explore different aspects of the service sector to determine which services can be managed through IT and, being combined, lend themselves into value-added services and service networks. Linked-USDL provides the basis for sharing information about services in such envisioned service networks. Service networks need to be supported by an appropriate Web-based infrastructure consisting of distributed repositories, marketplaces, business model support, service communities and more.

Potential users and stakeholders for Linked USDL are

  • Service providers
  • Resellers, brokers
  • Infrastructure providers
  • Consumers

Various different stakeholders in the service business come together and work jointly on specifications and applications.

Linked Data is proven approach to put data in the Web and allow linking to other data much like linking Web pages. Data is expressed in a universal standard data format, which is easy to produce and consume.


Easy to use

The entry barrier for applying Linked USDL should be as low as possible in order to enable also small companies describing their services with a reasonable amount of effort and resources and participate in the ecosystem. There is a balance between simplicity and expressive power to maintain. It must be possible to describe complex services without to sacrifice the simple cases.

Simplify the process of further development

In comparison to the Ecore object modelling approach, the Linked Data approach will make it easier to extend USDL with new aspects and domain specific variations.

Reusing existing standards and existing tools

By relying on existing and accepted standards, the USDL vocabularies can be concentrated on specific aspects and will be simpler and better to understand. Furthermore synergies with other communities can be leveraged.


It should be possible to link aspects of a service description with various other information resources according to the overall life cycle of a service, which relate to each another.

Platform neutrality

USDL abstracts from platform (technology) specific aspects and covers communication of different components/actors on an abstract level of interactions.

Domain independence

USDL descriptions are generic and not per se tailored to a specific application domain. Nevertheless it contains elements (taxonomies, properties) to enable to express domain-specific information.


USDL is not complete in all aspects. It rather abstracts important aspect of business with services. A fundamental principle of USDL is the extensibility according to specific business and life-cycle aspects in order to allow more functionality in a certain context.

Data Model

USDL is building on top of Linked Open Data principles. So the underlying data model is the graph model of RDF, which is standardized by W3C and supported by a wide range of tools (repositories, querying, programming language bindings, etc.).

USDL is reusing existing Linked Data vocabularies as much as possible in order to allow linking elements of USDL descriptions to other existing datasets. Examples of vocabularies currently used are FOAF, GoodRelations, DCTERMS, MSM, ORG, SKOS, Time, VCARD, sawsd, sa-rest, wl, and ctag. This allows the integration of data and processes on a global (Web) scale and allow applications (mashups) that integrate information across multiple sources.

USDL is not one monolithic RDF ontology. It rather comes as a collection of harmonized vocabularies, which express different aspects of the service business. The USDL Core module is the definition of basic concepts and properties for describing services, service models, composition, interaction, and classification. Further vocabularies complement the core vocabularies for describing other aspects, such as service level agreements, pricing, security, and platform requirements and resources (computing infrastructure, IoT enablement, network and devices). The supplemental vocabularies can be available in different flavors, depending on the needs of the application domain.

In the context of a specific technical realization of the platform, USDL can be serialized into a couple of serializations such as RDF/N3, RDF/XML, RDF/JSON for the developer convenience. The Generic Enablers using USDL are encouraged to deliver different serializations on request (content negotiation).

The following picture gives an overview of the USDL core vocabulary.

Use Cases Examples

Telecom: Trading Services


  • No common format to describe the business side of technical services (e.g. WSDL)
  • Marketplaces are ‘islands’ of services
  • No solution to transfer services across marketplaces

The use of a common language such as Linked-USDL enables providers to transfer services across platforms

Cloud Services: IaaS


  • Many offerings in the wild
  • No coherent description of services available
  • No common marketplace

Comparison of offerings (price, SLA, capabilities, …) is very difficult for users Linked-USDL can help to put light into the dark and make Cloud offerings more transparent to the consumer!

Transport & Logistics

Freight Forwarder’s problems (FINEST use case)

  • No common scheme for transportation services
  • Planning of routes with many legs is cumbersome
  • Main criteria are price, reliability and time
  • Hard to find transport options if plan must be changed on the fly
  • Vast amount of transport options is inaccessible
  • Phone calls, paper work are still dominant collaboration means

A spot market and planning tool based on Linked-USDL logistic service descriptions would have an enormous effect.

Creating a community of practice

The definition of Linked USDL is not final. After stabilizing the core vocabulary, additional aspects as well as domain specific extensions and variants need to be supplemented. Therefore before going into a standardization process, Linked-USDL need to be adapted and proven useful by the stakeholders above within different use case domains. So it is an important goal of the linked-usdl.org to facilitate a community of users, providers, researchers, developers etc.

The following steps are identified for starting the community:

  • Identification and invitation of stakeholders (research, development, service providers, consumers, ...)
  • Providing more documentation (background and use case presentations, snippets, manifesto, etc.)
  • Providing a basic infrastructure (repository, search) for testing and demonstration
  • Apps showing value and attract people (such as a simple marketplace and additional mashups)
  • Concept of managing/moderating the community with appropriate community tools
  • Organizing events, challenges and the like

An alignment with other service description and standardization activities is also desirable.


USDL itself is just a set of vocabulary specifications that is used to describe services in a business framework and platform relying on the concept of services. USDL descriptions are usually stored in distributed repositories to be used by the different components when necessary or transferred as part of the API of components of such a platform (e.g. between a marketplace and stores). Its purpose is that of a lingua franca within the framework.

USDL descriptions can be created manually by using dedicated editing tools. However, USDL descriptions or parts of them can also be generated automatically from information in existing catalogs and enterprise systems. For example a service store can provide an interface for marketplaces to deliver service descriptions in a USDL serialization from the specific native data structures of the store implementation (internal database schema). A specific USDL API for this generation will not be provided because existing RDF tools are sufficient for this purpose.

However, USDL implies a common infrastructure of basic services and tools such as editors, repositories, search engines and marketplaces. FI-WARE will provide reference implementations and open specifications for some of this base infrastructure components.

Design Principles

  • Unified Service Descriptions

The central purpose of USDL is to describe services for stores and marketplaces as well as for the business relevant aspects in the runtime platform, e.g. monitoring service level aspects and revenue sharing.

  • Modular Design

USDL follows a modular design approach. Not every concept or property needs to be specified in a USDL Service Description

  • Extensibility Principle

USDL provides extensibility mechanisms to allow business and life-cycle specific aspects to allow more functionality in a certain context.

Open Specifications

Open API Specifications

USDL is a schema/vocabulary definition and does not provide any API

Other Open Specifications

USDL is used in many other projects outside the scope of the FI-PPP initiative. An open source like community was founded on linked-usdl.org in order to foster take up and collaboration. All Linked USDL vocabularies relevant for FI-WARE will be published and maintained by the Linked USDL community. For example currently there are four vocabularies complementing each other for describing different aspects of the service business.

It is expected that these vocabularies will be complemented by additional topic specific or domain specific vocabularies coming from the Use Case projects.

Further References

BARROS, A. ; OBERLE, D.: Handbook of Service Description: USDL and Its Methods. Springer, 2012. – ISBN 9781461418634

Personal tools
Create a book