Package mandala.rami.transparency.total

Total-transparent asynchronous method invocation mechanism implementation.

See:
Description

Class Summary

AsynchronousProxyInvocationHandler

This class implements the total transparent reflexive asynchronous method invocation mechanism.

Package mandala.rami.transparency.total Description

Total-transparent asynchronous method invocation mechanism implementation.

Total-transparent reflective asynchronous method invocation

The total transparent mechanism means you invoke a method in a standard manner, but in fact, the invocation is asynchronous.

Consider the generic example. In a total transparent reflective asynchronous method invocation, you just replace :

// Step 1
MyClass myObject = new MyClass();

by

// Step 1
MyClass myObject = (MyClass) mandala.rami
    .Framework.getTotalTransparentAsynchronousProxy(new MyClass());

and then, without any modification, step 2 and step 3 will execute concurrently or in parallel if you have more than one processor (well in fact the effective execution of the method myMethod on the real instance of MyClass will execute concurently with the execution of the method doingSomething).

This technique is the wait-by-necessity mechanism and is implemented in RAMI with one constraint : the object given in parameter of the Framework.getTotalTransparentAsynchronousProxy(Object) must be an instance of a class which implements at least one interface. The object returned by the framework is also an instance of a class which implements the same interfaces. To be clearer, in the example above, MyClass must be an interface.

Limitations

The total-transparent mechanism can be achieved using inheritance, but this implementation leads to many problems (mainly fields control and final methods and classes). This is why RAMI implements the mechanism in an interface-based manner which eliminates the mentionned problems but add a serious constaint.

Even if the total-transparent technique seems to be very powerfull and attractive, because of its ease of use, it must be noticed that it has two main problems :

• Exceptions which are raised during the asynchronous method call could not be catched in the usual way : the thread which has made the asynchronous invocation is probably not in the enclosing try/catch block.
• Usually, code written in a synchronous way is not efficient in a total-transparent asynchronous method invocation since it does not lead to concurrency (or parallemism). In fact, the code example above would have been written by any standard developer :

  // Step 1
  MyClass myObject = new MyClass();
  
  // Step 2
  MyInfos infos = myObject.myMethod(myParameters).getInfos();
  
  // Step 3
  doingSomething();
      

The alternative is to use the semi-transparent mechanism. which is the prefered way asynchronous method invocation must be dealt with.