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
 

In a recent post Steve Vinoski said:

"Frankly, if I were an enterprise architect today, and I were genuinely concerned about development costs, agility, and extensibility, I’d be looking to solve everything I possibly could with dynamic languages and REST, and specifically the HTTP variety of REST. I’d avoid ESBs and the typical enterprise middleware frameworks unless I had a problem that really required them (see below). I’d also try to totally avoid SOAP and WS-*."

It is easy to dismiss this as just another yahoo who goes against conventional wisdom until you remember that Steve spent more than a decade working in Iona in leading roles like Chief Engineer of product innovations and helped develop some of the middleware standards for OMG and W3C.

Well, I guess that's becoming an epidemic  now :)  just recently we had Michael Stonebreaker talking about the RDBMS demise, Pat Helland talking about life beyond distributed transactions.  and now Steve on ESBs.

That trend aside, I think Steve is doing throwing the baby out with the bath water. The dream of a single infrastructure for an enterprise is ludicrous enough (Remeber Peter Deutsch and the "The network is homogeneous" fallacy). but if you drop the "E" from the ESB moniker you get a valuable middleware which is very usable in many situations and not just legacy system integration. For instance one thing that is missing form "HTTP variety of REST" implementation is reliable messaging. location transparency is  harder to solve with HTTP etc.

Another problem I have with the current approach of Steve is that he is replacing one dogma (EBSs are good) with another (ESBs are bad use Ruby, REST) - this is not a healthy approach. The solution should match the problem, that's probably the primary reason why we need architects after all