Page History

...

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 (I'm not sure if JInterface will JInterface won't allow this)
• creating message boxes
• receiving messages
• linking to remote Erlang processes

...

• 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

...

<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 pid, 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.

...

• 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 -->
    <exception class="SomeException1"/> <!-- exception class names which will cause throwing 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

...