Riziv / Inami : InterProject communication

Using Events for inter-project communication

One-Many Communication 

Publish – subscribe

• Source publishes the Event upon the Topic
• Clients subscribe to a topic ( filtered or not ) to retrieve all published messages
• The Messagebus will multiply the message for every subscriber known upon the moment of publish. 

Concerns

• The content will be "public" and open for everyone with rights upon the Topic

Advantage 

• easy setup and little to none security settings needed ( only on topic level) 

Good to know

• Responses are not given in this scenario

Many-One Communication

Push-Pop

• Source requests Send rights upon the destination Queue
• Destination retrieves all Messages upon 1 Queue
  • Source is needed to be included in the message if responses are given )
• Destination requests Send rights upon the Source Queue for the responses
  • ​Same response Contract is used, but Destination knows on what queue to send

Concerns

• Rights will become a hassle to maintain as Source and Destination will start to have multiple links

Advantages

• Messages are more secure ( Nobody but destination can even accept/filter/read )
• responses don't need filters upon MessageType of Content/Header value

Good to know

• deployable units need send rights 
• this is also named "Command-Response"

Symptoms when choosing the wrong setup and the Danger/Cost

Publish - Subscribe 

• messages are "Public" on the Topic -> Data Security
• responses need to be filtered upon MessageType of Content/Header value
  • ​This means changes for every Source that wants to communicate
    • ​Code - Deploy - Test - VAL - PRD -> TTR ( Time to Release )​​

Push-Pop

• Same messages need to be Send multiple times for every Destination 
  • this is in a Loop by settings or even by Change ( TTR enlarges ) 
• Responses are never implemented or popped 
  • Delays and cost of the bus infrastructure