KIARA%–%FI(WARE%Advanced%Middleware%GE%Introduc:on%Webinar%–%2013(06(06%

http://www.fi-ppp.eu http://www.fi-ware.eu Follow @Fiware on Twitter ! !

Organization of the Webinar

Todays webinar consists of two parts: ! Part 1 (~90'): Overview of Basic Technologies (DDS, RPC for DDS)

•  Jaime Martin Losa (eProsima) CTO eProsima JaimeMartin@eProsima.com

! Part 2 (~20'): Overview and outlook to the Advanced API • Philipp Slusallek (DFKI)

Scientific Director slusallek@dfki.de

KIARA – FI-WARE Advanced Middleware GE Part 1: Basic Technologies (DDS, RPC for DDS)

http://www.fi-ppp.eu http://www.fi-ware.eu Follow @Fiware on Twitter !

Jaime Martin Losa CTO eProsima JaimeMartin@eProsima.com +34 607 91 37 45

Agenda

About eProsima Future Internet Middleware - The challenge

– Solutions – Future Internet impact

eProsima RPC & DDS (Base of Middleware GE) – DDS

Introduction Demo

– RPC for DDS Introduction Performance Standarization Roadmap Hands on Example

Questions

About eProsima

About eProsima

Experts on middleware, focused on DDS. OMG Members.

About eProsima: Products And Services

eProsima Products: – DDS based: Plugins, add-ons, adaptors, etc

Services: – Communication modules, App development, DDS

training, Support. R&D:

– R&D Projects with enterprises and universities. Quality: ISO 9001

– Design, Development, Marketing and Support of Software.

Customers (I)

Amper Programas: – BMS – Simacet (Main Spanish C2 System)

Cassidian: – UAVs - Neuron, Atlante

Ground Station Comm Server

– Comfut INDRA:

– Defense (BMS, UAV PASI) – Air Traffic Control, – SESAR, ATC Interoperability

Spanish Army:, – IDT :Tactical Data Interface

Customers (II)

Isdefe Spanish Army: JCISAT, DGAM CATEC-FADA: R&D Aerospatial Santa Barbara: Armoured Vehicles RTI GMV

Customers (III)

Tecnobit: COSMOS, Reserved Projects. IKERLAN: R&D. Navantia: F105 (Aegis) Boeing: Atlantida, Swim suit

eProsima Products.- Index

eProsima RPC: – Remote procedure calls framework over DDS and

other comm engines. eProsima Fast Buffers.

– Serialization engine. Now in beta. eProsima DDS Non-Intrusive Recorder.

– Stores DDS communication history in a data base.

Ongoing Project

FP7: KIARA, Future Internet Middleware – FI-WARE 1st open call – Based on eProsima RPC & OMG DDS – Lots of new features:

Improved IDL Direct Use of Application native types New formats of marshalling (SOAP, RestFul) Web Services compatibility Protocol negotiation Extended transport support High performance dispatching agent (RPC)

Current Development: Future Internet Middleware

The challenge

Introduction: Everything is distributed

Enterprise Internet, Internet of Things Cloud Computing

Fi-ware too!

Challenge

Everything is connected, and we should enable communication between the different nodes.

And this means: – Common protocols – Common Data Types – Known interfaces – Different QoS over different datalinks and

performance requirements. – Different comunications patterns. – Broad platform and programming language support. – …

fi-ware middleware GE

Middleware GE Epics

Epics – FIWARE.Epic.General.Middleware.IDL – FIWARE.Epic.General.Middleware.API – FIWARE.Epic.General.Middleware.DataAccess – FIWARE.Epic.General.Middleware.Marshaling – FIWARE.Epic.General.Middleware.Negotiation – FIWARE.Epic.General.Middleware.TransportProtocol – FIWARE.Epic.General.Middleware.TransportMechanisms – FIWARE.Epic.General.Middleware.Dispatching – FIWARE.Epic.General.Middleware.Security

More in FI-ware wiki

Solutions

Solutions (I)

User Middleware? – Propietary solutions not intended for public use

Not open & documented

– Limited features – Limited platform & language support. – Usually not fully tested for extended use.

Hmm, NO!

Solutions (II)

Mix of middlewares & bridges? – Legacy: CORBA – Enterprise: WS, Rest, JMS, RMI, Dcom… – High Performance: DDS, ZeroC ICE, Tibco – Cloud Message Queues: RabbitMQ, – Emerging: Apache Thirft, Google Protocol Buffers,

Apache Avro, eProsima RPC… Too complex!

– Lot of Bridges, Different Interface definitions, DataType incompatibilities… Babel Tower

Solutions (III)

Multi-use Middleware: – Common Interface Definition and DataTypes – High performance and flexible comm engine. – Multi-pattern – Broad platform and language support – Many QoS parameters available.

Yes! But, is it possible? – Fi-Ware Middleware GE – Based on eProsima RPC and DDS – Already available for download

New releases with extended features comming.

Fi-ware middleware

Code Named KIARA Partners:

– Our partners in this project are the Zurich University for Applied Sciences, the German Research Center for Artificial Intelligence, and the German Center for IT Security, Privacy, and Accountability.

Future Internet Impact

Fi-ware impact

Efficiency: – All systems talking in the same language – Common way to define the offered services – Faster and easier development.

Scalability: – Support for different platforms, devices, and data

links – Broad set of QoS parameters – Easy to use

Performance: – Fast Comm Engine

eProsima RPC

DDS

DDS (Data Distribution Service for Real-Time Systems) is a OMG specification for a pub/sub data centric model (DCPS, Data Centric Publish/Subscribe) for Real-Time data comms in distributed systems.

DDS is a networking middleware that: – Simplifies and Standardizes data flows in distributed real-time

systems. – Provides robust comms (no single point of failure) and efficient

(minimum latency) – Provides all kind of QoS to shape the data flows and deliver

predictable results.

DDS

DDS uses the concept of Global Data Space. In this Space we define topics of data, and the publishers publish samples of these topics. DDS distributes these samples to all the subscribers of those topics. Any node can be a publisher or a subscriber.

Why DDS? Decoupled model

Space (location) – Automatic Discovery ensures network topology independence

Redundancy: – It is possible to configure redundant publishers and subscribers,

primary/secundary and takeover schemas supported Time:

– The reception of data does not need to be synchronous with the writing. A subscriber may, if so configured, receive data that was written even before the subscriber joined the network.

Platform: – Applications do not have to worry about data representation, processor

architecture, Operating System, or even programming language on the other side

Implementation: – DDS Protocol is also an standard. Different implementations

interoperate.

Why DDS? Fully configurable

QoS Policy DURABILITY

HISTORY

READER DATA LIFECYCLE

WRITER DATA LIFECYCLE

LIFESPAN

ENTITY FACTORY

RESOURCE LIMITS

RELIABILITY

TIME BASED FILTER

DEADLINE

CONTENT FILTERS

Vola

tility

User Q

oS

Del

iver

y

Presentation R

edundancy

Infra

stru

ctur

e

Transport

QoS Policy USER DATA

TOPIC DATA

GROUP DATA

PARTITION

PRESENTATION

DESTINATION ORDER

OWNERSHIP

OWNERSHIP STRENGTH

LIVELINESS

LATENCY BUDGET

TRANSPORT PRIORITY

Demo

RPC over DDS

DDS implements a pub/sub model, but no a direct way to do Remote Procedure Calls (RPC)

DDS Can be used thought for RPC with some effort: We can create a couple of topics, one for the in parameters of the function we want to call, and the other one for the out parameters, and then implement the client-server interaction through a couple of pub-sub.

Client-Server comms over DDS

myService.idl: interface myService

funReturnValueDataType Fun(DataType1 parameter1, DataType2 parameter2…);;

Client-Server comms over DDS: Manual Steps

For each interface: – myService, myServiceSupport, myServicePlugin (rtiddsgen) – myServiceProxy, myServiceServer – Client main, Server main. – Client and Server code for data flow management, initialization

and setup of DDS entities, server threading…

For each method: – funRequest, funRequestSupport, funRequestPlugin (rtiddsgen) – funReply, funReplySupport, fun1ReplyPlugin (rtiddsgen) – Client and Server code to manage function calls/return-values,

parameters...

Client-Server comms over DDS: Automatic (using eProsima RPC over DDS) A parser creates all the stuff you need. For each method, just implement the behavior.

eProsima RPC: Advantages

Allows to the developer focus in the development of his application.

Approach similar to Apache Thrift, but easier to use and with configurable QoS

Transparent. Multithreaded Server. Automatic Generation of:

– Client and Server Code. – Request and Reply Topic – Development enviroment files: Visual Studio

projects or makefiles

eProsima RPC: DDS as comm engine

OMG DDS: Real-Time Data Distribution Service – High performance – Broad platform support – Open Standard – Proven in exigent domains: Defense and aerospace. – Publish-Suscribe Model

eProsima RPC: Features

Open Source – Support available

Main Features: – Windows and Linux support (32 and 64 bits)

Project and makefile generation for VS2010 & gcc 4.x

– Synchronous, asynchronous and one way operations – Different Server threading models

Single threaded, thread by request and thread pool

– Internet enabled: udp (unicast/multicast) and TCP support

– 100% Standard: ISO C++ and OMG DDS RTI DDS and OpenDDS supported

Performance vs Web Services (Throughput)

0

100

200

300

400

500

600

700

10 100 200 300 400 500

Req

uest

s/se

c

Request Payload (bytes)

eProsima RPC vs Web Services (25 Clients)

eProsima RPCWeb Services

Performance vs Apache Thrift (One to One Latency)

0

100

200

300

400

500

600

700

100 250 500

Late

ncy

(Mic

ro S

econ

ds)

Request/Reply Size (bytes)

One to One Latency

eProsima RPC over DDS

Apache Thrift

Performance vs Apache Thrift (Many to One Latency)

0

200

400

600

800

1000

1200

1400

100 250 500

Late

ncy

(Mic

ro S

econ

ds)

Request/Reply Size (bytes)

Four to One Latency

eProsima RPC over DDS

Apache Thrift

eProsima RPC: Rest & WS Support

Multiple “Transports” Supported Shared IDL

RoadMap

Fast Buffers: Serialization Engine, Including Dynamic serialization through TypeCode (June – Beta Already Available!)

Rest/Web Services Support .- July 2013 Compliance with eProsima Revised

Submission .- June 2013 Native Data Support .- September 2013

Standarization

OMG Standard ongoing – RPC for DDS RFP (public) – eProsima, RTI, PrismTech – Revised Submission : May, 20, 2013 – Presented in the next OMG meeting

June 17,18 – Berlin See www.eprosima.com for more info.

Hands on: A First Example

Install the software: – DDS

http://www.rti.com/downloads/connext.html

– RPC over DDS http://www.eprosima.com/index.php/en/downloads-all

Windows and Linux (32 & 64) supported

Hands On: A first Example

Create math.idl Compile:

/////////////////////////// // KIARA Webinar Example // /////////////////////////// interface math float sum (in float x,in float y); // x+y float substract (in float x,in float y); // x-y float multiply (in float x,in float y); // x*y ;

rpcddsgen -ppDisable -example x64Win64VS2010 math.idl

Hands On: A First Example

Edit the Example: – Client.cxx

– mathServerImpl.cxx

// Call to remote procedure "sum". try sum_ret = proxy->sum(2, 2); std::cout << "KIARA Says 2+2=" << sum_ret << std::endl;

DDS_Float mathServerImpl::sum(/*in*/ DDS_Float x, /*in*/ DDS_Float y) DDS_Float sum_ret = 0; sum_ret = x+y; return sum_ret;

Hands On: A First Example

Run the Client and the Server – Same or different connected machines

– Remember to disable/setup firewall

D:\KIARA_Webinar_Examples\math\objs\x64Win64VS2010>mathClient KIARA Says 2+2=4 D:\KIARA_Webinar_Examples\math\objs\x64Win64VS2010>

Questions?

Jaime Martin Losa CTO eProsima

JaimeMartin@eProsima.com +34 607 91 37 45 www.eProsima.com

Thank you!

Jaime Martin Losa CTO eProsima

JaimeMartin@eProsima.com +34 607 91 37 45 www.eProsima.com

KIARA – FI-WARE Advanced Middleware GE Part 2: Overview & outlook to the Advanced API

http://www.fi-ppp.eu http://www.fi-ware.eu Follow @Fiware on Twitter !

Philipp Slusallek DFKI Scientific Director WP Architect, FI-WARE slusallek@dfki.de

KIARA – FI-WARE Advanced Middleware GE

! FI-WARE OpenCall 1: • The goal of this GE is to create and establish a middleware that enables flexible,

efficient, scalable, and secure communication between distributed applications and between FI-WARE GEs.

! 1.25 Mio € EU funding ! 18 Months (starting Nov. 2012) ! 4 Partners:

KIARA – FI-WARE Advanced Middleware GE

! Flexible, efficient, scalable and secure communication between distributed applications and Generic Enablers & services

KIARA – FI-WARE Advanced Middleware GE

! Flexible, efficient, scalable and secure communication between distributed applications and Generic Enablers & services ! Enabling high-performance & secure operations:

• Real-time, low-latency, high bandwidth • Novel network transport mechanisms (e.g. RDMA) & network control (SDN) • Security by Design: Providing advanced security around applications & services

KIARA Design Principle

! Clear Separation of Responsibilities •  IDL: Specifies WHAT data needs to be transferred • API: Specifies WHERE the data is stored • Transport: Specifies HOW the data is transferred (negotiated) • Annotation: Specifies PROPERTIES of the data and the communication

Application Data

IDL

Transport Mapping

KIARA Architecture

Application Data

IDL

Transport

“Client“

Mapping Transport

IDL

Application Data

“Server“

Mapping

Negotiation

App App

KIARA – Advanced Features

! Support for multiple communication patterns ! Improved IDL (based on OMG-IDL) ! Declarative API: Direct usage of application native types ! Transport protocol / mechanism negotiation ! Extended transport protocols and mechanisms

(Shared Memory, UDP, RDMA, SDN Plugin,...) ! Dynamic mapping of native data to IDL and used protocol ! Run time optimization with embedded compiler/interpreter (LLVM) ! High performance dispatching agent ! RESTful Web Service compatibility (XML/JSON marshaling) ! Synchronous, asynchronous operations ! Advanced security features (security policies, locally tested/global policy) ! Support for modern Languages (C & C++ in first release)

KIARA – Component Overview

IDL, API, Data Access

! Advanced KIARA API • Application declares its own interface function calls • Uses application data types (declared to KIARA)

! Provides meta-data annotations (QoS, security policies, etc.) ! Generates support code (function stubs/skel) and data-mapping

• Done at run-time (after negotiation), optionally also at compile time

! Embedded run-time compiler/interpreter for optimized code paths

KIARA API Example (C++, current version)

! KIARA Uses Native Data Structures (1) • Any data structures could be used • Might need app support (e.g. mem mgnt)

! Declaration of Data Structures (2) • Structure is provided to KIARA • Same for interface functions

! General KIARA Initialization (3) • Thread save internal data structures

! Initial connection to a service (4) • Established connection • Negotiates communication details • Generates interface function (compiler/interpr.)

! Use interfaces as normal code (5)

struct float x; float y; Vec2f; KIARA_DECL_STRUCT(Vec2f, KIARA_STRUCT_MEMBER(KIARA_INT, x) KIARA_STRUCT_MEMBER(KIARA_FLOAT, y) ) // int Add(float*, float, float); KIARA_CXX_DECL_FUNC(AddFunc, KIARA_CXX_FUNC_RESULT(float *, result) KIARA_CXX_FUNC_ARG(float, a) KIARA_CXX_FUNC_ARG(float, b) ) kiaraInit(); KIARA_Context *ctx = kiaraNewContext(); KIARA_Service *service = kiaraOpenConnection(ctx, "http://localhost:8080/service"); AddFunc addf = KIARA_GENERATE_CLIENT_FUNC(service, "calc.addf", Add, ""); float result; int errorCode = addf(&result, 21.0, 32.0);

1

2

3

5

4

Embedded Compiler/Interpreter

! High-Performance Implementation (HPC, Streaming, ...) • Goal: Thinnest possible layer between app data and „network“ ›  „Network“ may be: in-app function call, SHMEM, TCP, RDMA, …

•  Ingredients: ›  Data Access Layer: Direct access to app data ›  Marshaling: May depend on run-time negotiation (e.g. text vs. binary, may need encoding) ›  Transport mechanism: E.g. function call / socket / RDMA ›  Mapping: May need to convert data types, etc. (advanced capabilities) ›  Security policies: Data may need to be encoded, signed, identity information added, etc.

• Eliminate (virtual) function call overhead ›  Typically many tiny functions, so overhead can be huge ›  Embedded compiler inlines code, interpreter as fallback

KIARA – WebService compatibility

!  Service is described in a service description document (JSON) •  Contains/points to IDL, lists end-points

!  Advanced IDL (based on OMG IDL) with Security/QoS annotations • Support for all features, binary data encoding (CDR), additional transport protocols/

mechanisms, full performance

!  RESTful WebService backward compatibility (WADL) •  Limited features, XML/JSON data encoding, HTTP transport

Client Server

KIARA App KIARA App

KIARA IDL

CDR

KIARA IDL

Transport (DDS/TCP/...) Mapping

KIARA App REST-WS

WADL

XML/JSON

WADL

Transport (HTTP) Mapping

Transport Protocols / Mechanisms

!  Normally Middleware like DDS is working "over the top" best effort (does not consider the infrastructure topology)

!  Implementation of additional performing protocols (in a controlled environment: within Data Center / Cloud-Provider), e.g. •  Datagram Congestion Control Protocol (DCCP)

performs better specifically for streaming environments transfer rate adoption

•  RAW Ethernet?

!  Or use better performing transport mechanisms, e.g. • Usage of IPC, RDMA, etc.

!  Mapping of API/IDL QoS annotations to network QoS

Security By Design

! Motivation • Make the middleware the built-in „Firewall“ of the application • App expresses security requirements (i.e. policies) ›  Defines kinds of data: e.g. Password, Account number ›  Defined security policy to be used for each kind:

›  e.g. must not be exposed, can only be communicated to certain group

›  Communication partner must guarantee that they obey to these policies

! Main challenges • How to formulate the policies (policy language)? • How to formulate guarantees between partners? • How to most efficiently implement them? • How do policies interact with the legal system?

Negotiation

! Runtime Negotiation do determine: • Best Transport Mechanism • Most efficient Transport Protocol • Marshaling CDR, XML, JSON (Text vs. Binary) • Block size i.e. depending on interaction pattern

(RPC, Messaging, Data Transfer, ...) • Security features • Can renegotiation in case the environment changes

! Interact with Network Control Plane • SND Plugin to interact with SDN-Controller ›  Generic (e.g. NOX, Floodlight) or ›  I2ND GE

hBp://fi(ppp.eu%hBp://fi(ware.eu%Follow @Fiware on Twitter ! %%

Thanks!!!