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 [email protected]
! Part 2 (~20'): Overview and outlook to the Advanced API • Philipp Slusallek (DFKI)
Scientific Director [email protected]
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 [email protected] +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: 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)
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. – …
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 (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.
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
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
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
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>
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 [email protected]
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)
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