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.OpenSpecification.Apps.CompositionEditor - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Apps.CompositionEditor
Chapter Apps,
Catalogue-Link to Implementation Wirecloud
Owner UPM, Javier Soriano



Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


  • Copyright © 2012 by UPM and EAB and DT

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.


The Composition Editor is a core enabler of the FI-Ware Platform. It empowers users with an environment that allows them to create application mashups and composed services in a graphical way.

This GE is intended to be the main client (application) of the Marketplace, Repository and Composition Execution GEs. Moreover, this GE is closely related to the Composition Execution GE in the sense that they both conform the Composition Provider.

Target usage

The Composition Editor GE helps the service provider to create application mashups and composed services. Editors should provide an environment to combine and configure applications and services in graphical way.

Different editors could cater for different user expertise (from technical experts with skilled in the composition language to domain experts without technical expertise or even simple end-users with no programming or technical skills) and roles (from composed service creators, to resellers and finally to prosumers) by hiding complexity behind different types of construction blocs, trading off flexibility for simplicity. By prosumer we denote a consumer-side end-user who cannot find a service which fits her needs and therefore modifies/creates services in an ad-hoc manner for her own consumption.

Editors should support facilities for consistency checking of interfaces and simple debugging. They should connect to the Execution Engines allow testing, debugging, installing, executing, controlling and post execution analysis of the composed applications.

Composition descriptions and technical service descriptions should be edited/created in the editor and stored/fetched to/from the Repository.

When creating compositions/mashups editors might connect o the business infrastructure:

  • Marketplace to search for services
  • Shops to purchase component services them for testing /deployment, and to expose composed services for purchase
  • USDL Registry to browse business information related to services

Editors could be connected to a user and identity management service for controlling access to the applications.

Composition Provider Architecture

Figure 3.2.1: Composition Provider Architecture

Basic Concepts

The Composition Editor GE conforms the means by which end users will create their mashup applications and composed services. Different types of composition editors representing the GE are shown here.

Mashup Editor

A mashup is the composite application created by the Composition Editor GE, deployed into the Composition Execution Engine GE. Mashups are described by means of the mashup description language (MDL, XML Schema published at: https://github.com/Wirecloud/wirecloud/blob/develop/docs/source/mashups/mashup_template_xml.xsd, RDF Schema published at: https://github.com/Wirecloud/wirecloud/blob/develop/docs/source/mashups/mashup_template_rdf.rdf)

A mashup is a remix and integration of several widgets (also known as gadgets), that is, atomic user interfaces frames that allow accessing to backend services and offer a simple but complete functionality. Widgets API and functionality must be also described by means of the Widget Description Language (WDL, XML Schema published at https://github.com/Wirecloud/wirecloud/blob/develop/docs/source/widgets/template/xml_template.xsd, RDF Schema published at: https://github.com/Wirecloud/wirecloud/blob/develop/docs/source/widgets/template/rdf_template.rdf);

Both the Composition Editor and the Composition Execution Engines will use the MDL and WDL descriptions to instantiate, show and deploy the mashup. However, when the user looks at the Marketplace for discovering new widgets or mashups to use, the MDL/WDL will be delivered as the technical description of both mashup and widget within the USDL service description.

The following figure shows an example of how a mashup developer can create a mashup application by means of the Composition Editor. To do so, she deploys individual widgets obtained from the Marketplace, interconnects them, and then arranges them all together as she wishes into something that makes sense to her.

Figure 3.2.2: A Mashup Editor showing how the mashup developer can arrange widgets to create her own mashup application

Composition Editor

The editor allows the creation of composed services (also denoted as skeletons). The Composition Editor is an instantiation of the Composition Editor GE and its skeletons are deployed and executed on the Service Composition Engine which is an instantiation of the Composition Execution GE. The following figure shows the main graphical user interface exposed by the Composition Editor. There the user can define service descriptions (to describe how the component services can be invoked) and create compositions by adding skeleton elements and interconnecting them.

Figure 3.2.3: Composition Editor GUI

In order to create compositions, we need to specify in the editor how to access the services that represent the components that are invoked when executing the composition. The execution engine needs to know what are the API and the protocol used by these services, and how to set the parameters at invocation time. Thus we need to create a service description for all the services used in a composition.

When creating a service description first we need to specify what service type(s) this service is (e.g. SOAP, REST, SIP, etc). Then we need to specify values for the attributes that will be used when invoking the service (e.g. in case of a SOAP service the namespace, the port, the operation, the parameters passed to the operation, etc). The attributes to be specified could be either fixed or variable.

Figure 3.2.4: Composition Editor - Service Description Example

The skeletons provide the business logic, the data and control flow, and service templates (placeholders that are bound to specific service implementation during each invocation). Several services might be suitable to implement a service template. These services can have different input and output parameters and the editor needs to offer the possibility to correctly map the different dataflow types, while providing an easy way to use the unified interface. These elements are placed via drag&drop in the composition editing area and connected by linking their input and output ports. The elements can then be configured using static data or by using the relevant variables. Each skeleton consists of several interconnected elements of the following types:

  • Skeleton Start Element. The skeleton start element is the mandatory first element for all skeletons. It provides the entry point for the skeleton evaluation during service composition and holds overall properties valid for the whole skeleton.
  • Service Template. The service template element is used during execution of the skeleton in a service composition to decide what service shall be invoked. The service description available in the local descriptions storage of the Composition Editor that fulfils the specified constraints at runtime will be selected. Only one service can be specified per service template element. Call parameters, service selection constraints, invocation semantics (synchronous or asynchronous) and the result variable (the name of the variable in which to save the response of the service) can be specified. For example in Figure 3.2.3 any service that is of type “logger” is chosen.
  • Condition. The condition element provides the possibility to branch within the skeleton upon certain conditions evaluated during runtime of the service composition execution. Different outgoing branches are supported where one outgoing branch can be connected to an unspecified default condition value which is chosen in case none of the other branches condition matches.
  • SSM Command. The SSM Command element provides the option to set or remove variables in the memory space used during service composition execution. The expression to be assigned in the setVariable clause can be of a static value or a condition to be evaluated at runtime.
  • Goto. The goto element provides the option to perform a jump to another skeleton element during skeleton execution. The specified jump target can either be a skeleton element from the same skeleton and thereby offers the possibility to implement a loop construct or can be any skeleton element from a different skeleton present in the advanced composition repository.
  • End. Each branch of a skeleton must close with an end element.

A skeleton is created iteratively using the GUI by using a selection tool for selecting skeleton elements and interconnecting them using a connection tool. When making a connection between a Condition Element and another skeleton element, branching can be realized.

Figure 3.2.5: Composition Editor - Service Composition (skeleton) Example

Specification of global and local constraints are used to decide runtime service selection and event filtering. A global constraint can be specified in the skeleton start element, and is valid in the context of the composite service, for example all services used in that particular skeleton must be SIP services (syntax example: $(srv.type)='SIP'). A local constraint is to be specified within a service template. Local constraints are evaluated every time the control flow of the skeleton arrives at the evaluation of a service template and invocation of a component service (syntax example: srv='ServiceName'+$(variable_name)). Note that global constraints are defining restrictions applicable to all components of the composite service, while local constraints are applied only for choosing the particular service specified by that particular template element.

Many communication-type services depend heavily on events, and first class support for events needs to be provided. External and internal events may start actions, events can be filtered, events can be triggered. Basically it is assumed that at execution all the services within a session have access to a shared state via a shared state manager (SSM). Any change in the shared state produces a high-level event related to it, e.g. change of the variable's value can generate a state change event depending on variable name, old value, new value. These events are the only way of communication between components using different technologies. The SSM employs a subscribe/notify model.

The Composition Editor (Mashup Factory) is an instantiation of the Composition Editor GE. Mashup Factory is an experimental web-based application which supports an end user to compose and execute mashups in an intuitive workflow. During the composition of the mashup, user activities like design, creation, configuration and simulation are enabled. The following figure shows the main graphical user interface exposed by the Composition Editor (Mashup Factory).

Figure 3.2.6: Composition Editor - Service Composition (Mashup Factory) Example

The user creates mashups by adding services from the library and combining services according to her needs.

The Composition Editor (Mashup Factory) contains a library of categorized services and a work surface to combine the services. Services can be added via drag & drop from the repository to the work surface. Services have input and output ports, connections between services are created via linking input and output ports. A data flow between connected services is supported. The configuration of certain services with configuration data is possible. When a mashup is composed (i.e. every input port is connected with an output port), the mashup composition is saved by giving it a name.

After storing a composed mashup a user can activate, stop, remove or publish the mashup. The status of a mashups can be monitored.

Main Interactions

Mashup Editor

Get Mashup Applications or Widgets from an external Catalogue

Getting both Mashup Applications and Widgets from an external catalogue is one of the main interactions to be performed in the Mashup Editor of the Composition Editor GE. When the user needs a new resource (Mashup or Widget), she looks for it in the Marketplace in order to get a list of offerings. If she finds the offering she is looking for, she demands it to the Marketplace, getting a returned value MashupDescription (or WidgetDescription) which includes the USDL of the resource enriched with the declarative description of the mashup (MDL) or the Widget (WDL).

Once the Composition Editor has the description, it will be delivered to the Composition Execution to have it deployed in its local catalogue, sending back a unique value which identifies the deployed Mashup or Widget. Using this identifier, the Mashup can be instantiated in the Composition Execution, and thus be executed.

Figure 3.2.6: Interaction with the Marketplace, Repository and Composition Execution GEs

This interaction can also make use of the merge functionality, allowing the user to merge two different mashups into a single application.

Add Widgets to a Mashup Application

The Add a Widget to a Mashup Application interaction deploys a new Widgets in the Composition Execution to have it instantiated within a selected mashup (usually the mashup being developed). This interaction follows the process of looking for the needed Widget in the Marketplace and then use its functionalities to get the Widget description. By using this description, the Composition Execution can instantiate the Widget within the selected Mashup Application, enhancing its functionality.

Figure 3.2.7: Adding a new widget to the current mashup application

Figure 3.2.7 describes how the user can use the Composition Editor to include a new Widget into her Mashup Application.

Export Mashup Applications or Widgets

This interaction provides the description of the Mashup (or Widget) being edited in order to either store it in the Repository, deploy it to the Composition Execution engine, or just leave a local copy of the description in the user hard disk. A returned value MashupDescription (or WidgetDescription) will contain the USDL + MDL (or WDL) description of the Mashup (or Widget).

Figure 3.2.8: Exporting the Mashup Application to the Repository

Figure 3.2.8 describes how the user can share her mashup with others by storing it into a Repository. The way the Repository uploads the new mashup to the Store in order to be offered from there is out of the scope of this interaction.

Get Packaged Mashup Applications or Packaged Widgets

This interaction allows the user to have either a packaged Mashup Application or a packaged Widget. The packaging format acts as a container for files used by a Mashup Application or a Widget.

Figure 3.2.9: Interaction with the Composition Execution to get the Mashup Application or Widgets in a packaged format

Figure 3.2.9 shows how the user can use the Composition Editor to download the packaged Mashup or Widget. To do so, a packaged parameter is set on true.

Interconnect Widgets

This functionality allows users to connect a Widget (or a set of them) to another Widget (or to another set of them), by means of a Channel, a kind of a Operator element. The Composition Editor will aid the user to connect one or more of the possible outputs of a Widget with the input of a Channel, and then to connect the output of the Channel with one or more of the inputs of a Widget.

This way, data flows between Widgets allowing the mashup application to act as an information and process dashboard.

Figure 3.2.10: Widget Interconnection Management process

Figure 3.2.10 shows how the user creates a new channel between two Widgets, and how then she can remove the connection.

Connect a Widget with backend services by means of Operators

This functionality creates the binding between the front-end interface and a specific backend service. To do so, user can make use of Operator elements. By connecting the backend service to the Widget using different kind of operators, users can adapt o filter the data they really needs.

Figure 3.2.11: Connecting Widgets with backend services

The figure shows how the user creates the binding of a services backend with the Widget by means of unary Operators.

Add Marketplace

The Composition Editor will allow end users to access and look for the resources (mashup, widgets and backend services) they need. To do so, Marketplaces must be accessible from the Editor and new ones could be added from time to time. This functionality adds the Marketplace URI to the internal list of marketplaces of the Composition Editor.

Figure 3.2.12: Adding the URL of a new Marketplace

Composition Editor

Create Composite Services

This functionality allows the end user to create a new composition skeleton using graphical representation for data and control flow and for service placeholders. This is the main function and will be detailed further. Note that this functionality is not available as an API to be used from other architecture components, but functionality exposed to the end user via a GUI.

  • Create/Edit Service Description
Thid function offers user sth epossibility to create and edit composnent services. When creating a service description the user specifies what service type(s) this service is (e.g. SOAP, REST, SIP, etc). Then the user specifies values for the attributes that will be used when invoking the service (e.g. in case of a SOAP service the namespace, the port, the operation, the parameters passed to the operation, etc). The attributes to be specified could be either fixed or variable. Once a service is created it is stored in the local descriptions storage. Subsequently the user can browse and edit the description of component services that can be used in the composition.
Figure 3.2.13: Create New Service Description

  • Create/Edit Skeletons
In building the composition several building blocks are added iteratively, using the GUI. The building blocks expose data flow, control, and service invocation functionality (e.g. StartElement ServiceTemplate, Condition, StateManager Command, Goto, End). Connections between skeleton elements denoting result scope and partial order may be also edited. Two types of constraints are present in the context of skeletons, the skeleton constraint and the service constraints. The service constraints are being used for selecting the appropriate service during skeleton execution upon runtime. The service constraints are mandatory in the service template element and the skeleton constraint is optional in the skeleton start element. Once a skeleton is created it is stored in the local descriptions storage. Subsequently the user can browse and edit available skeletons.
Figure 3.2.14: Create New Skeleton

Import and Expoert

  • Import Service Descriptions and Skeletons

This operation imports (composed) service descriptions from a Repository GE to the local descriptions storage. Out of the list of available service descriptions and compositions only a subset may be selected. Note that from the perspective of the Repository and the USDL description part there is no differentiation between compositions (i.e. skeletons) and the other service descriptions. The Composition Editor however will make the difference and can edit and deploy the composed services in a Execution Engine to be run, while simple service descriptions can be used by the editor only as a component service in a skeleton and needs to be already up and running when the composition is triggered.

Figure 3.2.15: Import from Repository

  • Export Service Descriptions and Skeletons

This operation exports (composed) service descriptions from the local descriptions storage to a Repository GE. Out of the list of available service descriptions and compositions only a subset may be selected. The description of a (composed) service may contain a USDL description providing a high level business description in addition to the technical description for the use of an Execution Engine. The latter may provide both the description of the API technology used for exposing/using this service and the composition skeleton that describes the runtime execution of the service in a formal composition language (if applicable).

Figure 3.2.16: Export To Repository

Search Marketplace for Services

The Composition Editor may allow end users to search for the service they need. To do so, Marketplaces need to be queried, and the editor may allow detailed query construction based on constraints on USDL and other technical service description parameters.

Figure 3.2.17: Search in Marketplace

Manage Services for Execution

Through this UI the user may control how the service is deployed on the execution engine and specify execution parameters such as logging and tracing. Moreover the UI may be used to visualize results and additional information associated with previous runs. See also paragraph 3.2 in the "FIWARE.OpenSpecification.Apps.CompositionExecution" of the specification.

Figure 3.2.18: Manage Execution Example

Basic Design Principles

  • API Technology Independence
The API abstracts from the concrete implementation technology. Implementations using various kinds of platforms and frameworks should be possible.
  • Web Browsers do not have to limit the functionalities of the Composition Editor GE
HTML5, CSS and JavaScript must be used to fully exploit the brand new Web applications capabilities.
  • User-matched interaction abstraction level
Editors could cater for different user expertise (from technical experts with skilled in the composition language to domain experts without technical expertise or even simple end-users with no programming or technical skills) and roles (from composed service creators, to resellers and finally to prosumers) by hiding complexity behind different types of construction blocs, trading off flexibility for simplicity.

Detailed Specifications

Open API Specifications

The Composition Editor GE will access the Repository, Registry and Marketplace via their REST API:

Other Open Specifications

The Composition Editor GE will use information retrieved from the Repository and the Marketplace using the Linked USDL specifications:

Re-utilised Technologies/Specifications

The Composition Editor GE requires both authentication and authorization in order to safeguard the different compositions from its users.

On the other hand, Composition Editor relies on the Marketplace, Store and Repository GEs, so it must support the following technologies and specifications:

  • RESTful web services
  • HTTP/1.1
  • JSON and XML data serialization formats
  • Linked USDL

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • Aggregator (Role): A Role that supports domain specialists and third-parties in aggregating services and apps for new and unforeseen opportunities and needs. It does so by providing the dedicated tooling for aggregating services at different levels: UI, service operation, business process or business object levels.
  • Application: Applications in FIWARE are composite services that have a IT supported interaction interface (user interface). In most cases consumers do not buy the application, instead they buy the right to use the application (user license).
  • Broker (Role): The business network’s central point of service access, being used to expose services from providers that are delivered through the Broker’s service delivery functionality. The broker is the central instance for enabling monetization.
  • Business Element: Core element of a business model, such as pricing models, revenue sharing models, promotions, SLAs, etc.
  • Business Framework: Set of concepts and assets responsible for supporting the implementation of innovative business models in a flexible way.
  • Business Model: Strategy and approach that defines how a particular service/application is supposed to generate revenue and profit. Therefore, a Business Model can be implemented as a set of business elements which can be combined and customized in a flexible way and in accordance to business and market requirements and other characteristics.
  • Business Process: Set of related and structured activities producing a specific service or product, thereby achieving one or more business objectives. An operational business process clearly defines the roles and tasks of all involved parties inside an organization to achieve one specific goal.
  • Business Role: Set of responsibilities and tasks that can be assigned to concrete business role owners, such as a human being or a software component.
  • Channel: Resources through which services are accessed by end users. Examples for well-known channels are Web sites/portals, web-based brokers (like iTunes, eBay and Amazon), social networks (like Facebook, LinkedIn and MySpace), mobile channels (Android, iOS) and work centers. The access mode to these channels is governed by technical channels like the Web, mobile devices and voice response, where each of these channels requires its own specific workflow.
  • Channel Maker (Role): Supports parties in creating outlets (the Channels) through which services are consumed, i.e. Web sites, social networks or mobile platforms. The Channel Maker interacts with the Broker for discovery of services during the process of creating or updating channel specifications as well as for storing channel specifications and channeled service constraints in the Broker.
  • Composite Service (composition): Executable composition of business back-end MACs (see MAC definition later in this list). Common composite services are either orchestrated or choreographed. Orchestrated compositions are defined by a centralized control flow managed by a unique process that orchestrates all the interactions (according to the control flow) between the external services that participate in the composition. Choreographed compositions do not have a centralized process, thus the services participating in the composition autonomously coordinate each other according to some specified coordination rules. Backend compositions are executed in dedicated process execution engines. Target users of tools for creating Composites Services are technical users with algorithmic and process management skills.
  • Consumer (Role): Actor who searches for and consumes particular business functionality exposed on the Web as a service/application that satisfies her own needs.
  • Desktop Environment: Multi-channel client platform enabling users to access and use their applications and services.
  • Front-end/Back-end Composition: Front-end compositions define a front-end application as an aggregation of visual mashable application pieces (named as widgets, gadgets, portlets, etc.) and back-end services. Front-end compositions interact with end-users, in the sense that front-end compositions consume data provided by the end-users and provide data to them. Thus the front-end composition (or mashup) will have a direct influence on the application look and feel; every component will add a new user interaction feature. Back-end compositions define a back-end business service (also known as process) as an aggregation of backend services as defined for service composition term, the end-user being oblivious to the composition process. While back-end components represent atomization of business logic and information processing, front-end components represent atomization of information presentation and user interaction.
  • Gateway (Role): The Gateway role enables linking between separate systems and services, allowing them to exchange information in a controlled way despite different technologies and authoritative realms. A Gateway provides interoperability solutions for other applications, including data mapping as well as run-time data store-forward and message translation. Gateway services are advertised through the Broker, allowing providers and aggregators to search for candidate gateway services for interface adaptation to particular message standards. The Mediation is the central generic enabler. Other important functionalities are eventing, dispatching, security, connectors and integration adaptors, configuration, and change propagation.
  • Hoster (Role): Allows the various infrastructure services in cloud environments to be leveraged as part of provisioning an application in a business network. A service can be deployed onto a specific cloud using the Hoster’s interface. This enables service providers to re-host services and applications from their on-premise environments to cloud-based, on-demand environments to attract new users at much lower cost.
  • Marketplace: Part of the business framework providing means for service providers, to publish their service offerings, and means for service consumers, to compare and select a specific service implementation. A marketplace can offer services from different stores and thus different service providers. The actual buying of a specific service is handled by the related service store.
  • Mashup: Executable composition of front-end MACs. There are several kinds of mashups, depending on the technique of composition (spatial rearrangement, wiring, piping, etc.) and the MACs used. They are called application mashups when applications are composed to build new applications and services/data mash-ups if services are composed to generate new services. While composite service is a common term in backend services implementing business processes, the term ‘mashup’ is widely adopted when referring to Web resources (data, services and applications). Front-end compositions heavily depend on the available device environment (including the chosen presentation channels). Target users of mashup platforms are typically users without technical or programming expertise.
  • Mashable Application Component (MAC): Functional entity able to be consumed executed or combined. Usually this applies to components that will offer not only their main behaviour but also the necessary functionality to allow further compositions with other components. It is envisioned that MACs will offer access, through applications and/or services, to any available FIWARE resource or functionality, including gadgets, services, data sources, content, and things. Alternatively, it can be denoted as ‘service component’ or ‘application component’.
  • Monetization: Process or activity to provide a product (in this context: a service) in exchange for money. The Provider publishes certain functionality and makes it available through the Broker. The service access by the Consumer is being accounted, according to the underlying business model, and the resulting revenue is shared across the involved service providers.
  • Premise (Role): On-Premise operators provide in-house or on-site solutions, which are used within a company (such as ERP) or are offered to business partners under specific terms and conditions. These systems and services are to be regarded as external and legacy to the FIWARE platform, because they do not conform to the architecture and API specifications of FIWARE. They will only be accessible to FIWARE services and applications through the Gateway.
  • Prosumer: A user role able to produce, share and consume their own products and modify/adapt products made by others.
  • Provider (Role): Actor who publishes and offers (provides) certain business functionality on the Web through a service/application endpoint. This role also takes care of maintaining this business functionality.
  • Registry and Repository: Generic enablers that able to store models and configuration information along with all the necessary meta-information to enable searching, social search, recommendation and browsing, so end users as well as services are able to easily find what they need.
  • Revenue Settlement: Process of transferring the actual charges for specific service consumption from the consumer to the service provider.
  • Revenue Sharing: Process of splitting the charges of particular service consumption between the parties providing the specific service (composition) according to a specified revenue sharing model.
  • Service: We use the term service in a very general sense. A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. Services could be supported by IT. In this case we say that the interaction with the service provider is through a technical interface (for instance a mobile app user interface or a Web service). Applications could be seen as such IT supported Services that often are also composite services.
  • Service Composition: in SOA domain, a service composition is an added value service created by aggregation of existing third party services, according to some predefined work and data flow. Aggregated services provide specialized business functionality, on which the service composition functionality has been split down.
  • Service Delivery Framework: Service Delivery Framework (or Service Delivery Platform (SDP)) refers to a set of components that provide service delivery functionality (such as service creation, session control & protocols) for a type of service. In the context of FIWARE, it is defined as a set of functional building blocks and tools to (1) manage the lifecycle of software services, (2) creating new services by creating service compositions and mashups, (3) providing means for publishing services through different channels on different platforms, (4) offering marketplaces and stores for monetizing available services and (5) sharing the service revenues between the involved service providers.
  • Service Level Agreement (SLA): A service level agreement is a legally binding and formally defined service contract, between a service provider and a service consumer, specifying the contracted qualitative aspects of a specific service (e.g. performance, security, privacy, availability or redundancy). In other words, SLAs not only specify that the provider will just deliver some service, but that this service will also be delivered on time, at a given price, and with money back if the pledge is broken.
  • Store: Part of the Business Framework, offering a set of services that are published to a selected set of marketplaces. The store thereby holds the service portfolio of a specific service provider. In case a specific service is purchased on a service marketplace, the service store handles the actual buying of a specific service (as a financial business transaction).
  • Unified Service Description Language (USDL): USDL is a platform-neutral language for describing services, covering a variety of service types, such as purely human services, transactional services, informational services, software components, digital media, platform services and infrastructure services. The core set of language modules offers the specification of functional and technical service properties, legal and financial aspects, service levels, interaction information and corresponding participants. USDL is offering extension points for the derivation of domain-specific service description languages by extending or changing the available language modules.

Personal tools
Create a book