[zeromq-dev] Martin Fowler MicroServices

[artemv zmq]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140710/9507612c/attachment.htm>