introducing Obvs, the observable µService* bus

I was recently asked to integrate a distributed Windows application, comprised of several Windows services and a desktop client, with some existing systems. After we decided on a better namespace and solution structure, I set about migrating it to Git, replacing libs with NuGet dependencies, creating a CI build, and getting it deploying from Octopus. All the best forms of procrastination.

To communicate between processes it was using a ‘homegrown’ .NET remoting solution where all services registered with a central service and could then interrogate this service for the location of other services. I suggested we aim to migrate all inter-process communication away from RPC and to messaging with a message broker, in this case ActiveMQ which was already in widespread production use at the time and so would make future integration easier.

obvsdoesnotsimply

To help convince the developers of the application who were not familiar with messaging patterns that this was a sound plan, and steer things towards the ‘pit of success’, I decided to write a simple layer to abstract the ActiveMQ API, based on Reactive Extensions. At first this was just a class called MessageSource which exposed an Observable of messages wrapping a single ActiveMQ topic and a very simple MessagePublisher to send messages. This was enough to get started, and soon we were sending messages around the system as well as integrating with existing messages from other systems.

However, soon the configuration of these sources and publishers began to get complicated and sprinkled throughout the code, and I realised they’d need to be consolidated. I also realised we needed to be clearer about the types of messages we were sending and what their intention was, and so introduced the well established concepts of ICommand/IEvent, and IRequest/IResponse. To consolidate the configuration I introduced the concept of an Endpoint for a service, which grouped its sources and publishers together. Each process then creates an instance of a ServiceBus which merges all the Endpoints it depends on into a single Observable stream per message type. Surfacing the observables directly in this way allows the user of the ServiceBus to easily create message pipelines by composing powerful RX operators. The ServiceBus instance can then be passed around or injected into the classes which require it. Simples.

Eventually this messaging library grew mature enough that a developer from another team expressed interest in using it for their own application, so I broke it out into its own solution, split out dependencies into their own projects, and named it Obvs – short for observable services. Never having published an open source project, I thought it might be a good learning experience to upload the code to GitHub.com and push the packages to NuGet.org  in the hope of getting some feedback and developing it further. I’d be thrilled if anyone took the time to review it or use it, so please do!

* The microservice moniker is a little tongue in cheek as I’m usually in the SOA camp, but I suppose it did seem apt as Obvs was always intended to be simple and unambitious. It also seems obvious that using message contracts to reduce coupling is preferable over REST API’s if you’re going to create a system of many small inter-dependent services.

One thought on “introducing Obvs, the observable µService* bus”

Leave a Reply