Robotics Service Bus

h1. Overview

h2. Problem statement

* easier integration of complex (partially) distributed systems required

** in-house (one middleware)

** adaption (combination with other middlewares)

* reduce islands of non-accessible functionality

* targeting at technical architecture (only supporting functional concepts)

* performance requirements

* platform requirements

* programming language requirements

** desired set of languages

** natural feeling in each language by using native mechanisms

* basis for describing and analyzing systems required

* accept heterogenity: open architecture required

** specifications for data format and transport protocols

** use of existing (and open) naming services

h2. Sebastian's Aims

* XCF support ends

** better solution required

* limited client interface that converts to domain data as soon as possible to prevent dependency on middleware throughout the whole client code

* variable dispatching mechanisms not forced by the framework

h2. Lessons learned (from other frameworks, e.g. XCF, YARP, ROS, NaoQi)

identified problems:

* Footprint too large for embedded systems

* Architectural erosion

* Unmaintainable code base

* important parameters and implicit assumptions should not be hidden in the code for analysis

* missing introspection functionalities

* bad error handling strategies, e.g. missing transparency for the client (i.e. swallowed exceptions)

* sending schema-free messages was too easy

lessons learned:

* layered architecture with improved functional decomposition in distinct libraries, layers:

** core (bus realization across different transports)

** tools

** XML compatibility layer

** XCF API adapters

* clear dependency statements:

** core must survive with the least amount of external libraries

** different language implementation should not depend on a single base implementation (reduce development and deployment complexity, increase usability of the framework)

* development process

** bigger developer team > 1 experienced person

** clear testing strategies

** continuous integration

* allow more flexibility through defined interfaces and protocols

** allow different transports, e.g. in-process

** encoding flexibility for user data to meet domain and performance requirements

* provide additional system structures like services to aggregate coherent functionality

* avoid centralized nameservice

* possibility to send schema-free messages is still possible, but using well-defined schemas is much more enforced

h2. What is and what it is not

* Soft-RT but no hard real-time

* in-process, shared-mem, ipc

* no component architecture

h2. Functional properties (so far):

* Event-driven middleware with broadcast semantics

** Additional communication patterns implemented on top of this base functionality

* logically unified bus across multiple transports

** currently a spread-based and an in-process transport are available

** extensible to other transports -> compatibility to existing frameworks

* Bus is structured by hierarchical channels

** / receives all messages of sub-scopes like /a/test

* Support for filtering events:

** content-based

** on meta-data

* URI-based

Adopted concepts (from XCF):

* event-driven

* broadcast semantics

* content-based filtering

* introspection

h2. Non-functional properties (so far):

* lightweight (will remain [for the core]):

** small dependency footprint for the core layer

** Targeting at embedded systems (e.g. Nao)

* Languages: cpp, java, python, common lisp

** real implementations, no bindings to provide natural interfaces in each language

* No single wire type like XML:

** instead arbitrary client data is serialized to different wire types using (user-installed) converters

*** default set of converters exists (e.g. source:/trunk/cpp/core/src/rsb/converter/StringConverter.cpp)

** provide flexible and fast serialization mechanisms

** XML support layer as additional library

* performance requirements on network-based (UDP) and in-process transport

** no hard real-time

** avoid serialization when possible

* No hard dependency on name service

h2. Planned functionality:

* introspection tools

* model-based setup

* Naming, Service discovery

** Distributed (e.g. mdns, upnp, etc.)

* Sychronization primitives

** E.g., AV Fusion

* Tools, in particular

** Introspection

** Logging, Replay

* Platforms

** Web integration (WebServices)

** XMPP

** Mobile devices

** DNLA (streaming, etc.)

* Timing

** Time-informer

*** Clock source

*** Synchronization

** Associated Patterns

*** Clock-driven behavior

*** Clock-based filtering

* Model Layer/Component Model

** Role of @Service@ class

* Framework Interoperability

* Plugin Mechanism (for C++)

* Content-based filtering

** ProtocolBuffer layer

** Ideally, without unpacking