You might want to check out Mongrel2 - a modular web server that routes requests to handlers connected via ZeroMQ. The documentation is long and winding but it should help you achieve your goals. http://mongrel2.org/
On Thu, Apr 24, 2014 at 1:47 AM, techbird <[email protected]> wrote: > Hi Peter - > > Yes... I've been reading your guide in depth (it's excellent), running > examples and thinking things through. > > I guess what I am trying to do is map the diagram on slide 31..38 - into an > architecture implemented with 0MQ - using REST as a request protocol > (on/off ramp) to enable Internet scale, event driven services. Therefore > piping events through filters/workers. > > http://www.slideshare.net/jamesalewis/java-microservices > > "The second approach in common use is messaging over a lightweight message > bus. The infrastructure chosen is typically dumb (dumb as in acts as a > message router only) - simple implementations such as RabbitMQ or ZeroMQ > don't do much more than provide a reliable asynchronous fabric - the smarts > still live in the end points that are producing and consuming messages; in > the services." > > If anyone has any working hints, or diagrams - they are appreciated. I'd be > truly interested in peoples interpretation from a 0MQ perspective. > > Thank you kindly , Gareth. > > > On 23/04/14 21:39, Pieter Hintjens wrote: > > Hi Gareth, > > I think you simply need to read the Guide and work through the > examples... much of what you are asking will become clear then. > > -Pieter > > On Wed, Apr 23, 2014 at 10:25 PM, techbird <[email protected]> wrote: > > On 23/04/14 09:52, Pieter Hintjens wrote: > > On Wed, Apr 23, 2014 at 9:33 AM, techbird <[email protected]> wrote: > > The main article focuses on using http - atom/json with a pull model, for > Internet scale collaboration . > > It's a simple and widely-used approach, yet very poor. It basically > enforces the thin-client fat-server model, where clients hang off > specific servers. I don't think it's acceptable in 2014 to propose > HTTP-style pull as a basis. Indeed, large-scale service providers are > working very hard to escape that (websockets, HTTP2, SPDY, etc.) > > A different, still simple model, is to treat every tasks as an > event-driven actor that can receive messages from any source, be it > another thread in the same process, or a box on the other side of the > world. In this model, tasks do not poll or pull; they receive messages > asynchronously from any number of sources. > > On top of that you can build pub-sub, push-pull, request-reply etc. as > multi-message protocols. You can even recreate RESTful semantics quite > simply. > > -Pieter > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > Can I pause for a second to say thank you for your knowledge Pieter. > > So if I understand correctly - micro-services receive asynchronous messages > (i.e. http 202) - the message can be processed using various patterns using > push-pull, sub pub across what ever processes/workers are required. > Therefore holistically messages are pushed (POST'd) through a http pipe, > which is serviced asynchronously by 0MQ channels/patterns. Is that right? > or have I mis-understood? > > I do have a secondary question. With Martin's PULL model - subscription > services (pub sub) have low temporal coupling. Therefore they are able to > play 'message catchup' with a provider if running slow or they are off line > for a bit (say due to a network problem). This capability comes from the > service's ability to ask for events since a certain point in time (request > parameter). I guess this is a little like event sourcing. How would that > subscription pattern translate in 0MQ? > > Gareth. > > > > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
