[zeromq-dev] Martin Fowler MicroServices

[techbird]

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

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