Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
3  
I think you have some good questions here, but maybe you could break them up into a few questions on this site? Or ask one particular one at a time and see where that leads you? This kind of sounds like you're asking for someone to give you an architecture rather than asking a question.. or if there's a question in there, I can't find it? –  Jimmy Hoffa Jun 24 '13 at 15:31
1  
@JimmyHoffa Sorry, I have updated the question to include what I'm really trying to ask at the end. But I am leaving the option on the table for someone to suggest that I'm going about this the wrong way entirely. –  Colin Morelli Jun 24 '13 at 15:34
    
Don't worry about leaving options open, if an engineer thinks you're doing something wrong they don't usually keep their mouths shut, do they? :) –  Jimmy Hoffa Jun 24 '13 at 15:37
    
@JimmyHoffa Fair point. We tend to be part of the "brutally honest" crowd. Something along the lines of: "your entire design sucks. Do it again." –  Colin Morelli Jun 24 '13 at 15:38
    
You might think about this generic service just passing around the serialized forms of whatever messages it gets. Then it doesn't care about the type, it's up to publishers and subscribers to be sure they have a common language. Your delegator just passes what it's given. You may not need to even worry about serializer stuff, working in ActiveMQ with NMS there's built in message objects from the NMS framework, I presume JMS similarly has a general message object you can receive and forward. –  Jimmy Hoffa Jun 24 '13 at 15:38
show 6 more comments

1 Answer

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.