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?
- Name participants within a "composite / group / ..."
- Add interface type information to participants?
- Clarify relationship with existing type information?