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

FIWARE.OpenSpecification.MiWi.Middleware

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.MiWi.Middleware
Chapter Advanced Middleware and Web-based UI,
Catalogue-Link to Implementation [N/A ]
Owner EPROS, ZHAW, DFKI, USAAR-CISPA, Christof Marti

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 Legal Notice to understand the rights to use these specifications.

Overview

This specification describes the Advanced Middleware GE, which enables flexible, efficient, scalable, and secure communication between distributed applications and to/between FI-WARE GEs.

Middleware in general provides a software layer between the application and the communication network and allows application to abstract from the intricacies of how to send a piece of data to a service offered by a another application and possibly return results. The middleware offers functionality to find and establish a connection to a service, negotiate the best wire and transport protocols, access the applications native data structures and encode the necessary data in a format suitable for the chosen protocol, and finally send that data and possibly receive results in return. In a similar way an application can use the middleware also to offer services to other applications by registering suitable service functionality and interfaces, which can then be used as targets of communication.

In contrast to other GEs, the Advanced Middleware GE is not a standalone service running in the network, but a set of compile-/runtime tools and a communication library to be integrated with the application.

The Advanced Middleware (AMi) architecture presented here offers a number of key advantages over other available middleware implementations:

  • High-Level Service Architecture: AMi offers applications a high-level architecture that can shield them from the complexities and dangers of network programming. When applications declare services and data structures they can annotate them with the QoS, security, and other requirements while AMi automatically implement them. Thus applications can exclusively focus on the application functionality.
  • Security: The network is the main security threat to most applications today but existing middleware has offered only limited security functionality that has often been added as an afterthought and requires the application developer (who are often not security experts) to configure the security functionality. Instead, AMi offers Security by Design where security has been a designed into the architecture from the start. Applications can simply declare their security needs in the form of security policies (security rules) and apply them to data structures and service at development time or even later during deployment definitions. AMi then makes sure that these requirements are met before any communication takes place and applies any suitable security measures (e.g. encryption, signatures, etc.) during the communication.
  • High-performance: The AMi API has been designed as to allow for the highest possible communication performance. Besides the common networking technologies like TCP/IP, this also includes the option of doing Remote DMA (RDMA) directly between in-memory data structures thereby completely eliminate the OS and network stack from the data communication on some modern networks (e.g. Infiniband), the use of shared memory on the same machine, or even the use of direct function calls for services within the same address space (e.g. via plug-ins).
  • Dynamic Multi-Protocol support: The AMi architecture can select at run-time the best way to communicate with a remote service. Thus, an AMi application can simultaneously talk with legacy services via their predefined protocols (e.g. DDS, REST) while able to take advantage of higher performance functionality when talking to other AMi services. It also supports various communication patterns, like Publish-/Subscribe (PubSub), Point-To-Point, or Request-/Reply (RPC).
  • QoS and Software Defined networking: Where possible the QoS annotations are also used to configure the network using modern Software Defined networking functionality, e.g. to reserve bandwidth.

The following layer diagram shows the main components of the Advanced Communication Middleware GE.

MiWi Middleware Architecture Overview
Advanced Middleware Architecture Overview

In the above diagram the principle communication flow goes from top to bottom for sending data, respectively and from bottom to top for receiving data. As in a typical layer diagram each layer is responsible for specific features and builds on top of the layers below. Some modules are cross cutting and go therefore over several layers (e.g. Security).

Here are some of the highlights of the AMi architecture shown in above diagram:

  • AMi clearly separates the definition of WHAT data must be communicated (the communication contract via one of many interface definition languages (IDLs)) from WHERE that data comes from in the application and from HOW that data is transmitted. This separation of concerns is critical to support some advanced functionality and be portable to a wide range of services and their communication mechanisms.
  • AMi offers a declarative API where the applications declare their native data structures (explicitly or implicitly, depending on the language used). Instead of enforcing its own type definitions onto applications, AMi allows applications to declare their native data types to the middleware which are then used as the sources and targets for sending data. This specifically means that AMi operates on an end to end basis between the memory spaces of two communicating applications
  • AMi supports multiple IDLs to define what data needs to be communicated. On establishing the connection the interface definition of a service are obtained (explicitly or implicitly).
  • AMi offers annotations for QoS, security, or other features that can be added to the data declared by the application, to the IDL, as well as later during deployment. They are are used by the middleware to automatically implement its functionality by requesting QoS functionality from the network layer or automatically enforcing security measures.
  • As the connection to a service is established, both sides choose a common mechanism and protocol (negotiation) to best communicate with each other. Besides the traditional network protocols like TCP/IP, AMi also supports advanced communication mechanisms like RDMA, shared memory, or simply function calls for plugins. AMi has been designed to also support Software Defined Networking in order to configure QOS parameters in the network.
  • AMi uses an embedded compiler to combine the information from the IDL and the data declarations and generates the most efficient code to map the native types to the network buffers and back. AMi can generate native code for best performance through JIT compilation, use an internal interpreter, or optionally also generate static stubs for fixed configurations. The generated code combines several of the layers including data access, encryption, marshaling, wire protocol encoding, as well as using some transport protocol for sending the data.
  • AMi offers an efficient dispatching mechanism for scheduling incoming request to the correct service implementation.

Below we give a short description of the different layers and components.

API & Data Access

The application accesses the communication middleware using a set of defined function calls provided by the API-layer. They may vary depending on the communication pattern (see below).

The main functionality of the Data Access Layer is to provide the mapping of data types and Function Stubs/Skeletons (request/response pattern) or DataReaders/-Writers (publish/subscribe or point-to-point pattern).

The Advanced Middleware GE provides two variants of this functionality:

  • A basic static compile-time Data-Mapping and generation of Function Stubs/Skeletons or DataReaders/-Writers, created by a compile time IDL-Parser/Compiler from the remote service description, which is provided in an Interface Definition Language (IDL) syntax based on the Object Management Group (OMG) IDL (see below) or, in case of WebService compatibility in Web Application Definition Language (WADL) syntax, which is submitted as a W3C draft.
  • An advanced dynamic runtime Data- and Function-Mapping based on a declarative description of the internal data-structures and functions provided by the application and the IDL description of the remote service with an embedded Runtime Compiler/Interpreter

Quality of Service (QoS) parameters and Security Policies may be provided through the API and/or IDL-Annotations. This information will be used by the QoS and Security modules to ensure the requested garantees.

Depending on the communication pattern, different communication mechanisms will be used.

  • For publish/subscribe and point-to-point scenarios, the DDS services and operations will be provided. When opening connections, a DataWriter for publishers/sender and a DataReader for subscribers/receivers will be created, which can be used by the application to send or receive DDS messages.
  • For request/reply scenarios the Function Stubs/Skeletons created at compile- or runtime can be used to send or receive requests/replies.

Marshaling

Depending on configuration, communication pattern and type of end-points the data will be serialized to the required transmission format when sending and deserialized to the application data structures when receiving.

  • Common Data Representation (CDR) an OMG specification used for all DDS/RTPS and high-speed communication.
  • Extensible Markup Language (XML) for WebService compatibility.
  • JavaScript Object Notation (JSON) for WebService compatibility.

Wire Protocols

Depending on configuration, communication pattern and type of end-points the matching Wire-Protocol will be chosen.

  • For publish/subscribe and point-to-point patterns the Real Time Publish Subscribe (RTPS) Protocol is used.
  • For request/reply pattern with WebService compatibility the REST/HTTP Protocol is used.
  • For request/reply pattern between DDS end-points the Real Time Publish Subscribe (RTPS) Protocol is used.
  • For for high-performance communication the wire protocol might be skipped entirely and set up directly on lower layer communication mechanisms and protocols.

Dispatching

The dispatching module is supporting various threading models and scheduling mechanisms. The module is providing single-threaded, multi-threaded and thread-pool operation and allows synchronous and asynchronous operation. Priority or time constraint scheduling mechanisms can be specified through QoS parameters.

Transport Mechanisms

Based on the QoS parameters and the runtime-environment the QoS module will decide which transport mechanisms and protocols to choose for data transmission.

In Software Defined Networking (SDN) environments, the SDN plugin will be used to get additional network information (e.g. from the I2ND GE) or even provision the network to provide the requested quality of service or privacy.

Transport Protocols

All standard transport protocols (TCP, UDP) as well as encrypted tunnels (TLS, DTLS) are supported. For high-performance communication in specific environments optional optimized protocols will be provided (Memory Mapping, Backplane/Fabric,...).

Security

The security module is responsible for authentication of communication partners and will ensure in the whole middleware stack, the requested data security and privacy. The required information can be provided with Security Annotations in the IDL and by providing a security policy via the API.

Negotiation

The negotiation module provides mechanisms to discover or negotiate the optimal transmission format and protocols when peers are connecting. It discovers automatically the participants in the distributed system, searching through the different transports available (shared memory and UDP by default, TCP for WebService compatibility) and evaluates the communication paradigms and and the corresponding associated QoS parameters and security policies.

Basic Concepts

In this section several basic concepts of the Advanced Communication Middleware are explained. We assume that the reader is familiar with the basic functionality of communication middleware like CORBA or WebServices.

Communication Patterns

We can distinguish between three main different messaging patterns, Publish/Subscribe, Point-to-Point, and Request/Reply, shown schematically bellow:

Publish/Subscribe Pattern
Publish/Subscribe Pattern


Point-To-Point Pattern
Point-To-Point Pattern


Request/Reply Pattern
Request/Reply Pattern


All middleware technologies available implement one or many of these messaging patterns and may incorporate more advanced patterns on top of them. Most of RPC middleware is based on the Request/Reply pattern and more recently, extents towards support of Publish/Subscribe and/or the Point-To-Point pattern.

W3C Web Service standards define a Request/Reply and a Publish/Subscribe pattern which is built on top on that (WS-Notification). CORBA, in a similar way, build its Publish/Subscribe pattern (Notification Service) on top of a Request/Reply infrastructure. In either case the adopted architecture is largely ruled by historical artifacts instead of performance or functional efficiency. The adopted approach is to emulate the Publish/Subscribe pattern on top of the more complex pattern thus inevitably leading to poor performance and complex implementations.

The approach of the Advanced Middleware takes the other direction. It provides native Publish/Subscribe and implements the Request/Reply pattern on top of this infrastructure. Excellent results can be achieved since the Publish/Subscribe is a meta-pattern, in other words a pattern generator for Point-To-Point and Request/Reply and potential alternatives.

Interface Definition Language (IDL)

The Advanced Middleware GE supports a novel IDL to describe the Data Types and Operations. Following is a list of the main features it supports:

  • IDL, Dynamic Types & Application Types: It support the usual schema of IDL compilation to generate support code for the data types, but also, dynamic runtime type creation, allowing the applications to use its own data structures without forcing to use the IDL compiler generated types. See the data-access feature bellow for a complete description.
  • IDL Grammar: An OMG-like grammar for the IDL as in DDS, Thrift, ZeroC ICE, CORBA, etc.
  • Types: Support of simple set of basic types, structs, and various high level types such as lists, sets, and dictionaries (maps).
  • Type inheritance, Extensible Types, Versioning: Advanced data types, extensions, and inheritance, and other advanced features will be supported.
  • Annotation Language: The IDL is extended with an annotation language to add properties to the data types and operations. These will, for example, allows adding security policies and QoS requirements.
  • Security: The IDL allows for annotating operations and data types though the annotation feature of our IDL, allowing setting up security even at the field level.

For compatibility with REST-based WebServices the Middleware also supports the W3C draft submission Application Definition Language (WADL).

Data Access Layer

The Advanced Middleware supports an advanced set of data types:

  • Static Data Types: Types generated via the IDL compiler in compliance with traditional approaches to warrant backward compatibility.
  • Dynamic Middleware Data Types: Data types generated by the middleware at runtime.
  • Application Native Data Types (new technique): To use application native data types, where the application provides type marshaling and data management using a declarative and/or procedural approach. To this end the Advanced Middleware GE provides two different mechanisms:
  • Letting the application developer provide his own data type plug-in using calls to low-level routine in the middleware that then perform the required marshaling and other operations. Some basis support for this is already provided by RTI-DDS (and also OpenDDS).
  • Exposing an API to describe the application data type and generating the required marshaling and management operations at run-time by:
  • Interpretation: Generating an intermediate byte-code to implement the operations and interpret this byte-code by a small “virtual machine”, or
  • Compilation: Generating an intermediate representation but compiling this data access code to native code with a JIT compiler (e.g. by an embedded LLVM-based compiler). This includes integrating and optimizing (e.g. inlining) the code for performing the chosen data marshaling and submission to the transport mechanism.

Main Interactions

As explained above, the middleware can be used in different communication scenarios. Depending on the scenario, the interaction mechanisms and the set of API-functions for application developers may vary.

API versions

There will be two versions of APIs provided:

  • Basic API
  • Static compile-time parsing of IDL and generation of Stub-/Skeletons and DataReader/DataWriter
  • Compatible to RPC-DDS and DDS applications
  • Advanced API
  • Dynamic runtime parsing of IDL and generation of Stub-/Skeletons
  • Mapping of application datatypes and functions
  • Advanced security policy and QoS parameters
  • Support for high-performance transport mechanisms and protocols
  • REST Webservice support

Classification of functions

The API-Functions can be classified in the following groups:

  • Preparation: statically at compile-time (Basic API) or dynamically at run-time (Advanced API)
  • Declare the local applications datatypes/functions (Advanced API only)
  • Parsing the Interface Definition of the remote side (IDL-Parser)
  • Building the data-/function mapping (Advanced API only)
  • Generate Stubs-/Skeletons, DataReader-/Writer (Compiler-/Interpreter)
  • Build your application against the Stubs-/Skeletons, DataReader-/Writer (Basic API only)
  • Initialization:
  • Set up the environment (global QoS/Transport/Security policy,...)
  • Open connection (provide connection specific parameters: QoS/Transport/Security policy, Authentication, Tunnel encryption, Threading policy,...)
  • Communication
  • Send Message/Request/Response (sync/async, enforce security)
  • Receive Message/Request/Response (sync/async, enforce security)
  • Exception Handling
  • Shutdown
  • Close connection (cleanup topics, subscribers, publishers)
  • Free resources

Detailed description of the APIs and tools can be found in the User and Programmers guide, which will be updated for every release of the Advanced Middleware GE.

Basic Design Principles

Implementations of the Advanced Middleware GE have to comply to the following basic design principles:

  • All modules have to provide defined and documented APIs.
  • Modules may only be accessed through these documented APIs and not use any internal undocumented functions of other modules.
  • Modules in the above layer model may only depend on APIs of lower level modules and never access APIs of higher level modules.
  • All information required by lower level modules has to be provided by the higher levels modules through the API or from a common configuration.
  • If a module provides variants of internal functionalities (e.g. Protocols, Authentication Mechanisms, ...) these should be encapsulated as Plugins with a defined interface.

Detailed Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labelled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE. Specifications labelled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

Open API Specifications

Re-utilised Technologies/Specifications

The Advanced Middleware GE is a set of communication libraries and tools to be delivered with applications/services. It is not a RESTful service running as a standalone component, but in the final advanced version it however can be used to provide or consume RESTful web services.

The technologies and specifications used in basic version of this GE are:

The Advanced Version will use and support additional technologies:

  • RESTful web services
  • HTTP/1.1 (RFC2616)
  • JSON and XML data serialization formats.

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

Annotations
Annotations refer to non-functional descriptions that are added to declaration of native types, to IDL interface definition, or through global annotations at deployment time. The can be used to express security requirements (e.g. "this string is a password and should be handled according the security policy defined for password"), QoS parameters (e.g. max. latency), or others.
AR
AR → Augmented Reality
Augmented Reality (AR)
Augmented Reality (AR) refers to the real-time enhancement of images of the real world with additional information. This can reach from the rough placement of 2D labels in the image to the perfectly registered display of virtual objects in a scene that are photo-realistically rendered in the context of the real scene (e.g. with respect to lighting and camera noise).
IDL
IDL → Interface Definition Language
Interface Definition Language
Interface Definition Language refers to the specification of interfaces or services. They contain the description of types and function interfaces that use these types for input and output parameters as well as return types. Different types of IDL are being used including CORBA IDL, Thrift IDL, Web Service Description Language (WSDL, for Web Services using SOAP), Web Application Description Language (WADL, for RESTful services), and others.
Middleware
Middleware is a software library that (ideally) handles all network related functionality for an application. This includes the setup of connection between peers, transformation of user data into a common network format and back, handling of security and QoS requirements.
PoI
PoI → Point of Interest
Point of Interest (PoI)
Point of Interest refers to the description of a certain point or 2D/3D region in space. It defines its location, attaches meta data to it, and defines a coordinate system relative to which additional coordinate systems, AR marker, or 3D objects can be placed.
Quality of Service (QoS)
Quality of Service refers to property of a communication channel that are non-functional, such a robustness, guaranteed bandwidth, maximum latency, jitter, and many more.
Real-Virtual Interaction
Real-Virtual Interaction refers to Augmented Reality setup that additionally allow users to interact with real-world objects through virtual proxies in the scene that monitor and visualize the state in the real-world and that can use services to change the state of the real world (e.g. switch lights on an off via a virtual button the the 3D scene).
Scene
A Scene refers to a collection of objects, which are be identified by type (e.g. a 3D mesh object, a physics simulation rigid body, or a script object.) These objects contain typed and named data values (composed of basic types such as integers, floating point numbers and strings) which are referred to as attributes. Scene objects can form a hierarchic (parent-child) structure. A HTML DOM document is one way to represent and store a scene.
Security
Security is a property of an IT system that ensures confidentiality, integrity, and availability of data within the system or during communication over networks. In the context of middleware, it refers to the ability of the middleware to guarantee such properties for the communication channel according to suitably expressed requirements needed and guarantees offer by an application.
Security Policy
Security Policy refers to rules that need to be fulfilled before a network connection is established or for data to be transferred. It can for example express statements about the identity of communication partners, properties assigned to them, the confidentiality measures to be applied to data elements of a communication channel, and others.
Synchronization
Synchronization is the act of transmitting over a network protocol the changes in a scene to participants so that they share a common, real-time perception of the scene. This is crucial to implementing multi-user virtual worlds.
Type Description
Type Description in the context of the AMi middleware refers to the internal description of native data types or the interfaces described by an IDL. It contains data such as the name of a variable, its data type, the hierarchical relations between types (e.g. structs and arrays), its memory offset and alignment within another data type, and others. Type Description are used to generate the mapping of native data types to the data that needs to be transmitted by the middleware.
Virtual Character
Virtual Character is a 3D object, typically composed of triangle mesh geometry, that can be moved and animated and can represent a user's presence (avatar) in a virtual world. Typically supported forms of animation include skeletal animation (where a hierarchy of "bones" or "joints" controls the deformation of the triangle mesh object) and vertex morph animation, where the vertices of the triangle mesh are directly manipulated. Virtual character systems may support composing the character from several mesh parts, for example separate upper body, lower body and head parts, to allow better customization possibilities.
WebGL
WebGL → (Web Graphics Library) is a JavaScript API for rendering 3D and 2D computer graphics in web browser.
Personal tools
Create a book