Push-Based Events in a Services Oriented Architecture

Question

I have come to a point, in building a services oriented architecture (on top of Thrift), that I need to expose events and allow listeners.

My initial thought was, "create an EventService" to handle publishing and subscribing to events. That EventService can use whatever implementation it desires to actually distribute the events. My client automatically round-robins service requests to available service hosts which are determined using Zookeeper-based service discovery. So, I'd probably use JMS inside of EventService mainly for the purpose of persisting messages (in the event that a service host for EventService goes down before it can distribute the message to all of the available listeners).

When I started considering this, I began looking into the differences between Queues and Topics. Topics unfortunately won't work for me, because (at least for now), all listeners must receive the message (even if they were down at the time the event was pushed, or hadn't made a subscription yet because they haven't completed startup (during deployment, for example) - messages should be queued until the service is available).

However, I don't want EventService to be responsible for handling all of the events. I don't think it should have the code to react to events inside of it. Each of the services should do what it needs with a given event. This would indicate that each service would need a JMS connection, which questions the value of having EventService at all (as the services could individually publish and subscribe to JMS directly). However, it also couples all of the services to JMS (when I'd rather that there be a single service that's responsible for determining how to distribute events).

What I had thought was to publish an event to EventService, which pulls a configuration of listeners from some configuration source (database, flat file, irrelevant for now). It replicates the message and pushes each one back into a queue with information specific to that listener (so, if there are 3 listeners, 1 event would become 3 events in JMS). Then, another thread in EventService (which is replicated, running on multiple hots) would be pulling from the queue, attempting to make the service call to the "listener", and returning the message to the queue (if the service is down), or discarding the message (if the listener completed successfully).

tl;dr

If I have an EventService that is responsible for receiving events and delegating service calls to "event listeners," (which are really just endpoints on other services), how should it know how to craft the service call? Should I create a generic "Event" object that is shared among all services? Then, the EventService can just construct this object and pass it to the service call. Or is there a better answer to this problem entirely?

Answer 1

If the service must receive the message, even though it is unaware of its existence, then the publish/subscribe pattern is not the answer. Publishers are not supposed to know about their subscribers. The subscriber is supposed to care, not the publisher.

If the "publisher" is responsible for maintaining messages, then what you want is polling.

Answer 2

First of all, this Event Service introduces some kind of orchestration. This service is tightly coupled with all the services it interacts with, resulting in a chatty communication, very likely implemented with synchronous request-reply, which is probably the biggest evil of all.

Think of this service when it will orchestrate 100 services. It sounds pretty scary.

Besides that, the logic is inevitably spread over two services: the central governing service and invoked service because of a problem I’ve just mentioned -- synchronous communication nature between them.

After all, this looks like a smart pipes approach. Definitely not good.

Here is a good and more detailed overview of this approach.

Or is there a better answer to this problem entirely?

I think there is. Let all your services listen to events they are interested in.