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

FIWARE.OpenSpecification.Apps.CompositionExecution

From FIWARE Forge Wiki

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


Contents


Preface

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

  • Copyright © 2012 by UPM and EAB and DT

Legal Notice

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

Overview

The Composition Execution engine is the enabler in charge of exposing and executing the application mashups and the composed services. It deploys mashups and services using technical service descriptions (USDL+MDL/WDL/BPMN/BPEL/etc) fetched from the Repository GE and locally stored in the Local Catalogue.

The GE offers three alternative types of engines that cater to different composition descriptions and application domains. The first one is a mashup container able to execute applications built from discrete front-end components (e.g. widgets/widgets, apps), offering inter-widget communication, mashup state persistence and cross-domain proxy facilities. The decentralized nature of mashups demands this execution engine to coordinate widget execution and communication within the mashup. This engine allows the addition of extra functionality as external modules (i.e. security, publish/subscribe and piping modules).

The second one is a service orchestration engine supporting the deployment, execution (upon invocation), monitoring, life cycle management and undeployment of service orchestrations, implemented using standard process composition languages, such as BPMN and BPEL. The engine interactions between the composition and the external services may be mediated through the mediator proxy services.

The third engine type is a service composition engine using a model-driven approach to composition creation based on composition skeletons (see FIWARE.ArchitectureDescription.Apps.CompositionEditor#Composition_Editor). The skeleton includes the main parts of the business logic of the composed services. During the run-time the composition engine dynamically decides about what services to invoke or which data source to use based on constraints evaluated at that particular time. Essentially the composition engine is creating the workflow step-by-step during runtime, and different composition decisions can be taken depending on external events or on the return values of previously executed services.

Target usage

The Composition Execution exposes and executes the composed services. The service provider/operator deploys services/mashups by fetching technical service descriptions and composition description from the repository. This most likely will happen through a graphical user interface in the Composition Editor. The service provider/operator controls execution modes (start, stop, debug), and can fetch logs and tracing data, most likely through the Composition Editor GUI.

Basic Concepts

The basic concepts of the three types of execution engines representing the GE are presented here.

Mashup Execution Engine

The Composition Execution GE makes use of the same mashup, widget and service descriptions than the Composition Editor GE in order to have them instantiated and executing. The availability of these descriptions helps decoupling the GE from the Repository.

Figure 3.2.1: Mashup Execution Engine Architecture

The Mashup Execution Engine mainly executes on the client side as widgets must run in a browser environment (where they can make use of html, css, javascript, etc.). However, some operations may require, at least partially, be executed in a server. For example, widget preferences will usually be stored in a server.

Mashup Execution Modules may affect both client and server sides. They may extend the javascript API provided to widgets to allow them to use the new functionalities provided by the module.

Widget Interface

Interaction between the Mashup Execution Engine and widgets is performed using a Javascript API. Widgets use this Javascript API as an access point to the features of the Mashup Execution Engine in the scope of widgets like the interconnection between widgets.

Service Composition Engine

File:ServiceCompositionEngineArch.png
Figure 3.2.2: Service Composition Engine Architecture

Composite applications are created as “application skeletons”, designed as a model of the core business-logic of the application in terms of participating constituent services. Protocol-level details related to the interaction with modules are left to the Composition Execution Agents (CEAs), which are responsible for enforcing composition decisions in the corresponding platform in a technology and protocol specific way. A shared state is used as means of mediating information between the application skeleton and the CEAs, thus coordinating the service execution. A variety of CEAs has been developed. The process is triggered by a composition execution agent (CEA) that receives a triggering event and requests the next step from the composition engine. Based on what the triggering events was, the composition engine selects the matching skeleton and creates a new session. Then, at each step it selects a suitable service that matches all the global and local constraints and serves it to the agent to execute. Execution results from the previous steps together with potential external events can influence the constraint-based decision process selecting the service for the new step. If several services are suitable to implement a certain step one of them is chosen. If a component service fails during execution, the next compatible one might be executed instead.

An essential component of the presented service composition technology is the use of formal technical service descriptions for all constituent services. This service description is important for runtime service discovery, selection and invocation. It is comprised of information about the service API and service binding information.

The local descriptions storage keeps skeletons and service descriptions previously obtained from the Repository GE. Further the user can enable/disable the service and skeletons and also controlling the execution, specifying logging and tracing behaviour.


Main Interactions

Mashup Execution Engine

Mashup container operations

Deploy a Mashup or Widget into the local catalogue

The operation Deploy Mashup is used to deploy a mashup into the local catalogue, having it ready for later instantiation and execution within the mashup execution engine. The operation is invoked by an agent (usually the mashup developer via the user interface of Mashup Composition Editor). It needs a complete mashup description including both USDL and MDL as described in the Composition Editor GE Open Specification. A returned mashupID value is a unique value which identifies the mashup and it will be used later by other modules.

The operation Deploy Widget is used in the same way that Deploy Mashup, but deploying widgets instead of the whole mashup. It uses the widget description as input. A returned widgetID value identifies univocally the widget.

Once the mashup or widget is deployed into the local catalogue, the operation Get Description is used to retrieve either the mashup or widget description in order to have it also stored in a Repository. This operation is invoked by the mashup developer and it receives the identifier of the mashup/widget and a boolean value that means whether the description must be packaged or not. If this value is set on true, the W3C Widget Packaging format will be used.

Figure 3.2.3: Interaction with the Mashup Execution Engine to deploy and get descriptions of mashups and widgets

Undeploy a Mashup or Widget

The operation Undeploy Mashup removes a mashup from the local catalogue. It is usually invoked by the mashup developer through the Mashup Composition Editor. It needs the mashupID of the mashup as input data. As a result of this invocation, the mashup editor will get whether the undeployment was successful or not. Undeploying a mashup will not remove its individual widgets from the local catalogue.

The functionality Undeploy Widget removes a widget from the local catalogue. The instance of that widget will be removed too. This operation needs the widgetID of the widget as an input parameter. It will notify the mashup editor whether the undeployment was ok or not.

Figure 3.2.4: Interaction with the Mashup Execution Engine to undeploy mashups and widgets

Instantiate a Mashup or Widget

The Instantiate Mashup functionality instantiates a mashup, available in the local catalogue, in the Composition Execution Engine. This operation is invoked by the mashup developer from the Mashup Composition Editor. It needs the following information to be provided in its call:

  • mashupID: id of the mashup to instanciate.
  • options: instantiation options.
    • newMashupName: title to use for the new mashup instead of the original name.

As a result of this invocation, the mashup will execute in the Composition Execution Engine and it will be available in the mashup developer workspace of the Mashup Editor.

The operation Instantiate Widget instantiates a widget (also available in the local catalogue) into an existing mashup application. The mashup developer invokes this operation from the Mashup Composition Editor. It uses the following parameters as input data:

  • widgetID: id of the widget to instanciate.
  • mashupID: target mashup id.
  • options: e.g. Initial widget title.

As a result of this invocation, the widget will be added to the mashup and they will execute in the Composition Execution Engine. The whole mashup will be available in the mashup developer workspace of the Mashup Editor.

The operation Merge creates a new mashup by merging two existing ones. This operation, just like the rest, is invoked by the mashup developer from the Mashup Composition Editor. It needs the following parameters as input data:

  • mashupID: id of one of the mashups to merge.
  • currentMashupID: id of the other mashup to merge.
  • options: merge options. E.g.:
    • appendTabs: Merge mashups by appending their tabs.

The new mashup will execute in the Composition Execution Engine and its description will be stored in the local catalogue. The returned value mashupID identifies this new merged mashup.

Figure 3.2.5: Interaction with the Mashup Execution Engine to instantiate and merge mashups and widgets

Remove a Mashup or Widget

The operation Remove Mashup removes a mashup application from the Composition Execution Engine. This operation is invoked by the mashup developer from the mashup composition editor when he wants to get rid of the whole mashup application. This operation needs the mashupID of the mashup to be removed. As a result of this operation, the mashup will stop executing.

The operation Remove Widget removes a widget from the Composition Execution Engine. This operation is invoked by the mashup developer from the mashup composition editor when he wants to get rid of the widget in the mashup application being developed. This operation needs the widgetID of the widget in order to have it removed. As a result of this operation, the widget will stop executing.

Figure 3.2.6: Interaction with to stop mashups and widgets executing

Connect Widgets between them or bind them to backend services

When developing a mashup, it is important data can flow between widgets in order to create a fully-functional mashup application. To do so, the following operation are needed:

The operation Create Operator creates a new instance of an Operator element. Operators are a kind of service, and are meant to transform, filter, sort, propagate and/or modify data in piping processes. This operation needs the following parameter in its call:

  • name: name to assign to the instanciated operator.
  • type: type of the operator.
  • options: operator options. E.g. parameters to use with the operator.

As a result of this operation, a new operator instance is returned.

The Connect functionality connects the output of a connectable element (Widget, Mashup, Operator...) with the input of another connectable element. This operation is invoked when the mashup developer connects widgets between them through channels (a kind of operator) or connects widgets with backend services using operators. It needs the identifier of both connectable elements as an input parameters.

The Disconnect operation performs the other way around. This operation is invoked when the mashup developer want to remove the connection between two connectable elements, so its call needs the two identifiers of the connectable elements to be disconnected.

Figure 3.2.7: Interaction with to stop mashups and widgets executing

Widget Operations

Make HTTP Request

The Get Proxy URL operation is invoked by widgets to obtain a suitable URL for working around the cross-domain problem. This is usually handled by using the cross-domain proxy but it can also be handled by using the access control request headers if the browser support them. In case of meeting all the requirements, this operation will return a simple Url (that is, not using the cross-domain proxy). It needs the following information to be provided in its call:

  • url: target URL.
  • options: request options.

The Make Request operation is invoked by widgets to make ajax requests working around the cross-domain problem. This operation is similar to the Get Proxy URL operation but it makes a request instead of returning a Url.

  • url: target URL.
  • options: request options.

Request options:

  • method (String; default POST): The HTTP method to use for the request. Methods DELETE, GET, PUT and POST must always be supported whereas other methods as HEAD cannot be guaranteed.
  • postBody (String): Specific contents for the request body.
  • contentType (String; default application/x-www-form-urlencoded): The Content-type header for your request. Change this header if you want to send data in another format (like XML).
  • encoding (String; default UTF-8): The encoding for the contents of your request. It is best left as-is, but should weird encoding issues arise, you may have to tweak this.

Push driven operations

Widgets may use these push driven operations to communicate between them. However, the connection between widgets is handled by the platform (usually guided by the end user), thus, widgets must provide information about the type of information it can process and what type of data it can produce in the WDL.

The register callback operation is invoked by widgets to be able to receive events.

  • input name: name of the input endpoint.
  • callback: function that will be called when an event reaches the input endpoint.

The push event operation is invoked by widgets to publish a new event.

  • output name: name of the output endpoint.
  • data: event data.

Preference operations

Widgets may use these operations to retrieve and to be notified of changes in the values of their preferences.

The register preferences callback operation is invoked by widgets to listen to changes .

  • callback: function that will be called when the user changes any preference.

The read preference operation is invoked by widgets to retrieve the current value of a preference.

  • preference name: name of the preference as defined in the WDL of the widget.


Service Composition Engine

The interactions described below are basic functionality provided by the Service Composition Engine to an external controller. Most likely the composition editor is the right tool to provide a GUI that will allow the end user to control the Service Composition engine.

Import

This operation imports a service or a skeleton description (e.g. from the Repository GE) into the local descriptions storage.

Export

This operation exports a service or a skeleton description from the local descriptions storage (e.g. to the Repository GE).

Remove

This operation removes a service or a skeleton description from the local descriptions storage. Only disabled skeletons and services can be removed.

Enable

This operation prepares a service or a skeleton description from the local descriptions storage for execution. In case of a skeleton it instantiates the composed application skeleton and makes it ready to be triggered for execution. Only enabled services will be considered during the skeleton execution.

Disable

This operation removes a service or a skeleton description from the executable list.

Service Orchestration Engine

Composition deployment based on standard business process language

This functionality deploys a service composition, implemented as an standard business process orchestration on the execution engine. Once deployed, the composition is ready for execution upon invocation.

Input Parameters

  • composition_file - The service composition to be deployed, specified using standard BPM composition languages, such as BPMN or BPEL.

Output Parameters

  • result - The result of the operation

Fault Parameters

  • reason - Parameter allowing to identify the reason for fault for further exception handling.

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.
  • The Composition Execution GE must provide a cross-domain proxy facility
Widgets can use a cross-domain proxy for accessing services without taking into account whether they are accessed by means of cross-domain requests or not.
  • Specifications of the Composition Execution GE are not tied to a particular technology for storing mashup, widget and service data
The specific technology used for storing the inventory of Resources (mashups, widgets and services) and their respective associations is not tied to any type of storage solutions, being opened to final implementations through SQL (MySQL, Oracle, ...) or No-SQL systems (MondoDB, Casandra, ...).
  • Widget execution isolation
Widget execution does not have to interfere in the execution of other widgets.
  • Composite service exposure via different API technology
Depending on what CEAs are available, a composed application can be exposed to the outside world via different API technologies
  • Execution engine deployment
An execution engine implementation might be highly distributed and scalable, if intended to be used by many parties on a global scale.


Detailed Specifications

Open API Specifications

The Composition Execution GE will access the Repository and Registry via its REST API:

Other Open Specifications

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


Re-utilised Technologies/Specifications

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

On the other hand, Composition Execution uses 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