Overview » History » Version 19
Version 18 (J. Wienke, 06/10/2011 06:08 PM) → Version 19/24 (J. Wienke, 06/10/2011 06:14 PM)
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 (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)
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
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:
* naming and discovery
* introspection tools
* model-based setup
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 (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)
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
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:
* naming and discovery
* introspection tools
* model-based setup