I am trying to design an event based messaging system which works as follows:
Let us say that there are multiple products in a store, and their prices vary every day. Clients can login to the application, and request to know (via SMS) the price of a particular product on a particular date (say 1 month from the date of login).
How to introduce the concept of events (as described above) when using zeromq? Is OpenDDS better suited for such a scenario?
On
It seems the solution would need to combine three or four different technologies.
(1) Some storage technology, like a data-base, to keep long-term information and support custom queries. Basically to hold "data at rest". A classic RDBMS may be a good fit.
(2) A messaging technology to update the state, get notification of state changes, signal and coordinate integrate between different applications and processes. Messaging middleware technologies such as DDS/RTPS, ZeroMQ, JMS/AMQP would seem the best for this.
(3) Web client and server technologies. Something like Java Script for the client-side and Node.js or some other HTTP/REST back end.
(4) A protocol mediation and integration technology. Something that allows different protocols and technologies to be integrated. E.g. detect a change to a database remotely by getting a message, Integrate between the HTTP/REST service, the messaging technologies and the database, integrate between SMS and the back-end etc. The kinds of things Apache Camel and Enterprise Service busses provide.
I and most familiar with building systems that are centered around DDS as a messaging platform. If you chose DDS, then the different DDS vendors provide a lot of these building blocks already. For example searching on the web I found integrations with Apache Camel Integration and Node.js. Hans already mentioned Vortex from PrismTech. RTI has ready made integrations with relational databases (https://www.rti.com/products/dds/database-integration.html) so any changes made on a data-base are reflected on the message bus and vice-versa, as well as integration with Web/HTTP/REST (http://www.slideshare.net/GerardoPardo/london-connext-dds-conference-web-enabled-dds), and several other of the already mentioned Web Technologies.
Another approach you could take is to develop your approach centered around some an ESB and use the adaptors it provides to the different technologies. This is probably one of the simplest approaches but it has the disadvantage that everything will be brokered by the ESB, this may or many not matter to your application. You may want to look at this article I wrote where I describe some of these tradeoffs: http://soa.sys-con.com/node/467488
Gerardo
Reading your use-case its maybe less about 'events' than about having distributed access to the 'state' (in this case the potentially historical price) of a modeled object (in this case your products).
DDS as an open-standard technology directly supports this by offering distributed access to shared data using a smart combination of pub/sub messaging in combination with relational data-modeling. It also standardizes and supports a vast set of Quality of Service (QoS) policies that can be related to both producers/consumers of data as well as the data 'itself'. In your use-case its the 'durability' QoS on the data that would allow the DDS infrastructure to maintain historical data for each uniquely identified 'instance' of a data-object (called a topic in DDS terminology).
What is important in a DDS approach is to determine a proper 'data-model' for a specific usecase and in your case it looks like it can be pretty straightforward i.e. a product having a unique product-code (an ID that will be a 'key-attribute' in DDS, like in a RDBMS), likely a description and then a price. Each time the price changes a new 'instance' of that data-type will be published and as its QoS policy would be defined as PERSISTENT, it would then be maintained by the middleware (typically by one or more 'durability-services' that are part of the DDS implementation)
Applications in DDS take a subscription to these topics and will be provided automatically with the historical data of the product topics. Some DDS implementations allow to specify a refinement for the delivery of historical data based on a combination of content, time and/or volume (amount). In your use-case it would be a selection of the 'right product' (by ID or name) and time.
Finally, assuming your system is 'web-enabled' i.e. should work on an internet-scale, perhaps supporting cloud-based permanent storage of your data for distributed access on PC's, mobile-devices etc. then I'd suggest to take a look at Vortex (www.prismtech.com/vortex). Note that there's also an opensource version of the Vortex OpenSplice product available (www.prismtech.com/dds-community).
Good luck !