Overview » History » Version 10
Version 9 (J. Wienke, 06/10/2011 05:33 PM) → Version 10/24 (J. Wienke, 06/10/2011 05:39 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
* basis for describing and analyzing systems required
* open architecture
** specifications for data format and transport protocols
h2. Sebastian's Aims
* Solid foundation for system development
** XCF support ends
** better solution required
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
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
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
* open architecture
** specifications for data format and transport protocols
h2. Sebastian's Aims
* Solid foundation for system development
** XCF support ends
** better solution required
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
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