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
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.