6

I'm asking your sugegstions about an "architectural" scenario:

I'd looking for a simplest publish/subscribe architecture to let talk two decoupled servers over on internet, sharing "sparse" but "real-time" messages/events.

Let me explain:

  • The PUBLISHER: Is a server (http://www.server.com) that generate some sort of events (by example events==ORDERS data on a e-commerce website).

  • SUBSCRIBERS (one or more): Are "clients" that can subscribe to receive ORDERS events (http://www.client.com).

In real life case, the publisher is a server developed (in Rails) by a third party. At the moment I can interface it getting "orders" with a plain "polling" strategy: every N seconds I call a GET /new_orders.

BAD!

So I'm thinking about a bit better pub/sub architecture with a REST approach where Publisher share the EVENTS recources:

  • The client Subscribe to receive events, supplying to the Publisher a "URL HOOK" to be call in future (by example: http://www.client.com/orders).

  • The Publisher, when there is a new event (== order) simply HTTP POST data to client URL Hook previously supplyied by Client.

Make sense ? Or I'm reinventing the wheel ?

BTW, I develop in Ruby language and, I'm aware of pub/sub messaging systems as Faye. but what do you think about this simple protocol (I'd like implment client-side simply with Ruby/Sinatra) ? (see image 1)

Any suggestion welcome. Thanks a lot

Giorgio

simple architecture proposed

Giorgio Robino
  • 2,148
  • 6
  • 38
  • 59

1 Answers1

3

Any time you can get a third-party to POST to your web services, it's a good thing! A lot of the time, this isn't an option and you must resort to some kind of inefficient polling architecture. I don't think there's anything wrong with your architecture diagram.

You can always use third-party messaging systems (Amazon SQS, RabbitMQ, etc.) but there's not much reason to do that unless you need durable messaging.

EDIT:

If you're concerned about HTTP traffic--specifically, the number of calls being made to your web service--you could also encourage the third-party to support batch POSTing. Perhaps they can only send subscribers new orders every 5 minutes as part of a batch.

NathanAldenSr
  • 7,841
  • 4
  • 40
  • 51
  • Have the publisher send your web service all the orders that have been collected since the last publish operation. Although, looking at your diagram in detail, it seems it's already designed that way (at least, there is an array of orders). If you want the orders as soon as they are created then the batch architecture would not be appropriate. – NathanAldenSr Feb 26 '14 at 17:34
  • thanks Nathan! hat do you mean with "batch POSTing" ? do you mean a batch events "collector" by the Publisher to feed data to subscriber(s) every 5 minutes by example? The batch sound bad, because, subscriber side, I wish to receive Events (orders) as soon as possible. Viceversa maybe naively, I thought about a "simple" syncronous POST by Publisher to Subscriber as soon the Event arise In my case number of Events are "limited" (e-comemrce orders) but the real-time processing is prioritary so pheraps there is not an HTTP traffic concern. Or I misanderstood your edit? – Giorgio Robino Feb 26 '14 at 17:36
  • No, you're right. In your case, there seems to be no need to batch orders. POSTing them in real-time is fine. – NathanAldenSr Feb 26 '14 at 17:46