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

FIWARE.OpenSpecification.Apps.ApplicationMashup R4

From FIWARE Forge Wiki

Jump to: navigation, search
FIWARE WIKI editorial remark:
This page corresponds with Release 4, please refer to Summary of FIWARE Open Specifications for the current Open Specs of the GEs of FIWARE
Name FIWARE.OpenSpecification.Apps.ApplicationMashup
Chapter Apps,
Catalogue-Link to Implementation Wirecloud
Owner UPM, Álvaro Arranz



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


  • Copyright © 2012-2016 by UPM

Legal Notice

Please check the following FIWARE Open Specification Legal Notice (implicit patents license) to understand the rights to use this open specification.

Note: UPM provides the software associated to the Application Mashup, Wirecloud, as open source under Affero General Public License version 3 (AGPL v3) with a classpath-like exception so widgets and operators can be licensed under any license. Please check the specific terms and conditions linked to this open source license at https://github.com/Wirecloud/wirecloud/blob/develop/LICENSE.txt


Web application mashups integrate heterogeneous data, application logic, and UI components (widgets/gadgets) sourced from the Web to create new coherent and value-adding composite applications. They are targeted at leveraging the "long tail" of the Web of Services (e.g. the so-called Web APIs, which have proliferated during recent years and have doubled in number during 2012. See programmableweb.com) by exploiting rapid development, the Do-It-Yourself (DIY) metaphor, and ability to share. They typically serve a specific situational (i.e. immediate, short-lived, customized, specific) need, frequently with high potential for reuse. It is this "situationality", which prevents them from being offered as 'off-the-shelf' functionality by solution providers.

Web application mashups can be manually developed using conventional web programming technologies, but this fails to take full advantage of the approach. Application mashup tools and platforms such as the one being specified by the FI_WARE's Application Mashup GE are aimed at development paradigms that do not require programming skills and, hence, target end users (being them business staff, customers or citizens). They also help to leverage innovation through experimentation and rapid prototyping by enabling their users (a) to discover the best suited mashable components (widgets, operators and off-the-shelf mashuplets) for their devised mashup from a vast, ever-growing distributed catalogue, and (b) to visually mash them up to compose the application.

Key features of the Application Mashup GE that will be covered by this open specification are:

  • Support for a Platform-independent Mashable Application Component Definition Language (MACDL), which is needed to describe the application mashup and its building blocks so that any platform implementing the GE's open specifications will be able to instantiate and execute them. This language is deeply described later as part of this open specification.
  • Support for XML/RDF schemas for the MACDL, containing all widget-, operator- and mashup-related contextual information, plus all the preferences, persistent variables, and wiring/piping, context and rendering information (i.e. elements that manage the platform-component interaction) required to support application mashup persistence and to instantiate and run the application mashup on a platform that conforms to these open specifications.
  • Compatibility with the USDL specification: mashable application component descriptions can be linked to USDL documents using the RDF flavour of the MACDL.
  • Support for a zipped file format (WGT) that allows mashable application components to be conveniently stored and distributed.
  • Support for wiring: a mechanism empowering end users to easily connect widgets in a mashup to create a fully-fledged event-driven dashboard/cockpit with RIA functionality. Alternative wiring editors can be implemented, provided that they generate a MACDL description of the resulting mashup.
  • Support for piping: a mechanism empowering end users to easily connect widgets to back-end services or data sources through an extendable set of operators, including filters, aggregators, adapters, etc. Different piping editors (commonly offered as part of a wiring editor) are allowed provided that they give a MACDL description of the resulting mashup.
  • Support for visual rendering of the widgets in the application mashup UI. Different editors are allowed as long as they provide a description of the resulting mashup in MACDL.
  • MAC (widget, operator and mashup) life-cycle management support.
  • An application mashup execution engine model capable of deploying and running a mashup from a MACDL file. It provides support for managing mashup state persistence, and for managing the wiring and piping mechanisms.
  • Support for interaction with a catalogue of MACs: the catalogue empowers end users to store and share their newly created application mashups with other colleagues and users by communicating with the Store GE.

This document contains all the information required in order to build compliant products that can work as alternative implementations of the Application Mashup GE and therefore may replace any implementation developed in FIWARE within a particular FIWARE Instance.

Target usage

FIWARE strives to exploit the ability to compose application and service technologies, thus enabling to support cross-selling and to take advantage of the derived network scaling effects in multiple ways. The platform enables composition either from the front-end perspective --application mash-ups- or the back-end perspective --composite services. Specifically, the Application Mashup GE targets composition from the front-end perspective and is expected to leverage the creation and the execution of value-added applications not only by application providers, but also by intermediaries and end users acting as composers, a.k.a. prosumers. Prosumers are consumer-side end users who cannot find an application that fits their needs and therefore modify/create an application mashup in an ad-hoc manner for their own consumption. As the capabilities and skills of the target users being considered are expected to be very diverse, all kinds of usability issues, conceptual simplification, recommendation and guidance, etc. are taken into consideration.

Basic Concepts

Key concepts and ideas

The Application Mashup GE describes a Web platform that helps users to easily and visually create and run their own Web application mashups. Its functionality can be divided into a client-side part running on the user web browser and a server-side part running on a web server.

The Application Mashup GE is based on a composition model already published by the authors of this specification in a journal publication[1] (please refer to that publication for a detailed description of the underlying composition model of this enabler), which has been specifically designed to empower end users with few or no programming skills to create and share their own web composite applications in a fully visual fashion:

Widgets are the key elements of the composition model that the Application Mashup GE must support. Together with connectors and mashups (mashups are considered as building blocks for other application mashups), they make up the complete set of Mashable Application Components (MAC) that the Application Mashup GE must support. A widget is a lightweight Web application that runs on the user's web browser, in the context of an Application Mashup GE implementation. Widgets are usually developed using current Web technologies (HTML(5), CSS, Javascript, ...) and they are bound to heterogeneous data coming from the Web (e.g. Web APIs). They can be regarded as the service front-end, because they offer to users a graphical user interface (GUI), so that they can easily get a visual representation of the service data and functionality to which the widget is bound.

The figure below shows an example of what iGoogle's widgets (one of the first products to implement this idea) look like:


An example of some isolated widgets coexisting in the same desktop

These early widgets per se are isolated applications that do not interact with each other. However, the Application Mashup GE aims at providing a mechanism to visually compose a fully-fledged web application from different widgets that can now interact with each other via events and data sharing. This mechanism is what the composition model calls wiring. The idea behind wiring is easy: widgets expose (data/event) inputs and (data/event) outputs, so that an output from one widget can be linked to other widgets' inputs following a composition technique based on pre- and post-condition mechanisms. This way, the Application Mashup GE manages the data/event flow between widgets.

The mechanism allows for the use of event-driven programming features, e.g. a widget can send an event through one of its outputs on an event trigger. The figure below shows an example of the wiring metaphor:


An abstract representation of how the Application Mashup GE could support the Wiring mechanism

Widgets supported by the Application Mashup GE must be able to access their data from services in at least the following two ways: programmatically or by means of operators and through a visual technique called piping that establishes how these operators can be combined to form a pipe.

The Application Mashup GE supports the invocation of services programmatically from the widget's code: through what we call WidgetAPI (see the Architecture and Open API Specification page of the GE). Moreover, following the ideas from the composition model, it also supports operator use and the piping mechanism. This targets end users (i.e. users with few or no programming skills): an operator does not offer a GUI but, like widgets, it has an abstract representation with both inputs and outputs and can thus be wired to widgets allowing the data flow between them. Operators are usually bound to some kind of data source (SOAP service, REST API, etc.). In other words, operators are configured out-of-the-box to get access to a backend service, but they can also be made to subscribe to and get events from a publish/subscribe system. They can also act as filters, aggregators, mediators, etc. when used in the piping technique to build a pipe.

To sum up, an implementation of the Application Mashup GE must support the process of visually creating a composite web application by composing different widgets using the wiring mechanism, which interconnects those widgets, along with the piping mechanism, that makes use of operators to get access to new data, perform an operation on that data, and finally pass it to the widgets through their inputs.

The figure below shows and example of what a web application mashup looks like. It is made up of a number of widgets, which interoperate with each other by exchanging data and events following the connections defined by the user. These widgets can be easily repositioned and/or resized to reflect the user needs and/or preferences.

An implementation of the Application Mashup GE showing how the mashup developers can arrange widgets to create their own Web mashup

Example scenario

To illustrate what is expected from the Application Mashup Generic Enabler, we have borrowed the following example scenario from the FInest Use Case Project, which is part of the FI-PPP program (http://www.finest-ppp.eu/). The scenario is part of its Fish transport from Ålesund to Europe use case:

"A fish producer needs to ship frozen/dried fish from Norway to a customer overseas. The scenario covers the feedering phase, i.e. the shipping from Ålesund to Northern Europe. The fish cargo is first delivered at the Port of Ålesund (ÅRH) and stored and stuffed in container at the terminal (Tyrholm & Farstad: TF). The shipping line NCL covers the North Sea voyage (feedering) from Ålesund to Hamburg/Rotterdam, and further shipped overseas by a deep-sea container shipping line (e.g. APL). The process involves customs and food health declarations. The transport set-up is mostly fixed."

As it is: The Port updates the website with information on the port’s services, capacity, resources, and weather (in practice, port calls info updated systematically). This serves as information source for customers (ship agents, terminal operators) and all other stakeholders.

Challenges: Much manual info registration, and a lot of work duplication.

For improvement in the future, the port envisions the following improvements:

  • A marketing portal, like a resource hub accessible from the website, enabling online management of bookings, resources and services as well as communication and coordination with third party service provider systems.
  • Automatic update of Webpages (“ship calling”, “at port”, “departure”, etc.) based on information from SafeSeaNet and actual data from AIS (Automatic Identification System).
  • Online registration of booking directly by the ship / ship agent.

In order to make these improvements, FInest demands from FIWARE the following EPIC that will be covered by the Application Mashup GE:

"FInest.Epic.IoS.WidgetPlatformInfrastructure: A visual portal website is needed where each user can add, remove and use widgets. Therefore, also a widget repository is needed from which a user can select widgets. An infrastructure should be provided to deploy new widgets in the portal. It should be easy for end users to use."

There follows the description of how the Application Mashup GE can be used to help to deal with the envisioned improvements:

  • The functionality and information sources are split into a set of widgets. There is one widget for each resource that will be made accessible from the website: management of bookings and registrations, management of resources, management of services. Widgets from a third party service provider capable of communicating and coordinating with their systems, event-driven widgets connected to SafeSeaNet and actual data from AIS, e.g. "ship calling", "at port", "departure", etc. are also added to the catalogue of available widgets.
  • These widgets are shared and offered through a repository (e.g. provided using the Business API Ecosystem GE) which the project stakeholders and customers (ship agents, terminal operators, etc.) can search to select and retrieve the offerings of their interest.
  • Each customer and stakeholder involved in this scenario, regardless of their level of technical or programming skills can leverage the application mashup editor to visually build a customized cockpit with the most valuable data and operations for their work by adding, removing and using available widgets and mashuplets (off-the-shelf mashups that can be customized by adding and removing widgets to/from them). Moreover, they even can share the resulting application mashup for future use by other customers or stake holders (for further customization).
  • A widget platform (or application mashup container) will serve as the envisioned visual portal website where these customers and stakeholders can easily deploy and use the widgets that make up the application mashup (i.e. the customized cockpit or information/operations dashboard that best fit their interests).

Generic Architecture

This section describes the Application Mashup GE architecture. The diagrams use FMC (Fundamental Modelling Concepts) notation to facilitate the communication not only between technical experts but also between them and business or domain experts. The Application Mashup GE provides the functionality necessary for developing and executing mashups. As the figure below shows, the core of the Application Mashup has three main components: the Composition Editor, the Mashup Execution Engine, and the Local Catalogue.


The Application Mashup GE Architecture

The Composition Editor component is the web-based tool with which end users interact via a web browser in order to create their own mashup applications. This component must, at least, offer end users a kind of workspace where they can spatially place or arrange widgets, plus an extra view of the wiring mechanism to set the interconnection between the arranged widgets. Because this component is a visual editor, this document does not set the visual appearance that this tool must have. It is up to the GE's implementation developers to create their own look & feel for this tool.

The Mashup Execution Engine component is probably the most important part of the GE. It coordinates widget execution and controls the data flow between widgets. It can access the Local Catalogue to deploy and execute stored widgets. The functionality of this component can be connected to and extended by a number of plug-in modules as shown in the Application Mashup GE Architecture figure. Module functionality is exposed to widgets and operators by means of the WidgetAPI (see Open API Specifications). Some of these plug-in modules must always be there:

  • The Cross-Domain Proxy module: this component will provide widgets and operators with a proxy to overcome the JavaScript cross-domain problem.
  • The Wiring Engine Module: this component manages the wiring mechanism.
  • The Mashup State Persistence Module: this module is in charge of guaranteeing the persistence of the MACs under execution. This includes not only to store the widgets and operators involved in the mashup and their state, but also their position in the editor view, their interconnections (wiring and piping) and so on.

It must be possible to enhance widget and operator functionality by adding new modules to the Mashup Execution Engine. For example, a Publish/Subscribe module could be added to provide widgets with the ability to receive and publish data in a pub/sub fashion using the new added module.

All plug-in modules must be able to make use of internal storage (i.e. a database) for their specific persistence needs.

The third main component is the Local Catalogue. This component is where MACs, either purchased from the FIWARE Business API Ecosystem GE or installed (uploaded) by the end-user, are stored, configured, and set ready for deployment and execution. This component should be a kind of showcase for the logged user of the Application Mashup GE.

The following sections describe the languages needed to support widgets, operators and mashups, including the USDL extensions for all business-related GEs to process any MAC as an offering, and the specific file formats used to store and distribute widgets. By implementing these artifacts, a concrete implementation of the Application Mashup GE will support an internal representation of MACs (widgets and mashups), which is necessary to interact with them.

Mashable application component Definition Language (MACDL)

The Application Mashup GE should be implemented as a mashup platform that empowers users to create their own application mashups. Application mashups are made of a set of widgets and operators interconnected with each other (that is, wired). To fully support widgets and operators (and mashups) instantiation, the implementation of the Application Mashup GE must support a platform-independent description language.

The Mashup Application Component Definition Language is the chosen language. It define all the inner information (metadata) regarding MACs including their relationships/interconnections. This includes typical metadata, such as component's name, vendor, version, authors, contact info, but also graphical information such as the location of the widgets on the dashboard, widget width and height, etc.

Mashable Application Component description file

To internally represent and deal with mashable application components, the Application Mashup GE must support their description files (config.xml files). config.xml file contains all the MAC contextual information needed by the Application Mashup plus a set of preferences, persistent variables, wiring and rendering information. Those MAC descriptions can be written using two flavours: XML and RDF.

XML flavour of the MACDL

The latest version of the XML Schema described in the following sections is available at:

Mashable application components descriptions use the http://wirecloud.conwet.fi.upm.es/ns/macdescription/1 namespace for the root element. The name of the root element varies depending on the type of the component: widget, operator or mashup. Whereas it always require the following attributes:

  • vendor: The id of the vendor/distributor of the mashable application component. It cannot contain the character "/".
  • name: Name of the mashable application component. It cannot contain the character "/".
  • version: Current version of the mashable application component. It must define starting sequences of numbers separated by dots. Moreover, zeros can only be used alone (e.g. 0.1 is valid but 03.2 is not). Following a release number, you can have a pre-release tag. A pre-release tag is a serie of letters: a (alpha), b (beta) or rc (release candidate); followed by digits. Pre-release tags make a version be considered older than the version they are appended to. So, revision 2.4 is newer than revision 2.4rc1, which in turn is newer than 2.4b1 or 2.4a1.

These tree fields (vendor, name and version) uniquely identify the mashable application component, therefore there can not be a repetition of such identifier in any collection of WireCloud components (including widgets, mashups, operators, ...).

details element

file: AM_mac_description_details_element.png
The "details" element

Mashable application components descriptions should provide generic information about what you will obtain by using it, information about who develops the component, etc... All this generic information is provided through the details element. This element can contain any of the following elements:

  • title: Name used in the user interface for the mashup application component. Used for example when listing mashable application components. This field can be translated, therefore this field is not used to uniquely identify the mashable application component. This field is also uses as the default title for widgets added to workspaces.
  • authors: Comma separated list of developers, e.g.:
    Álvaro Arranz, Aitor Magan
    You can also provide an email and/or an url:
    Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)
  • contributors: Comma separated list of contributors. Same format than the authors field.
  • email: E-mail address for getting support. It is recommend to provide, at least, this field or the issuetracker as these fields are helpful for people who encounter issues with the component.
  • license: Name of the license associated to the mashable application component.
  • licenseurl: Absolute or description-file-relative URL pointing to the full license document.
  • description: A brief textual description of the mashable application component.
  • longdescription: Relative path to a markdown file describing the mashable application component.
  • changelog: Relative path to a markdown file detailing the changes made to the mashable application component in each version.
  • image: Absolute or description-file-relative URL of the mashable application component image for the catalogue. (170x80px)
  • smartphone: Image to be used in smartphones. (59x60px)
  • doc: Relative path to the markdown file containing the mashable application component documentation. For backwards compatibility, this field also supports an absolute URL to the documentation of the component (pointing to a web page).
  • issuetracker: Absolute URL to the component's issue tracker. It is recommend to provide, at least, this field or the email as these fields are helpful for people who encounter issues with the component.

requirements element

file: AM_mac_description_requirements_element.png
The "requirements" element

The requirements element is used for declaring on which features the component depends on. Currently those features are associated with the injection (by WireCloud) of the API required for accessing a given feature (e.g. a widget can depend on the NGSI feature to notify WireCloud it requires the injection of the NGSI API). In future releases of the Application Mashup GE this element will provide support for adding other kind of dependencies (e.g. with another mashable application component), but for now this element only accepts feature sub-elements.

  • name: Name of the feature required by the application mashup component.

XML elements that manage the Platform-Component interaction

To guarantee the platform-widget interaction, templates also define a set of variables that widgets use to get connected to the environment and set different platform options. Likewise, it also defines some other interface elements, such as the initial widget size. They are all managed by the platform, which will ensure their persistence.

Let us go through all these elements:

The preferences element

The first platform-related element is the preferences one:

file: AM_mac_description_preferences_element.png
The "preferences" element

It defines user preferences, which may be changed through the platform interface. This element is made up of one, many or none preference sub-elements. This defines the actual user preference. It requires the following attributes:

  • type: preference data type: text (string), number, boolean, password and list.
  • name: name of the preference to be referenced in the source code.
  • label: text that the preference will show in the user interface.
  • description: text that describes the preference.
  • default: preference default value.
  • readonly: indicates whether this preference can be modified.
  • value: initial value. If not specified, the default value will be used as the initial value.
  • secure: access to the value of this preference is disallowed if the value of this attribute is true (the value of this preference will be usable through the Application Mashup cross-domain proxy). default: false.

If the type attribute is set to "list", the different choices are defined by means of the option element. It has the following attributes:

  • label: text to be displayed in the selection list.
  • value: value to be used when the option is selected.
The persistentvariables element

The next XML element is the persistentvariables element. Its main purpose is to define a set of variables to store the state of the widget/operator while it is executing, in order to have it available for future executions. Its structure is shown in the figure below:

file: AM_mac_description_persistentvariables_element.png
The "persistentvariables" element

This element is made up of a list of variable elements that require the following attributes:

  • name: property name.
  • type: property data type: only "text" (string) datatype does make sense in here.
  • label: text to be displayed in the user interface.
  • description: Descriptive text.
  • secure: Access to the value of this persistent variable is disallowed if the value of this attribute is true (the value of this variable will be usable through the Application Mashup cross-domain proxy). default: false.
The wiring element

This is probably one of the most important elements. It defines both the inputs and outputs needed by widgets/operators to intercommunicate with other widgets/operators. The Application Mashup GE implementation must take this information into account to manage and control the wiring mechanism and its internal data flow.

The figure below depicts the wiring element:

file: AM_mac_description_wiring_element.png
The "wiring" element.

This element may contain any number of inputendpoint and outputendpoint elements.

Widgets and operators may send data (events) through an output endpoint. To do so, they must declare the endpoint using the outputendpoint element. These elements have the following attributes:

  • name: output endpoint name.
  • type: output endpoint data type: only "text" (string) datatype does make sense in here.
  • label: text to be displayed in the user interface.
  • description: text that describes the output.
  • friendcode: keyword used as an output endpoint tag: it will help the platform to make suggestions in the wiring process.

On the other hand, widgets and operators can receive asynchronous data through the input endpoints. These endpoints are meant to be used by widgets and operators for receiving data (events) coming from other widgets/operators. The inputendpoint element supports the following attributes:

  • name: input endpoint name.
  • type: input endpoint data type: only "text" (string) datatype does make sense in here.
  • label: text to be displayed in the user interface.
  • actionlabel: short text that describes what is going to happen if an event is sent to this input endpoint. Widgets could use this text in buttons, selection boxes, etc... allowing end users to select what to do (and the widget will send an event to the associated target endpoint)
  • description: text that describes the input.
  • friendcode: keyword used as an input endpoint tag: it will help the platform to make suggestions in the wiring process.

Specific Widget metadata

The figure below depicts the structure followed by widget elements (and therefore, the structure followed by widget descriptions):

file: AM_mac_description_widget_element.png
widget structure
The contents element

Widget descriptions must link to the actual source code of the widget. This is done through the contents element.

file: AM_mac_description_content_element.png
The "content" element binds the description with the actual widget source code

The contents element supports the following attributes:

  • src: absolute or description-file-relative URL of widget code.
  • contenttype: linked resource content type: suggested values are: text/html and application/xml+xhtml. This is an optional attribute, with 'text/html' by default. All implementations of the Application Mashup GE must support HTML files (text/xml), other options (like SVG or Flash are optional).
  • charset: Charset used by the source file. This is an optional attribute, with 'utf-8' by default.
  • cacheable: sets if the linked code can be cached by the platform: possible values are "true" and "false". This is an optional attribute, "true" by default.
  • useplatformstyle: Use platform style to display HTML elements. Optional attribute, "false" by default.

In addition to these attributes, the contents element allows to provide a list of extra source files (through the altcontents subelement) that will be use instead of the one provided in the main contents element if the conditions are met (controlled by the scope attribute).

The rendering element

The rendering element specifies the default width and height of the widget once it is deployed in the user workspace.

file: AM_mac_description_rendering_element.png
The "rendering" element

Width and height are its only subelements. They represent the initial width and height of the widget.

Specific Operator metadata

The figure below depicts the structure followed by operator elements (and therefore, the structure followed by operator descriptions):

file: AM_mac_description_operator_element.png
operator structure
The scripts element

While in widgets define it code entry point, in general, through an HTML file, operators, as they do not provide an user interface, need to declare directly the list of javascript files to use. This script list is declared using the scripts element that is composed of one or more script sub-elements. script elements supports the following attributes:

  • src: Absolute or description-file-relative URL of the JavaScript file.

Specific Mashup metadata

The figure below depicts the structure followed by mashup elements (and therefore, the structure followed by mashup descriptions):

file: AM_mac_description_mashup_element.png
mashup structure
The structure element

The structure element is in charge of describing the structure of the mashup. The figure below depicts what it looks like:

file: AM_mac_description_structure_element.png
The "structure" element

The preferencevalue element allows the modification of the initial values of the preferences of the final workspace.

The tab element is used for describing each of the tab that build up the mashup. So this is the key element for describing the visual part of a mashup.

The wiring element is used for describing the wiring/piping configuration of the mashup. This element also is used for describing the operators used in the mashup. Note that this element has the same name to the wiring element used on the root of the description, but this element is different in structure.

The tab element
file: AM_mac_description_tab_element.png
The "tab" element

The structure element should contain at least one tab element that represents tabs in Application Mashup GE dashboard. It has the following attributes

  • name: the name of the tab
  • id: the identification of the tab; this id is internal to the description.

The tab element may contain any number of resource elements which represent widget instances used in the mashup. It has the following attributes:

  • vendor: the widget distributor
  • name: name of the widget
  • version: version of the widget
  • title: name to be displayed in the dashboard.
  • readonly: indicates if the widget can be remove from the dashboard.
  • id: the widget identification; this id is internal to the mashup description.

The preferencevalues and the variablevalues elements allows the modification of the initial values and the behaviour of the preferences an persistent variables respectively. The parametrisation of each preference/persistent variable is controlled by one of those elements and their attributes:

  • name: name of the preference/persisten variable to parameterise.
  • value:: initial value for the preference/persistent variable. If not provided, the initial value of the preference (obtained from the widget description) will be used.
  • readonly: indicates if the preference/persistent variable can be modified.
  • hidden:indicates if the user will be able to see the value for this preference/persistent variable on the user interface of the Application Mashup GE.

The position element describes the widget position into the dashboard. It has the following attributes:

  • x: the widget's X coordinate.
  • y: the widget's Y coordinate.
  • z: the widget's Z coordinate.

The rendering element describes some characteristics of the widget representation. It has the following attributes:

  • width: widget width in the dashboard.
  • minimized: Boolean attribute that defines whether the widget is minimized in the dashboard
  • layout: widget layout in the dashboard
  • height: widget height in the dashboard
  • fulldragboard: Boolean attribute that describes whether the widget is using all the dashboard.
The Mashup's wiring structure element

This element describes how widgets and operators in the mashup are connected using their output and input endpoints.

file: AM_mac_description_mashup_wiring_element.png
The "wiring" structure element

The wiring element may contain any number of operator elements. An operator element defines an operator that is used in the wiring. It has the following attributes:

  • id: identification of the operator; this id is internal to the mashup description.
  • vendor: the distributor of the operator; it cannot contain the character "/".
  • name: operator name; it cannot contain the character "/".
  • version: current operator version; it must define starting sequences of numbers separated by dots where zeros can only be used alone (e.g. 0.1 is valid but 03.2 is not).

The wiring element may contain any number of connection elements. These elements describe which output endpoints are connected with which input endpoints. The connection elements are composed of a source element and a target element.
The source element defines the output endpoint of the connection. It has the following attributes.

  • type: type of the element that has the output endpoint; this attribute could have the values "widget" or "operator".
  • id: id of the element that has the output endpoint; this id is the same as the id defined in the resource element if the element is a widget, whereas this id is the same as the id defined in the operator element if the element is an operator.
  • endpoint: the name of the output endpoint. This name is the same as the defined in the outputenpoint element.

The target element defines the input endpoint of the connection. It has the following attributes:

  • type: type of element that has the input endpoint; the possible values of this attribute are "widget" or "operator".
  • id: id of the element that has the input endpoint; this id is the same as the id defined in the resource element if the element is a widget, whereas this id is the same as the id defined in the operator element if the element is an operator.
  • endpoint: the name of the input endpoint; this name is the same as the defined in the inputenpoint element.

Providing MACs on USDL offering: RDF flavour of the MACDL

The Application Mashup GE also offers a RDF flavour of the MACDL that can be use for creating semantic documents build upon Linked Data principles. Those documents can be linked for other semantic resources as the USDL documents supported by the Store, Marketplace and Repository Generic Enablers (now discontinued in favour of the Business API Ecosystem GE).

The RDF flavour of the MACDL is based on two new RDF vocabularies. The first vocabulary, WIRE (https://github.com/Wirecloud/wirecloud/blob/develop/src/wirecloud/commons/utils/template/schemas/wire.rdf), deals with the definition of the information that the Application Mashup GE must use to instantiate widgets and operators, including its user preferences, persistent variables, wiring information, and so on. The second vocabulary, WIRE-M (https://github.com/Wirecloud/wirecloud/blob/develop/src/wirecloud/commons/utils/template/schemas/wire-m.rdf), defines the mashup-related information needed to create an instance of the user workspace, including platform-specific information such as widget instances, wiring and piping between widgets and operators, etc.

The following sections show both vocabularies, that can be used for describing MACs using RDF.

WIRE vocabulary

The diagram below shows the WIRE vocabulary.

file: Wdl-rdf.png
The WIRE vocabulary

The Application Mashup GE must support this vocabulary to provide a way to represent MAC information as RDF and allow those descriptions to be used from USDL documents.


Class: wire:Widget

This class represents a widget. This is the main class of the vocabulary.

URI: http://wirecloud.conwet.fi.upm.es/ns/widget#Widget

Properties include:

dcterms:title, dcterms:description, dcterms:creator, usdl:hasProvider, usdl:utilizedResource, foaf:page, wire:hasPlatformPreference, wire:hasPlatformWiring, wire:hasPlatformRendering, wire:hasPlatformStateProperty, usdl:versionInfo, wire:hasImageUri, wire.hasiPhoneImageUri, wire:displayName, vcard:addr

Subclassof: usdl-core:Service

Class: wire:Operator

This class represents an operator.

URI: http://wirecloud.conwet.fi.upm.es/ns/widget#Operator

Properties include:

dcterms:title, dcterms:description, dcterms:creator, usdl:hasProvider, usdl:utilizedResource, foaf: page, wire:hasPlatformPreference, wire:hasPlatformWiring, wire:hasPlatformRendering, wire:hasPlatformStateProperty, usdl:versionInfo, wire:hasImageUri, wire.hasiPhoneImageUri, wire:displayName, vcard:addr

Subclassof: usdl-core:Service

Class: wire:PlatformPreference

This class represents a user preference in the Application Mashup GE, that is, data users can see and configure. The Enabler must make this value persistent and provide users with tools to edit and validate this data.

URI: http://wirecloud.conwet.fi.upm.es/ns/widget#PlatformPreference

Properties include:

wire:hasOption, dcterms:title, dcterms:description, rdfs:label, wire:type, wire:default, wire:secure

Used with: wire:hasPlatformPreference

Class: wire:PlatformWiring

This class represents the wiring status of a widget.

URI: http://wirecloud.conwet.fi.upm.es/ns/widget#PlatformWiring

Properties include:

wire:hasOutputEndpoint, wire:hasInputEnpoint

Used with: wire:hasPlatformWiring

Class: wire:PlatformRendering

This class represents the widget size when it is instantiated.

URI: http://wirecloud.conwet.fi.upm.es/ns/widget#PlatformRendering

Properties include:

wire:renderingWidth, wire.renderingHeight

Used with: wire:hasPlatformRendering

Class: wire:PlatformStateProperty

This class represents a widget state variable that the platform needs to know in order to make it persistent.

URI: http://wirecloud.conwet.fi.upm.es/ns/widget#PlatformStateProperty

Properties include:

dcterms:title, dcterms:description, wire:type, rdfs:label, wire:default, wire:secure

Used with: wire:hasPlatformStateProperty

Class: wire:Option

This class represents an option that a user preference could have.

URI: http://wirecloud.conwet.fi.upm.es/ns/widget#Option

Properties include:

dcterms:title, wire:value

Used with: wire:hasOption

Class: wire:OutputEndpoint

This class represents an output endpoint.

URI: http://wirecloud.conwet.fi.upm.es/ns/widget#OutputEndpoint

Properties include:

dcterms:title, dcterms:description, rdfs:label, wire:type, wire:friendcode

Used with: wire:hasOutputEndpoint

Class: wire:InputEndpoint

This class represents an input endpoint.

URI: http://wirecloud.conwet.fi.upm.es/ns/widget#InputEndpoint

Properties include:

dcterms:title, dcterms:description, rdfs:label, wire:type, wire:friendcode, wire:actionLabel

Used with: wire:hasInputEndpoint


Property: wire:hasPlatformPreference

This property states a user widget preference.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#hasPlatformPreference

Domain: wire:Widget

Range: wire:PlatformPreference

Property: wire:hasPlatformWiring

This property states the widget wiring status.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#hasPlatformWiring

Domain: wire:Widget

Range: wire:PlatformWiring

Property: wire:hasPlatformRendering

This property states how the widget must be rendered.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#hasPlatformRendering

Domain: wire:Widget

Range: wire:PlatformRendering

Property: wire:hasPlatformStateProperty

This property states a widget persistent variable.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#hasPlatformStateProperty

Domain: wire:Widget

Range: wire:PlatformStateProperty

Property: wire:hasOption

This property states a user preference option.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#hasOption

Domain: wire:PlatformPreference

Range: wire:Option

Property: wire:hasOutputEndpoint

This property states a widget wiring output endpoint.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#hasOutputEndpoint

Domain: wire:PlatformWiring

Range: wire:OutputEndpoint

Property: wire:hasInputEndpoint

This property states a widget wiring input endpoint.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#hasInputEndpoint

Domain: wire:PlatformWiring

Range: wire:InputEndpoint

Property: wire:friendcode

This property states a friendcode.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#friendcode

Domain: wire:InputEndpoint and wire:OutputEndpoint

Range: rdfs:Literal

Property: wire:actionLabel

This property states an input's action label.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#actionLabel

Domain: wire:InputEndpoint

Range: rdfs:Literal

Property: wire:hasImageUri

This property states the URI of the image associated with the widget.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#hasImageUri

Domain: wire:Widget

Range: foaf:Image

Property: wire:hasiPhoneImageUri

This property states the URI of the image associated with the Widget if the platform is running on an iPhone.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#hasiPhoneImageUri

Domain: wire:Widget

Range: foaf:Image

Property: wire:displayName

This property states the widget name to be displayed.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#displayName

Domain: wire:Widget

Range: rdfs:Literal

Property: wire:value

This property states the widget configuration element value.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#value

Range: rdfs:Literal

Property: wire:type

This property states the widget configuration element type.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#type

Range: rdfs:Literal

Property: wire:default

This property states the widget configuration element default value.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#default

Range: rdfs:Literal

Property: wire:secure

This property states whether or not a widget configuration element is secure.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#value

Range: rdfs:Literal

Property: wire:index

This property states the logical order of elements of the same type.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#value

Range: rdfs:Literal

Property: wire:codeContentType

This property states the widget code MIME type. The widget code URI is represented using usdl-core:Resource

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#codeContentType

Domain: usdl-core:Resource

Range: rdfs:Literal

Property: wire:codeCacheable

This property states whether or not the widget code is cacheable.

URI: http://wirecloud.conwet.fi.upm.es/ns/Widget#codeCacheable

Domain: usdl-core:Resource

Range: rdfs:Literal

WIRE-M vocabulary

The diagram below shows the WIRE-M vocabulary.

file: Mdl-rdf.png
The WIRE-M vocabulary

Like the WIRE vocabulary, this vocabulary must be supported by the Application Mashup GE implementations to provide a way to represent Mashup information using RDF and allow those descriptions to be used from USDL documents.


Class: wire-m:Mashup

This class represents a mashup. It will be implemented as a workspace.

URI :http://wirecloud.conwet.fi.upm.es/ns/mashup#Mashup

Properties include:

wire-m:hasMashupPreference, wire-m:hasMashupParam, wire-m:hasTab, wire-m:hasMashupWiring, wire:hasImageUri, wire:hasiPhoneImageUri, wire:version

subClassOf: usdl:CompositeService

Class: wire-m:Tab

This class represents a workspace tab.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#Tab

Properties include:

wire-m:hasiWidget, wire-m:hasTabPreference, dcterms:title

Used with:


Class: wire-m:iWidget

This class represents a widget instance.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#iWidget

Properties include:

wire-m:hasPosition, wire-m:hasiWidgetRendering, wire-m:hasiWidgetPreference, wire-m:hasiWidgetProperty

Used with:


subClassOf: wire:Widget

Class: wire-m:MashupPreference

This class represents a mashup preference.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#MashupPreference

Properties include:

dcterms:title, wire:value

Used with:


Class: wire-m:MashupParam

This class represents a mashup parameter.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#MashupParam

Properties include:

dcterms:title, wire:value

Used with:


Class: wire-m:Position

This class represents the position of a widget instance in the tab.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#Position

Properties include:

wire-m:x, wire-m:y, wire-m:z

Used with:


Class: wire-m:iWidgetPreference

This class represents a widget instance preference.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#iWidgetPreference

Properties include:

dcterms:title, wire:value, wire-m:readonly, wire-m:hidden

Used with:


Class: wire-m:iWidgetRendering

This class represents a widget instance rendering.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#iWidgetRendering

Properties include:

wire-m:fullDragboard, wire-m:layout, wire-m:minimized, wire:renderingHeight, wire:renderingWidth

Used with:


Class: wire-m:iWidgetProperty

This class represents a widget instance property.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#iWidgetProperty

Properties include:

wire-m:readonly, wire:value

Used with:


Class: wire-m:TabPreference

This class represents a tab preference.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#TabPreference

Properties include:

dcterms:title, wire:value

Used with:


Class: wire-m:Connection

This class represents a wiring connection between two widget instances or operator instances.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#Connection

Properties include:

wire-m:hasSource, wire-m:hasTarget, dcterms:title, wire-m:readonly

Used with:


Class: wire-m:Source

This class represents a widget instance or operator instance that is the source of a connection.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#Source

Properties include:

wire-m:sourceId, wire-m:endpoint, wire:type

Used with:


Class: wire-m:Target

This class represents a widget instance or operator instance that is the target of a connection.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#Target

Properties include:

wire-m:targetId, wire-m:endpoint, wire:type

Used with:


Class: wire-m:iOperator

This class represents an operator instance.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#iOperator

Properties include:

wire-m:iOperatorId, dcterms:title

Used with:



Property: wire-m:hasMashupPreference

This property states a mashup preference.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hasMashupPreference

Domain: wire-m:Mashup

Range: wire-m:MashupPreference

Property: wire-m:hasMashupParam

This property states a mashup parameter.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hasMashupParam

Domain: wire-m:Mashup

Range: wire-m:MashupParam

Property: wire-m:hasTab

This property states that a given tab is part of a workspace.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hasTab

Domain: wire-m:Mashup

Range: wire-m:Tab

Property: wire-m:hasiWidget

This property states that a given widget instance is instantiated in a tab.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hasiWidget

Domain: wire-m:Tab

Range: wire-m:iWidget

Property: wire-m:hasTabPreference

This property states a tab preference.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hasTabPreference

Domain: wire-m:Tab

Range: wire-m:TabPreference

Property: wire-m:hasPosition

This property states the position of an widget instance in a tab.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hasPosition

Domain: wire-m:iWidget

Range: wire-m:Position

Property: wire-m:hasiWidgetPreference

This property states a widget instance preference.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hasiWidgetPreference

Domain: wire-m:iWidget

Range: wire-m:iWidgetPreference

Property: wire-m:hasiWidgetProperty

This property states a widget instance property.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hasiWidgetProperty

Domain: wire-m:iWidget

Range: wire-m:iWidgetProperty

Property: wire-m:hasiWidgetRendering

This property states the rendering of a widget instance.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hasiWidgetRendering

Domain: wire-m:iWidget

Range: wire-m:iWidgetRendering

Property: wire-m:hasConnection

This property states a wiring connection.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hasConnection

Domain: wire:PlatformWiring

Range: wire-m:Connection

Property: wire-m:hasSource

This property states the source of a connection.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hasSource

Domain: wire-m:Connection

Range: wire-m:Source

Property: wire-m:hasTarget

This property states the target of a connection.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hasTarget

Domain: wire-m:Connection

Range: wire-m:Target

Property: wire-m:targetId

This property states the ID of a target.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#targetId

Domain: wire-m:Target

Range: rdfs:Literal

Property: wire-m:sourceId

This property states the ID of a source.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#sourceId

Domain: wire-m:Source

Range: rdfs:Literal

Property: wire-m:endpoint

This property states the ID of the widget instance or operator instance that is the source or target of a connection.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#endpoint

Range: rdfs:Literal

Property: wire-m:hasiOperator

This property states the wiring of an operator's instance.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hasiOperator

Domain: wire:PlatformWiring

Range: wire-m:iOperator

Property: wire-m:x

This property states the x coordinate of a widget instance position.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#x

Domain: wire-m:Position

Range: rdfs:Literal

Property: wire-m:y

This property states the y coordinate of a widget instance position.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#y

Domain: wire-m:Position

Range: rdfs:Literal

Property: wire-m:z

This property states the z coordinate of a widget instance position.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#z

Domain: wire-m:Position

Range: rdfs:Literal

Property: wire-m:fullDragboard

This property states whether a widget instance occupies the whole space in the tab.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#fullDragboard

Domain: wire-m:iWidgetRendering

Range: rdfs:Literal

Property: wire-m:layout

This property states the layout of a widget instance.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#layout

Domain: wire-m:iWidgetRendering

Range: rdfs:Literal

Property: wire-m:minimized

This property states whether a widget instance is minimized in its tab.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#minimized

Domain: wire-m:iWidgetRendering

Range: rdfs:Literal

Property: wire-m:hidden

This property states whether a widget instance is hidden in its tab.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#hidden

Domain: wire-m:iWidgetPreference

Range: rdfs:Literal

Property: wire-m:readonly

This property states whether a mashup configuration element is read only.

URI: http://wirecloud.conwet.fi.upm.es/ns/mashup#readonly

Range: rdfs:Literal

WGT zipped file format

The Mashup Application GE relies on PKWare's Zip specification as the archive format for the self-packaged version of the Mashable Application Components. The packaging format acts as a container for files used by a MAC whereas the only initial requirement is to have a configuration document declaring metadata and configuration parameters for the MAC. This configuration file must use the MACDL supported by the Mashup Application GE (in either of its flavours: XML or RDF). This configuration file must be present at the root of the Zip container and the name must be config.xml or config.rdf. Any relative path/URL included in the configuration document will use the root of the zip file as the base path/URL.

The Mashup Application GE should prohibit relative paths for accessing files outside the zip file container. This is especially important as the Mashup Application GE may extract these corrupt files to the file system.

Main Interactions

This section describes in detail all the interactions that the Application Mashup GE must support both with users and with other FIWARE GEs.

The Application Mashup GE is closely related to other FIWARE Generic Enablers, especially those concerning the business infrastructure and the provision of data sources. The figure below depicts some of these relationships:

How the Application Mashup GE relates to the other Generic Enablers

Life-cycle of a Mashable Application Component (mashup, widget and operators)

Note that Web mashups are aimed at leveraging the "long tail" of the Internet of Services by exploiting rapid development, the "Do-It-Yourself" (DIY) metaphor, and the ability to share mashable components. They typically serve a specific situational (i.e. immediate, short-lived, customized, specific) need, often with a high reuse potential. This need for sharing means that the Application Mashup GE should be fully compliant with the FIWARE's Business API Ecosystem Generic Enablers. The fact that a MAC can be offered in a Store before being used in the Application Mashup GE results in the definition of the following MAC life-cycle:


Lifecycle of a MAC (mashup, widget and operator)

Mashable Application Components (i.e. mashups, widgets and operators) must pass through the following states:

  • Published
  • Bought/installed
  • Deployed

The init state for a MAC means that the MAC is neither published in the store, bought, nor installed in the user local repository. A MAC is published when it is made available to Store customers. Users that are interested in using a published MAC, can buy the MAC, thus transferring it to a bought state. Once bought, the MAC is automatically installed in the local catalogue of the Application Mashup GE. An alternative is to upload a MAC that the users have developed and which they do not have to buy. This is why the state is named bought/installed. Once the users have uploaded the MAC to the local catalogue, they can proceed to publish the MAC. Once the MAC is installed, it can be deployed in the user workspace. Bought and installed MACs must be deployed in the user workspace before they can be configured.

Interaction diagrams

The Application Mashup Generic Enabler must be designed and developed to enable, at least, the interactions shown in this section. They cover the user-platform interactions needed to visually create a web application mashup, plus the main interactions between the platform and other generic enablers.

User-Platform Interactions

The interactions that the Application Mashup GE must support with regard to its users are as follows.

Upload a Mashable Application Component to the Local Catalogue

MAC developers must be able to upload their own developed resources to the local catalogue of the Application Mashup GE. End users must also be able to upload the MACs they already have stored in their local hard disk to the local catalogue. The implementation of the GE must enable users to select their new *.wgt packaged MAC and upload it to the Local Catalogue.

file: uploadMACLocalCatalogue1.png

Uploading a packaged MAC to the Local Catalogue

This interaction must result in the uploaded MAC being stored in the local catalogue, ready for configuration and/or deployment. In other words, the MAC will be at the Bought/Installed state of its lifecycle. A HTTP/1.1 201 Created Status Code response will be received if the interaction went well.

Note that there are two possible scenarios if the uploaded MAC is a mashup:

  • If the widgets within the mashup are currently installed in the local catalogue, the uploaded mashup will reference the widgets and will run out-of-the-box.
  • If some of the widgets have a commercial license, and the license has to be bought for the widget to be used, the uploaded mashup will be installed, but the GE must warn and notify users that they have to buy the licensed widgets.

Export a MAC from the local catalogue

Platform users must be able to export (download) any of the MACs they have installed in the local catalogue. Users should select the MACs they want to export and click on an export button for the Application Mashup GE implementation to generate a packaged version of the selected MACs, enabling users to download MACs using their Web browser.

file: exportSelectedMACs.png

Exporting (downloading) a packaged MAC from the Local Catalogue

Deploy a MAC to get a new runtime instance

The Deploy MAC functionality instantiates a mashup or widget, that is available in the local catalogue in the Mashup Execution Engine. This operation is invoked by the mashup developer from the Composition Editor. The call should include the following information:

  • macID: id of the mashup for instantiation.
  • wsID: id of the active user workspace.
  • tabID: id of the current tab within the active user workspace.

As a result of this invocation, the engine will get the MAC template from the local catalogue and will execute the MAC. It will also be available in the Mashup Editor mashup developer workspace. Its state will switch to deployed.


Interaction with the Mashup Execution Engine to deploy both mashups and widgets

Undeploy a MAC. Remove an instance from execution

The operation Undeploy MAC removes a mashup application or a widget from execution. Mashup developers invoke this operation from the mashup composition editor when they want to delete the whole mashup application or just a single widget.

The mashupID is required to undeploy a mashup:


Interaction needed to undeploy a mashup

The widgetID, workspaceID and tabID are required to undeploy a widget.


Interaction needed to undeploy a widget

As a result of this operation, the mashup or widget will stop executing, and thus it will reach the bought/installed state in its lifecycle.

Interconnect widgets/operators using wiring

Wiring functionality enables users to connect one or more widgets/operators to one or more other widgets/operators by means of a channel. The Composition Editor will help users to connect one or more of the possible outputs of a widget/operator with the input of another widget/operator. This way, data flows between MACs allowing the mashup application to act as an information and process dashboard.

Besides, piping deals with how operators can bind to a specific backend service to gain access to data provided by the service. Then, users can wire the operator outputs either to other operators in order to perform some kind of data filtering/adaptation processes or to other widgets to consume the data.

The figure below shows how users set up channels between widgets/operators for wiring/piping.


Widget Interconnection Management process

Interactions with other FIWARE Generic Enablers

The Application Mashup GE is closely related with the Business-related FIWARE GEs. The main interactions are as follows.

Install MACs from a Business API Ecosystem server

Buying mashup applications, widgets and operators from an external FIWARE Business API Ecosystem servers is one of the topics to be taken into account by the Application Mashup GE. The Application Mashup GE should provide a user interface for browsing the available offerings and manage the offerings purchased by the user. The Application Mashup GE should provide shortcuts for accessing the Business API Ecosystem server where the user will be able to fully manage the offerings (e.g. purchase them, manage payment invoices, ...). In any case, the Application Mashup GE should provide basic offering info as well as support for installing MAC from purchased offerings.


Buying a new MAC from a Business API Ecosystem server

Publish a MAC to a Business API Ecosystem server

Once users have either developed and uploaded a new widget or operator to the local catalogue or created their own mashup application, the Application Mashup GE must enable users to contact the Business API Ecosystem GE to publish their brand new MAC.

The Application Mashup GE must enable users to create new products on the Business API Ecosystem from any of the MACs owned by the user. The Business API Ecosystem GE is responsible for the entire transactions process (i.e. sending of pricing data, card number, etc.), which is out of the scope of the Application Mashup GE. However, at some point of the interaction, the Application Mashup can be used for sending the packaged MAC to the Business API Ecosystem for storage when it is set to published.


Publishing a new MAC to a given Business API Ecosystem server

Add new Business API Ecosystem catalogue

The Application Mashup GE must be able to include new Business API Ecosystem servers to search for new MACs. To do this, the Application Mashup GE should provide an user interface for accessing external catalogues from the Editor and new ones could be added from time to time. This functionality adds a new Business API Ecosystem server to the Composition Editor's internal list of external catalogues.


Adding the URL of a new Business API Ecosystem server

Basic Design Principles

  • API Technology Independence
The API abstracts from the specific implementation technology. Implementations using more than one type of platform and framework should be possible.
  • Web Browsers should not limit the functionalities of the Application Mashup 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 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 prosumers) by hiding complexity behind different types of building blocks, trading off flexibility for simplicity.

Re-utilized Technologies/Specifications

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

  • Use of the OAuth2 protocol is recommended: [1]

On the other hand, the Application Mashup GE relies on, and it must support, the following technologies and specifications:

  • RESTful web services
  • HTTP/1.1
  • JSON and XML data serialization formats
  • Markdown markup language

Previous versions of the Application Mashup GE architecture were based on the now discontinued Marketplace, Store and Repository GEs making optional the support for:

  • Linked USDL

There are a number of widget- and mashup-related specifications that should be considered and/or contributed to, including the four specifications listed in the following section:


OpenSocial is a public specification that defines a component hosting environment (container) and a set of common application programming interfaces (APIs) for web-based applications.

Widget Packaging and XML Configuration

W3C has published a set of specifications describing their view about widgets. "Widget Packaging and XML Configuration" is one of the most prominent specifications in this set.

OpenAjax Hub 2.0 Specification

The OpenAjax Hub is a standard JavaScript functionality set defined by the OpenAjax Alliance that addresses key interoperability and security issues that arise when multiple Ajax libraries and/or components are used within the same web page. The OpenAjax Hub represents one of the key technical contributions of the OpenAjax Alliance to the Ajax community consistent with the Alliance's mission. Seehttp://www.openajax.org for information on the OpenAjax Alliance.

The key feature of OpenAjax Hub 2.0 is its publish/subscribe engine that includes a "Managed Hub" mechanism that enables a host application to isolate untrustworthy components into secure sandboxes.

OMA Enterprise Mashup Markup Language

The Open Mashup Alliance (OMA) is a consortium of individuals and organizations dedicated to the successful use of Enterprise Mashup technologies and adoption of an open language that promotes Enterprise Mashup interoperability and portability.

OMA has developed a free-to-use Enterprise Mashup Markup Language (EMML) to promote the development, interoperability and compatibility of Enterprise Mashup offerings. The OMA also provides a reference runtime implementation that processes mashup scripts written in EMML.


  1. Lizcano, D., Alonso, F., Soriano, J., and López, G. (2011) A new end user composition model to empower knowledge workers to develop rich Internet applications. In Journal of Web Engineering, Vol.10 No. 3, pp. 197-233, Rinton Press Inc. Sept. 2011

Detailed Specifications

Open API Specifications

The Application Mashup GE offers two separate APIs that cannot be combined because they are of different types: the WidgetAPI is a JavaScript API, whereas the ApplicationMashupAPI is a RESTful API:

The Application Mashup GE will access the Repository, Registry and Marketplace via their REST API:

Other Open Specifications

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

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 of 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