views:

67

answers:

2

I understand that some software systems implement message buses or "spines". For what applications is such technology suitable and why?

+1  A: 

I've never heard of a "spine". However, a common architecture is an Enterprise Service Bus (ESB).

Typically, you use this when you have many different components who need to subscribe to messages sent from other components. Usually in a disconnected state (fire and forget), however sometimes you require replies back.

ESB is not a high speed way of handling two way communications.

Biztalk is an example of one such system. There are many others and you can obviously code your own.

One example need is in order management and billing systems. Let's say a customer places an order. Notice of the order could be sent on the bus. If you have separate billing and fulfilment systems, then the bus could propogate the message to each of those without the ordering system knowing how it was going to be billed or even who was going to fulfill it.

Chris Lively
+1  A: 

Well it all depends on your need.

For example if you have a client / server application and you want to provide a real-time update Pub / Sub semantic. Then a message bus is ideal since you don't want to re-invent the wheel.

If you have processes that need to be Queued up for running you could also use a message bus for this as you can dump all your items into the queue and the process listening would pick them up and process as necessary.

We tend to use a message bus for Trading Systems but it could be used for anything where messaging to multiple clients is necessary. It's a bit of overkill if you are just a single client / server app and you don't need all clients kept up to date.

However it all depends on your usage scenario, so it's hard to say. Look into what a message bus provides and see if it offers any help in your applications context. Ask yourself can you provide the same thing using simple services, do you need a Pub / Sub model, Do you need guaranteed message delivery, what about message acknowledgment. Are you just asking for data for read only purposes or is it a full data entry system. Is there workflow involved that can benefit from a message bus, etc, etc, etc.

The main thing is look into what these systems provide and see if it's right for you. But also look at things like volume, usability, maintainability, etc. You could find multiple solutions based on a simple scenario that could all benefit partially from something like this but might be super overkill for small projects.

Joshua Cauble