I got a question from Dru for my opinion of tow messaging subscription modes - subscription by message (type) and subscription by topic
The way I see it there are two different usages for Topics.

The first use for topics is for grouping or marking related messages. In this scenario you can actually break the subscription into three different levels of  generalization:
  1. Per message- interested parties subscribe to a specific type
  2. Topics - interested parties subscribe to a set of related types
  3. Topics hierarchy - interested parties subscribe to a set of sets
Here, when it comes to topics -on the pro side you get to easily subscribe to a lot of message types and on the con side you get to easily subscribe to a lot of message types...
The less specific the subscription, the harder it is to ensure it would work in open environments (i.e. when different organizations or groups get to integrate with your services). The problem lies in the number different messages you need to be able to handle/understand/parse and the control on new  types of messages. Getting versioning right with messages is hard enough when you have a hierarchy well that's just much harder

The second use for topics is routing.In this scenario a specific message type  can be sent using different topics.And the  topics basically become part of the  meta-data of the message. The supporting infrastructure can then use that meta-data to get messages to different subscribers. For example,  In a defense system project I participated in , we used Tibco Rendezvous support for topics to define interest regions on a closed set of messages e.g.  say you want only the messages related to the middle-east or the ones related to the US etc.
In the current infrastructure I am building I am going to implement something similar to topics (albiet without hirarchies) to allow different routings based on different saga types (so services that stay the same don't have to change thier behaviours)

To sum this, I would say that in my opinion the latter use for topics  is more useful for  general purpose use and the first use for topics is more useful in closed systems

P.S.
if you have an interesting question on SOA or architecture you can send it in and if I think it would interest a wider crowd I'll blog it here
 

Sunday, November 09, 2008 3:06:27 PM (GMT Standard Time, UTC+00:00)
Thanks! Arnon, excellent stuff as always, it nice to hear your actual experience with the topic as well, not just theory.
-d
Friday, November 21, 2008 9:57:13 PM (GMT Standard Time, UTC+00:00)
Great post, made me wonder whether you use the Datatype Channel approach?
Saturday, November 22, 2008 4:19:54 AM (GMT Standard Time, UTC+00:00)
@Jack
No we don't use the Datatype channel pattern. The event broker resolves the needed contracts (relying on conventions)
Arnon
Saturday, November 22, 2008 9:48:10 PM (GMT Standard Time, UTC+00:00)
Thanks for replying and yeah that makes perfect sense.

One question though, I notice that in your description of the Decoupled Invocation pattern you describe having several queues according to message priorities. Would the same thinking apply there, where the event broker decides how to deal with the high priority messages?
Sunday, November 23, 2008 3:47:05 AM (GMT Standard Time, UTC+00:00)
Channel optimization is problematic in WCF since it depends on the throttling settings on the receiving end.
Currently we have one channel per active saga (per source-> target pair) but that works because its a closed system (for now). previous version had one shared channel, since keeping the number of channels low in a general setting is more important, in a more general scenario we'll probably need priorities

Arnon
Comments are closed.