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
Adopted concepts (from XCF):
  • 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:
  • 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
  • Model Layer/Component Model
    • Role of Service class
  • Framework Interoperability
  • Plugin Mechanism (for C++)
  • Content-based filtering
    • ProtocolBuffer layer
    • Ideally, without unpacking