|Consortium Solutions Middleware Forge MyObjectWeb|
Jironde: Transactions in Fractal
Jironde is a framework for extending the Fractal Composition Framework with transactions.
We use several component controllers that manage transactional functionality on behalf of components. We identify several parts of transactional functionality that are implemented by different transactional controllers. For a component, to be transactional, the only requirement is to fulfill a component contract which is specific to various transactional controller implementations. Thanks to the flexibility and reflective nature of Fractal, it is possible to achieve different levels of component transactional functionality by combining different transactional controllers, with only taking their component contracts into account.
Our view of a component extended with transactions is shown in the figure below.
There are several transaction controllers that manage specific transactional functionality. Most of this functionality is done in component interceptors that correspond to related transactional controllers. Each of the interceptors checks whether a transaction is associated with the thread asking for method invocation. Then the code specific to each interceptor is executed.
The component's author does not care about the transactional controllers. When deploying a component, it is only necessary to specify which controllers and interceptors will be present in the target architecture. Moreover, the component's author eventually has to fulfill requirements of the controllers used. We call these requirements the component contract. For example, the OTS Registration Controller checks whether the component implements either the Resource or Synchronization interfaces. If it does, the interfaces are registered to the incoming transaction. Another example is the Concurrency Controller, whose component contract is only to create a simple configuration XML file which specifies conflict table specific to the component type.
The figure below presents an application that we use in our examples.
Both the Client and Account component are Fractal components. They are wrapped to the application composite components. The Transaction Controller of the Client component allows it to retrieve the transaction object. Then the client issues methods on the Account component. The Transaction Controller of the Account component registers Account to the incoming transaction (in the Jotm2 case, Account implements Jotm2 EventListener, and in the OTS case, it implements both Resource and Synchronization interfaces). The Concurrency Controller manages concurrency control according to the conflict table defined in the configuration file associated with Account.
So far we have implemented Registration Controllers for OTS and Jotm2, as well as the Concurrency Controller for Jotm2. The next step is to implement a simple Propagation Controller that would be able to modify the transaction context which is propagated to the component.
The last version of Jironde is available in the JOTM CVS repository in the jotm2 module inside the fractal directory.
In the context of the Osmose ITEA Project, a Forum dealing with the Transaction Framework is available here. You can use this forum for getting news about the evolution of the Transaction Framework and its implementation called GoTM and posting your requests.
Marek Prochazka, Romain Rouvoy, Thierry Coupaye: On Enhancing Component-Based Middleware with Transactions. Accepted for presentation at the Poster Session of the International Symposium on Distributed Objects and Applications (DOA 2003), Catania, Italy, November 2003
Marek Prochazka: Jironde: A Flexible Framework for to Make Components Transactional. Accepted for presentation at the 4th IFIP International Conference on Distributed Applications and Interoperable Systems (DAIS 2003), Paris, France, November 2003
Marek Prochazka: A Flexible Framework for Adding Transactions to Components, The Eighth International Workshop on Component-Oriented Programming (WCOP 2003, in conjunction with ECOOP 2003), Darmstadt, Germany, July 2003.
Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster | Last modified at 2009-03-13 02:12 PM