There is a need to develop a middleware module: the collector/distributor message, aka "message router", "message broker", "message orientated middleware". For big names in the current implementation — simple essence: clients send messages (asynchronously), the message comes to the broker and (while I call the required collector/distributor), he somehow handles and holds up to the moment it asks for the message recipient (the one to whom it was intended).
The recipient requests the message, the message transmitted to the recipient – all, the job broker and over.
The first idea is to implement a broker to use for storing memory were rejected, because the recipient is irresponsible, not taking data, make the broker eat all the memory.
The second is to use a database to store messages when "intensive" the receiver will always generate DB queries.
The final (current) option – memory use for a queue of references to messages stored in non-SQL database (of the advantages – requires no configuration database of the drawbacks – not enough quick start (read queue are stored at the time of the stop), and sensitivity to a regular stop (can not be recorded the current queue)).
Interested in the question, who created a similar solution?
The requirements are simple:
- small memory consumption
- quick start
- the ability to handle messages of large size, with a small quantity of the messages themselves
- preferably no need to create a database
Since the requirements are rather contradictory – on display in the descending order of priority.
Also interested in the question of the impact of messages to a recipient who uses what steps (notification of the processing, the periodic survey, subscribe to a message type, etc....)
PS: Finished software products are inappropriate as they require additional resources, settings, and suggest that the architecture will be built around them, and for me it's just a means of creating asynchronous messaging — then perhaps it will be merged into 1. exe file.