[zeromq-dev] Martin Fowler MicroServices

Pieter Hintjens ph at imatix.com
Thu Jul 10 13:51:00 CEST 2014


This sounds neat, and it's very close to the CZMQ zactor class. The
main difference there is that zactors look like threads+sockets, i.e.
one thread starts 1..N zactors, and can then send/recv to zactors as
if to sockets. So all socket creation and connect/bind from parent to
zactor is done automatically.

On Thu, Jul 10, 2014 at 11:37 AM, artemv zmq <artemv.zmq at gmail.com> wrote:
> hi there
>
> I dare to join this thread.
>
> Inspired by Pieter' mentioning of "actors", I had created, an actor
> framework on jzmq. If anyone cares, here's link:
> https://github.com/artem-v/jzmq-sdk/blob/master/src/main/java/org/zeromq/messaging/service/Worker.java.
> Yes, it's single class.
>
> Worker framework allows you to stick actors according to master<-slave
> principle, where slave connect on master (not vice versa) and traffic can go
> in both directions (from master to slave and backward).
> You can connect many slaves to many masters, and if you can have master
> connected to another master, i.e. master can be a slave towards to another
> master.
> So basically you can create a graph of actors (workers) and it's up to you
> what logic you plug inside those actors. The only requirement -- logic
> should be written keeping in mind that it's running in
> single thread; that's why you can't create threads and you can't block
> actor.
>
> Enjoy the code and send a feedback.
>
>
> BR
> artemv
>
>
>
> 2014-04-25 1:19 GMT+03:00 Sean Robertson <sprobertson at gmail.com>:
>
>> 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 <techbird at birdsoft.co.uk> 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 <techbird at birdsoft.co.uk>
>> > wrote:
>> >
>> > On 23/04/14 09:52, Pieter Hintjens wrote:
>> >
>> > On Wed, Apr 23, 2014 at 9:33 AM, techbird <techbird at birdsoft.co.uk>
>> > 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
>> > zeromq-dev at lists.zeromq.org
>> > 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
>> > zeromq-dev at lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev at lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev at lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list