Meetings2014-03-17

RSB Component/Service/Group/Composite Semantics

  • Currently, we lack the possibility to group participants and treat these as a kind of "component".
  • We (Jan, Arne, Sebastian) consider such a group of participants useful.
  • Features that relate to this notion of "components/groups/composites" could be:
    • Has own id and is participant
    • Assign (composite) transport configurations with default configurations that can be optionally overwritten
    • Assign (optional) / share common scope prefix?
    • Describe / prescribe (?) "component" interfaces (cf. RSB DSL) for the involved participants
  • Should "components/groups/..." be restricted to a single process?
  • Couldn't the Participant implement the Composite semantics and the existing RSB pattern objects (Informer, Listener, ...) be the leafs?

Named Participants

  • Name participants within a "composite / group / ..."
  • Add interface type information to participants?
  • Clarify relationship with existing type information?