Erlang Transport

A transport that can send and receive messages to and from Erlang nodes.

Pre-requisite

Erlang R13B01 or better must be installed on the host where you want to use this transport.

Classpath Settings

The latest Mule Erlang Transport has been tested with Mule 3.0.0-SNAPSHOT.

Mule Standalone

To set up the Mule classpath to use the Erlang Transport, you must first download the Mule Erlang distribution. Then simply take all the JARs inside the distribution lib/ directory and put them in MULE_HOME/lib/user.

Maven

If you are using Maven, you can use the MuleForge repositories and add a dependency to Jersey that way. First add the MuleForge repository to your POM:

<repositories>
    <repository>
      <id>muleforge</id>
      <name>MuleForge Repository</name>
      <url>http://repository.muleforge.org</url>
    </repository>
</repositories>

Then add the dependency:

<dependencies>
  <dependency>
    <groupId>org.mule.transports</groupId>
    <artifactId>mule-transport-erlang</artifactId>
    <version>3.0.0-SNAPSHOT</version>
  </dependency>
</dependencies>

Before using the Erlang transport

epmd must be running before starting the Erlang connector. For this use the startup command that is appropriate to your environment (for example, Linux).

Testing the transport

Simply run:

mvn -Pit clean verify

Erlang Escripts must be executable on your platorm for the integration tests to run.

Using the Erlang transport

Connector configuration

Basic configuration

<erlang:connector name="ErlangConnector" nodeName="MuleIT" cookie="mule_test_cookie" />

With this configuration, Mule will be accessible from remote Erlang nodes as if it was an Erlang node started this way:

erl -sname MuleIT -setcookie mule_test_cookie

You can host several of such connectors in a single Mule instance.

Inbound endpoint configuration

Mule takes care of the threading aspect of the services you expose as Erlang processes: each incoming request gets routed in its own thread to enable maximum throughput while using a single process inbox as the main entry point.

For In-Out services

<service name="ErlangInOutService">
  <inbound>
    <erlang:inbound-endpoint processName="capitalizer"
                             exchange-pattern="request-response" />
  </inbound>
  <component>
    <method-entry-point-resolver>
        <include-entry-point method="capitalizeFully"/>
    </method-entry-point-resolver>
    <singleton-object class="org.apache.commons.lang.WordUtils" />
  </component>    
</service>

The above service can be invoked as if it is a pure OTP gen_server:

1> gen_server:call({capitalizer, 'MuleIT@'}, "hello World").
"Hello World"

The Erlang transport also understands PID wrapped calls:

1> {capitalizer, 'MuleIT@'}!{self(), "hello World"}.
...
2> receive(M) -> M end.
"Hello World"

For In-Only services

<service name="ErlangInOnlyService">
  <inbound>
    <erlang:inbound-endpoint processName="jms_bridge"
                             exchange-pattern="one-way" />
  </inbound>
  <outbound>
    <pass-through-router>
      <jms:outbound-endpoint queue="erlang.it.queue" />
    </pass-through-router>
  </outbound>
</service>

The above service can be invoked as if it is a pure OTP gen_server:

1> gen_server:cast({jms_bridge, 'MuleIT@ddossot-laptop'}, "Lorem ipsum").
ok

The Erlang transport also understands raw calls:

1> {jms_bridge, 'MuleIT@ddossot-laptop'}!"Lorem ipsum".

In both cases, a JMS TextMessage has been generated from the Erlang call!

Outbound endpoint configuration

For gen_server calls

<erlang:outbound-endpoint node="nodeName@hostName"
                                processName="... gen_server name ..."
                                invocationType="GEN_CALL"
                                failIfTimeout="true"
                                exchange-pattern="request-response" />

For gen_server casts

<erlang:outbound-endpoint node="nodeName@hostName"
                                processName="... gen_server name ..."
                                invocationType="GEN_CAST" />

For PID wrapped calls

In this kind of calls, the payload is wrapped in a tuple with the PID of the calling process as the first element. This allows the remote process to send a response back.

<erlang:outbound-endpoint node="nodeName@hostName"
                          processName="...registered process name ..."
                          invocationType="PID_WRAPPED"
                          exchange-pattern="request-response" />

For raw calls

In this kind of calls, the payload is sent as is to the remote process.

<erlang:outbound-endpoint node="nodeName@hostName"
                          processName="...registered process name ..."
                          invocationType="RAW" />

For RPC calls

Allows the invocation of a module:function on a target node, using the current message as the arguments.

<erlang:outbound-endpoint node="nodeName@hostName"
                          moduleFunction="module:function"
                          invocationType="RPC"
                          exchange-pattern="request-response" />

Type mappings

Document Erlang <- Jinterface -> Java type mappings