/ Programming

What is a Service Bus

I have been asked at work to focus my attention on service buss's. In particular I am supposed to look at Fubu Transportation. My aim for this blog post is to help me understand service bus implementations along with answering the questions I have set forth to answer.

What is a service bus?

Is it public transportation? Eh, No. A service bus is an architecture that helps with transferring information between applications that share/use similar data. So in essence it is an easier way of sharing data between applications.

Where are they used today?

There is actually a lot of applications that are using these babies. Some companies use them for handling their shopping cart transaction information. Stock trading programs use them for pushing data out to multiple clients. So they have their uses.

Why would you use one?

Now why would you want to use one of these over some of the other architectures we have out there? What is the benefit over something like REST or a query type approach? Rest is a stateless architecture. As soon as you make a request and it responds, it's alzheimer's kicks in and forgets who you are.

Meanwhile a service bus is known to remember who you are, and or know about you before you know about it.

There are three main patterns that are demonstrated:

  • Store and forward
  • Request and response
  • Pub and sub

Store and Forward

This pattern is the fire and forget pattern. The client knows about the server. Once it has its message ready, instead of connecting to the server or checking to see if it is there; the client fires the message in the direction of the server and then doesn't wait around to see if the message made it.
I found this out in my presentation that Fire and Forget is actually different than Store and Forward. Store and Forward is taking advantage of durable messaging. So look at durable messaging to get and understanding of this pattern

Why is this pattern useful?

Think about it server end out, you need to send data to a client but you don't necessarily care if the client receives it. You just know you need to send it out if they are listening. You can fire (stock prices) out to the client and if they aren't there, no harm done.

The benefits is that this is non blocking/delaying. You can just keep firing out responses without needing to make sure the other side received it. This is considered a one way connection.

Request and Response

This pattern each client and server have a direct line to each other. Thing is, they don't have just one line. They have one line for out and one line for in.

Why is this pattern useful?

This particular pattern helps with managing server resources because the server doesn't need to keep track of the clients. A request will come in and the server can respond based on the content of the request.

Publisher and Subscriber

The pub/sub pattern is a fun one. This one allows for clients/servers to subscribe to each other. We all know what happens when you accidentally sign up for that one newsletter and they sell your email. Now you and a thousand other people are subscribed to junk.

The pattern here is the server can take subscription requests from clients and add them to a list. When state changes on the server or an event happens, the server will go through that list and fire off a change event sending the data down. Some implementations do not require the client to subscribe before hand. You could have the server already have a list of clients needing to have these messages sent to them.

Why is this pattern useful?

Depending on the implementation, the server or client don't have to do work. Or both can rely on each other to notify one or the other if state changes. Say that you have a load balanced server. Both servers have their own database, I would think it is a good idea to make sure both are in sync with each other. Otherwise depending on what server the client gets to, on one server they might have made a purchase while on the other there is no record of it ever happening.

Other features

So now that we have described the many patterns available for us to use, what else is out there for the taking?

Durable messaging

What is durable messaging you say? Is it a message that is encrypted? Does it not break while flying on the wire we so commonly call the internet? Eh, no.

Durable messaging is a way to ensure that you can make sure the recipient of the message, actually gets the message. Say you were transferring a large dataset to another server and it is interrupted mid transfer. You would want that to send once the connection is reestablished right? Well the server would be able to save the message via hard disk or memory and then start the transfer over again once it reconnects.

Another implementation is that say you have a client that needs to receive information no matter what. But when you try to send information it is down for a particular amount of time. The server can save those messaged in a queue until that client comes back online.

The conclusion

Even though I say in these examples that you have a client and a server, the client could very well be another server. It is all in relation to perspective. Next post I will show how to implement some of these practices.