Software Architectural Modeling of the CORBA Object Transaction Service

Transcription

1 Software Architectural Modeling of the CORBA Transaction Service Susanne Busse Fraunhofer ISST Mollstr. 1 D Berlin, Germany Susanne.Busse@isst.fhg.de Stefan Tai Technische Universität Berlin Sekr. E-N 7, Einsteinufer 17 D Berlin, Germany stai@cs.tu-berlin.de Abstract The OMG s Transaction Service (OTS) is an important CORBAService that provides transaction processing facilities on top of object request broker technology. With the OTS, specific interfaces and interaction models are introduced that intrinsically impact the design of single components and of component configurations that are to participate in transactional computation. In this paper, we argue to record impacts as introduced by the OTS as distinct abstractions of design, and propose a software architectural approach to software system representation. We present a pattern-like connector abstraction for one processing model of the OTS, and discuss its use for modeling CORBA applications that interface the OTS. Using our concepts of connector and component abstractions, a vocabulary of design can be established, and design rationales for introducing component features can be well recorded, supporting continuous development of ORB-based systems. 1. Introduction The Management Group s (OMG) Common Request Broker Architecture (CORBA) [5] specifies a standard technology that aims to facilitate the integration of diverse software components in distributed, heterogeneous environments [13]. CORBA is a constituent part of the OMG s Management Architecture (OMA) [4], a reference model for distributed, integrated object systems that complements the CORBA specification with generalpurpose object services the CORBAServices [6], and with domain-specific facilities. Among the CORBAServices are services for naming, events, or trading support, and the Transaction Service (OTS) for building transactional applications in CORBA environments. The OTS builds on the notion of transactions as employed in database management systems and Transaction Processing (TP) monitors of client-server systems. The concept of transactions supports the development of reliable (distributed) applications which require concurrent access to shared data. Transactions are characterized by the ACID properties atomicity, consistency, isolation, and durability [2], and these transactional properties must be guaranteed to all programs that run under the control of the transaction monitor. The OTS can be considered a TP monitor concept that is based on ORB technology, as has been adverted a major trend for next generation transaction processing [8]. The OTS, like other CORBAServices, defines standard required interfaces and interaction models for cooperating objects, and so introduces kinds of interconnection and interoperation patterns for software system design. These patterns exist both on the coding level of design, and on the software architecture level of design. Abstracting and understanding patterns (and pattern scales) that originate from, or are specific to systems built using object request broker technology, has been subject in a number of studies [14], [3]. In order to express software architectural patterns for ORB-based systems, however, dedicated modeling techniques are missing. Common traditional (object-oriented) modeling languages and notations have several shortcomings to representing ORB-based software system structures, as they typically structure designs around low-level programming language units like classes. As has been argued for in the research area of software architecture [9], software modeling techniques for the abstract representation of system-level structural concerns are needed. In this paper, we describe an approach to software architectural modeling of complex component compositions in ORB-based systems that are built using object services like the OTS. We argue for representing interconnection and interoperation patterns of ORB-based software infrastructure as distinct abstractions of design. We present a connector abstraction for the CORBA Transaction Service that captures one processing model of the OTS as a pattern to support modeling of applications that interface the OTS.

2 Our concept and understanding of connectors is embedded in a conceptual model for software architectural representation of integrated object systems [10], [12]. 2. The CORBA Transaction Service The OTS [6], [1] supports a nested transaction model, where a transaction may recursively spawn any number of subtransactions. The scope of a transaction is represented by a transaction context that is shared between all objects that are involved in the transaction. The transaction context can either be implicitly transmitted to all transactional participants by the ORB, or explicitly passed as a parameter of a request. The two modes of the OTS are therefore referred to as implicit and explicit. The OTS also distinguishes two modes of client-side transaction context management: indirect management via the use of a (local) pseudo object called Current, ordirect management via the use of the transaction context objects: the Control, Coordinator, and Terminator objects. The OTS correspondingly provides a number of interfaces that are used in either combination of implicit and explicit, and indirect and direct transaction processing. We will refer to and present interfaces for indirect transaction processing in more detail in the following section 3.0. An overview of the OTS can be described as follows: Transaction creation and beginning is supported by the Current and the TransactionFactory interfaces. A client typically uses one of these according to the processing mode chosen. Transaction management is supported by the Control interface that provides operations to return the respective Coordinator object and Terminator object for a specific transaction. The Coordinator object provides a number of operations for creating subtransactions, relating transactions, querying about the status of transactions, or for registering resources (persistent data that is affected by the transaction). The interface comprises operations similar to the X/Open XA interface for driving the twophase commit protocol (like prepare, rollback, or commit). These operations are called by the transaction management objects of the OTS. Alternatively, the OTS supports XA interoperability and can make use of transactional facilities of a database management system via the database s XA interface. A client can roll back or commit (terminate) a transaction by using the Current interface (in indirect management), or the Terminator interface (in direct management). Other interfaces of the OTS include the SubtransactionAware interface providing operations for committing or rolling back subtransactions (invoked by the OTS), and the empty Transactional interface that must be inherited by all objects that participate in implicit transaction context propagation. 3. Connector Indirect Transaction Processing This section presents the connector Indirect Transaction Processing as a pattern-oriented abstraction for software architectural modeling of CORBA applications that interface the OTS. The concept of connectors as proposed in [11] is here exemplified to describe component interdependencies of indirect processing for flat transactions using role abstractions, role interfaces, and interaction protocols Roles Roles represent the participants in the collaboration. Role abstractions serve for modeling collaboration responsibilities independent of specific components. Roles will be played by specific components when instantiating the connector (as in our modeling example, subsection 3.4). As roles abstract behavioral responsibilities (provided and/or required services), roles may be derived from other roles to incrementally define additional behavior. Note that we use specialization of roles exclusively to add behavior by leaving all inherited role behavior unchanged. For indirect transaction processing, the following roles exist: // Transactional client: any program invoking transactional // operations. TClient, // Transactional client that begins the transaction. TOriginator :TClient, // Transactional object: any object involved in the transaction. T, // Transactional object using implicit transaction propagation. ImplicitT :T, // Transactional object using explicit transaction propagation. ExplicitT :T, // Recoverable object Recoverable :T // object R, // Transaction context manager TManager. Figure 1. Roles

3 The OTS uses the term recoverable object to refer to transactional objects that have data that needs to be committed or rolled back when terminating the transaction. In our connector abstraction, a recoverable object is a transactional object with an associated resource object that represents the recoverable object s data Role Interfaces Role interfaces contain service specifications for a specific role, i.e. describe the externally visible behavior of the role. Role interfaces may be expressed using an interface definition language like OMG IDL. A role provides zero, one, or multiple role interfaces. // T interfaces T.Transactional { // ImplicitT interfaces ImplicitT.<SomeInterface>:Transactional { <t_operation()>; // ExplicitT interfaces ExplicitT.<SomeInterface> { <t_operation(arg, in Control c)>; // R interfaces R. { Vote prepare(); void rollback(); void commit(); void commit_one_phase(); void forget(); // TManager interfaces TManager.Current { void begin(); void commit(in boolean report_heuristics); void rollback(); Control get_control();... TManager.Control { Terminator.get_terminator(); Coordinator get_coordinator(); TManager.Terminator { void commit(in boolean report_heuristics); void rollback(); TManager.Coordinator { RecoveryCoordinator register_resource(in r);... TManager.RecoveryCoordinator { Status replay_completion(in r); Figure 2. Role Interfaces The role interfaces of our connector (Fig. 2) correspond to the IDL interfaces defined in the transaction service specification, module CosTransactions [6]. Between the roles and other role s interfaces, different directed usage relationships exist. These are described in Fig. 3. The semantics of the usage relationships is that a component playing a specific role has at one point of time knowledge of another role s interface and uses it. There is no information given about whether a role uses interfaces in a certain order or in certain states of the collaboration. For clarity, the figure also describes the role specialization relationships. TClient TOriginator Current 3.3. Interactions TManager <SomeInterface> Control Terminator Coordinator Recovery Coord. Implicit T {complete} T Recoverable <SomeInterface> Explicit T Figure 3. Role Interface Usage R Interaction protocols describe actions and orders of actions for the collaboration along with pre- and postconditions to be considered. They describe behavioral aspects of the collaboration for multiple participating roles. Our connector abstraction describes Transaction Initialization, Implicit and Explicit Transaction Propagation, Registration, and Transaction Termination by means of interaction protocols (Fig. 4). We use the UML notation of generic sequence diagrams [7] to describe role interactions. The preconditions specified for an interaction can be fulfilled using other interaction protocols. For example, the interaction Transaction Initialization serves for the precondition of the interaction Transaction Propagation. A typical transaction processing scenario is a sequence of transaction initialization, several transaction propagations and resource registrations, and transaction termination Modeling Example In the following, we provide a small example that illustrates software architectural modeling with the connector Indirect Transaction Processing. The example demonstrates use and impact of applying the OTS to a specific domain-oriented component composition. The modeling

4 Transaction Initialization A pseudo object supporting the Current interface is local to TOriginator. A transaction context is created and automatically associated with the client s thread. Registration An invocation has arrived at a recoverable object (with implicit or explicit transaction propagation). The recoverable object knows the control object of the transaction. A object is created and registered. :TOriginator :Recoverable Current::begin() robj:r Implicit Transaction Propagation Transaction has been initialized. The transaction context is associated with the ImplicitT s thread. :TClient <SomeInterface>:: <t_operation()> :Implicit T Control::get_coordinator() Coordinator:: register_resource(robj) Transaction Termination // Note, that an implemention of the transaction service may // permit that other TClient objects than the TOriginator terminate // the transaction. Transaction has been initialized. All functions that are executed within the scope of the transaction are either committed, or rolled back. Explicit Transaction Propagation Transaction has been initialized. The transaction context is associated with the ExplicitT s thread. :TOriginator [T nok] [T ok] Current:: rollback() :: rollback() :R * :TClient Current:: get_control() :Explicit T Current:: commit(false) vote :: prepare() ctrl_ref <SomeInterface>:: <t_operation(arg,ctrl_ref)> twophase commit protocol [votes ok] [votes nok] :: commit() :: rollback() Figure 4. Interaction Protocols example consists of descriptions of specific components,an abstract architecture, and a concrete architecture. Components. Components model computational entities of the system and are for our purposes defined as abstractions of systems of related programming objects that are encapsulated by ORB-level interfaces. Component descriptions are structured into three different parts: Interface specifications group all ORB-level interfaces of the component. Interfaces are expressed using an interface definition language like OMG IDL. The coding level design of the component is expressed using class modeling. The public classes describe the programming level entry-points for the component (Representation-Map), the non-public classes describe the internal component realization (Representation). Our simple example scenario concerns transactional money transfering between different banking accounts. Fig. 5 depicts a domain-oriented component abstraction of a bank. The bank component comprises the two IDL interfaces and, the respective programming level classes, and classes that implement the component functionality. The interface offers operations for creating and deleting accounts (as an factory), the interface is an abstraction of an account to deposit money onto, or to withdraw money from. Abstract Architecture Using Connectors. The connector Indirect Transaction Processing can now be used to model the abstract architecture of a component collaboration. Specific components are related on an abstract level of

5 _1 Interface Specifications _1 // OMG IDL interface { exception InvalidValue { float value; Transactional BOAImpl _i 1 1..* main() BOAImpl _i void Deposit (in float amount) raises (InvalidValue); void Withdraw(in float amount) raises (InvalidValue); Representation-Map // C++ class InvalidValue : public CORBA::UserException { class : CORBA:: { virtual void Deposit (CORBA::Float amount, ) virtual void Withdraw(CORBA::Float amount, ) Representation Figure 5. Component, Domain Abstraction Client TOriginator ImplicitT Recoverable R _1 Indirect Transaction Processing _2 TManager OTS_Implementation ImplicitT Recoverable R Transactional <class model of representation> // C++ class : CosTransactions::Transactional, CosTransactions:: { virtual CosTransactions::Vote prepare () virtual void rollback () virtual void commit () virtual void Deposit (CORBA::Float amount, ) virtual void Withdraw(CORBA::Float amount, ) Figure 7. Component, OTS Collaboration View example. The concrete architecture comprises component abstractions only and exhibits the internal structure and interconnections of the multiple components involved. The scheme serves as an abstraction over component programming structure using a uniform component model. Fig. 8 depicts only one bank component for reasons of brevity (another bank component may have the same or a completely different internal representation structure and external services). 4. Conclusions and Discussion Figure 6. Component Collaboration, Abstract Architecture software system representation by means of the connector: the roles of the connector are assigned to specific components to indicate that these components interoperate according to the interfaces and interaction protocols as specified in the connector. Fig. 6 depicts the abstract architecture for our example using the OTS connector. This component collaboration describes the application of the indirect OTS processing model for two (different) bank components, a banking client, and a component that implements the OTS. Concrete Architecture. The impact of adapting the OTS, i. e. of transactionalizing CORBA components, is illustrated for the specific component 1 in Fig. 7. The component now has additional interfaces and objects that exist because of transaction processing rationale. The bank component is in role Recoverable of the connector, as it manages account objects that are in role of. Fig. 8 shows the concrete architecture for our modeling In this paper, we proposed the concept of connectors as pattern-oriented abstractions for software architectural modeling of distributed integrated object systems. We introduced the connector Indirect Transaction Processing that captures one processing model of the CORBA Transaction Service, and illustrated the use of the connector for modeling component compositions. Using connectors like Indirect Transaction Processing, complex component interconnections and interoperations that result of software technological rationale can be well abstracted and described in software system design. Connectors particularly serve for describing component-level patterns, which appear inherently in CORBA-based systems, especially when regarding the OMG s common object service specifications (CORBAServices). Connectors abstract from specific components, but provide expressive capabilites for modeling component interdependencies, as shown in this paper. Connectors are an abstraction concept symmetrical to components. Our structured component descriptions relate well to today s component implementation technologies as represented by object request brokers: Interface and implementation abstractions are separated, and interfaces of the component (on the system-level) are distinguished from

6 Client _1 References <IDL Component Interfaces> <Client Public Classes> main() Current Control Coordinator Control Current OTS Coordinator BOAImpl _i <IDL Component Interfaces> Transactional 1 RecoveryCoord. 1..* main() Terminator Recovery Coordinator <OTS implementation> Terminator BOAImpl _i Figure 8. Component Collaboration, Concrete Architecture the programming level interfaces that realize the component s services. Different views on a component can be expressed, focusing on domain-specific functionalities in one view, or focusing on collaboration-specific component features in another. Component views result from different connector adaptations (role implementations). This describes design rationales for having introduced certain system-level interfaces, or internal design structures of a component. Such information is of high importance for future system modifications (component change and exchange), as domain functionalities and interconnection mechanisms of software infrastructure have been separatedly described and motivated. We have concentrated in this paper on the indirect processing model of the OTS for flat transactions. Other OTS connectors can be defined for the direct model of transaction context management, for nested transactions (using the interfaces SubtransactionAware and Coordinator), or for transaction processing using native DBMS support (X/Open XA interfaces). This is subject to future work, as well as defining OTS connectors for more specialized design problems like object caching in transactional CORBA environments. [1] E. Grasso. Implementing interposition in corba object transaction service. In Proc. First International Enterprise Distributed Computing Workshop. IEEE, [2] J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. Morgan Kaufmann, [3] T. Mowbray and R. Malveau. CORBA Design Patterns. Addison-Wesley, [4] OMG. Management Architecture Guide, Rev 2.0, OMG TC Doc Number , [5] OMG. The Common Request Broker: Architecture and Specification, Rev 2.0, [6] OMG. CORBAServices: Common Services Specification, Rev 2.0, OMG TC Doc Number , [7] OMG. Unified Modeling Language, Version 1.1, [8] R. Orfali, D. Harkey, and J. Edwards. The Essential Distributed s Survival Guide. Wiley, [9] M. Shaw and D. Garlan. Software Architecture Perspectives on an Emerging Discipline. Prentice Hall, [10] S. Tai. abstractions in the design of corba systems for air traffic control simulation. Technical Report 27/96, EUROCONTROL Experimental Centre, [11] S. Tai. A connector model for object-oriented component integration. In Proc. ICSE-98 Intl. Workshop on Component-Based Software Engineering, [12] S. Tai and S. Busse. Connectors for modeling object relations in corba-based systems. In Proc. 24th Intl. Conference on the Technology of -Oriented Languages and Systems. IEEE, [13] S. Vinoski. Corba: Integrating diverse applications within distributed heterogeneous environments. IEEE Communications Magazine, 14(2), February [14] K. Wallnau, N. Weiderman, and L. Northrop. Distributed object technology with corba and java: Key concepts and implications. Technical Report CMU/SEI-97-TR-004, Carnegie Mellon University, 1997.