Lately I’ve been thinking a lot about distributed systems and all the challenges that you’ll have to deal with. I find it very interesting to think about software that isn’t hosted in a single process on a single machine. How do you integrate seamlessly between different parts of a big system that aren’t hosted on the same machine? How does your e-commerce site communicate with the warehouse system that is versioned independently and has a whole other release cycle? What if the warehouse system is down for maintenance, how will the e-commerce site react?
One thing that I’ve found really effective in solving these kind of integration problems is messaging, and in particular events. A event is a message that broadcasts to anyone who’s interested that a certain thing has happened in the particular system. The system publishing the event doesn’t care what you do with it, it only knows that you’re interested in that particular event.
If you have a application that publish events each time anything interesting happens, then it’s very easy to integrate with that system. All you need to do is tell that system you’re interested in a event. Lets say that we have a OrderAccepted event in this case. If you’re a warehouse system listening to the OrderAccepted event you probably want to make sure that the products associated with that order gets sent to the correct address. If you’re some kind of economy system you’re probably interested in the value of the order. What you do when you receive the event doesn’t matter to the e-commerce application. As far as its concerned, the job is done after publishing the OrderAccepted event.
The same goes the other way around of course. When the warehouse system ships the order. It will publish a event, OrderShipped, which the e-commerce system listens to. In this case we probably want to update the status of the order and tell the customer that the order is on it’s way.
When using messaging as our way of integrating systems, we keep the systems separated from each other, and they only have a dependency on the message schema. As long as the schema is the same we can easily version them independently. If we use a persistent messaging infrastructure we can also handle things like applications being down. Lets say our warehouse system is down while the e-commerce application publishes a OrderAccepted event. In this case the e-commerce application will just continue it’s business as usual. When the warehouse system gets back up it will find a bunch of events waiting and process them one by one, the customer won't notice anything.
There are lots of ways to handle system integrations, and there is no silver bullet solution that solves everything. You need to find the best way for your case. The nice thing about messaging is how it keeps your different applications independent of each other while, at the same time, offer a very nice integration point.