Overview » History » Version 9
« Previous -
Version 9/24
(diff) -
Next » -
Current version
J. Wienke, 06/10/2011 05:33 PM
Overview¶
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
Sebastian's Aims¶
- Solid foundation for system development
- XCF support ends
- Footprint too large for embedded systems
- Architectural erosion
- Unmaintainable code base
- XCF support ends
Lessons learned (also from other frameworks)¶
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
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
- instead arbitrary client data is serialized to different wire types using (user-installed) converters
Planned functionality:¶
- naming and discovery
- introspection tools
- model-based setup