[zeromq-dev] [otish] "Why ZeroMQ"

Martin Sustrik sustrik at 250bpm.com
Tue Jul 27 10:53:41 CEST 2010


>  >By now it is clear that using 0MQ requires a mental paradigm shift (the
>  >"a-ha" moment) and -- unfortunately -- we are doing were little to
>  >alleviate it for the users. That's the reason IMO why "0MQ is
>  >interesting but lacks documentation" complaint is often heard -- even
>  >though there's detailed reference (man pages) available.
>  Its more than a basic queue once you do cross machine pipes , pub/sub  and
> filters your building an Eventing (EDA) system and these  are strictly in
> geek land . It requires some time and effort  ( consider what happens when
> you chain subscriptions on different machines you start creating a network
> graph etc) , the more you learn the more complex it gets ( but also how much
> more capable the system becomes)  . 
> I once tried to introduce an eventing system in a large company and it was
> so far beyond them it's not funny , they were still struggling with basic
> push /pull , SOA and how to migrate of cobol yet alone how SOA services can
> be event driven via a subscription .  I ended up implementing it  under the
> cover of SOA and it worked very well , note however I put a WS-EVenting
> wrapper on top which allows Visual Studio users to simply generate a proxy
> to the machine create an easy subscription and start receiving data ( they
> were a .NET shop on the client) , all devs understand pub /sub and they
> started creating company wide data events for the organization to hook into
> instead of resorting to DBs foreverything..

There are two problems here IMO. First one is changing how systems are 
implemented at the corporate scale. The momentum is so big here that we 
can be grateful for DBs being used at all by now instead of raw files :) 
There's no way to solve that. Just wait 30-40 years and the new 
technologies will get gradually adopted.

The second problem is an experienced user who used messaging solutions 
before, knows the problem space etc. In this case the problem is that 
0MQ fundamentally differs from other systems and initially (AFAIU) seems 
to be insufficient to perform the task required: "I cannot mix state 
notifications and control infrastructure within a single socket? What 
kind of lame messaging system is that?" Another manifestation of the 
problem is people trying to use PAIR sockets for everything, basically 
degrading 0MQ to a dumb TCP socket wrapper.

It requires few a-ha moments to grasp the concepts. My original comment 
was about how to make this as painless as possible.


More information about the zeromq-dev mailing list