[zeromq-dev] Martin Fowler MicroServices

[techbird]

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.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140423/f4a1f1eb/attachment.htm>