I'm trying to use SSB as full-duplex messaging infra for multiple distributed logical stations. Several stations can reside on same process, or on different machines (doesn't matter). The stations need to communicate and sync with each other by constantly sending messages back and forth. The stations run as part of a Windows Service, so, a station's life-time is very long. Each message a station sends may be designated to a single station or to multiple stations or to all stations (broadcast). A message is relevant to a specific station only if it's designated to that specific station, or if it's a broadcast message.
All the SSB's Dialog/Converstation/Group terminology really got me confused.
I can't figure out how to determine who and when should become an Initiator/Target, because according to my case, each station can send a message whenever it needs to, and should receive relevant messages all the time.
Since many stations might send messages to many other stations, all at the same time, dequeuing time should be a quick as possible, and performance must be optimal.
According to Microsoft, I should use many conversations with many messages for optimal performance. But I can't figure out when and how I should create a separate dialog/conversation, and when should a conversation end, if at all.
Can someone please shed some light on this, and give me a proper direction for my case?
Thank you.
Assuming that each station has an inventory of all of the others (which may take some hand holding!), this should be doable.
In regards to the initiator/target terminology, whomever starts the conversation is the initiator and the recipients of that message are targets. Imagine the following real world conversation. I'll prepend any messages sent by initiator with an [I] and those sent by the target with a [T]
In that case, there was only one target, but a given conversation can be initiated with multiple targets in mind (in your "multiple stations" or "broadcast" scenarios). To further the above analogy, it'd be akin to calling multiple stores at once and asking them all for their sock inventory.
Intuiting why you'd need to know who is the initiator and target, the above conversation could be broken down into the following message types: InventoryRequest, InventoryResponse, PurchaceRequest, PurchaseResponse. If you bundle those all into one contract, you should be off to the races.