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.LightSemanticComposition - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Apps.Light-weighted Semantic-enabled Composition
Chapter Apps,
Catalogue-Link to Implementation [ N/A]
Owner ATOS, Jesús Gorroñogoitia



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 © 2014 by ATOS

Legal Notice

Please check the following Legal Notice (implicit patents license) to understand the rights to use these specifications. Atos Spain strives to make the specifications of this Generic Enabler available under IPR rules that allow for exploitation and sustainable usage, both in Open Source and proprietary closed source products, to maximize adoption.


Light-weighted Semantic-enabled Composition is a tool suite that aims at simplifying the development of domain-specific business process, such as service compositions, by exploiting the full potential of semantic technologies. Development of business process in BPM (Business Process Modeling) realm requires multi-disciplinary teams, to share domain specific knowledge about processes, entities, roles, etc., as well as the ICT technology required to implement them. In particular the number and complexity of SOA-related technologies may hamper the implementation of business processes when they are meant as aggregations of open and Internet-accessible services.

In this sense, it is desirable that we simplify the access to these composition technologies to the domain specific experts, as well as to the unskilled end users. This can be achieved when the technology itself is capable of producing service compositions without requiring complex information structures, which otherwise can be obtained from end users in a more human readable format.

Target usage

Light-weighted Semantic-enabled Composition addresses situations where domain specific business processes require to be implemented as service compositions within a certain organization. Business processes are decomposed into different tasks, each one executed by an external service (some tasks provided by entities within the same organization, but others provided by third parties). Commonly, designing and implementing a business process as a service composition requires multidisciplinary teams, ranging from domain business experts (such as modelers) to service engineers and integrators. The complexity of these teams, in terms of expertise, is required by the modeling activity itself, since modeling a business process as a service composition requires different expertise:

  • Business analysts with knowledge on the concrete domain concepts, entities, agents, procedures, etc.
  • Business modeling experts, with knowledge on BPM languages, methodologies and practices.
  • Service engineers acting either as service providers and/or consumers, who provide or consume services on the domain, and exploit the technological infrastructure that make them possible.
  • Service Integrators, who orchestrate services into compositions, which offer more complex functionality by aggregating modular functionalities.

The involvement of those multidisciplinary teams, their associated procedures and methodologies, and the required service composition technologies make service composition a complex, time consuming and prone-to-error activity.

A typical scenario of a service composition to facilitate a business process is as follows. The business analyst describes the domain specific scenario, the required business process and related concepts, entities, roles, etc. The business modeler creates a business process model which is iteratively refined by interacting with the business analyst. Ideally this activity can be performed by the same role. The business process model is implemented as a service composition by the service integrator, who aggregates services provisioned by service providers. Commonly, different interaction cycles between the business modeler and the service integrator are conducted to refine and amend the service composition implementation of the business process.

The proposed GE aims to simplify the implementation of some business processes, for instance by enabling business modelers to directly create service compositions without requiring the involvement of service integrators. In this way, the business modelers describes the service composition by using domain specific languages (DSL), vocabularies, and ontologies, to describe the semantics of the tasks into which the service composition is divided.

The technical activities conducted by the service integrator are semi-automatically performed by the GE. In other words, the GE does not prompt the business modeler to provide technical information required for implementing the executable service composition, because the GE obtains that information by exploiting the semantic descriptions attached to the service composition by the modeler from the domain specific ontologies. In this way, a full executable service composition is created without requiring a technical expertise on BPM techniques.

User roles

For the purpose of this description, two main roles are identified:

  • Domain business modelers, who have knowledge about the domain where the business process will be executed as service composition. Therefore, they have the required domain specific knowledge, to model the business process as service composition by using domain specific vocabularies (or ontologies).
  • Service providers, who will deploy and host the service composition model by the business modeler, within the execution environment. They will also take care of composition management at runtime.

Basic Concepts

This section introduces the most relevant functional concepts considered in the Light-weighted Semantic-enabled Composition GE, which are related to the functional components described in the next section about GE architecture.

Light-weighted Semantic-enabled Composition GE is a tool suite supporting the implementation of domain business processes, such as service compositions, executed in backend execution environments as SOA services. Conceptually, this approach can be decomposed in few main concepts described in the following sections:

BPMN Composition Edition

A domain business process is decomposed into single working units or tasks, connected logically by a work flow and a data flow, according to the BPMN (Business Process Model and Notation) specification. Each task is performed by an external service, provided by either the composition provider in the same organization, or by an external third party, accessible through open Web standards.

Light-weighted Semantic-enabled Composition

This approach for the modeling of a service composition describes each composition task using semantic descriptions according to standardized semantic schema (WSMO/OWL-S) and in particular to the light versions (WSMOLite /MicroWSMO ). A practical procedure is to annotate each task with concepts selected from a domain specific ontology. These annotations constitute the semantic goal description of the task, that is, the intended purpose of the task. The task goal is matched against the available semantic service descriptions within a semantic knowledge base repository and the matching services are ranked, allowing the business modeler to select one of them as task binding, or let the system to select the best scored.

Semi-automatic Execution Composition Generation

This concept refers to a semantically annotated service composition with tasks bound that cannot be executed. A complete service composition including the technical bindings and the data flow mappings needs to be generated out of the semantically annotated composition

Composition Deployment and Execution

The composition is ready to be consumed as soon as the service integrator takes the generated executable service composition, selects a target execution environment and deploys the composition into the target.

Light-weighted Semantic-enabled Composition Architecture

Light-weighted Semantic-enabled Composition GE architecture is depicted in the next figure. This architecture is split into two main functional layers: Design and Execution.

Light-weighted Semantic-enabled Composition GE Architecture

The Design layer provides functional support for the modeling of service compositions. The GE constrains service composition modeling to use BPMN 2.0 for both the graphical (modeling) and execution semantics. That is, the GE assumes that service composition models are instances of the BPMN 2.0 standard metamodel.

The following functional components are part of the layers of this GE:

  • BPMN Composition Editor enables business modelers to create service compositions using the BPMN 2.0 Graphical notation and execution semantics. It provides a typical GUI to create, edit and manage service compositions, requiring the business modeler to have some background in BPM modeling.
  • Light-weighted Semantic Mediator complements the BPMN Composition Editor by providing additional semantic-enabled modeling aids that simplifies the modeling process. These assisting features allow business modelers to describe the composition tasks, bind matching services, generate the data flow mapping, and so on.
  • Semantic Knowledge Base complements the Light-weighted Semantic Mediator with a semantic repository of semantic service descriptions, domain specific vocabularies (DSL, ontologies), service composition annotations (tasks, compositions themselves), etc. This component provides content access features, including querying and reasoning.
  • BPMN Manager provides BPMN model management, including features to validate and complete BPMN models with required executable information (e.g. service bindings, data flow mappings, etc.)
  • BPMN Translator provides translation capabilities to other executable composition formats, such as BPEL 1.2/2.0
  • Composition Deployer, which belongs to the execution engine, acts as a proxy between the Light-weighted Semantic-enabled Composition Design layer and the Composition Execution layer. It manages the service composition deployment process into the selected Composition Execution layer.

Components in the design layer interact with some other GE components such as the Marketplace and Repository:

  • Marketplace is used to query and retrieve USDL service descriptions for those services matched to composition tasks through semantic matchmaking, thanks to links contained within their semantic descriptions.
  • Repository contains the technical descriptions (i.e. WSDL , WADL , etc.) of services aggregated in the composition and the composition models (BPMN).

The Composition Execution layer contains the Composition Execution component, which deploys, enables and executes the service compositions, upon remote invocation by a service consumer.

Main interactions performed by the components that comprise this GE are described in next section, grouped by a functional classification.

Main Interactions

A functional classification of Light-weighted Semantic-enabled Composition GE main features is depicted in the next UML use case diagram, and described in more detail in next paragraphs.

Note: This tool defines a specific methodology and all the tasks/operations are mandatory, except when they are indicated as optional.

Light-weighted Semantic-enabled Composition GE functional classification

Model Composition

This GE provides support for service composition modeling, assuming BPMN 2.0 as graphical notation and execution semantics. Through the BPMN Composition Editor, business modelers can create or open composition models, modify (edit) and manage (save, delete) them. Composition models are stored within a Repository.

Composition edition also includes support for creating/updating/deleting features for composition elements, such as service tasks, gateways (exclusive, parallel), flows and events (start, end).

Composition editor allows to select the composition itself or concrete composition elements.

Prepare DSL/Semantics

In the adopted approach, the business modelers describe composition models and their elements by annotating them with concepts taken from concrete domain specific languages DSL (or vocabularies), which provide concrete semantics. From the operational point of view, it is common to use ontologies as DSL or vocabularies. The Light-weighted Semantic Mediator enables the business modeler to:

  • Register new DSL/Ontologies within it.
  • Select a concrete DSL/Ontology for a given domain modeling context and select a concrete DSL/Ontology concept within the domain ontology. These concepts are used to annotate and describe a composition model and their elements.

Describe Model Composition/Task using DSL/Semantics (Business modelers)

The Light-weighted Semantic Mediator enables the business modeler to describe the composition model and its elements using semantic annotations.

In the scope of a composition task, the annotations constitute a description of the goal of the task. This goal will be used in the service matchmaking process to look for services whose semantic description will match it. A semantic task description is constituted by several annotations of a certain type according to the semantic schema used to represent the goal (i.e. MSM).

In the scope of the composition itself, the annotations constitute a description of the global composition requirements, preferences and contextual information.

Describe Service using DSL/Semantics (Service Providers)

The Light-weighted Semantic-enabled Service Composition GE approach assumes that composable services are described using light semantics. Those semantic service descriptions are available within the Semantic Knowledge Base, and are provided by service providers. A service composition created by applying this GE approach is a service by its own, whereby the business modeler, acting as service provider, is required to provide this semantic description. The same applies to any other third party service intended to be composed by others.

The Light-weighted Semantic Mediator enables service providers to create semantic descriptions compliant to the semantic schema used by the complete GE solution. The concrete schema is left for the implementation, but it should be consistent along with all the components that use it.

The schema includes links to the business oriented description stored in the Marketplace, and the technical description stored in the Repository.

Task binding

One of the main jobs in service composition modeling is to bind every service task type: the composition is divided into matching services for each of the task. A business modeler can conduct this task-binding per task or for the whole composition. The Light-weighted Semantic Mediator enables the modeler to discover matching services based on task goal criteria, rank them according to preferences or non-functional requirements (NFR) and select one service, which is bound to the task. Those activities are typically performed by querying the Semantic Knowledge Base.

Validate, generate, translate executable BPMN composition model

Next step in service composition modeling consists on filling the missing information that the composition model requires before being shipped for deployment and execution. Examples of missing information are:

  • Task binding technical description: for each BPMN 2.0 service task, a concrete task binding information has to be included, by inspecting the technical description (i.e. WSDL)
  • Data flow mapping, including I/O mappings at task and composition level

Once the service composition model has been completed with missing required executable information, the composition model is validated (BPMN 2.0 compliance validation) and serialized (for storage and deployment).

Optionally, the composition model can be translated from its original BPMN 2.0 format to another compatible format, such as BPEL 1.2/2.0. This is required when the select target environment for execution is not BPMN 2.0-compatible.

Deploy composition model

Full executable validated composition models can be deployed into the selected target Composition Execution environment, using the Composition Deployer. Once deployed, the service composition is enabled, being ready to received incoming requests from service consumers.

Similarly, deployed service compositions can be undeployed any time.

Composition Execution

During the execution time, deployed services can be enabled or disabled any time through the Composition Execution UI. Besides this, running (enabled) compositions can be continuously monitored and monitoring data can be collected for given time frames.

Next paragraphs detail the main operations using UML sequence diagrams for the most relevant scenarios concerning the light-weighted semantic modeling of a service composition.

Modeling a BPMN Composition

A business modeler, through the BPMN Composition Editor, can either:

  • Create a new BPMN composition model.


  • Open an existing one from the Repository, using a unique model Id. The unique model Id is provided by the Repository during the model saving.

The business modeler can work on this composition model, editing the model and its elements. This activity includes create/edit/delete operations on model elements such as tasks, gateways, flows, events, etc. Each model element is uniquely identified by a unique identifier (within the model) provided by the editor upon creation.

Anytime, during the modeling of the composition, the business modeler can either:

  • Save the composition model into the Repository. This process requires serializing the BPMN composition model according to the BPMN 2.0 serialization standard (XSD/XMI).
  • Delete the model from the Editor and Repository (in case the model was previously saved). Models are identified within the repository by a unique identifier.

Modeling a BPMN Composition

Modeling a composition using light-weighted semantics

A composition work-flow and its tasks decomposition can be modeled by using the BPMN Composition Editor itself. However, once each task has to be bound to concrete services or the data flow mapping has to be designed, the light-weighted semantic composition approach comes up.

This GE encourage modelers to describe composition task by attaching light-semantic annotations, according to some pre-established task goal schema (for instance WSMOLight/MicroWSMO) which are taken from domain-specific ontologies, or any other domain specific language (DSL) or vocabulary. Based on this semantic task goal, the semantic matchmaking activity determines the best matching service and binds the task to it.

The next UML sequence diagram describes the overall process in detail, decomposed by operation and involved components.

Modeling a composition using light-weighted semantics

Domain Ontologies preparation phase

A business modeler selects the suitable domain specific ontology that will be used to describe the composition tasks, depending on the concrete context which the composition will be applied to.

If the domain ontology has not being previously registered within the Light-weighted Semantic Mediator, the modeler registers it by giving the ontology URL. The ontology is downloaded from that URL and stored within the Semantic Knowledge Base. The ontology has to be accessible in a compatible format with the Semantic Knowledge Base (i.e. serialization format such as RDF/XML , N3 , etc.).

Any time during the composition modeling the business modeler can switch from one domain ontology to another by selecting them in the Light-weighted Semantic Mediator. The selected ontology is loaded from the Semantic Knowledge Base. Ontologies are uniquely identified within the GE implementation by an URI.

Lightweighted semantic composition modeling

A business modeler can start this activity either by annotating the composition itself (global annotations) or the concrete composition elements (particular tasks).

Global annotations describe the composition global requirements, preferences and contextual constrains, as stated by the selected semantic annotation schema (i.e. WSMOLite/MSM). Any annotation is concretized by a selected ontology concept (with an URI and a type). Each annotation is stored within the Semantic Knowledge Base (with the annotation type, annotation concept and process URI).

Tasks are semantically annotated in a light weighted manner to describe them, according to the selected semantic annotation schema (i.e. WSMOLite/MSM). Each annotation is stored within the Semantic Knowledge Base, given the annotation type, annotation concept and task URI.

Once the business modeler has described all the tasks within the model using light-weighted semantic annotations, he proceeds to bind each task to a concrete external service. This can be done automatically for the whole composition, whereby all tasks are automatically bound to the best-ranked compatible service, matched by the matchmaking process, or semi automatically, task by task where selection is conducted by the business modeler. Nonetheless, this process, either manual or automatic, is similar.

There are two ways to search services:

  • The Light-weighted Semantic Mediator is invoked to search for services, whose semantic descriptions match the task goal description. Using this local task goal description, a semantic query (i.e. SPARQL) is prepared and sent to the Semantic Knowledge Base, which returns a list of unranked matches (candidate service descriptions). Based on global annotations (requirements, preferences and context constrains), candidate services are filtered out (according to requirements and context constraints) and ranked (based on preferences), by querying and reasoning the Semantic Knowledge Base.
  • The Marketplace GE is invoked to search services which are published by service providers in different Stores. Nevertheless, this discovering is not a semantic matchmaking and it is based on syntactic searching through keyword criteria. The Marketplace GE returns the list of services, which contain these keywords, and the rating of them. Hence, the modeler can visualize the detail of the best service to determine if it is the appropriate. Afterwards, he can choose the method that should be bind to the analyzed task.

Finally the best-ranked candidate service is automatically selected, or the business modeler selects one by inspecting the service candidate list, using descriptions obtained from the Marketplace. The selected service is then bound to the task in the Semantic Knowledge Base.

Process a complete executable BPMN composition model

A semantically fully processed composition model, once its tasks have been bound to semantically annotated services, contains all the information required to create an executable composition model.

This procedure is initiated by the service provider who requests the processing of the BPMN model through the Light-weighted Semantic Composition Editor. This procedure conducts two main jobs for each composition task:

  • Task binding is included in the BPMN composition model, according to the BPMN specification, by getting the technical required information from the technical description stored within the Repository.
  • Task data flow mapping (IO mapping) is included in the BPMN composition model, according to the BPMN specification as well. Data flow mapping considers all data objects available before reaching this task, following in the workflow.

Once the BPMN executable composition model has been created, it is validated against the BPMN specification.

Optionally, the BPMN executable composition model can be converted into another executable model, compliant to another composition language, such as BPEL 1.2/2.0. This could be required by the target Composition Execution Environment.

Finally, the executable composition model is serialized into XML or any other standardized serialization schema for interchange, as determined by the selected target execution language (BPMN XSD/XMI, BPEL XSD, etc.).

Process a complete executable BPMN composition model

Deploy a service composition model

A service composition model can be deployed within a selected target. A service provider selects the target execution environment and deploys the current composition model edited in the Light-weighted Semantic Composition Editor. The Deployer returns the URL where the deployed composition is listening as service or any other required information to invoke it.

Anytime after deployment, the service provider can enable or disable the composition (depending on its status) through the Composition Execution UI. Moreover, through this UI, the service provider can monitor a composition within a specified time frame.

Deploy a service composition model

Basic Design Principles


This GE follows the following design principles:

  • Machine and human based computation principle

This GE allows a semi-automatic (human and machine) service composition modeling.

  • Template-based composition

Recently created process models (and some fragments) can be reused in future modeling tasks.

  • Reusable

This GE is completely domain-independent concerning the knowledge intensive reusability feature.

  • Composability principle

The GE design allows it to split a complex process-modeling problem into several smaller ones that the GE resolves separately by its specific agents.

  • Openness principle

This GE can be easily extended either by coding/replacing architectural components.

  • Ontology based principle

This GE extensively uses ontology-based knowledge.

Detailed Open Specifications

Open API Specifications

The Light-weighted Semantic-enabled Composition GE is not exposed as a service but as a Web application (GUI), accessed through the end user Web browser. Although some GE components are exposed as services, they only expose an API for internal consumption (within the GE), but it is not expected they will be integrated by other GEs.

The Light-weighted Semantic-enabled Composition GE will access the Marketplace and Repository REST APIs:

Re-utilised Technologies/Specifications

The Light-weighted Semantic-enabled Composition GE relies on following technical specifications:

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It is meant 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