General

Extension would be realized as Tuscany binding extension (both service and reference). JInterface ("The Jinterface Application is a java communication tool package to erlang") wuold be used.

Service binding

Responsible for publishing SCA components as Erlang processes/nodes. Instance of service binding would be equivalent to one Erlang node. It would support:

• exposing components procedures as Erlang procedures (JInterface won't allow this)
• creating message boxes
• receiving messages
• linking to remote Erlang processes

Reference binding

Responsible for accessing existing Erlang processes/nodes. It would support:

• invoking remote procedures
• sending messages
• linking to remote Erlang processes

Remote procedure calls (reference binding only)

Name mapping: local composite operation name will be used to call remote Erlang procedure. Java types would be used and translated transparently to/from OtpErlang* types.

Messages and message boxes

a. Service binding

Message boxes would be configured in binding configuration, as follows:

<binding.erlang nodePointer="...">
    <mbox name="mbox1" operation="handleMessageOnMbox1"/>
    <mbox name="mbox2" operation="handleMessageOnMbox2"/>
</binding.erlang>

Java interface for this binding would be:

public interface SCAErlangProcess {

    void handleMessageOnMbox1(String pid, String message); // first mbox mapped in binding configuration. Methods arguments are example and shows that we expect message in such format.

    void handleMessageOnMbox2(String pid, String mPart1, String mPart2); // second mbox mapped in binding configuration

}

Incoming messages will trigger calling operation which is assigned to certain mbox.

b. Reference binding

Message boxes would be configured in binding configuration, as follows:

<binding.erlang nodePointer="...">
    <mbox name="mbox1" operation="sendToMbox1"/>
    <mbox name="mbox2" operation="sendToMbox2">
</binding.erlang>

Java interface for this binding would be:

public interface RemoteErlangProcess {

    void sendToMbox1(String pid, String message); // first mbox mapped in binding configuration. Methods arguments are example and shows that we allow to send such message.
    void sendToMbox1(String mPart1, String mPart2); // second mbox mapped in binding configuration

}

User call on mapped operation will cause to send message to mbox which is pointed in configuration.

In Erlang processes are being created dynamically and without registering mbox name user cannot guess its PID. In Erlang communication processes often sends their PIDs as first part of message (as an return address), so similar mechanism should be provided. In example it could be additional parameter in binding configuration which would cause sending messages preceeded with its mbox PID.

Linking

Link - it's a bi-directional propagation path for exit signals - see http://www.erlang.org/course/error_handling.html.

It's optional feature.

Linking in service bindings should conform two cases:

• when remote process raises exit signal Erlang service binding intercepts it and passes to handler. User implements behavior for such signal. Handler operation could be configured such as mbox (see example).
• when local exception occurs Erlang reference binding should propagate it as exit signal. User should have possibility to specify which exceptions will trigger such signal - it could be placed in binding configuration as list of class names (see example). (It seems that JInterface won't allow to raise exit signal. Maybe after closing OptNode manually or terminating JVM host?)

<binding.erlang nodePointer="...">
    <link process="x" operation="handleSignal"> <!-- operation for handling exit signal -->
</binding.erlang>

Linking in reference bindings should conform two cases:

• when user wants to propagate exit signal to referenced Erlang process - it could be like mbox configuration in reference binding (see example). (It seems that JInterface won't allow to raise exit signal. Maybe after closing OptNode manually or terminating JVM host?)
• when referenced process raises exit signal (no idea for this now).

Problem with static approach to linking

Proposed linking approach does not provide any way to configure links in runtime. Imagine that after receiving exit signal linked process ended, link was canceled and we would like to establish another link.

External Erlang and JInterface resources

• Erlang course: http://www.erlang.org/course/course.html
• Official JInterface documentation: http://web.mit.edu/erlang_vR11B-5/arch/sun4x_510/lib/erlang/lib/jinterface-1.3/doc/html/part_frame.html
• Article about integrating Java and Erlang using JInterface: http://www.theserverside.com/tt/articles/article.tss?l=IntegratingJavaandErlang
• More about Java and Erlang integration (samples): http://people.apache.org/~dennisbyrne/erlang_exchange/erlang_exchange_jinterface.ppt