Q:

Why should i not build a webservice based on ZeroMQ?

We are currently in the process of developing a public data subscription webservice for registered client apps, currently this clients consume our api data via access tokens.
So for the data subscription endpoint we have been thinking of different approaches, our current approach is based on simple HTTP Posts every couple of a seconds to the clients subscribed for a particular change in a given object (Only when changes occur obviously). 
EX: User creates a new doc, all apps subscribed to that particular user subscription (UserUploadDoc), will be notified via POST. This is really simple to implement.
But then we started investigating messaging services, and well ZeroMQ seems quite capable. 
I can easily picture a simple message service working in similar fashion as a Hospital PA, where we just broadcast something, and someone listening for it gets it, 
Like Nurse Sally have a call at Nursery, and well Nurse Sally can come to the Nursery and only her will receive the full message.
Please confirm that I am totally wrong at this approach, and should probably stick with the painfuls HTTP Posts!

A:

A message queue is a great idea for this scenario as it adds guaranteed delivery as well as an audit trail in case of problems. For example, you have the potential to find out if a particular client has not been available to get messages at a particular time, or to rewind the message queue and replay it to test the clients. It does add an extra overhead as other posts point out, so it's really down to a cost-benefit analysis of whether this trade off is worth it in your particular case.
Generally, I'd say that if the failure for a message to get through for any reason would cause serious problems (in a hospital, I'd suspect it would), then you should have a message broker. Were you not using push via POST, it would presumably be up to the client to keep polling the server's REST interface until it got an update so this wouldn't matter as the user would see an 'unable to update' message and could take action. As long as you're happy that ZeroMQ is going to be easy/cheap enough to maintain, I'd say go for it.

A:

I don't think there's just right or wrong on adapting ZeroMQ in this scenario.
I think the factors you need to take into considerations are

What's the cost when clients(all apps) need to integrate ZeroMQ interface as subscribers instead of more standard HTTP methods.
MQ brokers offers temporal storage and management for messages to ensure messages can be successfully delivered between producers(sender) and consumers(receivers), such as persistent mode. So there will be more cost on space, time, management, but more reliability.
You can still integrate HTTP interfaces with ZeroMQ with additional layer of proxy to interact with between ZeroMQ consumers and actual client. For example, client send a subscription HTTP message to ZeroMQ consumer proxy, then ZeroMQ consumer proxy "subscript" to ZeroMQ producer, once 
ZeroMQ consumer proxy got broadcast-ing message, it will still send HTTP POST to actual client.
In the end, it has sort of message management such as publisher-subscriber model and also remain it's simple HTTP interface on broadcaster and clients. 

Just some thoughts.

A:

ZeroMQ is a great choice for building out services, but you mention that the system was somewhat public. That might be something worth considering - while there has been a lot of great work in making ZeroMQ stable to hostile connections, there is a still a lot of work that you might have the layer on top of it to make it as reliable as a typical webserver might be in the face of bad guys. You may also have to layer on encryption and authentication, which are both absolutely doable, but potentially a bit more work. 
If you service will be open to the outside world, you might want to consider using something like Websockets (or even HTTP/S as Jim suggests), with something like Mongrel2 providing the translation to ZeroMQ, and then building out your internal services with ZMQ. 
Of course if I've got the wrong end of the stick and the service itself wont be on-the-public-internet type public, then I would definitely go with ZeroMQ - it's very easy to use in almost all commonly used languages, and there are some simple patterns you can apply to add the appropriate levels of reliability (see the guide at http://zguide.zero.mq for details).

