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
