[erlang-questions] About the pattern of services implemented by Erlang

[Garrett Smith]

Hi 钱晓明,

On Fri, Mar 12, 2010 at 10:48 PM, 钱晓明 <kyleqian@REDACTED> wrote:
> Hi, I want to implement a service by Erlang communicating with other
> language, such as c/c++, java, c#. Is there any common pattern I can use ?
> This erlang service receives requests and parameters from other softwares
> implemented by other language. I though TCP socket(gen_tcp) may be works.

I have used ports with success:

http://www.erlang.org/doc/tutorial/c_port.html

The rest of the docs may be of interest to you as they cover other options:

http://www.erlang.org/doc/tutorial/users_guide.html

With either ports or a socket interface, you'll need to keep an eye on
managing the external process (startup/shutdown), obviously. But the
advantage is that your external program isn't going to crash Erlang.

Ports present challenges for implementing concurrent requests/responses.

> And I also want this service is high available, so if it crashed, a new
> service process will be started in same server computer( or another computer
> if that one is shutdown). For this, should I must use another computer to
> monitor the service process? Can supervisor module fit me? If the service is
> implemented using TCP socket, and if it is restarted in another computer,
> the client must to find the new node to submit request. This is also a
> question. So, Is there any common pattern I can use?
>

Using ports, I "wrap" an external program and put that under
supervision in Erlang. That's nice because the external process can be
treated like any other supervised worker.

For standalone apps, runit is helpful:

http://smarden.org/runit/

And, if you're system architecture is as complex as it sounds it might
be, consider using a message broker (e.g. rabbitmq), which will give
you several things:

- message passing abstraction over all your programs
- wire protocol for sending and receiving messages
- decoupling of "clients" and "servers", which makes the system less
brittle (among other advantages)

Garrett