Overview¶
Problem statement¶
- easier integration of complex (partially) distributed systems required
- in-house (one middleware)
- adaption (combination with other middlewares)
- reduce islands of non-accessible functionality
- 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
- accept heterogenity: open architecture required
- specifications for data format and transport protocols
- use of existing (and open) naming services
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
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)
- sending schema-free messages was too easy
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
- possibility to send schema-free messages is still possible, but using well-defined schemas is much more enforced
What is and what it is not¶
- Soft-RT but no hard real-time
- in-process, shared-mem, ipc
- no component architecture
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
- event-driven
- broadcast semantics
- content-based filtering
- introspection
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
- instead arbitrary client data is serialized to different wire types using (user-installed) converters
- performance requirements on network-based (UDP) and in-process transport
- no hard real-time
- avoid serialization when possible
- No hard dependency on name service
Planned functionality:¶
- introspection tools
- model-based setup
- Naming, Service discovery
- Distributed (e.g. mdns, upnp, etc.)
- Sychronization primitives
- E.g., AV Fusion
- Tools, in particular
- Introspection
- Logging, Replay
- Platforms
- Web integration (WebServices)
- XMPP
- Mobile devices
- DNLA (streaming, etc.)
- Timing
- Time-informer
- Clock source
- Synchronization
- Associated Patterns
- Clock-driven behavior
- Clock-based filtering
- Time-informer
- Model Layer/Component Model
- Role of
Service
class
- Role of
- Framework Interoperability
- Plugin Mechanism (for C++)
- Content-based filtering
- ProtocolBuffer layer
- Ideally, without unpacking