You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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 (I'm not sure if JInterface will 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

Name mapping: local composite operation name will be used to call remote Erlang procedure.

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

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).
<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).
  • when referenced process raises exit signal (no idea for this now).
<binding.erlang nodePointer="...">
    <link process="x" operation="propagateSignal"> <!-- operation which will cause throwing exit signal -->
</binding.erlang>
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

  • No labels