XSTM Makes Things Simpler
XSTM is a library which enables high performance object replication between processes. With it you can set a value to a field of an object in one process and see the value changing on an object in another process. This can be very useful in scenarios where the same data is present on several machines like client-server communication, application clustering, peer to peer etc…
In a client-server configuration, XSTM can replicate changes made to an object to and from selected clients. This simplifies a lot for example Ajax applications where clients interact with the server in complicated ways. Using XSTM, you can forget all the error-prone code to call the server or notify the clients of a data update. No more intermediary objects you send back and forth. No useless copying of fields from objects to objects. No call to the server sending a whole form when only one field has been changed. Model your application in the usual object oriented way, write the code that creates and modifies those objects on the server and the clients, and let XSTM handle the synchronization.
XSTM is symmetric, which means you can put the code which modifies your shared objects on the machine that's best suited. For example form validation code would be identical on a server or on the clients so you can choose the best solution for your application.
But Not Too Simple
Distributed programming frameworks have often the flaw to try to hide too much of the difficulties that occur in distributed configurations. Networks have characteristics that cannot be hidden like latency or disconnections. XSTM on the contrary exposes them to the developer through a nice programming model.
Objects are replicated using transactions, and each transaction represents a set of updates to some object fields. The state of a transaction indicates if it has succeeded or not. Callbacks are called when the transaction’s status changes to help the developer deal with latency. When a transaction is aborted, remote objects are not modified and local objects are automatically restored to their previous state.
Shares
Our model is based on object shares, which work like file shares. When an object is added to a share, it appears on the other machines which have the same share opened. Modifications done to the fields of the object are from this point replicated between machines.
Shares can be connected in client-server and cluster topologies. Objects are replicated only between machines where the same share is opened, which can be for example two clients of a server, but not the other ones.
In Practice
XSTM is written in Java and uses no "magic": it does not require compiler support, makes no JVM or bytecode modification. It can be added to your application as a simple jar file of about 200KB. This makes it possible to use XSTM for web development thanks to Google's GWT Java to JavaScript compiler. A .NET port is also available using IKVM. The three versions are compatible with each other so object replication can take place e.g. between a Java server and a .NET Smart Client.
XSTM uses code generation, so the first thing you have to do is to describe the objects you want to replicate. The easiest way to do this is to use an XML file like this one:
This generates a Java or C# class named Form with two getter/setters or properties of type String. You could write this class yourself but the generated one also contains code to replicate its fields. This class generation step is also useful in that it imposes constrains on the objects. You cannot generate any kind of objects, only the one that can be replicated. If you try to use unsupported classes, for example, the generation will fail. If it succeeds, the replication should always work.
In addition to the classes you generate, XSTM provides replicable implementations for common collections like Set, List, and Map (Dictionary in C#).
When your object model is ready, start a Transport class to connect to other machines. XSTM can communicate over socket, http, GWT RPC and JGroups. It is then possible to create an object share and publish it for other machines.
Internally
It is not necessary to understand XSTM internal workings to use it, but if you are interested it is implemented as an extended Software Transactional Memory. It could also be useful to manage concurrency in a single process. When a XSTM transaction commits, it modifies the objects on several machines instead of one as with a usual software transactional memory. More info here on how this enables object replication.
Links
XSTM: www.xstm.net
Blog: http://jstmcn.blogspot.com