Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
How it works
RestBus follows the conventional RPC messaging style as shown below:
A publisher (client) can be any kind of application but a subscriber (service) is a service running on a supported web framework.
Each service has a work queue, which is created once the publisher or subscriber is started. A client places a message in HTTP format on the work queue and any instance of the subscriber can receive the message and process it.
Once the message has been processed, the subscriber places the response on an exclusive queue the client listens to for replies.
The subscriber adds an X-RestBus-Subscriber-Id header containing the name of an exclusive queue the subscriber listens to. If the client wishes to talk directly to the subscriber that processed the message, it can place a message on that queue.
As shown in the diagram, publisher (Client) C is able to send messages directly to subscriber (Service) instance 3.
The client can place another message on the work queue to be processed by any instance of the service.
A publisher can indicate that a message is a one-way message and will not listen for replies to that message. The subscriber that received that message will process it but not send a response.
Messages are distributed to subscribers from the work queue in a round-robin manner, therefore it's easy to horizontally scale your services, by simply launching a new instance.