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


From FIWARE Forge Wiki

Jump to: navigation, search



Legal Notice

Please check the following FI-WARE Open Specification Legal Notice (essential patents license) to understand the rights to use this open specification. As all other FI-WARE members, Telecom Italia has chosen one of the two FI-WARE license schemes for open specifications.

Telecom Italia provides the software associated to the Mediator as as Open and Free Access to PPP partners during the FI-WARE/PPP duration and under a FRAND (Fair, Reasonable And Non-Discriminatory) licensing terms afterwards. This means that it is accessible by the partners of the FIWARE-PPP Projects, and in particular by the Use Case Projects, as share-ware but it is not available for public distribution. In particular the usage of the Mediator under the following circumstances is defined: Projects being part of the FI-PPP program can use the Mediator product under the conditions established in the FI-PPP Collaboration Agreement that they should have signed as beneficiaries of the program.


Providing interoperability solutions is the main functionality of the Mediator. The heterogeneity that exists among the ways to represent data (i.e. to represent syntactically and semantically the information items that are requested or provided by an application or a service), and to represent the communication pattern and the protocol or the public process needed to request a functionality (executing a composition in a different execution environment or implementing dynamic run-time changes might require a process mediation function), are problems that arise in many Future Internet applications. Acknowledging the necessity to deal with these heterogeneities, mediation solutions are provided in FIWARE.

The Mediator is basically a middleware application responsible for providing interoperability among different communication protocols and among different data models. For example it can convert ASCII delimited message payloads from older protocols such as FTP into an XML message payload submitted to a web service (both soap over http or rest over http). Thus the main capabilities of the mediator are protocol and data transformations. Another example of data transformation is the transformation of an XML payload into another XML payload through XSLT or XQuery.

The Mediator provides data mediation and protocol mediation capabilities to enable clients playing the role of Mediation Service Creators to compose different kinds of target service, and to enable clients playing the role of Mediation Service Clients to invoke the mediated services (see figure 1.1).
The Composition Engine GEs can play both the roles of Mediation Service Creator and Mediation Service Client.

Figure 1.1: Mediator Role in FI-WARE

The Mediator provides an Administrator GUI and APIs allowing mediation services to be constructed given a target service and to be used in a service composition.

Basic Concepts

FI-WARE platform should be able to support services exposed through different protocols and technologies and enable the creation of new composed services. The mediator shall provide the "glue" between the service layer and the composition layer in order to enhance the composition capabilities of the composing GEs.

Within FI-WARE we abstract this functionality into a Generic Enabler called Mediator. The API abstracts the concrete implementation technology. Implementations using various kinds of platforms and frameworks should be possible. The main goal of the Mediator is to provide a virtual proxy of the target service to be used by the Composition Engine GE instead of the target service. The Virtual Proxy is configured with Mediation Tasks and Dynamic Mediation Tasks that provide data mediation and protocol mediation capabilities in order to make the target service suitable for composition. The first release of this GE will provide an Administration GUI for the configuration of such Virtual Proxies. The final release will provide remote generic APIs to allow the configuration of the Mediator directly by the other GEs

Data Model

The Mediator offers a set of available mediation tasks and dynamic mediation tasks: the set of mediation capabilities that can be used via the mediator. The mediator allows users to create and manage their mediation services: a mediation service is a virtual proxy towards a web service that executes a chain of mediation tasks and/or dynamic mediation tasks between the caller and the target service. The mediation tasks and dynamic mediation tasks must be chosen from the set of available task types and the concrete implementation of the mediation tasks to be chained are potentially provided by different mediator implementations.

Each mediator implementation (asset) will provide its own set of addressable mediation tasks and/or dynamic mediation tasks. How to build a concrete mediation task or dynamic mediation task depends on the specific mediator implementation.

Mediation Task

Mediation tasks are the mediation capabilities that can be used via the Mediator. The Mediator maintains a set of the available mediation tasks.

The concrete implementation of a mediation task is provided by a specific mediator implementation (asset).

Examples of provided mediation tasks include:

  • SOAP2REST: allows a REST Service to be called from the SOAP protocol
  • SOAP2POX: allows a service that is expecting a POX Payload (Plain Old XML) to be called from the SOAP protocol
  • TCP2HTTP: allows a service exposed via HTTP to be called using TCP transport

The mediation tasks exposed by the Mediation GE are a chain of the built-in low level mediation capabilities provided by WSO2 ESB and Apache Camel.

A short list of these mediation capabilities:

Name Description
Send Sends a message out
Log Logs a message
Property Sets or removes properties associated with the message
Sequence Refers to a sequence
Event Sends event notifications to an event source
Drop Drops a message
Enrich Enriches a message
Enqueue Creates an enqueue mediator
Filter Filters a message using Xpath (if else logic)
Out Inbuilt filter for choosing messages in ESB out path
In Inbuilt filter for choosing messages in ESB path
Switch Filters a message using Xpath (switch logic)
Router Routes messages based on XPath filtering
Conditional Router Routes messages based on 'Condition'
Validate Schema validation for messages
XSLT XSLT Transformations
XQuery XQuery Transformations
Header Sets or removes SOAP Headers
Fault Creates or removes SOAP Faults
Rewrite Creates a rewrites mediator

We provide some examples of the configuration of these mediation tasks.

Example 1: WS-Security
Virtual proxy configuration that adds WS-Security to the unsecured target service "ServiceExample"

<proxy xmlns="http://ws.apache.org/ns/synapse" name="SecuredServiceExampleProxy" transports="https" startOnLoad="true">
       <header xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" name="wsse:Security" action="remove" />
       <address uri="http://<ServiceExample URL>" />
       <send />
 <enableSec />
 <policy key="conf:/repository/axis2/service-groups/SecuredServiceExampleProxy/services/SecuredServiceExampleProxy/policies/UTOverTransport" />

Example 2: Protocol Transformation TCP2HTTP

<proxy xmlns="http://ws.apache.org/ns/synapse" name="TCPServiceExample" transports="tcp" startOnLoad="true">
        <address uri="http://<ServiceExample URL>" />
        <send />

Dynamic Mediation Task

In the current vision of the Mediator GE, this enabler allows users to create and manage mediation services “offline”, at design time. A mediation service is a chain of mediation tasks and dynamic mediation tasks between a service producer and consumer that can be accessed through a Web service interface. This chain deals with all the mediation problems that may arise between these two protagonists.

To cope with some limitations in this current pragmatic vision of how mediation is made – limitations related to potential missing information at design time – the mediator GE offers specific mediation tasks called “Dynamic mediation tasks”. These tasks may be needed because, at design time (when the chain of tasks is defined), all the needed data and/or information is not necessarily available to be able to solve mediation issues between the caller request (“service consumer”) and the target service (“service provider”).

We postulate that these data and information will become available at runtime and that the dynamic mediation tasks will then dynamically solve the remaining mediation issues. This approach is the first step toward a fully dynamic mediation.

The concrete implementation of a dynamic mediation task is provided through features provided by an existing asset called SETHA2 that deals with data, protocol and process mediation in a SOA context. In using semantics to replace the information that are not known, SETHA2 bridges the gap between a consumer and a service provider.

Figure 4.1: SETHA2 dynamic mediation engine

We identify multiple dynamic mediation tasks types that are detailed hereafter:

  • Data dynamic mediation tasks

The data dynamic mediation tasks can be used to solve the following issues:

- Consumer knows the target service and the operation to invoke but not its parameters (e.g. order of parameters, exact type of parameter to use, …). So consumer provides his data, with their semantic description, and the semantic description of the target service. Then the dynamic mediation task builds the payload to provide to the target service.

- Consumer knows the target service but not exactly the operation to invoke (e.g. the precise name of the target operation is not known). So consumer provides his data with their semantic description and the semantic description of the target service. The dynamic task finds the correct semantic matching operation in the target service and builds the payload to provide.

  • Protocol dynamic mediation tasks

If the target service protocol is not known at design time, the protocol dynamic mediation task will be used to bridge the protocol gap between service consumer and producer (e.g. SOAP/HTTP service consumer and DDS service).

  • Process dynamic mediation tasks

To be used if there is a potential process mismatch at runtime between the consumer and the producer in the case where one of the processes (either from consumer or producer) is not known at design time.

A second step toward fully dynamic mediation in FI-WARE would be to rely directly on the dynamic mediation SETHA2 engine to deal with extreme cases where only consumer’s side requirements are known at design time and all mediation must be automatically defined and invoked at runtime.

Mediation Service

The mediation service represents the final mediation capability exposed by the Mediator to the external word. A mediation service can be composed by a single mediation task (the simplest case) or by a chain of mediation tasks that can be provided by different Mediator implementations The mediation service is configured with a chain of mediation tasks and/or dynamic mediation tasks: they are the mediation tasks that the mediation service will execute between the caller and the service.

The Mediation service URL is the URL that allows the invocation of the target service with the mediation logic included in the chain of mediation tasks/dynamic mediation tasks configured.

To configure the mediation service the Target service endpoint must be specified: it is the URL of the target web service that will be invoked via the mediation service.

Mediator Architecture

The Mediator GE is used mainly by the Composition Engine GEs within the FI-WARE platform. It provides a layer of virtual proxies to be used by the composer instead of the target services in order to allow the composer support various kinds of target services. Besides the FI-WARE platform, Future Internet applications or composed services on top of the FI-WARE platform can use the mediator as a service for their own purpose.

Figure 4.2: Mediator Architecture

Main Interactions

There are two main interactions provided by the mediator:

  • at design time there are interactions in order to create and handle virtual proxies
  • at execution time the mediator provides the virtual proxy, whose URL has to be invoked in order to mediate the target service

The design time interaction occurs between a client that plays the role of the Mediation Service Creator and the Mediator.
The execution time interaction occurs between the Mediation Service Clients and the Mediation Services exposed by the Mediator. The mediated services are invoked by the Mediation Service Clients just like any other service.

As regards the current release, all design time interaction needed to manage mediation tasks and services is performed through the Web GUI of the various Mediator Implementations (assets). Refer to the User guide of the specific asset.

The main interaction at execution time will be:

  • invocation of the mediation service, exposed by the mediator

The main interactions at design time will be (remote APIs that will be provided by the final release of the mediator):

  • create a mediation service (mandatory operation)
  • delete a mediation service (mandatory operation)
  • get a specific mediation service configuration (mandatory operation)
  • get available mediation tasks (mandatory operation)
  • get available dynamic mediation tasks (mandatory operation)

Invocation of the Mediation Service

At execution time the mediation capabilities are provided through services that can be invoked by the client GE using the mediation service URL. The mediation services can be exposed using various technologies, for example through soap web services and rest web services.

Mediation Service Management

The design time API will be designed for future releases of the FIWARE platform taking into account the available implementations (assets) of the Mediator GE

Basic Design Principles

  • API Technology independence
The API abstracts the concrete implementation technology. Implementations using various kinds of platforms and frameworks are possible.
  • Modularity
Mediation Tasks can be composed, creating Mediation Task chains that realize complex mediation logic.

Detailed Open Specifications

Concrete Implementation Documentation

Static mediation engine

In order to learn how to create mediation tasks refer to our presentation Mediator-doc and to understand in deep detail the concept of Virtual proxy see apache-synapse project mediation catalog (http://synapse.apache.org/userguide/mediators.html ).

In order to have an understanding of the Administration GUI of the static mediation engine see the User guide of Wso2 ESB Wso2-ESB-UserGuide

Dynamic mediation engine

The setha2 engine offers to FI-WARE a set of dynamic mediation tasks. SETHA2 is a software framework that deals with dynamicity and heterogeneity concerns in the SOA context and is composed of several components/tools that can be deployed independently, depending on the targeted needs of FI-WARE. A major part of SETHA2 is about providing libraries/facilities dedicated to data mediation. A brief description is available at SETHA2_DESCRIPTION.

Examples of dynamic mediation tasks provided by the dynamic mediation engine ("SETHA2"):

  • Data dynamic mediation tasks
  • Protocol dynamic mediation tasks
  • Process dynamic mediation tasks
Personal tools
Create a book