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

* basis for describing and analyzing systems required

h2. Sebastian's Aims

* Solid foundation for system development

** XCF support ends

*** Footprint too large for embedded systems

*** Architectural erosion

*** Unmaintainable code base

h2. Lessons learned (also from other frameworks)

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