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 R3 - FIWARE Forge Wiki

FIWARE.OpenSpecification.Apps.ApplicationMashup R3

From FIWARE Forge Wiki

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

Contents

Preface

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

FIWARE WIKI editorial remark:
This page corresponds to Release 3 of FIWARE. The latest version associated to the latest Release is linked from FIWARE Architecture

Copyright

  • Copyright © 2012-2014 by UPM

Legal Notice

Please check the following FI-WARE 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

Overview

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 Mashup Definition Language (MDL) and a Widget Definition Language (WDL), which are 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. A mashup's MDL links to the WDL descriptions of its constituent widgets. These two languages are deeply described later as part of this open specification.
  • Support for XML/RDF template schemas for both the WDL and the MDL languages, containing all widget- and mashup-related contextual information, plus all the preferences, state properties, and wiring/piping, context and rendering information (i.e. elements that manage the platform-widget interaction) required to support application mashup persistence and to instantiate and run the application mashup on a platform that conforms to these open specifications.
  • USDL extensions to the WDL and MDL: WDL-RDF / MDL-RDF vocabularies for representing WDL/MDL data as part of a USDL offering.
  • Support for a zipped file format (WGT) that allows mashable 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 MDL 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 MDL 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 MDL.
  • MAC (widget, operator and mashup) life-cycle management support.
  • An application mashup execution engine model capable of deploying and running a mashup from a MDL file. It provides support for managing mashup state persistence, and for managing the wiring and piping mechanisms.
  • Support for interaction with a catalogue of mashable components: 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 FI-WARE within a particular FI-WARE Instance.

Target usage

FI-WARE 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, see Terms and Definitions) 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:


File:widgets_igoogle.png


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:


File:wiring_mechanism.png


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 FI-WARE 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 (or store, or marketplace) 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).

Application Mashup 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.


File:ApplicationMashupArchitecture_R3.png


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 the widgets 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 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 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 FI-WARE Store 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.

Mashup and Widgets Definition Languages (MDL and WDL)

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 interconnected with each other (that is, wired). To fully support widgets (and mashups) instantiation, the implementation of the Application Mashup GE must support platform-independent widget and mashup languages.


The Mashup Definition Language (MDL) and the Widget Definition Language (WDL) are the chosen languages. They define all the inner information (metadata) regarding both a mashup and their widgets and their relationships/interconnections. This includes typical metadata, such as widget's name, vendor, version, last updated date, but also graphical information such as the location of the widgets on the editor canvas, widget width and height, etc.

The following section shows the concept of "template". The template represents the definition of both languages and must be supported by the Application Mashup GE.

Mashup and Widget Template

To internally represent and deal with both mashups and widgets, the Application Mashup GE must support their "templates". A template is an XML file that contains all mashup and widget-related contextual information needed by the Application Mashup plus a set of preferences, state properties, and wiring and rendering information. Both MDL and WDL templates have their associated XML Schema. The latest version of the XML Schemas described in the following sections is available at:

WDL Template description as a XML Schema Definition

First we create a description of the widget template XML Schema, i.e. what WDL looks like. It uses the http://wirecloud.conwet.fi.upm.es/ns/template# namespace for the root element, called Template. The figure below shows the Template element and the sequence of subelements that it contains.


file: Wdl_1.png
The "Template" root element

The Template element defines all the widget-related contextual information in an XML element called Catalog.ResourceDescription. This is a mandatory element of the XML document. The figure below depicts what it looks like:


file: Wdl_2.png


The "Catalog.ResourceDescription" element

This core element it is made up of the following attributes:

  • Vendor: Company that distributes the widget. It cannot contain the character "/".
  • Name: Name of the widget. It cannot contain the character "/".
  • Version: Current widget version number. It must define starting sequences of numbers separated by dots. Zeros can only be used alone (e.g. 0.1 is valid but 03.2 is not).
  • DisplayName: Name shown in the user interface of the widget. This field can be translated; therefore this field does not identify the widget.
  • Author: Widget developers.
  • Mail: Developer's e-mail address.
  • Description: Full widget description to be shown in the catalogue.
  • ImageURI: Absolute or template-relative URL of the image shown in the catalogue.
  • iPhoneImageURI: Image to be used in iPhones and other smartphones.
  • WikiURI: Absolute or template-relative URL of the widget documentation.

The vendor, name and version fields are the widget's ID. Therefore, no such identifier can appear more than once in any collection of the Application Mashup GE stored resources (this includes widgets, mashups, operators, etc.).

XML elements that manage the Platform-Widget 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 Platform.Preferences element

The first platform-related element is the Platform.Preferences one:


file: Wdl_3.png
The "Platform.Preferences" element

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

  • name: name of the preference to be referenced in the source code.
  • type: preference data type: text (string), number, Boolean, password and list.
  • description: text that describes the preference.
  • label: text that the preference will show in the user interface.
  • default: preference default value.

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

  • name: text to be displayed in the selection list.
  • value: value to be used when the option is selected.
The Platform.StateProperties element

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


file: Wdl_4.png
The Platform.StateProperties element


This element is required. It is made up of a list of Property elements and requires 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.
The Platform.Wiring element

This is probably one of the most important widget template elements. It defines both the widget inputs and outputs needed to intercommunicate with other widgets. 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 Platform.Wiring element:

file: Wdl_5.png
The Platform.Wiring element.


This element may contain any number of InputEndpoint and OutputEndpoint elements.

Widgets 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 can receive asynchronous data through the input endpoints. These endpoints are meant to be used by the widget for receiving data (events) coming from other widgets. The required InputEndpoint elements requires 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.
  • action_label: 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.
The Platform.Link element

The actual source code of the widget must be linked to this template. To do this, the Platform.Link element is needed.

file: Wdl_6.png
The Platform.Link element binds the template with the actual widget source code


It is made up of the XHTML element, which has the following attributes:

  • href: absolute or template-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.
  • 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.
The Platform.Rendering element

The last template XML element is Platform.Rendering. It specifies the default width and height of the widget once it is deployed in the user workspace.

file: Wdl_7.png
The Platform.Rendering element


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

MDL Template description as a XML Schema Definition

The MDL XML template schema is quite similar to the WDL template and is used to describe a mashup composed of widgets. The figure below shows the Mashup Template element and its sequence of subelements.

file: Mdl_1.png
The Mashup "Template" root element


The Catalog.ResourceDescription element has the same fields as in the widget template with an extra field called IncludedResources that is used to describe widgets within the mashup. The figure below depicts what it looks like:

file: Mdl_3.png
The "IncludedResources" element


This element contains 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 template.

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; it cannot contain the character "/".
  • name name of the widget; it cannot contain the character "/".
  • version current version of the widget; 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).
  • title name to be displayed in the widget dashboard.
  • id the widget identification; this id is internal to the mashup template.

The Resource element is made up of a Position element and a Rendering element. 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 Platform.Wiring element

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

file: Mdl_4.png
The "Platform.Wiring" element


The InputEndpoint and OutputEndpoint elements define the same information as in the WDL template. The Platform.Wiring element contains all the input and output endpoints of all the widgets and operators in the mashup.
The Platform.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 template.
  • 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 Platform.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.

Mashup and Widgets as a USDL offering: USDL extension

In order for both mashups and widgets to be offered as a USDL offering in the Store GE so that both widgets and mashups can be part of the data managed by the FI-WARE's Marketplace, Store and Repository Generic Enablers, the Application Mashup GE must make use of the following RDF(S) vocabularies, built upon Linked Data principles as Linked USDL extensions.

The first specification, WDL-RDF (https://github.com/Wirecloud/wirecloud/blob/develop/docs/source/widgets/template/rdf_template.rdf), deals with the definition of the information that the Application Mashup GE must use to instantiate a widget, including its user preferences, state properties, wiring information, and so on. The second specification, MDL-RDF (https://github.com/Wirecloud/wirecloud/blob/develop/docs/source/mashups/mashup_template_rdf.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, etc.

The following sections show both vocabularies to be used within the USDL offerings.

WDL-RDF

The diagram below shows the WDL-RDF vocabulary.

file: Wdl-rdf.png
The WDL-RDF extension for USDL


The Application Mashup GE must support this vocabulary to provide a way to represent WDL information as part of a USDL offering.

Classes

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

Properties

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

MDL-RDF

The diagram below shows the MDL-RDF vocabulary.

file: Mdl-rdf.png
The MDL-RDF extension for USDL


Like WDL-RDF, this vocabulary must be supported by the Application Mashup GE to provide a way to represent MDL information as part of a USDL offering.

Classes

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:

wire-m:hasTab


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:

wire-m:hasiWidget

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:

wire-m:hasMashupPreference


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:

wire-m:hasMashupParam


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:

wire-m:hasPosition


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:

wire-m:hasiWidgetPreference


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:

wire-m:hasiWidgetRendering


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:

wire-m:hasiWidgetProperty


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:

wire-m:hasTabPreference


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:

wire-m:hasConnection


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:

wire-m:hasSource


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:

wire-m:hasTarget


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:

wire-m:hasiOperator

Properties

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 one of the metadata description languages supported by the Mashup Application GE (WDL and MDL 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 container. This is especially important as the Mashup Application GE may extract these 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 FI-WARE GEs.

The Application Mashup GE is closely related to other FI-WARE 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 FI-WARE's Marketplace, Store and Repository 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:


File:widget_lifecycle.png


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


It should also be possible to upload the XML template of the MAC, where the Application Mashup GE is in charge of getting and storing the linked source code of the MAC in the Local Catalogue.


file: uploadMACLocalCatalogue2.png


Uploading a MAC from its XML template to the Local Catalogue


Regardless of the upload method, 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.


File:InstantiateMashupWidget.png


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:


File:undeployMashup.png


Interaction needed to undeploy a mashup

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


File:undeployWidget.png


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.


File:ConnectWidgetsAndChannels.png


Widget Interconnection Management process

Interactions with other FI-WARE Generic Enablers

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

Buy MACs from a Store

Buying both mashup applications, widgets and operators from an external FI-WARE Store is one of the topics to be taken into account by the Application Mashup GE. Once users have used the Marketplace GE to search and select the MAC that they want to buy, the Application Mashup GE must provide the Store with a URL (through the Application Mashup RESTful API) and request the uploading of the bought MAC. The Store GE will be the actor that uploads the MAC to the local catalogue. Once the MAC has been uploaded, it is automatically installed in the local catalogue. From this point onwards, it will be possible for the MAC to be instantiated and thus executed.


File:GetMashupFromMarketplace.png


Buying a new MAC from a Store

Publish a MAC to a Store

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

The Application Mashup GE must enable users to notify the Store GE that they intend to publish the MAC. The Store 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 must send the packaged MAC to the Store/Repository for storage when it is set to published.


File:publishMACtoStore.png


Publishing a new MAC to a given Store

Add Marketplace

The Application Mashup GE must be able to include new Marketplaces to search for new MACs. To do this, 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 Composition Editor's internal list of marketplaces.



Adding the URL of a new Marketplace

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 the Marketplace, Store and Repository GEs, and it must support the following technologies and specifications:

  • RESTful web services
  • HTTP/1.1
  • JSON and XML data serialization formats
  • 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

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.

References

  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