<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 16, 2015 at 9:17 PM, Thomas Elsgaard <span dir="ltr"><<a href="mailto:thomas.elsgaard@gmail.com" target="_blank">thomas.elsgaard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I should maybe add that this is for low volume but complex service activation in the telco domain, the current approach has been the traditional SOA solution with an ESB and process orchestration (all Java based), but the number of services has increased, and the ESB (service bus + message queue) is suffering from memory leaks and other stability issues which is hard to troubleshoot, and in general, the solution is just complex.</blockquote></div><br>To me, this suggests a solution based on RabbitMQ+Protobufs, or RabbitMQ+Transit/Msgpack. This allows you to slowly lift services out of the clutches of Java and into Erlang one service at a time. Make a number of Erlang nodes able to handle any kind of service task by making each service a separate application, and you also have some added fault tolerance. Messaging is also asynchronous if you want it, so you can avoid some of the weaknesses of RPC.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Later on, you can probably just consider distribution of the Erlang nodes and then send messages directly, but don't underestimate RabbitMQ as a mediation layer.</div><div class="gmail_extra"><br></div><div class="gmail_extra">For low volume, the flexibility of RabbitMQ is really good.<br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>