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

FIWARE.ArchitectureDescription.Apps.CompositionExecution

From FIWARE Forge Wiki

Jump to: navigation, search

Contents

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.
Personal tools
Create a book