next up previous
Next: A Reflective Framework for Up: Background and Motivation Previous: TP Monitors in the

   
A Practical Approach Based on Reflection

The challenge of opening up a legacy TP monitor, is therefore, characterized by two inter-related problems. The first problem is the interface for customization. Conventional TP monitors have a standard application-level interface that accepts only traditional transaction control operations, such as Begin_Transaction and Commit_Transaction. Extending the TP monitor through the available API would require application programmers to learn intricate details of the TP monitor architecture and the available API. The second problem is the level of customization. TP monitor system-level code functions 'underneath' the application code and is not subject to the same abstractions as the application. Indeed, with the API approach the TP monitor must be customized outside the application, rather than within it. An application, then, has no means to specify its requirements for extended transaction behaviors at runtime. At best, systems programmer could hope to anticipate the requirements of application programmers and adjust the TP monitor behavior through the API to implement an extended transaction model a priori, but this is at the cost of reusability of the TP monitor by applications with other requirements. Both of these problems combine to give users no easy way to reach in to the TP monitor and customize the way in which transaction functionality and interface are provided.

Computational reflection gives us a conceptual tool, the notion of a reflective module, to address these two problems. A reflective module contains a representation of the system, and has a causal connection between that representation and the actual behavior of the system. The causal connection is two-way; not only are changes in the system reflected in equivalent changes to the representation, but changes in the representation will also cause changes in the behavior of the system. A reflective module presents the application developer with a base interface that provides access to the default system behavior. In addition to the base interface, a reflective module presents a separate meta interface which a programmer can use to ''reach in'' and adjust the representation to add new behaviors to the system. In the next section we describe the Reflective Transaction Framework, demonstrating how reflection and the notion of a reflective module can used to enhance a legacy TP monitor, providing the flexibility to open the interface and implementation.


next up previous
Next: A Reflective Framework for Up: Background and Motivation Previous: TP Monitors in the
Matt Hurlbut
1998-07-06