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 <[email protected]> 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 <[email protected]>: > >> 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 > > > > _______________________________________________ > 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
