

RestMS - setori88
http://www.restms.org/article:introduction-to-restms

======
tumult
Shining example of another person who has failed to understand IRC
(asynchronous messaging with spanning-tree delivery.)

I like all of the wordings he has made up for things that have been around for
15+ years.

 _Making a good messaging system seems to be an unusually difficult problem.
People have tried, over many years, and the results - as we just saw - seem to
be all round mediocre. In my view the main reason we have not "solved" this
domain (as we've solved operating systems, databases, file systems, word
processors, spreadsheets, email, data representation, etc.) are that the
problem has been too arcane to interest enough engineers._

I believe every statement in that paragraph to be incorrect.

~~~
drewr
I often think of SMTP as well -- robust message queueing and routing with
built-in failover, backoff algorithms, and myriad tools to view all the parts
involved. An RFC822 message's envelope can contain infinite metadata and its
body can contain text, json, xml, base64-encoded binary, you name it. You can
encrypt messages with PGP, or secure the transport layer if you can determine
who talks to you. There are more implementations that one can count, it works
on every platform, and it doesn't scare away the systems guys.

~~~
sad
I've also thought of SMTP as the ultimate queuing system. It really covers all
of the bases for persistence, async delivery, bridges to every kind of network
imaginable (think back to FidoNET, UUCP -- revive the bang path!), built in
fault tolerance, etc.

The only thing really missing is delivery order guarantee. It isn't uncommon
at all for a message to fail delivery, get stuffed into a retry bucket, and
then a bunch of other messages get delivered without problem before the retry
occurs. But even this is just an implementation issue. The underlying
architecture is nearly perfect.

------
jwilliams
I don't see the reason for the "housecat", "parrot" and "wolfpack" patterns.
These patterns have been around a long time in the EAI space, not sure in the
logic in giving them a new name.

<http://www.eaipatterns.com/> \-
<http://www.eaipatterns.com/PointToPointChannel.html> \-
<http://www.eaipatterns.com/PublishSubscribeChannel.html> \-
<http://www.eaipatterns.com/CompetingConsumers.html>

It also claims the "parrot" (publish-subscribe) pattern is the most widely
used. In certain situations it is very common (Market Data, News, Master Data
etc) - but these are fairly specific.

------
setori88
Don't you think, maybe, thinking of a pack of wolves tearing away at a dead
carcass, or a kitty coming to your outstretched hand, a flock of colourful
macaw parrots flying in the Amazonian basin is more friendly than a dryly
spoken PointToPointChannel, PublishSubscribeChannel and CompetingConsumers in
camel case? It is understandable that application programmers demand
simplicity. As they need to implement these patterns, why not change the name?

~~~
joshsharp
More colourful, yes, but I couldn't see the reason behind the names
immediately. "Dry" terms that actually happen to _describe_ their behaviour
are immediately grasped and understood.

I understand that perhaps colourful and friendly names can be fun, but I
suspect you'd have a hard time getting these accepted among the people that
actually use the protocol.

~~~
setori88
<http://github.com/pieterh/restms/tree/master>

~~~
jwilliams
Which goes into "Reverse Housecat", "Multimaster Housecat", "Wolf Call"... I
can't say they are obvious at first glance.

Metaphor is great for explaining things - and as a guide. Those names might
make a great sidebar. I just don't see the need to rename things when it's a
firmly established domain.

------
mrshoe
I don't understand how an in-depth article like this can not include a mention
of RabbitMQ. Did I miss it somehow?

------
shrikant
Would someone with more knowledge than me on this shed light on whether this
is essentially what the Google chaps have done for their Wave protocols?

~~~
setori88
<http://www.slideshare.net/pieterh/restms-introduction>

