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

FIWARE.ArchitectureDescription.Apps.CompositionEditor

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 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.
File:ACE-SD-createNewServiceDescription.png
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.
File:ACE-SD-createNewSkeleton.png
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.

File:ACE-SD-importFromRepository.png
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).

File:ACE-SD-exportToRepository.png
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.

File:ACE-SD-searchInMarketplace.png
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.

File:ACE-SD-manageExecution.png
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.
Personal tools
Create a book