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)

* 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

* 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 (also from other frameworks)

XCF:

* identified problems:

** Footprint too large for embedded systems

** Architectural erosion

** Unmaintainable code base

* 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)

h2. Functional properties:

* Event-driven middleware with broadcast semantics

** Additional 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

h2. Non-functional properties:

* lightweight:

** 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

h2. Planned functionality:

* naming and discovery

* introspection tools

* model-based setup