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
  • 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

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 (also from other frameworks)¶

• 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
  • different language implementation should not depend on a single base implementation (reduce development and deployment complexity, increase usability of the framework)

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

Planned functionality:¶

• naming and discovery
• introspection tools
• model-based setup