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

FIWARE.OpenSpecification.Apps.Mediator

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Apps.Mediator
Chapter Apps,
Catalogue-Link to Implementation [ N/A]
Owner Telecom Italia, THALES, Marco Ughetti, Pierre Chatel


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.

Copyright

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.

Overview

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">
 <target>
    <inSequence>
       <header xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" name="wsse:Security" action="remove" />
    </inSequence>
    <endpoint>
       <address uri="http://<ServiceExample URL>" />
    </endpoint>
    <outSequence>
       <send />
    </outSequence>
 </target>
 <enableSec />
 <policy key="conf:/repository/axis2/service-groups/SecuredServiceExampleProxy/services/SecuredServiceExampleProxy/policies/UTOverTransport" />
</proxy>

Example 2: Protocol Transformation TCP2HTTP

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

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.

File:MediatorArchitecture4.png
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

  • FIWARE.OpenSpecification.Apps.Mediator

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


Detailed Specifications

Open API Specifications

Other Relevant Specifications

None

Re-utilised Technologies/Specifications

  • RESTful web services
  • HTTP/1.1
  • W3C WS-*
  • XML data serialization format

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 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.
  • 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.
  • Dynamic Mediation Task: Mediation Tasks that can handle scenarios where all the needed data and/or information is not necessarily available at design time, but will became available at runtime.
  • Mediation Service: The mediation service represent the final mediation capability exposed by Mediator GE 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.
Personal tools
Create a book