Towards a Model-Driven Approach to Build ... - ACM Digital Library

195

Middleware 2004 Companion

Towards a Model-Driven Approach to Build Component-Based Adaptable Middleware ∗

Romain Rouvoy , Philippe Merle INRIA Jacquard Project, Laboratoire d’Informatique Fondamentale de Lille, UPRESA 8022 CNRS – U.F.R. I.E.E.A. – Batiment ˆ M3, Universite´ des Sciences et Technologies de Lille, 59655 Villeneuve d’Ascq Cedex, France. {rouvoy,

merle}@lifl.fr

ABSTRACT

1. INTRODUCTION

Adaptability is one of the goals that applications and middleware frameworks are trying to achieve. On one hand, the component paradigm is a way of reaching this goal by enforcing the reusability of functionalities involved in a component-based middleware framework. In particular, reflection could be combined with components to improve the adaptability of the structure of their assemblies. On the other hand, the model driven paradigm provides an efficient way to describe an application with enough abstraction to enable its mapping on various execution platforms. The contribution of this paper is a combination of both model and component paradigms to reach more adaptability in middleware, especially in a component-based framework to build transaction services. The framework presented uses models to describe middleware standards and compiles them to components. These components are coupled with a compliant component-based middleware framework. This approach provides adaptability at various levels with some added values.

Adaptability is one of the goals that applications and middleware are trying to achieve. In the context of transaction services, reflection has provided many results on constrained contexts such as the Object Transaction Service [14] or Legacy Transaction Monitors [2]. But these constrained approaches consider only one transaction standard and it becomes difficult to apply their benefits to other middleware contexts. However two other paradigms provide artefacts to improve adaptability. The component paradigm allows one to clarify the structure of middleware. Small and reusable entities could be composed in different ways to achieve a particular functionality. Reflection could be combined with components to improve the adaptability of the structure of an assembly of components. For instance, the Fractal component model [6] provides reflective mechanisms to integrate adaptability capabilities to middleware platforms which are developed with it. Nevertheless the assemblies of component-based middleware are handwritten and their structural patterns are not abstracted. The second paradigm based on models is able to provide adaptability at the application level. For example, the Object Management Group’s Model Driven Architecture (OMG MDA) [3] promotes the generation of the code of an application from its abstract model [13]. Once defined, the model of an application is successively transformed to produce an executable version. Reflection is used here to keep the cohesion between models and meta models during the phases of transformations. But the resulting applications do not provide any guarantee in terms of quality, adaptability and performance. The main contribution of this paper is to argue for the combination of the component-based and the model-driven approaches to obtain adaptability in middleware. It describes a framework based on models to personalize component-based adaptable middleware to a particular standard. These models are transformed to executable components and configuration descriptors by an adaptable compilation process. This approach is illustrated in GoTM1 : Our component-based framework to build transaction services. The remainder of this paper is organized as follows. Section 2 describes the characteristics of the component-based and the modeldriven approaches with a criticism of each of them. Section 3 introduces our approach to achieve adaptability in the implementation of middleware standards. Section 4 details a meta model supporting the description of standards. Section 5 provides some design elements of an adaptable model compiler. Section 6 discusses sim-

Categories and Subject Descriptors D.2.0 [Software Engineering]: General—Standards; D.2.13 [Software Engineering]: Reusable Software—Reusable libraries, Reuse models

General Terms Component-Based Adaptive Middleware

Keywords Components, CBAM, Models, MDSE, Transactions ∗This work is partially funded by the Region Nord - Pas-de-Calais.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 3rd Workshop on Adaptive and Reflective Middleware Toronto, Canada Copyright 2004 ACM 1-58113-949-7 ...$5.00.

1

GoTM: http://gotm.objectweb.org/

Adaptive and Reflective Middleware

196

ilar approaches combining models and components. Section 7 concludes on the added values and the perspectives of our approach.

2.

COMPONENTS VERSUS MODELS

2.1 Component-Based Adaptive Middleware Nowadays middleware platforms require more and more adaptability to address the amount of enquiries of their users. Indeed the number of functionalities provided by middleware is still growing and it should follow the global evolution of technologies. This evolution takes into account the evolution of existing standards but also the publication of new standards in the same domain (communication, transaction, security, etc.). In order to address these requirements with better time-to-market properties, some recent developments have spread out the use of components in middleware as a way to reach adaptability. A component could be viewed as a software entity which clearly defines the provided and required services [19]. Once each component is well defined, it becomes easier to reuse it in different contexts and connect it to various other components depending on the use case. To address the multiplication of standards, some initiatives define the notion of personality which could be understood as a customization of a middleware framework to a particular standard. Thanks to the notion of personality coupled to the component paradigm, these middleware frameworks are able to handle several standards and to follow their evolution.

G

B

JTS

F

OTS

Personality

Adaptable

B

A

Transaction

Kernel

C Framework

G A

E C

I

D

Properties

Figure 1: Component-Based Adaptive Middleware Figure 1 depicts an example of a component-based transaction framework which provides adaptability properties. This middleware framework is composed of three layers which are the Personality, Kernel and Property layers. The Kernel layer could be seen as a repository of generic components dealing with transaction concerns (coordination, concurrency, recovery, resources, etc.). The Property layer captures the ACID2 properties of the transaction framework and allows us to easily configure and adapt them to various execution contexts. The Personality layer groups customizations of the transaction framework according to existing standards such as Java Transaction Service (JTS) [7] and Object Transaction Service (OTS) [16]. A particular Personality is built by composing Kernel components and configuring the Property elements. This example of a component-based transaction framework is implemented in our GoTM project using the Fractal component model [6] but other Component-Based Adaptive Middleware (CBAM) 2

ACID: Atomicity-Consistency-Isolation-Durability

exist. The Jonathan project [10] provides a component-based framework to build various instances of Object Request Brokers (ORB) on top of protocols such as Java Remote Method Protocol (JRMP) or Internet Inter-ORB Protocol (IIOP). The OpenORB project [4] provides also an adaptable framework to build ORB using OpenCOM [9] as the underlying component model. The Dream project3 is a Fractal-based component framework to build asynchronous message-oriented middleware. Moreover the Fractal component model is commonly used in a suite of frameworks dealing with persistency concerns. This suite is composed of the JORM [1] framework4 to provide various data source to memory mappings; the MEDOR [1] framework5 to support various query languages and data sources; the Perseus framework6 for caching and concurrency concerns. These three frameworks are then reused and customized in the Speedo project to implement the Java Data Object standard. One could consider that the CBAM approach has proven its reliability and its consistency to build standard-independent and adaptable middleware.

2.2 Model-Driven Software Engineering The Object Management Group (OMG) promotes another approach to achieve adaptability at the application level with the ModelDriven Architecture (MDA) [11]. The concepts involved in MDA are based on the definition of two kind of models: Platform Independent Models (PIM) and Platform Specific Models (PSM). A PIM provides an abstract representation of an application independently of any standards and aims at capturing only the business concerns. A PSM is the result of the transformation of a PIM to apply it on a particular technology. One could notice that PIM and PSM are defined by specific meta models which constrain the expression of the models. Figure 2 depicts the Model-Driven Software Engineering (MDSE) approach. It deals with the design of the PIM of an application. It uses a production chain to transform the PIM either to a PSM dedicated to the CORBA Component Model (CCM) or to another PSM dedicated to Enterprise Java Beans (EJB). Once the PSM is defined for CCM (resp. for EJB) the second step of the production chain generates the associated code which will be executed by a CCM platform (resp. an EJB platform). Here the adaptability is considered at the application level and allows designers to change the underlying technology used (CCM or EJB) to implement the application without developing the application twice. So the MDSE approach allows us to build applications independent of the underlying middleware based on the definition of abstract models.

2.3 A Criticism of these Approaches One could observe that these two approaches address adaptability in software engineering. CBAM targets the middleware adaptability and MDSE aims at providing application adaptability. Nevertheless the CBAM approach does not provide any methodology to build the personalities of component-based middleware. Indeed there are no abstraction elements factorized between the personalities, for example the transaction model is not abstracted between the JTS and the OTS personalities. On the other hand, the MDSE approach considers that the whole business code could be generated from its model and executed on 3

Dream: http://dream.objectweb.org/ JORM: http://jorm.objectweb.org/ 5 MEDOR: http://medor.objectweb.org/ 6 Perseus: http://perseus.objectweb.org/ 4

197

Middleware 2004 Companion PIM

PIM

Transaction

Application

Transformation

Transformation PSM

PSM

EJB

CCM

JTS

CCM

OTS

JTS

Generation

MDSE

PSM

PSM

Generation

OTS

EJB

Execution

Personalisation

CBAM

Component−Based Adaptable Transaction Framework Figure 3: The Mixed Approach CCM Platform

EJB Platform

Figure 2: Model-Driven Software Engineering any platform. But in this approach, it becomes hard to imagine that a full transaction service will be generated from its transaction model and will provide middleware adaptability properties. Then we think that the next generation of adaptive middleware would adopt a mixed approach combining both CBAM and MDSE approaches.

3.

TOWARDS A MIXED APPROACH

Our mixed approach aims at completing the CBAM approach with the introduction of standard models to generate personalities using the MDSE approach. But the pieces of code to generate only concerns the personality components used to customize the underlying component-based middleware framework. Then we only need to model the notion of personality and to express their requirements towards the underlying component-based middleware framework in terms of interactions and behaviors. In Figure 3, the CBAM approach is represented by the two lower elements which are the Component-Based Adaptable Transaction Framework and both the JTS and OTS personalities. The MDSE approach is applied here to the transaction purpose and the considered PIM is a generic transaction model. As the PIM does not take into account standard concerns, it only describes the generic configuration and behavior of the transaction manager. In our context, it models the kind of functionalities which are required (resource management, synchronization management, two-phase commit validation, recovery support, concurrency support, etc.). This PIM is transformed to PSM and checked. If the verification does not raise any incoherence, the PIM model will be enhanced with the standard specification which mainly introduces specific Application Programming Interfaces (API). These API are mapped to the

API of the Component-Based Transaction Adaptable Framework via Adapter Components. As Adapter Components must be assembled with the other components of the underlying framework, the PSM also enhances the assembly of components described by the PIM with these Adapter Components. Then a compilation process takes the PSM to produce components and descriptors fitting with the component model supported by the underlying framework. The component model runtime will next interpret the descriptors written with an Architecture Description Language (ADL) [15] to assemble and configure an instance of the PSM. Thanks to this mixed approach, we could use a basic flat transaction PIM to transform and enrich it with the JTS standard which uses Java Transaction API (JTA) and then generating an instance of a JTS transaction manager based on the GoTM framework. Next section focuses on the PSM layer and its generation process. The PIM layer and the transformation process to PSM are not detailed in this paper by lack of space.

4. A META MODEL FOR ABSTRACTING PERSONALITIES The PSM layer we present covers two aspects which are the models used to represent a particular standard and the compilation framework used to generate the pieces of code which are not provided by the CBAM used. These aspects are detailed in Figure 4 depicting the linear view of our Model-Driven Production Chain. In Figure 4, a PSM model is composed of three parts which are the Standard API, the Adapter and the Behavior layers. The Standard API layer captures the API defined by a standard. In the context of the JTS PSM model, the Standard API layer would consider the JTA interfaces. The Adapter layer is composed of various personality components implementing the Standard API layer with conversions to the underlying CBAM. The personality components for JTS would implement the JTA interfaces to provide a Wrapper

Adaptive and Reflective Middleware

Adapter

Compiler Generator

Middleware IDL

API



API

CPT

Compilers QVT



QVT

Model

IDL

Adapter



MOF

MOF

IDL

MOF

Meta Model

198

Personality

formalism to describe the Adapter meta model.

Structure

ADL

Interpreter

CPT

Behavior

QVT

Behavior

MOF

MOF

Interface Assembly CBAM

* Method

*

Parameter

*

Figure 4: Overview of the Model-Driven Production Chain Facade [18] to the interfaces of the GoTM framework. The Behavior layer is inherited from the transaction PIM and describes the functionalities awaited by the model designer. The behavior model of JTS would describe that the transaction manager uses a flat transaction model with a two-phase commit protocol and supports the notion of resources and synchronizations. It could also specify that the transaction manager would be distributed and should support the recovery process. The behavior of the transaction model could be described with a finest granularity to specify the internal state automaton of a transaction model to achieve adaptability in details. Each layer of the PSM model is associated to a layer of the PSM meta model. The Standard API layer of the PSM model would be defined by an IDL meta model in the PSM meta model. This meta model would be the Java meta model in the case of JTA but it would be the OMG IDL meta model in the case of OTS. The Adapter layer would be based on an Adapter meta model which would provide a way to map the Standard API layer to the CBAM API. The Behavior layer could use the same meta model as the one used in the PIM to abstract the behavior. Moreover, each layer of the PSM model would be handled by a dedicated compiler which would generate the pieces of code or the descriptors required to run the instance of the PSM model on top of the selected CBAM. In most of the standards, the Standard API layer content could be considered as programming elements directly interpretable by the CBAM. But the Adapter layer content requires to be converted from a mapping expression to an adapter component. Finally the Behavior layer content would generate a set of descriptors to configure the CBAM with the appropriate attributes and binding it with the adapter component.

4.1 The API Meta Model Considering that the API layer is strongly imposed by the standard designer, the API meta model would depend from the language used to express the API. Taking the case of JTS and OTS, the API meta models are respectively the Java meta model and the OMG IDL meta model. But one could also consider an abstract model based on the Unified Modeling Language (UML). In this case we just need an UML compiler to generate Java code in the case of the Fractal component model.

4.2 The Adapter Meta Model The Adapter layer groups the conversions between a middleware standard and the CBAM. One could observe that the constructions involved in adapter components are quite simple because they are only dealing with classical method calls. The Adapter model should allow one to transform a call to a standard method with its parameters and its exceptions to a set of calls to CBAM methods with parameters and exceptions which could differ from the standard ones. Figures 5 and 6 use the Meta Object Facility (MOF) [12]

Elt

Exception Out

1

Return

Standard

CBAM

Figure 5: The Structural Meta Model Diagram Figure 5 describes the structural meta model of the API of middleware standards and CBAM. In this meta model, an Interface is composed of several Methods. A method would have several incoming Parameter elements and only one Return value. Each method could also define a set of throwable Exception elements. The Return element and the Exception elements could be considered as Out elements. The structural meta model could be inherited by both Standard and CBAM MOF packages. This structural meta model is used to define the adapter meta model depicted in Figure 6.

Adapter set

*

Adapter from

1 Standard::Method

Mapping

CBAM::Method

sequence

* Call

1

to

with

* Attribute

Standard::Elt

to

*

CBAM::Elt 1

1

from

Conversion

Link

from

Figure 6: The Adapter Meta Model Diagram As shown in Figure 6, an Adapter element is composed of a set of Mappings. Each Mapping addresses a particular Method of the middleware standard and is associated to a sequence of Call elements. A Call captures an invocation on a Method of the ComponentBased Adaptable Middleware with all Attributes (this includes incoming parameters, return value and exceptions). An Attribute could be either a Conversion between an Elt of the standard and an Elt of the CBAM or a Link to a declared Elt of the CBAM (e.g. a value returned by a previous call to a method of the CBAM).

5. FRAMEWORK IMPLEMENTATION Once the adapter meta model is defined and an instance of this meta model describes a given standard, a model compiler is needed to produce a personality of the CBAM. In order to compile a standard, several generators are needed because the target elements are

199

Middleware 2004 Companion heterogeneous (components, descriptors, etc.). An adaptable architecture should be used to compose the generators of the compiler. As there are several standards and each of them is subject to evolution, the compiler should reflect its standard in order to reduce the cost of the compiler development. In order to achieve adaptability at the compiler level, we propose to generate most parts of the compiler using meta model definitions. Then we need a meta model compiler to produce model compilers which would be able to handle various standards. An architectural representation of these compilers is depicted in Figure 7.

Meta Model

Meta Model

Meta Model

Builder

Builder

6. RELATED WORK

feeds

parses

generates

generates

Co mp on en t

parses

Descriptor

feeds

feeds

Generator

Converter

parses Repository

Converter

Model

Parser

parses

parses

Generator

Meta Compiler Builder

meta model used to describe the standard. The ModFact Repository Maker Tool [5] already allows us to produce the model repository with its parser and its generator from any input model compliant with the MOF formalism. The ModFact project provides also an implementation of a QVT engine which could be coupled with generated repositories to provide an instance of the model compiler. Thanks to this meta model compiler any evolution of standards or any definition of a new standard could be handled in an easier and prettier way than if the model compilers needed to be written or modified by hand.

The approach described in this paper has still been applied by other projects. i.e. to combine CBAM and MDSE approaches to generate assemblies of components from model descriptions. The Cadena Project7 [8] provides an integrated environment to build and model systems based on the CORBA Component Model. The Component Synthesis with Model Integrated Computing Project8 (CoSMIC) [13] provides a Model Driven Middleware tool chain which integrates OMG MDA technologies with QoS-enabled component middleware. The Open Tool Integration Framework9 (OTIF) provides a meta-model driven infrastructure for the integration of design tools for embedded system development. Even if these approaches mix CBAM and MDSE, our approach distinguishes from them by addressing the production of middleware components rather than application components.

Repository

Compiler

Rules

Rules

7. CONCLUSION

Figure 7: Overview of Personality Compilers

5.1 The Model Compiler The model compiler aims at producing the pieces of code to adapt standards which are currently hand written (e.g. Adapter components, Assembly Descriptors, Configuration Files, etc.). The model compiler would provide a particular assembly of the CBAM enhanced with adapter components to support a specific standard. The model compiler parses an input model and stores it into a dedicated repository. Then this repository is parsed by converters built on top of a transformation engine driven by a set of rules. Each converter transforms the content of a given repository (e.g. Adapter repository) to one dedicated to another specific model (e.g. UML repository). The generic transformation engine is based on the OMG’s Query View Transformation (QVT) specification and does not need to be developed, only transformation rules between meta models need to be defined. This modular approach promotes the composition of converters to avoid multiple developments of transformation rules. Once the model of the standard is stored in a final repository, a generator would provide a textual representation (Java, XML, etc) of the standard model. Finally the result of this compilation process is coupled with the underlying CBAM to assemble an instance of the standard.

This paper has described two approaches to reach adaptability in middleware. The first is based on components and personalities and is called CBAM. The second is based on models and compilers and is called MDSE. Next we presented our approach to build adaptable middleware combining CBAM and MDSE to describe various standards. Finally the associated meta models used in our approach have been described in details before giving some elements of the implementation of our adaptable model compiler framework.

7.1 Added Values The introduction of models in the process of developments of reflective and adaptable middleware provides clear added values: • Platform Specific Models (PSM) allow us to clearly identify the concepts involved in a particular standard without dealing with technical properties. It provides high level constructions to describe the specific elements of a standard. • Some of these concepts could be abstracted and grouped in Platform Independent Models (PIM) to enforce their reusability in other PSM. • Adapter components as many other descriptors could be automatically generated using dedicated model compilers which would be able to interpret the models of standards. • This approach respects the principle of separation of concerns because it deals only with the notion of adaptation of middleware and lets the technical code to the responsibility of the dedicated underlying middleware framework.

5.2 The Meta Model Compiler We argue that the model compiler could be now built by a meta model compiler. This meta model compiler would mainly generate a repository, its parser and its generator from an input meta model. The meta model compilation is reproduced for each input

7

Cadena: http://cadena.projects.cis.ksu.edu/ CoSMIC: http://www.dre.vanderbilt.edu/cosmic/ 9 OTIF: http://www.isis.vanderbilt.edu/Projects/WOTIF/default.html 8

Adaptive and Reflective Middleware • Models and compilers are designed to support evolutions of standards and could be reused to consider more ad-hoc standards. • Model compilers could be obtained by the compilation of their associated meta models thanks to meta model compilers.

7.2 Perspectives Now we need to fully implement this model-driven framework and its production chain to validate this approach. However first prototyping experimentations allow us to be optimistic. Our objective is not limited to the construction of instances of standards but it also aims at reaching the best performance by applying efficient design patterns at every level of design. Our past experiences on transaction demarcation abstraction [17] have shown that adaptability and performance were not incompatible and we want to broaden this approach to the design of transaction services. We also want to improve the behavior model expressiveness to provide a finest level of adaptability and be able to consider advanced transaction models. In a longer term perspective, we would like to extend our approach to capture models of other non functional services and component-based middleware platforms such as our OpenCCM10 platform. Then from these models, middleware could be generated automatically.

8.

REFERENCES

[1] A LIA , M., C HASSANDE -BARRIOZ , S., D ECHAMBOUX , P., H AMON , C., AND L EFEBVRE , A. A Middleware Framework for the Persistence and Querying of Java Objects. In Proceedings of the 18th European Conference on Object-Oriented Programming - ECOOP 2004 (Oslo, Norway, June 2004), vol. 3086 of Lecture Notes in Computer Science, Springer-Verlag, pp. 291–315. [2] BARGA , R., AND P U , C. Reflection on a Legacy Transaction Processing Monitor. In Proceedings of Reflection ’96 (San Francisco, CA, USA, Apr. 1996). [3] B EZIVIN , J. From Object Composition to Model Transformation with the MDA. In Proceedings of TOOLS’USA (Santa Barbara, USA, Aug. 2001), vol. IEEE TOOLS-39, pp. 346–354. [4] B LAIR , G., C OULSON , G., B LAIR , L., D URAN -L IMON , H., G RACE , P., M OREIRA , R., AND PARLAVANTZAS , N. Reflection, self-awareness and self-healing in OpenORB. In Proceedings of the First Workshop on Self-Healing Systems WOSS 2002 (Charleston, South Carolina, USA, Nov. 2002), ACM, pp. 9–14. [5] B LANC , X., B OUZITOUNA , S., AND G ERVAIS , M. A Critical Analysis of MDA Standards through an Implementation: the ModFact Tool. In Proceedings of the First European Workshop on Model Driven Architecture with Emphasis on Industrial Application - MDA-IA’04 (University of Twente, Enschede, The Netherlands, Mar. 2004), pp. 115–122. [6] B RUNETON , E., C OUPAYE , T., L ECLERCQ , M., Q UEMA , V., AND S TEFANI , J.-B. An Open Component Model and Its Support in Java. In Proceedings of the 7th International Symposium on Component-Based Software Engineering CBSE 2004 (Edinburgh, Scotland, May 2004), vol. 3054 of Lecture Notes in Computer Science, Springer-Verlag, pp. 7–22. 10

OpenCCM: http://openccm.objectweb.org/

200 [7] C HEUNG , S. Java Transaction Service Specification Version 1.0. Sun Microsystems, Dec. 1999. [8] C HILDS , A., G REENWALD , J., R ANGANATH , V. P., D ENG , X., DWYER , M. B., H ATCLIFF , J., J UNG , G., S HANTI , P., AND S INGH , G. Cadena: An Integrated Development Environment for Analysis, Synthesis, and Verification of Component-Based Systems. In Proceedings of the 7th International Conference on Fundamental Approaches to Software Engineering - FASE 2004 (Barcelona, Spain, Apr. 2004), vol. 2984 of Lecture Notes in Computer Science, Springer, pp. 160–164. [9] C LARKE , M., B LAIR , G., C OULSON , G., AND PARLAVANTZAS , N. An Efficient Component Model for the Construction of Adaptive Middleware. In Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms - Middleware’01 (Heidelberg, Germany, Nov. 2001), pp. 160–178. [10] D UMANT, B., H ORN , F., T RAN , F. D., AND S TEFANI , J.-B. Jonathan: An Open Distributed Processing Environment in Java. Distributed Systems Engineering 6, 1 (Mar. 1999), 3–12. [11] F UENTES , L., P INTO , M., AND VALLECILLO , A. How MDA Can Help Designing Component- and Aspect-based Applications. In Proceedings of the 7th International Enterprise Distributed Object Computing Conference EDOC 2003 (Brisbane, Australia, Sept. 2003), IEEE Computer Society, pp. 124–135. [12] G ERHARDT, F. Reengineering with the CORBA Meta Object Facility. In Object-Oriented Technology, ECOOP’98 Workshop Reader, ECOOP’98 Workshops, Demos, and Posters (Brussels, Belgium, July 1998), vol. 1543 of Lecture Notes in Computer Science, Springer-Verlag, pp. 6–7. [13] G OKHALE , A., S CHMIDT, D. C., NATARAJAN , B., G RAY, J., AND WANG , N. Model Driven Middleware. John Wiley & Sons, Ltd, 2004. [14] K ARLSEN , R., AND JAKOBSEN , A. Transaction Service Management - An Approach Towards a Reflective Transaction Service. In Proceedings of International Middleware Conference, Workshop Proceedings, The 2nd Workshop on Reflective and Adaptive Middleware (Rio de Janeiro, Brasil, June 2003), PUC-Rio, pp. 135–138. [15] M EDVIDOVIC , N., AND TAYLOR , R. A Classification and Comparison Framework for Software Architecture Description Languages. IEEE Transactions on Software Engineering 26, 1 (Jan. 2000), 70–93. [16] OMG. Object Transaction Service Specification Version 1.4. In CORBAservices : Common Object Services Specification (Sept. 2003), Object Management Group. OMG TC Document formal/2003-09-02. [17] ROUVOY, R., AND M ERLE , P. Abstraction of Transaction Demarcation in Component-Oriented Platforms. In Proceedings of the fourth ACM/IFIP/USENIX International Middleware Conference - Middleware’03 (Rio de Janeiro, Brasil, June 2003), vol. 2972 of Lecture Notes in Computer Science, Springer-Verlag, pp. 305–323. [18] S CHMIDT, D., S TAL , M., ROHNERT, H., AND B USCHMANN , F. Pattern-Oriented Software Architecture : Patterns for Concurrent and Networked Objects - Volume 2. John Wiley & Sons, Ltd, New York, USA, Apr. 2001. [19] S ZYPERSKI , C. Component Software: Beyond Object-Oriented Programming. Addison Westley Longman, Nov. 2002.