I ask for your judgments about the "architectural" scenario:
I would look for the simplest publish / subscribe architecture to allow talking about two decoupled servers on the Internet, sharing “sparse” but “real-time messages / events”.
Let me explain:
PUBLISHER: It is a server ( http://www.server.com ) that generate some kind of events (for example, the event == ORDERS data on the e-commerce website).
SUBSCRIBERS (one or several): "Clients" can subscribe to receive ORDERS events ( http://www.client.com ).
In real life, a publisher is a server developed (in Rails) by a third party. At the moment, I can interact with receiving “orders” with a simple “polling” strategy: every N seconds I call GET / new_orders.
BADLY!
So, I'm thinking of a better pub / sub architecture with a REST approach in which Publisher shares the EVENT sources:
Customer Subscribe to receive events by supplying the publisher with a “URL HOOK” for future calls (for example: http://www.client.com/orders ).
Publisher, when there is a new event (== order), just the HTTP POST data to the client Hook URL previously provided by the client.
Make sense? Or am I reinventing the wheel?
By the way, I am developing in Ruby, and I know about messaging / sub-messaging systems like Faye. but what do you think of this simple protocol (I would like the implanted client interface to be just with Ruby / Sinatra)? (see image 1 )
Any suggestion is welcome. Many thanks
Giorgio

rest ruby web-services publish-subscribe messaging
Giorgio robino
source share