Remote Method Invocation
In addition to data replication, XSTM lets you invoke remote methods to execute code on other machines. This is similar to what you are used to when calling a web service or using communication stacks like .NET Remoting or GWT RPC. Methods are exposed by a machine. Arguments are serialized from the caller to the target, the code is executed, and the return value is sent back to the caller.
Calling methods using XSTM has advantages and disadvantages. First it is well integrated with data replication, so when the arguments you send or the value you get back are replicated objects, they are not sent again. Only a small id is sent, which is much faster. Also, a method invocation is part of a transaction, like data replication. This means that the code on the remote machine is running in the same transaction as the code that calls the method. The transaction is serialized and sent on the remote machine at the same time as the method arguments. This allows a transaction to run code on several machines without committing. Methods can modify replicated objects on several machines, and those modifications will still be private to a given distributed transaction. This enables sophisticated applications to be written in a clean and simple way.
The model proposed by XSTM is very simple. When a machine wants to expose a service to other machines, it creates an instance of an object which has been generated with some methods. It adds the object to a share to make it visible to others. Remote sites can call methods on this object, and the method itself will be executed on the initial machine, i.e. the site where the object was initially created. This means that when the method is called from another site, the arguments of the method call are serialized and sent to the origin site. The method is executed there and its return value is sent back to the calling site. This allows each machine to expose services to others with a model similar to the one used for data replication.
In Practice
First, you have to generate methods on replicated objects in the same way you generate fields. Here is an example of an XML file generating a replicated object with a simple method:
The generated MyClass class contains the following code:
The first method is the asynchronous form you will have to use when calling the method. XSTM makes it mandatory to call the method asynchronously for now but it might change in the future. The second method is the default implementation of the method, which simply throw an exception saying that you must implement it.
You then need to write a new class that extends the generated one to override the method. Here is an example implementation:
To expose this class to some remote sites, create an instance of your derived class and add it to a share. As XSTM can only replicate transacted classes, the other sites involved in the share will see a new instance of the generated class (i.e. a MyClass instance, instead of a MyClassImpl in the example). On this instance, they can call the generated asynchronous version of the method, giving a callback to retrieve the result:
The callback has an onTransactionAborted method because method calls are part of transactions. If the current transaction is aborted before getting the return value from the remote machine, onTransactionAborted will be called instead of onResult. If you do not start a transaction before you call a method on an object, a new transaction will be started for the call.
As we saw earlier the code of the method runs on the origin site of the object, and in the context of the same transaction as the caller. This means that Transaction.getCurrent() can be used in the implementation of the method, e.g. to get the calling site using getOrigin() on the transaction. It also means the modifications you do on transacted objects during execution of the method can be cancelled if the transaction is aborted.
If your method does actions that cannot be cancelled, like modifications to non transacted objects, IO or user interface operations, you must make sure the transaction is not aborted. Otherwise, you could have inconsistencies between updates done to transacted objects that would be cancelled, and the other effects of your transaction that could not be aborted. An abort occurs only if there is a conflict between two updates done to the same transacted object. That is why if you modify transacted objects concurrently, it is a good design to try to separate in different transactions the operations on them from operations which cannot be cancelled.
There are some limitations in the current version of XSTM about method invocation. Methods can only be called from a client on a server, and the method is only executed when the client commits his transaction. This makes it still possible to use methods but it reduces a little the flexibility.
Comments (0)
You don't have permission to comment on this page.