text:
IMPLEMENTATION OF AN ADVANCED TRANSACTION MODEL FOR AN INTEGRATED COMPUTING ENVIRONMENT FOR BUILDING CONSTRUCTION
Architectural design ( jstor )
Architectural models ( jstor )
Building construction ( jstor )
Databases ( jstor )
Estimators ( jstor )
Flow charting ( jstor )
Information resources ( jstor )
Java ( jstor )
Modeling ( jstor )
Rollbacks ( jstor )
Copyright the author. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
UFE1000138.pdf
UFE1000138_pdf.txt
IMPLEMENTATION OF AN ADVANCED TRANSACTIO N MODEL FOR AN INTEGRATED COMPUTING ENVIRONMENT FOR BUI LDING CONSTRUCTION By HUANQING LU A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF TH E REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2002
Copyright 2002 by HUANQING LU
To My Parents
iv ACKNOWLEDGMENTS I would like to thank and acknowledge my gratefulness to my committee chair, Dr. Randy Y. C. Chow, for his true understanding and inspiration. It is a privilege to be able to work with him. I would like to thank Dr. R. Raymond Issa for hi s guidance and support to my research, especially for his extra efforts in reviewing of the manuscript. This study would not have been possible without his assistance. I want to thank Dr. Joachim Hammer for serving on my advisory committee. I am thankful for the one special person, Hui, who offers her invaluable support to my study with her love.
v TABLE OF CONTENTS page ACKNOWLEDGMENTS ................................ ................................ ................................ .. iv LIST OF TABLES ................................ ................................ ................................ ............. vii LIST OF FIGURES ................................ ................................ ................................ .......... viii ABSTRACT ................................ ................................ ................................ ........................ ix CHAPTERS 1 INTRODUCTION ................................ ................................ ................................ ............ 1 2 REVIEW OF RELATED WORK ................................ ................................ .................... 3 Distributed Object Architecture and CORBA ................................ ................................ 3 Co ncept and Features ................................ ................................ ................................ .. 4 CORBA Basics ................................ ................................ ................................ ........... 5 Advanced Transaction Model ................................ ................................ ......................... 6 A Road Map for Characterization of Transaction Models ................................ .......... 7 Comparison of T ransaction Models ................................ ................................ ............ 8 Correctness Criteria and Description of Dependency ................................ ................. 9 Efforts to Combine Different Transaction Models ................................ ................... 12 Transaction Service in CORBA ................................ ................................ ................ 15 Workflow System ................................ ................................ ................................ ......... 16 Workflow Basics ................................ ................................ ................................ ....... 16 Transactional Workflow ................................ ................................ ........................... 18 3 SYSTEM DESIGN AND BACKGROUND IN BUILDING CONSTRUCTION ......... 20 Overview of Integration Research for Building Construction ................................ ...... 20 Building Construction Workflow ................................ ................................ ................. 22 Modeling of the Construction Process ................................ ................................ ...... 22 Unique Requirements of the Building Construction Workflow System .................. 23 Defining a Workflow System for Building Construction ................................ ............. 24 Basic Construction Unit (BCU) ................................ ................................ ................ 24 Concurrency Control for BCU ................................ ................................ .................. 26 Objectives of the Research ................................ ................................ ............................ 27 Methodology ................................ ................................ ................................ ................. 27
vi Deliverables and Testing ................................ ................................ ............................... 28 4 CASE STUDY ................................ ................................ ................................ ................ 30 Description of t he Project ................................ ................................ ............................. 30 Basic Information ................................ ................................ ................................ ...... 30 System Setup for the Prototype ................................ ................................ ................. 31 Generic Activities ................................ ................................ ................................ ..... 33 Transaction Structure Design ................................ ................................ ........................ 34 Subtransactions ................................ ................................ ................................ ......... 35 Multitransactions ................................ ................................ ................................ ....... 38 M01: Architect proposed changes ................................ ................................ ......... 39 M02: The architect updates the product model ................................ ..................... 40 M03 Contractor proposed changes. ................................ ................................ ...... 41 M04 Owner requested changes ................................ ................................ ............. 42 Single step multitransactions ................................ ................................ ................ 42 5 SYSTEM IMPLEMENTATION ................................ ................................ .................... 44 Tech nical Issues ................................ ................................ ................................ ............ 44 Object Web and Distributed Technologies ................................ ............................... 44 Enable CORBA in Java: Java IDL ................................ ................................ ............ 45 Design of the Prototype ................................ ................................ ................................ 47 Description of S ites ................................ ................................ ................................ ... 47 Build the Sites with Packages ................................ ................................ ................... 49 Design of Shared Information Objects ................................ ................................ ..... 51 Locks and Rollbacks ................................ ................................ ................................ . 53 Transactions ................................ ................................ ................................ .................. 55 Definition and Execution ................................ ................................ .......................... 55 Modeling of Project Elements ................................ ................................ .................. 56 MTransaction, Step, and STransaction ................................ ................................ ..... 57 Testing ................................ ................................ ................................ ........................... 58 Time Factor s ................................ ................................ ................................ ............. 58 Performance ................................ ................................ ................................ .............. 60 Availability of Resource ................................ ................................ ........................... 61 Scalability ................................ ................................ ................................ .................. 62 Analysis and Discussions ................................ ................................ .............................. 63 6 CONCLUSIONS AND RECOMMENDATIONS ................................ ......................... 65 APPENDIX CLASS HIERARCHY FOR PACKAGES FOR THE PROTOTYPE ......... 67 REFERENCES ................................ ................................ ................................ .................. 70 BIOGRAPHICAL SKETCH ................................ ................................ ............................. 75
vii LIST OF TABLES Table Page 2 1 A Comparison of Transaction Models ................................ ................................ ............ 9 4 1 Computer Applications Used in the Construction Project ................................ .............. 32 4 2 Generic Activit ies for the Case Study ................................ ................................ ............. 33 4 3 Access to the Shared Resources ................................ ................................ ..................... 34 4 4 List of Subtransactions ................................ ................................ ................................ ... 35 4 5 List of Compensating Transactions ................................ ................................ ................. 37 4 6 List of Single Step Multitransactions ................................ ................................ ............. 43 5 1 Summaries of 5 Types of the Sites ................................ ................................ .................. 48 5 2 Java Packages for the Prototype ................................ ................................ ..................... 49 5 3 Locks Operations ................................ ................................ ................................ ............. 54 5 4 Physical Objects and Information Objects ................................ ................................ ...... 57 5 5 Step Object Types ................................ ................................ ................................ ............ 57 5 6 STransaction Object Types ................................ ................................ .............................. 58 5 7 Relative Execution Time of System Event s ................................ ................................ .... 59 5 8 Comparison of the Performance of ACID and ACTA (50% rejection) .......................... 60 5 9 Comparison of the Performance of ACID and ACTA (0% rejection) ............................ 61 5 10 Comparison of the Availability of Resource between ACID and ACTA ..................... 61 5 11 Scalability Test of the System ................................ ................................ ....................... 62
viii LIST OF FIGURES Figure Page 2 1 Road map for the study of transaction models ................................ ............................... 7 2 2 The transaction structure of a multitransaction ................................ .............................. 12 4 1 Setup of th e Basic Construction Unit (BCU) for the case study ................................ .... 32 4 2 Multitransaction M01 – the architect proposes a change ................................ ................ 39 4 3 Multitransaction M02 – the architect updates the product model ................................ ... 40 4 4 Multitransaction M03 – the contractor propose a change. ................................ .............. 41 4 5 Multitransaction M04 – owner requests changes. ................................ ........................... 42 5 1 CORBA programming in Java ................................ ................................ ....................... 46 5 2 Interactions between the sites ................................ ................................ ......................... 48 5 3 Setup of the prototype with packages ................................ ................................ .............. 50 5 4 Relations between locks and remote methods for the Building object. .......................... 52 5 5 Relations between locks and remote methods for the Catalogue object. ....................... 53 5 6 Definitions and execution of multitransactions. ................................ .............................. 55 5 7 The trend in execution time with increase of users ................................ ......................... 62
ix Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science IMPLEMENTATION OF AN ADVANCED TRANSACTIO N MODEL FOR AN INTEGRATED COMPUTING EN VIRONMENT FOR BUILDI NG CONSTRUCTION By Huanqing Lu May 2002 Chairman: Dr. Randy Chow Major Department: Computer and Information Science and Engineering This research is to solve the integration problem that is caused by the fragmentation of the c onstr uction industry . The participants in a construction project often encounter difficulties in communication and collaboration efforts because of the different computer systems that they are using. A solution that combines the benefits of process model an d product model is proposed. The system provides a distributed object space to facilitate the collaboration among the participants in the project. The construction industry has some unique features, such as the temporary nature of construction project orga nizations, the requirement of complex information entities like the buildings, and the human involvement in the decision making process. Because of these, an advanced transaction model with ACTA properties is used in the system instead of the traditional m odel with ACID properties. An
x ACTA transaction model allows the result of a transaction to be seen by concurrent transactions before committing. Compensating is required in the event of rollbacks. A prototype is built with Java and CORBA technology to com pare the ACTA model against the traditional transaction model. A generic construction project with 5 types of participants is used as a case study. Each site plays a role either as architect, owner, estimator, contractor or supplier. Shared information obj ects are maintained at the sites. Every site issues transactions according to their role and operations to interact with shared information objects. Tests are conducted to compare the performance and availability of resource between the advanced transacti on model and the traditional model. It shows that both the performance and availability of resource are improved because of the use of an advanced transaction model. However the benefits diminished with the increase of rollbacks of transactions. The scalab ility issues of the prototype are also studied. The scalability of the systems is closely related to the functionality of the shared information object.
1 CHAPTER 1 INTRODUCTION The initial motivation of this research is to solve the integration problem that has troubled the building construction industry for years. The c onstruction industry is extremely fragment ed b ecause of specialization. The participants in a co nstruction project, because of their different computer systems, often encounter difficulties in communication and extensive collaboration efforts. Methods based on the product model and the process model have been proposed but none of them have yet been able to provide a viable solution to the problem. An ideal solution is to combine the benefits of both the process model and the product model into such a system that provides a distributed object space and uses a transaction schema other than the traditio nal schema with ACID properties. Extensive research has been conducted regarding advanced transaction models [BUC92, ELM90, GAR90, MOS87, WEI92, ZHA94]. The most notable application of the advanced transaction model is workflow systems, which the proposed prototype system is able to support. The characteristics of the construction industry pose new challenges to the application of advanced transaction models. The organization s of construction projects are temporary and customized according to a specific p roject and will be dissolved after the completion of the construction project. A complex information object, the building, is the center of c onstant information exchange between participants in the project. More human involvements, such as decisions by the participants in the project, are required
2 than in a generic workflow system. The behaviors of the system under these conditions need to be studied. A prototype has been built using a generic construction project as a case study. The prototype is a CORBA compliant system with JTS (Java Transaction Service) capability. The purpose of the research is to compare the performance of the advanced transaction model against the traditional one and to address scalability issues of the prototype. Chapter 1 is a br ief introduction of the research. Chapter 2 reviews some critical technology for this research, including distributed object architecture, CORBA, Advanced Transaction Model, and workflow system. Chapter 3 shows the background, objectives, methodology, and deliverables of this research. Chapter 4 contains essential information for the simple construction project used in the case study and design of transactions. Chapter 5 describes the prototype and testing procedures as well as the discussions of testing re sult. Chapter 6 is the conclusion and recommendations.
3 CHAPTER 2 REVIEW OF RELATED WO RK This chapter reviews basic technologies related to this research, including distributed object architecture, CORBA, advanced transaction model, and workflow systems. The proposed integration system for construction is based on the d istributed object architecture with CORBA compliant implementations. The advanced transaction model is the basic component of the solution to the concurrency control problem for the complex business application of this kind. The workflow management system becomes relevant because the proposed system has the potential to support a full fledged implementation in the workflow system format. Distributed Object Architecture and CORBA The concept of distributed computing is widely used in operating systems, dat abase management and complex applications. Distributed computing system is an infrastructure technology required by the extension of computing from single machine to network, distribution of resources, and increase of complexity in business applications. A t a time of constant changes, it is important to define a system with good architectural principles. In general, the architecture of a distributed system should support [BAL00, p. 2] t he types of abstraction necessary to model the business (real world) i nteroperability to handle a diversity of machines and systems. s calability to allow different amounts of throughput.
4 e xtensibility to support future enhancements. c omponent based implementation so that new components can be added and existing components can be reused. Concept and Features Distributed systems, which is basically a two tier system with the client as the first tier and the server (database) as the second tier, first appeared as the client/server architecture in the 1980's. Later on multi tiered systems were introduced by separating the user interface from application logic and persistent data service. A distributed object is the product of bringing the object oriented paradigm into a distributed system. The basic features of an object ori ented system, which are inheritance, encapsulation, and polymorphism, make it a natural way to build a distributed system. Distributed objects include not only databases but also other types of application. In some cases the relations between distributed o bjects expand from client/server to peer to peer. The Distributed Object Management (DOM) system is proposed based on the study of various schemes. According to Buchmann et al. [BUC92, p.124]: A DOM system creates an environment in which complete appli cations can be developed in what appears to be a homogeneous, distributed object system, in which all objects are expressed in a common object model, even though some of the objects actually represent data and functionality of attached heterogeneous system s. In its role of integrator, DOM ensures that the attached systems retain a high degree of autonomy by maintaining their behavior and their local control. The description of the DOM system is the starting point of a study about transactions and interacti ons between distributed objects [BER96, BER99a, BER99b, BER00, BUC92, GEO94, GEO95, GEO96]. Objects in such a system may represent both
5 transactional systems like databases, and transactionless systems such as word processing applications. The involvement of non database application brings challenges to the transaction schemas designed for the concurrency and consistency control of the system. These studies lead to the establishment of CORBA as a factual industry standard for distributed computing [BEN94]. CORBA Basics The Common Object Request Broker Architecture (CORBA) is an open standard supported by the software industry to provide infrastructure in support of distributed systems. CORBA provides commercially viable technology, cross platform capability and vender independent specifications for the software industry. The first CORBA version 1.0 was released in Oct. 1991 by the Object Management Group (OMG), which is a consortium with about 800 companies as members [OMG01a], including both software vendor s ( IONA, Insprise, etc.) and users (Boeing, Motorola, Cisco, etc.). It was followed by CORBA version 2.0 in 1994 and then the forthcoming CORBA 3. CORBA delivers a clean, high level approach to implement distributed applications. The CORBA specification provides a relatively simple definition language called the interface definition language (IDL) to specify the interface for distributed objects, which allows for the changing of object implementation without affecting any clients. The Object Request Broke r (ORB) is a middleware defined by CORBA specification to enable and regulate interoperability between objects and applications. ORB, which acts like a software bus for object, represents a higher level of abstraction than sockets, RPC, and message passing . CORBA also provides standard services for
6 distributed object systems including name service, event service, transaction service, security service and trader service. CORBA does not provide an all in one solution for distributed object systems. The behav ior semantics of the distributed object cannot be described with IDL. The naming service is not interoperable between different systems. Objects can only be passed by value. A functionality of passing objects like the one in Java RMI is needed. The incomin g CORBA version 3 includes expansions regarding to some of these problems [OMG01b]. Advanced Transaction Model Advanced transaction models were motivated by complex applications like office automation, CAD/CAM and software engineering. The tasks in these systems are characterized by the following features: Long duration, could run for hours or even days Cooperative tasks Operate on heterogeneous systems It is no longer feasible to implement these tasks with the traditional transaction model. New transacti on models, which are referred to in general terms, as extended transaction model or advanced transaction model , are developed for these special tasks. Key features of these models include complex transaction structure non serializable correctness criter ion capability of running against both transactional and transactionless object
7 A Road Map for Characterization of Transaction Models Transaction models can be characterized by transaction structure, object structure on which the transactions operate, and correctness criterion. Figure 2 1 is a road map showing how a transaction model can be characterized. The transaction structure varies as a result of making extensions to the original transaction model. A flat transaction has a single start point and end point, and was studied extensively for database management system. A nested transaction may contain subtransactions which may recursively contain other subtransactions. Closed nestings are actually nested transactions with traditional transaction semantics [GRA96]. Open nestings relax the rule of isolation in ACID properties by making the effect of the transactions visible to other transactions running concurrently. Some transaction models try to cover both open nesting and close nesting and therefore are c alled combinations [ELM90]. Figure 2 1: Road map for the study of transaction models The object structure becomes relevant because complex applications for which advanced transaction models are designed often contain more than simple ob jects. An example of a simple object is a physical page in a database. Operations on a simple object Transaction Model Transaction Structure Flat Transaction Closed Nesting Open Nesting Combinations Object Structure Simple Objects Complex Objects A ctive Objects Correctness Criterion Serializability Non Serializability
8 do not consider the semantics of the object. Complex objects could encapsulate a set of objects and often have a set of inheritance relations with other ob jects. Sharing of state and/or behavior among objects may be involved. A transaction operating on one object may spawn additional transactions on component objects. An active object is able to respond to events by triggering actions for certain condition. Serializability is a common correctness criterion for database systems. Any non serializable correctness criterion, which is not as restrictive, leads to an advance transaction model. The correctness criterion issues will be discussed in further detail la ter in this Chapter. Comparison of Transaction Models Some notable works about advanced transaction models include, nested transactions [MOS87], sagas [GAR90], multi level transactions [WEI92], flexible transactions [ELM90, ZHA94], and multitransactions [BUC92]. The transaction structure, object structure and correctness criterion are three dimensions of the concept space of transaction models. Different transaction models can be described using the combinations of the values from these dimensions. For e xample, the original transaction concept uses flat transactions operating on simple objects and use serializability as correctness criterion. Sagas use open nesting transactions on simple object with non serializability as correctness criterion. Multitrans action goes to the other end of the spectrum, with combination transactions on active objects using non serializable correctness criterion. Table 2 1 is a comparison of the transaction models. The focus of this research will be open nested transactions wit h non serializable correctness criterion that operates on complex objects in an attempt to solve a specific engineering problem.
9 Table 2 1 A Comparison of Transaction Models Transaction Models Transaction Structure Object Structure Correctness Criterion Recovery Mechanisms Traditional Model Flat Transaction Simple Object Serializable Nested Transaction Closed Nesting Simple Object Serializable Multi level Transaction Open Nesting Simple Object Non serializable Commutativity Saga Open Nesting Sim ple Object Non serializable Log based Flexible Transaction Combinations Simple Object Non serializable Retry and Compensating Multitransaction Combinations Active Object Non serializable Compensating Transaction The basic logic about relaxing the ACID properties of transactions is, the semantic information about the transaction and its objects can be used to achieve a higher level of concurrency. Transactions are decomposed into smaller steps and non serializable correctness criteria are used. Some key research issues include, failure recovery, correctness and dependency issues, and partitioning and granularity of objects. Correctness Criteria and Description of Dependency Serializability is typical correctness criterion widely used in concurrency cont rol of database systems. To maintain the consistency, the execution history of concurrent transaction has to be equivalent to a serial execution. Two types of serializability, view serializability and conflict serializability, can be defined according to t he definition of equivalence of execution histories [BUC92]. There are also different ways to define a conflict. Commutativity means two operations conflict if the results of serial executions of these operations are not equivalent. This is a common type of serializability. Invalidation defines conflicts according to whether the execution of one invalidates another or not. Some other types of serializability such as recoverability are also defined [BAD92]. Non serializability is often discussed with advan ced transaction models. Most of the proposed models for non serializable correctness criterion relax the isolation property. If a transaction is allowed to reveal intermediate result or status to concurrent
10 transactions, compensation will be a complex mat ter if the transaction rolls back. Involvement of distributed objects make the situation even more complicated. Transaction models with non serializable correctness criterion often provide only a vague definition for compensation transaction therefore prov ide little clue about exactly how to handle this situation. Solutions could be found based on the analysis of how transactions affect on each other. A simple solution is to assign transactions into disjoint groups. The transaction from the same group may i nterleave arbitrarily while those from different groups cannot interleave at all. In the context of multidatabase, two classes of transactions are defined at the global and at the local level. An individual DBMS manages local transactions while global tran sactions are maintained by multidatabase software, which is also responsible to maintain the correctness of the transactions. Some studies have been done on dependencies between transactions [GEO96]. T wo types of transaction dependencies are defined. Tr ansaction state dependencies describe the conditions of execution between steps of a complex transaction. For example, we may have one complex transaction T with two steps T1, T2, backward commit begin (T2, T1) means T2 cannot begin before T1 commits. Many other types of relations can be defined as well according to the relations between steps. Transaction correctness dependencies specify concurrent executions of transactions that may preserve consistency and produce correct results therefore satisfy the c orrectness criterion. Studies have been done regarding serialization dependencies, visibility dependencies, cooperation dependencies, temporal dependencies [GEO96, FAR89].
11 Correctness dependencies may become application specific by reflecting application semantics. Combined use of correctness dependencies and state dependencies is sufficient to ensure certain types of correctness. Georgakopoulos et al. [GEO96] also provides a dependency descriptors which can be used to define almost all types of dependenc ies, ( ) Post En t T i , , , , , O t where Ti : a dependent transaction; t : the set of transactions that Ti depends on O: the set of objects the dependency must consider. En : the enabling condition specifies when the postcondition must be considered P ost : the post condition must evaluate to true to make the dependency satisfied. The specification of dependency can be used to monitor the correctness of execution of a complex transaction. At any given point during the execution of a complex transaction T, T's dependency descriptors must reveal whether the execution that took place until then satisfies T's dependencies. A transaction cannot proceed if a violation is detected. The evaluation of a dependency descriptor is a critical step for maintaining correctness of the system. It is important for the dependency descriptors to provide reliable results of the evaluation. The parameter En is introduced for this purpose. En is a Boolean value indicating the enable condition of the transaction. The postcon dition will be evaluated if En is false. For example, a dependency "T2 cannot begin before T1 commits" can be evaluated with the following specifications:
12 ( ) false En iff false post and true En iff true post and true En iff know t don violated satisfied Post En t T i = = = = = = O ' , , , , , t En is set to "T2.state = begin" to prevent the dependency descriptor from being evaluated (It is not known if En = false ). In this case there is not enough information to decide if the dependency is satisfied until T2 begins. Efforts to Combine Different Transaction Models Many efforts have been made to provide a unified defini tion for different advanced transaction models. Some of them have been successful in one aspect or another but a perfect solution has yet to be found. The followings are an overview of some methods, including DOM, ACTA framework, ASSET and CTM. DOM [BUC9 2] is a result of early studies on advanced transaction models. Multitransaction is defined as a concept of general transaction structure for flat transactions, nested transactions, sagas, flexible transactions, and multi level transactions. Figure 2 2: The transaction structure of a multitransaction Figure 2 2 is an illustration of a Multitransaction. Toptransaction is a closed nested transaction with complex transaction structure but it appears as an atomic transaction to peers. A Multitransaction is a combination of Toptransactions with global Multitransaction Toptransaction Contingency transaction Compensating transaction
13 transaction semantics but it permits partial results to be visible outside of a Multitransaction. In order to accommodate the requirement of saga, a compensating transaction is d esigned to undo already committed partial results in the situation when a Multitransaction has to roll back. For each member Toptransaction of a Multitransaction, a compensating transaction has to be defined. The concept of contingency transaction comes fr om the research on Flexible Transaction. It is executed if the primary transaction fails. Depending on the requirements of the application, the DOM transaction model may behave as a conventional flat transaction, a transaction model that allows for closed nesting and the execution, or combinations of closed and open nesting. DOM provides a good method in capturing transaction structure, however it does not address sufficiently the correctness criterion issues, which are critical to the success of an advanc ed transaction model. The ACTA framework [CHR90, CHR91, CHR94] is a tool to analyze and formally specify different transaction models. According to the research, the flexibility of a transaction model depends on the combinations of four notions [CHR91]: Visibility: the ability of a transaction to see the result of another transaction while executing Performance: the ability of a transaction to write to a database Recovery: the ability to keep the database in a correct state in case of failure Consistency: the correctness of the state of the database produced by a committed transaction.
14 The ACTA framework captures not only the interactions between transactions but also the effects of transactions on objects. Each object has a state and a status associated w ith it. The state is represented by the content of the object and the status contains synchronization information. Each transaction has a View Set containing the object set potentially visible to the transaction and an Access Set containing objects already accessed by the transaction. A transaction may transfer an object in its Access Set to another transaction via "delegation." The activity of delegation makes the state and partial results of the delegator become visible to the delegatee. ACTA framewo rk presents a simple way to define dependencies between transactions for the reasoning of the behaviors of transaction. Commit Dependency and Abort Dependency are known as completion dependencies. If Transaction A develops a commit dependency on Transactio n B, Transaction A cannot commit until Transaction B either commits or aborts. If Transaction A develops an Abort dependency on Transaction B, and if Transaction B aborts, Transaction A should also abort. ASSET [BIL94] is a flexible transaction facility ba sed on a set of transaction primitives. These primitives are designed according to the principle of ACTA, and can be used to define customized transaction models for specific applications. Many of the existing advanced transaction models can be specified w ith ASSET. It is also possible to use ASSET to specify activities or workflows that normally has transaction like properties. ASSET is actually an implementation of ACTA. Basic primitives in ASSET include, initiate(), begin(), commit(), wait(), abort(), s elf(), and parent(). Special primitives are setup for the functions of ACTA including
15 delegate(), permit(), and form_dependency(). These primitives can be used for the description and execution of transactions. As a research following DOM, CTM [GEO96] stu died the issues about application specific transaction model in the circumstances when distributed object system are involved. The primary value of CTM is to provide a framework about handling objects in heterogeneous, autonomous, and/or distributed (HAD) systems and a detailed descriptions and reasoning about correctness criteria. CTM provides facilities to ensure the correctness and reliability of distributed application by supporting customized transaction model according to the specific requirement of each application. CTM framework can handle not only transactional objects but also transactionless objects with no transactional support at the local systems. Transaction Service in CORBA The OMG specified the Object Transaction Service (OTS) to be the transaction monitor for distributed object systems. Commercial products are available for implementation of OTS for CORBA based system. Interfaces of all components in OTS are specified in IDL [GRA96]. The functionalities of transactions are provided by the interactions of three types of entities: transactional client, transactional objects, and recoverable objects. Transactional clients are user interface to applications that invoke operations on transactional objects as the originators of transactions. Transactional objects are entities that contain data subjected to change from transactions. Recoverable objects are also transactional objects but contain data that have already been changed by transactions. As the counterpart of transactional client, two types of application servers exist in a
16 distributed transaction system. Transactional server contains one or more transactional object. Recoverable server contains one or more recoverable object. The transactional capability of OTS is limited to nested transactions in the case when a failed subtransaction does not require rollback of the entire parent transaction [BAL00, p152]. Additional studies need to be done to provide support to complex applications with an advanced transaction model involved. The facility needs to consider the relation (dependency) between transactions in order to provide more functionality to handle rollbacks. A lower level service provided by OMG, Concurrency Control Service (CCS), will be helpful in this case. CCS provides me chanisms to implement and manage locks and helps to ensure the isolation property of transactions. CCS can be used to build customized transaction models. Workflow System The goal of this research is to provide a solution for a integrated system for buil ding construction where the interactions between construction activities can be coordinated with implementation based on the advanced transaction models. The study of advanced transaction models and dependencies between transactions could become the basis for the definition of workflow, and furthermore support a workflow system. Workflow Basics The initial idea of workflow comes from office automation and batch processing. Later on the technology evolved into a powerful paradigm for business process reengi neering, and produces implementations supported by information systems. Workflow management was described as "a technology supporting the reengineering of
17 business and information process" which involves everything from process modeling to synchronizing th e activities of information systems and humans [GEO95]. Many definitions for workflow have been given from different perspectives by Alonso et al [ALO97, DAS97, GEO95, KRI95, MIL96, RAN99]. Common features of these definitions for a workflow are a combi nation of multiple steps (tasks, activities), automated organizational process involving both human and automated tasks. dependency and cooperating relations between steps, and heterogeneous and distributed processing entities to operate on. Workflow mana gement can also be interpreted as a very high level programming language [ALO97] using autonomous, heterogeneous applications as basic instructions. Workflow Management System (WFMS) is a tool set supporting basic functions for workflow management such as process definition, execution facilities, and administration and management tools for users [DAS97]. Examples of WFMS include, Exotica [MOH95], RainMan [PAU97], ORBWork [DAS97], Mentor [WOD96] and C3DS [RAN99]. The Workflow Management Coalition (WfMC) is an industry wide consortium of workflow system vendors with more than 200 members. A reference model [WFM95] proposed by WfMC defines interfaces and a reference model for workflow systems in order to make different workflow systems interoperable. The WfMC reference model shows that the basic components for a workflow system are: process definition tools, administration and monitoring, workflow enactment service, and client applications.
18 Workflow related research efforts fills in three major categories, (1) Workflow specification and design, (2) inter task dependency and scheduling studies, and (3) workflow management system design and architecture. Many of these studies are closely related to the advanced transaction model. One of the major works about wor kflow specifications is transactional workflow, which is a combination of the concept of transaction and workflow (See next section for details). The study of dependencies between transactions in the advanced transaction models shares similar nature with t he study of inter task dependency for workflow systems. Many proposals for different architecture for workflow management systems have been made. Most of them feature distributed object oriented system for which the advance transaction model is a popular f acilities for concurrency control. The areas of interest for this research regarding workflow issues are workflow specification and dependencies between workflows. Transactional Workflow Workflow management is promoted by the industry using a process cen tric method and provides customized features for modeling and executing business procedures. Although commercial product for workflow management system are widely available, some apparent weakness of the workflow model still exist such as lack of theoretic al basis, limited support for concurrent workflow and correctness criteria, lack of interoperability, scalability and availability, and poor support for failure and exception handling [WOR97]. Transactional workflow represents an effort to solve some of th ese problems of the workflow systems by applying the concept of the advanced transaction model.
19 Transactional workflow gets the name from recognizing the relevance of transactions to workflow. Transactional workflow is defined as applying transaction conc ept to support activities that involved multiple tasks with different types and operate on different entities [SHE93]. Inter task dependencies are critical to the correct executions of the tasks. The basic idea is to apply the correctness criteria facilit ies developed for the advanced transaction model to the implementation of workflow. Transaction workflow does not support all ACID properties as a transaction with traditional definition does since transactional workflow is taking advantage of the advanced transaction model. This research will implement a concurrency control system following the concept of transactional workflow. Because of the involvement of a complex product model for buildings, further customization is needed for the existing systems.
20 CHAPTER 3 SYSTEM DESIGN AND BA CKGROUND IN BUILDING CONSTRUCTION This chapter shows the background, objectives, methodology, and deliverables of this research. This research originated from the integration requirement of the construction industry. A solution based o n a combination of the process model and the product model is proposed. This research targets implementation issues related to the development of such a system. A prototype is built to illustrate the solution. Overview of Integration Research for Buildin g Construction A trait of traditional construction industry is its fragmentation. Because of the magnitude and complexity of construction projects, a construction project is often divide d into work packages according to well established specialization. The work packages are assigned to different specialties. Although such a system brings significant benefits to the industry, it also results in difficulties in communication and maintaining extensive collaboration efforts among the participants in a construct ion project. This arrangement also l ead s to the diversity of computer software used on a construction project. These software packages have tremendous difficulties in exchanging information between each other although they are virtually handling the same physical object the building. Although commercial software packages are widely available for individual specialties, there is no industry standard about how to provide an integrated solution to the chaotic situation. What make s things worse is that the c onstruction industry has long been considered slow in its acceptance of new technolog ies [BRA97] in
21 comparison to manufacturing industry. It is extremely difficult to bring innovations to the current system. Efforts have been made to build models for cons truction projects and buildings in search for a solution for the integration dilemma. Two types of solutions have been proposed, a method based on the product model and a method based on the process model. Both are making progress but none of them can prov ide a viable solution by itself. A centralized object model for the building (product of a construction project) can be built so that information about the building can be stored in a consistent copy instead of the local databases maintained by different participants in the project. The Industry Foundation Classes (IFC) [WIX00] is a widely accepted industry standard for data structure and information exchange for construction projects. Prototypes based on IFC have been built in the form of product model s erver [HEM00]. A product model server for a building project shall contain all vital information about the project and provide a common platform for the collaboration between the participants in construction projects. Many research efforts have been made towards resolving the interface issues of the product model server. A system architecture for this type of implementation has also been defined [FRO00]. Process based methods have adopted the idea of process reengineering, which is also an initial moti vation for workflow systems. A complete process map for construction has been developed according to the practice of the construction industry in the United Kingdom [COO98]. The process map covers the entire lifecycle of a construction project from client briefing to facility management. Another type of research related to this is to
22 optimize the business processes of building construction according to predefined criteria [HAM01]. Both the product based method and the process based method fall short of pro viding a complete solution to the integration problem. Product based methods assume a static view of the buildings and projects. Any changes to the model will bring challenges to the system. Process based methods are suitable to define dynamic process, how ever, they do not address the issue of data management about the buildings. A construction project is a dynamic system with a complex information entity the building involved. A proper solution to the integration problem could not ignore any of these iss ues. Building Construction Workflow Intuitively, a solution that combines the benefits of both product model and process model would be the solution to the integration problem. A building construction workflow system with the consideration of an object mod el for the building is proposed in [LU02]. This research will address some critical issues related to the implementation of such a system. Modeling of the Construction Process The construction industry has long been familiar with process modeling. Traditi onally a work schedule has to be manually prepared for the construction project. The schedule contains a collection of activities representing the detailed construction processes. Nowadays it has been a common practice to use computer software to prepare the construction schedule. The activities are defined according to a model in which basic properties are included such as start and finish time, required resources, and dependency
23 between activities. The construction schedule, which is built as a process m odel for the project, serves as a tool for the contractor or the party who is responsible for project management and control. Therefore, it also has parameters for progress tracking such as current time, and so on but all the progress data has to be entere d into the system manually. The construction schedule is prepared for construction stage only while a complete process model for construction project should cover the entire lifecycle of a construction project. A process model like this could be used as a template to define a workflow system for building construction. The users of a construction workflow system include participants in the project from different business entities, who have different responsibilities and sometimes conflicting interests. The refore, the access coordination and concurrency issue s become critical to the success of a building construction workflow system. Unique Requirements of the Building Construction Workflow System Although commercial workflow system s are available with to ols for process definition, administration and monitoring, and workflow enactment service, a building construction workflow system brings unique requirements because of the features of construction industry as the followings, The organization s of construct ion project are temporary and customized according to a specific project. A complex information entity, the building, is the center of c onstant information exchange between participants in the project.
24 More human involvement is required than in a gener ic workflow system, such as office automation. The design of a workflow system for building construction has to take into account these issues . The feature of temporary organization requires a framework that enables flexible regrouping of different type s of business entities for new projects. A data model similar to the product model for buildings (IFC) has to be part of the system. The components of the system need to be customized to function with the product model. Constant human intervention means th at the system is at lower level of automation comparing to a generic workflow system. Many processes (workflow, activities) may run for long extended times. Defining a Workflow System for Building Construction A building construction workflow system w ill be built based on the modeling of the organization of a construction project. A complex building project can be decomposed into basic units according to the fundamental business relations on a construction project, which are represented by construction contracts. Business models for construction project can be built with the combinations of the basic units. Basic Construction Unit (BCU) The Basic Construction Unit (BCU) is a business model representing the primary contractual relation between particip ants in a construction project. BCUs can be used as components to construct an integrated model for the entire construction project. As the basic rules of engagement, construction contracts have many types defining different relations such as, owner arch itect, owner contractor, and general
25 contractor – subcontractor. Contracts define relations between two primary parties but often have more participants involved. This research will use a simplified situation to demonstrate the basic functionalities of BC U regarding to the coordination between participants and the maintenance of data integrity. BCU for owner contractor relation at construction stage will be used as a case to study in further details. Traditionally construction projects are divided into w orking packages at the construction stage. Different contractors are hired for these packages. The architect is responsible for coordinating and administrating the work of contractors. Basic business entities involved in a work package include owner, archi tect, and contractor. It is also possible that other participants in the project, such as suppliers, engineers, and estimators, are included in a BCU upon proper authorization. The entities involved in a BCU often use different types of computer applicat ions for their daily operation. For example, the architects may use AUTOCAD for design and modeling while the contractor may use MS Project for construction scheduling. The BCU should provide sufficient support for the portals based on user applications. Another basic component of the BCU is the product model of the building, which is the subject of a working package. The product model is initialized with the architects' design and contains critical information about the building and project, such as a obj ect model for the building, material requirements, cost information and so on. The Contractor will add new information to the model at the construction stage according to the actual execution of the project.
26 Concurrency Control for BCU The project partic ipants that are involved in the BCU are not simply users of the system, but part of the collaborative environment provided by the BCU. The participants in the BCU are possibly distributed because of the nature of construction industry. The BCU acts as a ru n time system during the execution of the construction project. The activities in the BCU represent complex business procedures with different business entities involved rather than simple tasks as defined in common construction schedule. As a member of th e BCU, the product model is shared and constantly updated by the activities initiated by the different project participants. A proper method is needed for the coordination of these activities and the concurrency control for the shared product model. Tradi tional transaction service has shown to be sufficient for common database systems [ELM92], however, that does not apply to the situation under discussion. Many activities of the BCU typically run for a long extended time and need to access heterogeneous da ta sources. Advanced transaction models are suitable for activities with these properties. Most of the existing advanced transaction models have limited description about the objects that the advanced transaction runs against. The objects are often d istinguished between transactional and transactionless entities. In the case of the BCU as defined above, the transactional model has to operate on a complex object model for the building. Further customizations need to be made to take advantage of this se mantic feature.
27 Objectives of the Research This research is part of the effort to develop an integrated environment for building construction that has the potential to become a workflow system with the consideration of an object model for the building. T he subject of this thesis is the implementation issue related to this general effort. The implementation of a workflow management system covers many issues such as user interface and system administration. However it is not the interest of this research t o build a full functioning workflow system. This research will concentrate on demonstrating that a customized advanced transaction model is a viable method for the concurrency control of the proposed system. Some other relevant workflow functionalities inc luding the process definition (workflow specification) for building construction and the design of a transaction service are discussed along with the development of the system proposed. Th e result of this research could be used as a basis for a full fledge d workflow system to support building construction activities. Methodology The basic idea is to build an advanced transaction system using basic CORBA services and to compare the system to a traditional transaction system. It is possible to use CORBA Tra nsaction Service (CTS) and Concurrency Control Service (CCS) as the basis for the traditional transaction system, which act as the control for this research. However, in this case we will have an advanced transaction system built from ground up and a trad itional transaction system built with higher level services. The accuracy of the comparison results may be compromised because of this. Therefore, a ground up method
28 using CORBA naming service and simple lock only will be used in both advance and tradition al transaction system. The execution of transactions will be demonstrated with a prototype built on a distributed platform with Java. CORBA compliant interfaces are implemented between the distributed objects of the prototype. The software packages of the participants in the project are represented with ORBs in the study. In the real world adaptors or wrappers between ORBs and software packages need to be developed. The product model server will be an independent application with an ORB interface administr ated by the architect. A simple construction project will be used for the case study. The Scenarios used are designed to show the generic operations of a construction project. A limited set of transaction will be developed according to the scenarios of th e case study. The prototype can be configured with different technical solutions and user requirements. P erformance and data consistency is tested for each configuration. Testing schema is used to evaluate the performance of the system as well as other par ameters. Details about the implementation will be discussed in Chapter 5. Deliverables and Testing The deliverables of the project is a COBRA compliant runtime system with a limited set of customized transactions and the analysis of testing results for different system configurations and user requirements. Three types of t esting are conducted: Performance: Performance of the system is compared between the traditional transaction model and the advanced transaction model. The same construction scenario s with rollbacks and concurrent transactions are used for both situations. The transactions
29 in the traditional transaction model are forced to execute sequentially because of their maintaining ACID properties. Concurrency will be allowed in the advanced tr ansaction model. Execution time will be used as a criterion for comparison purpose. Scalability: The initial scenario of the case study includes only a single contractor and supplier. Changes in the number of contractors and suppliers will have an impact on the operation of the system. The impacts are not necessarily negative. The increase in number of suppliers may reduce the occurrence of rollbacks because of the lack of availability. Response time and occurrence of rollbacks will be measured for differe nt numbers of users. Availability of resources: If a traditional transaction runs for longer time, the locks placed on a resource will prevent the access to the resource from other users (transactions). In this case, the concurrent transaction will either abort or wait because of the unavailability of the service. The number of occurrences of this situation will be counted as a measurement of performance improvement from implementing the advanced transaction model.
30 CHAPTER 4 CASE STUDY This chapter contains essential information for the simple construction project used in the case study. Transactions are designed according to the scenarios of the project for the testing purpose. Description of the Project The following assu mptions are made for the convenience of the case study: The project is at construction stage. Completed architectural design and engineering design is available. Participants in the project have sufficient capability to use computers for the project. Cons truction has started on the site. The product model is a viable method to represent the building. Basic Information The project is a simple building such as a single family home requires little technical specification. The architect is hired by the ow ner to administer the construction of the project and he/she has the authority to make many major decisions about the construction project. Contractors are hired to do the construction work. The estimator could be a functional unit of the architect or the owner. Because the work of the estimator
31 is independent in nature, the estimator is listed as a separate entity type in this case. Construction materials are either ordered by contractors or by the architect on behalf of the owner if special items are need ed. The organization of this project can be represented as a model of the BCU as described in Chapter 3. A prototype for the administration of the BCU is setup for the project. It is the responsibility of the architect to administer the prototype. The pr ototype is a middleware connecting the software systems of the participants in the project. Computer application s used by the p articipants in the project for their works are autonomous entities . The product model is a unique entity in the system that conta ins shared project information. The prototype is designed to cope with events happening to the project during the construction and to maintain the product model as the portal of information exchange between the parties in the project. Examples of events that could happen in the project include Changes to the design by architects. Contractor applies for substitution of materials. Owner requests changes to the building. Contractor record the progress of the project. System Setup for the Prototype The sys tem is built as described in Chapter 3. Major components of the system include a product model for the building, shared resource listings from contractors, shared material listings from suppliers, and the CORBA environment that joints all these
32 together. T he p roduct m odel contains a few IFC compliant Java objects representing the building. The advance transaction mechanism for the system is enforced using the locks associated with the shared objects. Figure 4 1 shows the setup of the BCU for this case study . The system is implemented with Java IDL [SUN01], which is the facility to add CORBA capability to the Java platform. Figure 4 1: Setup of the Basic Construction Unit (BCU) for the case study Behind the ORBs there are autonomous softwa re systems for each participant in the project. Table 4 1 shows a list of applications used by construction professionals. These systems "talk" to each other via the setup shown above. Table 4 1 Computer Applications Used in the Construction Project Part icipants Software Owner Application for project administrations Architect AUTOCAD, design tools, 3D modeling Estimator Cost estimating Supplier Assume the databases of suppliers have a public interface for browsing Contractor Scheduling, and cost est imating and control. Owner ORB ORB Contractor Resource Listing Estimator ORB Architect Product Model ORB ORB Supplier Material Listing CORBA Services
33 Generic Activities Generic activities on a construction project are smaller units of actions than the events such as changes to the design by the architect and can be acquired by decomposing generic events. For this case study, gene ric activities are defined with consideration of data accessing. A list of generic activities that are relevant to this case study is shown in Table 4 2. Table 4 2 is not intended to show a complete list of generic activities for a real life construction project. An effort to make such a list could be another research project. The list in Table 4 2 contains only the activities that are necessary to support enough multitransactions so that meaningful testing result can be obtained. Detail explanations for t hese activities can be found in the next section. An event can be defined as a complex task consisting of generic activities. The events are the basis for the definitions of multitransactions. Table 4 2 Generic Activities for the Case Study Initiator Activ ity Architect Pre update product model Architect Update product model Architect Review product model Architect Reserve contractor's resource Architect Reserve supplier's material Contractor Read in product information Contractor Update product model Contractor Reserve supplier's material Contractor Update public resource list Supplier Update public material list Owner Review progress of the project Owner Make a note at a certain part of product model Estimator Read in product information Estim ator Update product model
34 Transaction Structure Design Transactions are designed as part of the prototype for all events that can possibly happen to the project. Subtransactions are used to represent each generic activity. Multitransactions are composed of subtransactions just as events are combinations of generic activities. Because of the possible rollback of multitransactions, compensating transactions are needed for subtransactions that have altered the state of the shared resource. The operation s of the system are generally event based. When a certain type of event occurs, the corresponding multitransaction will be dispatched in the system. The multitransaction will read or modify the shared resources. If a multitransaction could not successfully execute, compensating transactions will be used to eliminate the effects of the partially executed multitransaction. This research will address the situation when more than one multitransaction is running concurrently in the system. The behaviors of the multitransactions will be decided by the dependencies between the subtransactions within the executing multitransactions. Different schedule of multitransactions will be arranged to test different aspects of the system according to the principles set in th e last chapter. Table 4 3 Access to the Shared Resources Users Product Model Material Catalogue Resource Catalogue Architect Read, Write Read, Write Read, Write Contractor Read, Write Read, Write Write Owner Read, Write NA NA Estimator Read, Write NA NA Supplier NA Write NA
35 Subtransactions Subtransactions are the basic units that run against the shared resources, which include, the product model, material lists of suppliers, and resource lists of contractors, as shown in Table 4 3. The product mod el stores critical information about the project, which could be from architect, estimator or contractor. The read only users of product model are owner, estimator, architect, and contractor for various reasons. Suppliers publish lists of the materials tha t are available so that the users (architect and contractor) can check for the availability of construction materials and make reservations. Contractors could be able to publish the availability of their extra resources such as labor, tools, and equipment. The architect will use the resource information for the planning of the project. Subtransactions and activities are defined in a way that each of them can access at most one shared resource. This arrangement will make it easier to analyze the relations b etween subtransactions, which are the basis of the advanced transaction model (ACTA framework as in this case). There might be a granularity issue for a system to be used in a real world construction project. Table 4 4 shows a list of subtransactions desig ned for the prototype. Table 4 4 List of Subtransactions Code Description Initiator P00 Read in product model information Architect, Contractor, Estimator, Owner P01 Pre update of product model Architect, Contractor P02 Final update of product mode l Architect, Contractor P03 Direct update of product model Contractor, Estimator P04 Mark the product model Owner, Contractor R00 Reserve resource Architect R01 Update resource list Contractor S00 Reserve materials Architect, Contractor S01 Update ma terials list Supplier
36 The users that are capable of performing a read operation against the product model (P00) are the architect, contractor, estimator, and the owner. It is the way that contractors and estimators get updates of project information. The owner needs to review the status of the project from time to time. The architect also needs read the product model because either owner or contractor may insert marks into the current product model as references in their reports or requests. Updating of the product model by the architect is a critical process that may change many aspects of the information about the building. Therefore, it has to be done with caution. P01 and P02 are the facilities designed for this purpose. Both the architect and the co ntractor are allowed to use these two subtransactions. Submitting the execution or computation results to the product model is part of daily routine of the contractors and estimators, and does not require a negotiation process. Therefore a direct update ( P03) is used for this purpose. The other operation on the product model includes inserting notes to the model (P04). The architect is the only user of the contractor's resource list that makes reservations from the list (R00). The architect needs this i nformation for additional project planning. Contractors need to update their resource lists from time to time. Both the architect and the contractor may make reservation of materials from the supplier's lists (S00). Suppliers have the least involvement wit h the project. The only operation by the supplier is to update their material lists. To make sure the transaction model works, it is required that compensating transactions are prepared for any subtransaction that modifies the shared resource. In any eve nt if a multitransaction is aborted, a compensating transaction will be executed for
37 each subtransaction to rollback any modification that has been made to the shared resources. Table 4 5 shows a list of compensating transactions for this purpose. The com pensating transactions are designed according to the behaviors of individual subtransactions. P00 is a read only subtransaction therefore no compensating transaction is necessary. P01 is a step before any stable change to the product model is made by the architect. A temporary copy of the design will be transferred to the product model and the affected portion on the permanent product model will be marked with a flag. The compensating transaction (P01C) needs to remove the temporary copy of design informat ion and the associated flag. Because P02 is protected by P01 and will always be the last step in a multi transaction, no compensating transaction is required for it. Table 4 5 List of Compensating Transactions Code Descriptions P00C NA P01C Remove tempor ary copy of the changes and marks on the product model P02C NA P03C NA P04C Remove marks R00C Cancel reservation of contractor's resource R01C NA S00C Cancel reservation of supplier's materials S01C NA The direct updates made by contractors and estimators are standalone operations that have no interaction with other steps, therefore, no compensation is needed for them. The owner is able to insert flags in the product model with subtransaction P04 just like the architect is able to. The compensat ing transaction (P04C) is used to simply remove the flags. R00 through S01 handle the subtransactions on the local data source of contractors and suppliers. R00C cancels the reservation for contractor's resources placed
38 by the architect. S00C cancels the r eservation of the supplier's materials placed by architect or contractors. Multitransactions Multitransactions are compositions of subtransactions described in the last section. The successful execution of a multitransaction depends on the status of the s hared resources as well as the decision of the participants. For example, if the multitransaction needs to locate a certain material in the databases of suppliers and the material is not available, the multitransaction will fail. A failed multitransaction results in rollbacks of its subtransactions with compensating transactions. If all subtransactions can be executed immediately, the multitransaction would be completed in relatively short time, which will make the problem being studied by this transactio n model trivial. However, human involvement makes multitransactions for building construction run longer than normal transactions. Some of the steps of multitransactions need decisions from the participants in the project. An example of this situation is, a change to the project proposed by architect needs approval from the owner to proceed. Additional steps other than subtransactions are needed for the execution of multitransactions. These steps represent messaging or logic computation and do not have any interaction with shared resources. Therefore, they do not have the features of a transaction. Question and answer blocks are a pair of messaging steps for the negotiation process between participants in the project. The question block sends information t o a designated destination and gets an answer back in an answer block. Checkpoints are set for certain stages of the multitransactions to trigger abort if needed. Logic "OR" and "AND" are used in the composition of multitransactions. The following
39 are mul titransactions designed for the events that could occurs on a building construction project. M01: Architect proposed changes The purpose of this transaction is to check if there is enough resource for changes proposed by the architect. The architect nee ds to check the availability of critical materials from suppliers and the availability of labor and equipments from the contractor. If all conditions for the changes are met, a request will be sent to the owner for approval (Q). The architect will proceed to the design stage upon approval from the owner. Figure 4 2 shows the details of multitransaction M01. Figure 4 2: Multitransaction M01 – the architect proposes a change Alternative transactions are prepared for subtransactions that check the contractor's resources and the supplier's materials as well as the one that inserts flags into the product model (P04). It is assumed that the resource and materials could be obtained from different sources. If the first attempt to get resource or materia l from a certain contractor or supplier fails, another attempt will be made towards another contractor or supplier. Checkpoints are set for the first two stages because failure of either of them will Sta rt R00C' R00C R00 R00' N Y Abort S00C' S00C S00 S00' N Y Abort Design Starts N Y Abort Check Contractor's Resource Check Supplier's Materials Owner's Review Uploading Q P04 A P04C Alternative Transaction Subtran saction Compensating Transaction Q Question Block Checkpoint A Answer Block Logic "OR"
40 result in rollback of the entire multitransaction. Anoth er cause of rollback is the disapproval of the owner. M02: The architect updates the product model The architect may submit the new design information to the product model following an appropriate procedure. For example, after execution of M01 and the desi gn for the changes are finished, the architect needs to update the product model with the new design. However, the design is not considered acceptable to the product model without checking with the other participants in the project, especially with the own er for their approval and the contractors for their constructability review. The architect needs to send a temporary copy of the new design to the product model. The new information will be an integral part of the model with flags indicating that the decision regarding to this part of the building is pending. The joint review stage includes three subtransactions running concurrently. The concurrency is allowed because no correlation exists between the review processes by different participants in the p roject and no write operation will occur. Figure 4 3 shows the details of Multitransaction M02. Figure 4 3: Multitransaction M02 – the architect updates the product model P01C P01 Y N Abort P02 O: Q A C: Q A E: Q A Submitting Joint Review Committing Previous Activities Design Start M01 Other Multitra nsaction Subtransaction Compensating Transaction Q Question Block Checkpoint A Answer Block Logic "AND"
41 M03 Contractor proposed changes. The contractor does not have the autho rity to make direct changes to the building. However, contractor may suggest changes under special circumstances. For example, sometimes the original design or plan for the building construction is no longer viable, e.g., a certain material specified by th e architect is no longer available. In this case, the contractor may report the problem to architect and suggest a substitution to the original material. Because some of the situations where the contractor needs to suggest a change can be much more compli cated than the example above, contractor needs to use the product model to describe the changes as well as their possible impact on the project, such as the delay of completion of a certain portion of the building. Temporary modifications will be made to t he product model which will be made permanent upon the architect's approval. If the architect considers it necessary to make sure that the change is acceptable to all participants in the project, the architect may initiate the multitransaction M02 on behal f of the contractor. Figure 4 4 shows the detailed procedures for M03. Figure 4 4: Multitransaction M03 – the contractor propose a change. Start P01C P01 Y N Abort M02 A: Q A P02 Submitting Architect's Review Committing Follow ups Other Multitra nsaction Subtransaction Compensating Transaction Q Question Block Checkpoint A Answer Block
42 M04 Owner requested changes Sometimes after reviewing the current condition of the project with presenta tions based on product model, the owner decides to make changes to the original design of the building or project planning. It could be expedition or changes of a certain part of the building. Figure 4 5: Multitransaction M04 – owner requests change s. The owner needs to make reference to the product model in the description of changes desired and send a request to the architect. If the architect considers the request viable and appropriate, multitransaction M02 will run against the product model aft er some necessary procedures. For example, if the owner is asking for an extension to the building, the design has to be finished by the architect before initiating M02. Single step multitransactions Some events do not access multiple data sources, which m eans these events often have only one step accessing one shared data. Although there is no semantic difference between a transaction for these events and a traditional transaction, these processes have to interleave with other complex multitransactions. To maintain the simplicity of the model, these simple processes are also defined as multitransactions. Table 4 6 shows a list of single step multitransactions. Other Multitransaction Su btransaction Compensating Transaction Q Question Block Checkpoint A Answer Block Submitting Architect's Review Follow ups Start P04C P04 Y N Abort M02 A: Q A Design
43 Table 4 6 List of Single Step Multitransactions CODE Descriptions Subs M05 Contractor reserve ma terials S00 M06 Contractor, estimator records real time progress of the project into product model. P03 M07 Owner, contractor, estimator read in product information P00 M08 Contractors update their resource catalogues. R01 M09 Suppliers update their m aterial catalogue. S01 Because the events represented by these multitransactions occur more frequently than complex multitransactions (M01 M04), a large percentage of the multitransaction will be of the single step type. The combinations of different mul titransactions, which will be discussed in Chapter 6, will determine the runtime requirement of the prototype. .
44 CHAPTER 5 SYSTEM IMPLEMENTATIO N This chapter will start with some technical issues regarding to the implementation of the system. Details of the prototype are provided, such as the arrangement and structure of the site, definition and execution of transactions, and so on. Tests are performed according to the criteria set forth in the last section of the Chapter 3. The testing result will be analyzed and discussed. Technical Issues Some technical issues related to the implementation of the prototype need to be discu ssed. Object web and distributed technologies provide the broad technical background for this research. The entire system is programmed with Java and CORBA enabled with Java IDL. Java and CORBA are a pair of technologies that are complementary to each othe r. Object Web and Distributed Technologies The evolution of the web starts with URL based web servers, which work as media to publish and broadcasting static files. The primary facility of the web is the HTTP server that serves documents in a client/ server fashion. CGI is the first technology that has been introduced to provide interactive features to the web. Later on, many other technologies, such as, scripts, DHTML, cookies, ASPs, servlets, and JSPs, have been developed to provide interactive funct ionalities to the web pages. One of the major flaws of this solution is the statelessness of the HTTP server, which maintains a loosely
45 constructed connection between client and server. The above mentioned technologies provide only patches to the URL based system. For example, cookies are used to store the state of client and passed to server during a connection. The concept of object web was introduced to provide a better solution with CORBA as the central piece of the jigsaw. Object web is considere d the next wave of Internet innovation [ORF97]. The future web shall include not only simple file servers but also functionalities with business objects involved. An object web should be able to deal with complex activities such as multi step business to b usiness and consumer to business transactions. Enable CORBA in Java: Java IDL CORBA and Java are a pair of technologies that are complementary to each other. CORBA is a comprehensive distributed object platform designed to work across the boundaries of ne tworks, languages, and operating systems. Java is not just another language that is able to work with CORBA. Java is actually a "portable operating system" that provides mobile code for running objects. It provides to CORBA a simple system to design and di stribute client/server applications. The build in features of Java, such as multithreading, garbage collection, and exception management, make it easier to build robust distributed objects. On the other hand, CORBA extends the capability of Java with distr ibuted services such as distributed introspection, dynamic discovery, transactions and naming. A basic idea of CORBA is to make a distributed object available for remote invocations, which is the same purpose of Remote Procedure Call ( RPCs). However CORB A ORBs have different features with compared to RPCs. RPCs operates on remote methods which may not have data associated with it. ORBs are able to identify remote
46 objects other than procedures (methods). In other words, ORBs are based on a more complete Ob ject Oriented concept with more precise operations with compared to RPCs. Java 2 Platform provides facilities in support of CORBA. The process of CORBA programming in Java is similar to Java Remote Method Invocation (RMI). It starts with the definition of the interface of the remote object with IDL, the interface definition language of CORBA. The compilation of each interface in the IDL file with a compiler called idlj generates the five files as shown in Figure 5 1. Figure 5 1: CORBA programming in Java The CORBA object at the server side needs to implement the interface _**ImplBase.java. An instance of CORBA ORB is created first and then the remote object is initialized and registered with ORB, the object bus. The main fun ction of the ORB in this case is to provide root naming context so that the new remote object can be bind to the CORBA naming service. To make this work, a naming service server IDL File s for Remote Object xx.idl Compile with idlj (JDK 1.3) _xxImplBase.java Server Skeleton _xxStub.java Client Stub xx.java Remote Interface for Client xxHelper.java xxHolder.java use Implement xxHolder.java
47 (tnameserv, as in JDK 1.3) needs to be started before the starts of CORBA clie nt and server applications. The client application calls the remote object as if it is local with the help of the CORBA facility. The application also needs to get the root naming context by creating a CORBA ORB. The reference to the remote object can be obtained with the root naming context and the name that the server originally registers it as. After the application gets the reference to the remote object, the remote object can be accessed as if it were local. Design of the Pro totype The participants i n the projects are represented with sites in the prototype. The sites are java applications that run on different machines over a network. Predefined transaction sequences are executed on each individual site. According to the task specified in each transa ction, the sites access shared information objects at both local and remote locations. The information objects are initialized at sites according to the function of the site in real world. Transaction mechanisms are enforced at both local and global level. The entire prototype is developed on the Java 1.2 platform. Major components of the prototype are organized in Java packages. Description of Sites The java applications that represent the sites run concurrently and are coordinated with a transaction s ystem. Each site works both as server and client. The server side maintains shared objects and accepts requests from other sites. The client side submits request to the others according to the transaction required by the job. The interactions between the s ites are illustrated in Figure 5 2.
48 There are 5 types of sites representing the owner, architect, estimator, contractors, and suppliers respectively. Assume a project always has only one instance of owner, architect and estimator. The initial case has onl y one instance of contractor and supplier but more will be added for the scalability test. Figure 5 2: Interactions between the sites Not all sites have a server side, which provides shared information. The owner and the estimator do not offer an y shared information. Therefore they do not have a meaningful server site although a remote object is initialized in its place for messaging purposes only. Another difference between the sites is the authorization to issue certain type of multitransaction s. Sites can only use transactions that match with their functionalities. Table 5 1 summarizes the differences between the sites. The representation of the multitransactions is shown in Chapter 4. Table 5 1 Summaries of 5 Types of the Sites Role Remote Ob jects Valid MultiTransactions Owner M00, M04, M07 Architects Building M00, M01, M2 Estimator M00, M06, M07 Contractor Catalogue: Resource M00, M03, M05, M6, M07, M08 Supplier Catalogue: Material M00, M09 Request Request Register Register CORBA Naming Service Site 1 Server Side Shared Info Client Side Transactions Client Side Tr ansactions Site 2 Server Side Shared Info
49 An extra Multitransaction M00 is added t o the original list from Chapter 4. It represents a block of time that a site has to wait between transactions. Build the Sites with Packages Java packages and API are defined in support of the various functions from the definition of transaction to the i nitialization of the sites. The classes defined in packages can be reused for other project and it is possible to extend the prototype for complex cases. Table 5 2 shows basic information about the packages for this prototype. The details of each class are shown in the Java documentation of the prototype, which are included as the Appendix. Table 5 2 Java Packages for the Prototype Package Classes Notes com.hlu.client Client, CorbaAdaptor, Decorder, Dispatcher, Sentry, TransactionBuilder Components that provide client functionalities, such as assemble and dispatch transactions. com.hlu.corba.information BuildingIDL, CatIDL, OtherIDL, Definition of the CORBA interface for server side. com.hlu.corba.sentry SentryIDL The facility that receive the roll back information at client side com.hlu.information BuildingComponent, Material Resource, Message, ProjectInfo, Classes that model the real world information object in construction project. com.hlu.server ACIDLock, ACTALock, Building, Catalogue, Dummy, Lock, Server Server side facilities including two type of locks, remote objects, and the server com.hlu.starter Site, Starter, StarterFrame, StarterHelper The program that starts multiple instances of Sites including a GUI for windows com.hlu.tools Objec tMapper, RemoteObjectBuilder Convenient facility to convert local object to remote object and so on com.hlu.transaction MTransaction, Step, STransaction Basic blocks for the definition of transactions. com.hlu.util Num, Sys, SimpleReader, Writer System related utilities and some functions for String handling. Figure 5 3 shows how a site works and how the packages are used to build the site. The class com.hlu.starter.Starter calls runtime executions to starts multiple instance
50 of the class com.hlu.st arter.Site, which in turn a server (com.hlu.server.Server) and a client (com.hlu.client.Client) at each site. The server side is responsible for building a CORBA object containing shared project information and for registering the object with the CORBA nam ing service. Either ACID lock or ACTA lock is setup for the shared information source according to the parameter passed in. Figure 5 3: Setup of the prototype with packages The functionalities at the client side of this prototype are more com plex than those at the server side. Input to a client includes information about transaction sequence, the project, and the shared resource. A predefined transaction sequence is converted to transaction objects in the TransactionBuilder. The class ProjectI nfo contains the name of all sites in the system, the number of contractors and suppliers, and the initial information for the shared resource. The TransactionBuilder needs information from ProjectInfo so transaction object may contain location information from where the shared information Interrupt rollbacks Build sites with parameters register register com.hlu.starter.Starter Site 2 Site 3 Site 4 more request Site 1 CORBA Naming Service Build client with transaction sequence, project information Build server com.hlu.server.Server BuildingComponent or Material or Resource ACID or ACTA lock Site com.hlu.client.Client ProjectInfo TransactionBuilder CorbaAdaptor Dispatcher Sentry
51 can be found. Transactions represent activities that sometimes have new information associated with them. For example an update operation to the product model needs the updated information to be sent to the site where the product model is located. The ProjectInfo randomly generates the information of this kind for the transactions. Dispatcher takes in a transaction object and sends the requests step by step to the shared resources via the CorbaAdaptor, which is the applica tion at the lowest level of the system. Sentry is a remote object setup to receive rollback information from other sites. Information so received interrupts the progress of the dispatcher. The operations of dispatcher may resume only after taking certain measures. Design of Shared Information Objects The design of shared information objects are highly simplified because it is not the focus of this research. Only a minimum set of data is stored in the shared information resource. Locks are the primary comp onents of the system. Two sets of locks are designed to make sure the transactions are handled according to two sets of rules. A Building object maintains an array of BuildingComponents, which contain only a reference number and a description. The operati ons on the building object read or change the descriptions of the BuildingComponent, which is represent by an integer. The initial number of the BuildingComponents is given when initializing an instance of the Building class. Four BuildingComponents are us ed for this study. Remote methods are designed for the subtransactions from P00 to P04, as well as the compensating transactions and the messaging facility. These methods are the basis for the design of subtransaction set as described in Chapter 4.
52 It is possible to setup two types of locks ACIDLock and ACTALock for a Building object. ACIDLock treats a multitransaction as traditional transaction at the global level. ACTALock allows concurrent multitransactions to read the shared information while a multitr ansaction keeps a write lock on the Building object, which means ACTA rules apply instead of ACID. The relations between the remote method and the locks for the Building object are shown in Figure 5 4. It shows all possible routes that a multitransaction m ay run through a Building object. Any route always starts with calling lock() of the lock object and ends with unlock(). The details about how the lock works will be discussed in the next section. Figure 5 4: Relations b etween locks and remote methods for the Building object. The main function of the Catalogue objects is to allow Clients to place reservations for resources or materials. The Catalogue object automatically generates a reservation ID for each reservation and keeps track of the reservation. A reservation Lock(read) ReadComponent() (P00) Commit Rollback Lock(write) PreUpdate() (P01) FinalUpdate() (P02) UndoPreUpdate() (P01C) Unlock() Unlock() Commit Rollback Lock(write) MarkBlock() (P04) RemoveMark () (P04C) RemoveMark() (P04C) Unlock() Unlock() Lock(wri te) DirectUpdate() (P03) UnLock() TakeMessage() (M)
53 placed at an early stage of a multitransaction will be canceled in the event of rollback. The site that maintains the Catalogue object constantly updates the available amount of resources or materials with a r andom amount. The functions of Catalogue object are illustrated in Figure 5 5. Figure 5 5: Relations between locks and remote methods for the Catalogue object. The design of Catalogue class is kept as simple as possible. A Catalogue object keeps a listing of a single item with current available amount only. No price and no other complex information are involved in the function of the Catalogue object. Contractors use the Catalogue class to list their extra resources while t he suppliers use it to list their inventory. The Catalogue objects for the contractor and the supplier are differentiated by the role they play in the system. A remote object called Dummy is initialized at the owner and estimator sites to enable them to t ake in a message and to give a reply. Locks and Rollbacks For the convenience of programming, the following interface is used for both the class ACIDLock and the class ACTALock, Commit Rollback Lock(write) reserve() (R00, S00) saveReserve () cancelReserve() Unlock() Unlock() Lock(write) update() (R01, S01) UnLock() TakeMessage() (M)
54 public void lock(boolean write, String site, int m); public ReaderInfo[ ] unlock(); Table 5 3 Locks Operations Method ACIDLock ACTALock Lock Status Locked Not Locked Locked Not Locked lock(read) wait read register then read. read lock(write) Wait lock, then write wait lock, then write Unlock() remove the lock. remov e the lock The lock method works differently for read and write actions. The implementations of these two methods are also different in the classes ACIDLock and ACTALock. For lock(read) operation, there is no lock placed in any event. The lock method is used only to keep the consistency of interface. The details of these operations are shown in Table 5 3. The major difference between ACIDLock and ACTALock is the read operations. In the event of locked, ACTALock allows the read operation process and regi sters the information of the reader. If the current locking transaction terminates with a rollback, all recorded readers will be informed of the event. There are two types of causes of rollbacks. A major cause of rollback is the negative reply from messag es sent to the participant who is responsible for making the decision. It is often the decision of the owner that decides if the multitransaction will stand. Another cause comes from the reservation process. The reservation request to Catalogue object may return a " – 1" value because the resource or material is not available. If the reservation cannot be secured from any possible source, the multi transaction will have to rollback.
55 If the rollback occurs and the partial result has already been revealed to some readers, these readers have to be informed of the event. It will be up to the readers to decide what to do about the data. The program will simulate the process with a review method applied on each multitransaction executed after the "dirty" read. Tra nsactions This section explains the definition and execution of transactions in the system. Many of these are simply programming details. Definition and Execution The multitransactions are represented with code system. Only 10 multitransactions are def ined for the system, which makes the task of code design fairly simple. Number 0~9 are assigned to the available multitransactions. A sequence of multitransactions is simply an integer. The sequence is taken in from a command line while starting a site and then passed to the Client. The definitions of multitransaction follow the description in Chapter 4 and are coded in the class TransactionBuilder. Transaction objects are assembled piece by piece with objects such as Message, Step, and STransactions as d efined in package com.hlu.transaction. The Dispatcher object is responsible for interpreting the transaction objects and for initializing remote calls to other sites at the subtransaction level. Figure 5 6: Definitions and execution of multitransact ions. " com.hlu.transaction.* Activities T o other sites Transaction Object TransactionBuilder Dispatcher Sequence Code
56 The running of a multitransaction has three possible stages: execution, commit, and rollback. At the execution stage, a multitransaction is executed piece by piece with calls made to remote sites. The status and results of the execution are stored w ith transaction objects. The status is checked at each checkpoint and at the end of the execution. If the check result is positive, the transaction may continue or enter the commit stage. If the check result is negative, the rollback stage starts. Because the execution of a transaction often needs to acquire more than one lock, deadlock is a concern. Fortunately the limited set of multitransaction obtains resource following a fixed order, as in the Catalogue for contractors – the Catalogue for suppliers – Buil ding. S o the deadlock will not happen because circular wait is not possible in this case. Modeling of Project Elements The package com.hlu.information (see Appendix) defines objects that model entities and elements on a real world construction project. Tw o types of objects are involved, physical objects and information objects. The physical objects that include BuildingComponent, Resource, and Material are housekeeping entities of the project and are used by both the client and the server side. The only i nformation object is Message, which is the carrier of questions and answers from one site to another. Table 5 4 shows details about these objects. The content of shared resources and the subjects of transactions can be either physical or information object s. Because the details about a real construction project are not relevant to this research, the information carried with these objects is generated randomly.
57 Table 5 4 Physical Objects and Information Objects Object Shared Resource Transaction IDL Interfa ce BuildingComponent Building M01, M2, M3, M4, M6, M7 BuildingDetails Material Catalogue (Supplier) M01, M5, M9 Resource Catalogue (Contractor) M01, M8 Message all M01, M2, M3, M4 MessageCapsule Some of the objects listed are used as inputs and outputs of the remote methods. A corresponding class with IDL interface is needed for any of these objects. To keep the clear boundary between the packages, IDL interface enabled classes are placed under com.hlu.corba.information. A facility called Object Mapper is designed to convert normal objects to IDL interface enabled objects and vice versa. MTransaction, Step, and STransaction Multitransactions are constructed with 3 levels of classes, MTransaction, Step and STransaction. MTransaction is an object that contains definition of a multitransaction and keeps track of run time status of the multitransaction. MTransaction maintains an array of Steps, which contains subtransactions, concurrent and alternative structures and decision boxes. Different types o f Step objects are shown in Table 5 5. Table 5 5 Step Object Types Code Type Content C Concurrent An array of concurrent subtransaction A Alternative An array of alternative subtransaction S Single A subtransaction D Decision Box Decide if the executi on of this multitransaction should continue B Empty Block A step that make the multitransaction keep appropriate pace STransaction keeps all the information that is required for a subtransaction to get executed. Table 5 6 shows the comparison of conten ts between different types of
58 STransaction objects. Extra work is needed to make the set of subtransactions become expandable, possibly through a graphic interface. Table 5 6 STransaction Object Types Type S.code (String) S.sender (String) S.receiver (St ring) Content (Object) Compensation Result P00 "P00" A,C,E,O A BuildingComponent null BuildingComponent P01 "P01" A, C A BuildingComponent STransaction null P02 "P02" A, C A null null BuildingComponent P03 "P03" C, E A BuildingComponent null BuildingCo mponent P04 "P04" O, C A BuildingComponent STransaction null R00 "R00" A C Resource STransaction String (Reservation ID) R01 "R01" C C Resource null null S00 "S00" A, C S Material STransaction String (Reservation ID) S01 "S01" S S Material null null P01C "P01C" A A BuildingComponent null null P04C "P04C" O, C A BuildingComponent null null R00C "R00C" A C String (Reservation ID) null null S00C "S00C" A, C S String (Reservation ID) null null Msg "M" Any Any Message null Message Testing This sect ion shows the principles, procedure and results of tests conducted upon the prototype. Time Factors The execution time of each step of the transaction needs to be adjusted so that the system events may simulate the occurrence of events in the real world . The adjustments are made using Thread.sleep(). Table 5 7 shows the adjustments for various activities in the system.
59 Table 5 7 Relative Execution Time of System Events Period Items Factor Wait before dispatching 250 Initialization (Client.java) Wait before client exits 250 Empty Step in multitransaction 2 Interval between steps 3 Execution of Transaction (Dispatcher.java) Review rollbacks 8 Decision making time 15 Execution time at Server Side Other remote methods 1 These factors in Table 5 7 are decided hypothetically. They are reasonably in accord with the real world situation. To make a better version of this table, more research needs to be done in the building construction area. Time intervals are measured as the results of the testin g in order to test the performance, availability of the resources, and scalability of the system. The time from the start of a dispatching transaction to the end is measured as an indication of performance. The average waiting time of a waiting call is rec orded to show the availability of the resource. It is also used as the basis for scalability analysis. The tests will be performed with a fixed set of transaction sequences for both ACID lock and ACTA lock and the results will be compared to measure perfo rmance, the availability of resources, and the scalability of the system. As stated in the last section, the major cause of rollbacks is the rejection message. One example is, the owner may not agree to the changes suggested by the architect. The percenta ge of rejection has significant impact upon the running of the system. Less rollbacks favor the performance of the ACTA model. Two scenarios are considered for the testing, total acceptance and 50% rejection. In the first case, the server side always gives a yes answer to the question messages. It is still possible that rollbacks happen
60 because of the failure of reservation. In the second case, a random answer will be given at the server side on a 50 50 chance. Performance To measure the performance, star t the minimized set of sites that include one instance of the owner, architect, estimator, supplier, and contractor. The system runs 10 consecutive times for both ACID lock and ACTA lock. The average execution times of the entire execution sequence at each site are recorded. Table 5 8 and Table 5 9 is a summary of the results. Table 5 8 Comparison of the Performance of ACID and ACTA (50% rejection) Architect Contractor C00 Estimator Owner Supplier S00 Test ACID ACTA ACID ACTA ACID ACTA ACID ACTA ACID ACTA 1 324 296 316 335 308 288 322 393 315 299 2 379 394 345 338 240 307 266 248 235 355 3 444 364 366 449 228 338 262 252 340 296 4 442 334 299 258 221 199 357 233 383 324 5 375 336 256 227 243 208 329 388 314 296 6 404 288 327 310 238 268 320 240 333 2 80 7 323 349 244 276 234 213 276 244 302 298 8 433 353 356 288 252 127 349 339 323 333 9 339 312 282 246 251 454 293 319 345 316 10 306 295 293 371 284 290 310 347 353 232 Avg 3769 3321 3084 3098 2499 2692 3084 3003 3243 3029 STDEV 52.5 34.349 41.2 6 6.5 26.7 90.2 33.3 63.87 39 33.2 T 2.258399 0.0566 0.6492 0.3555 1.3213 A Student's t test [MCC79] is used to show the statistical significance of the difference between the two sets of data. For f = 18 and p<0.05, t = 2.101. For the 50% rejection rate, only the architect site shows significance of performance improvement (T>t). If the rejection rate dropped to 0%, the testing result show significant improvement in the performance.
61 Table 5 9 Comparison of the Performance of ACID and ACTA (0% rejection) Architect Contractor C00 Estimator Owner Supplier S00 Test ACID ACTA ACID ACTA ACID ACTA ACID ACTA ACID ACTA 1 435 389 272 246 256 237 347 254 317 306 2 515 411 442 290 293 240 368 231 277 344 3 438 370 330 259 321 236 331 228 359 302 4 464 370 316 259 229 237 260 228 355 301 5 407 378 326 260 256 237 396 228 318 302 6 417 370 288 244 243 236 298 254 318 301 7 431 370 332 260 264 237 382 228 336 301 8 374 372 324 263 255 239 362 230 317 304 9 463 425 326 246 258 237 315 255 330 304 10 484 373 3 24 247 286 239 331 255 355 306 Avg 4428 3828 3280 2574 2661 2375 3390 2391 3282 3071 STDEV 40.4 19.736 44.6 13.6 26.8 1.35 41 13.3 24.8 13.1 T 4.2219 4.7845 3.3764 7.3231 2.3795 Availability of Resource The data for this testing comes from the same ex periment as the performance test but from the server side. The response time of a remote site in the case of busy waiting is used as an indicator for the availability of resources. The details of the testing result are shown in Table 5 10. The testing resu lt showed in Table 16 are based on running the system 10 times for both ACID and ACTA locks at rejection rates of 0% and 50%. Table 5 10 Comparison of the Availability of Resource between ACID and ACTA ACID ACTA Total Busy Waits Average Time/Wait Total Time Total busy waits Average Time/Wait Total Time Site 0% 50% 0% 50% 0% 50% 0% 50% 0% 50% 0% 50% Architect 19 19 41 39 780 749 21 22 27.14 22.14 570 487 Owner 36 36 51.3 42.5 1845 1531 20 16 39 27 789 431 Estimator 32 34 59.3 51.1 1898 1738 30 23 54 41 1615 948 Contractor C00 47 46 39.4 36 1853 1654 45 38 25.49 21 1147 794 Supplier S00 15 17 63 57 947 964 14 14 53 50 739 695 It is found that in all 3 categories the response times are considerably higher for ACID lock than those for ACTA lock, esp ecially at the owner and contractor sites. This
62 is consistent with the nature of ACID and ACTA locks. However, the difference between 0% and 50% rejection are not as significant. Scalability The purpose of this test is to examine the functioning of each pa rt of the system while the number of participants (sites) increase. The number of suppliers' sites and contractors' sites are increased from 1 to 10. Measurements were taken to discover any potential scalability problem in the system. Table 5 11 Scalabil ity Test of the System Extra Sites Architect Owner Estimator Contractor (Average) Supplier (Average) 1 351 239 218 241 283 3 596 339 345 409 255 5 836 473 313 659 250 7 1051 608 721 853 257 9 1380 790 879 1114 235 This test targets the working condi tion of each site. The transaction model and rate of rollbacks are no longer an issue here. Therefore the system with ACTA model and 0% rejection rate are used as the subject for testing. The test results are shown in Table 5 11 and Figure 5 7. 0 200 400 600 800 1000 1200 1400 1600 1 3 5 7 9 Architect Owner Estimator Contractor (Average) Supplier (Average) Figure 5 7: The trend in execution time with increase of users
63 The results show that architect sites sustain the strongest impact from the increase of the number of contractors and suppliers while the suppliers received the least impac t. The influence of the increase upon other sites falls in between the degrees of impact of the architect site and the supplier sites. This observation shows that the impact is related to the nature of transactions issued by the sites. Sites that have clos er contact with the Building object have a higher level difficulty in proceeding. Analysis and Discussions The testing shows the improvement in performance of the ACTA model over the ACID model. However, the improvement tends to diminish with the increase of rollbacks in the system. There are two major factors that have an impact on the performance of the system, the readings between a transaction lock, and the rollbacks caused by this. If the read transactions are allowed to proceed, while other transacti ons are in a lock position, the total execution time will be decreased. However to assure the correct execution of all transactions, extra works (review processes), which are simulated with waits, are needed if any rollback happens. So excessive rollbacks will reduce the benefits of the ACTA model. The availability of resources is improved as a result of using the ACTA model. It is understandable because read operations are not blocked in the ACTA model. This may relieve the congestion situation that may e xist in the system, which is counted as an additional benefit of the ACTA model. The current system may exhibit serious problems with large increases in the number of users. The major effect of increasing users is an increase in the workload of
64 the shared building model. Other shared resources, such as the resource listings, increase along with the increase in the number of users.
65 CHAPTER 6 CONCLUSIONS AND RECO MMENDATIONS The initial motivation of this research is to solve the integration problem that comes from the fragmentation of the c onstruction industry . The solution proposed in this thesis is a combination of the process model and the product model. The system provides a distributed object space to facilitate the collaboration between the participants in the project. Because of some of the unique features of the construction industry, an advanced transaction model with ACTA properties i s used in the system instead of the traditional model with ACID properties. Such a system should provide better performance and functionality than the one with traditional transaction model. To compare the ACTA model against the traditional one, a prototy pe was built with Java and CORBA technology. A generic construction project with 5 types of participants is used as case study. Each participating site plays a role either as architect, owner, estimator, contractor or supplier. Shared information objects a re maintained at the server side of the participating sites. The client side of every site issues transactions to interact with shared information objects either at local or remote sites. Transactions are designed for each site according to their roles and operations. Tests are conducted to compare the performance and availability of resources between the advanced transaction model and the traditional model. It shows that both the performance and the availability of resources is improved because of the us e of the advanced transaction model. However the benefits diminished with the increase in rollbacks of transactions. The scalability issues of the prototype are also studied. The
66 scalability of the systems is closely related to the functionality of the sha red information object. Some future research efforts are needed to make improvement to the prototype. F urther tests can be made based on study of the parameters of the construction process. The current study randomly chose the frequencies of different mult itransactions used on each site. It is possible to find out the ratio of multitransactions in construction project by further research. Currently the prototype is built upon a closed set of multitransactions and subtransactions. Further study is needed t o identify more multitransactions and subtransactions for application in the broader range of a construction project. The prototype also needs an interface that will allow the user to define new multitransactions and subtransaction at runtime. Although it is possible to build new multitransactions by combining subtransactions, the prototype does not provide such kind of support. All transactions are coded in the program. The only way to add new transactions is to change the code. A new transaction definiti on interface will provide more flexibility to the system.
67 APPENDIX CLASS HIERARCHY FOR PACKAGES FOR THE PRO TOTYPE Package Hierarchies: com.hlu.client, com.hlu.corba.information, com.hlu.corba.sentry, com.hlu.gui, com.hlu.information, com.hlu.server, com.hlu.starter, com.hlu.tools, com.hlu.transaction, com.hlu.u til Class Hierarchy: class java.lang.Object class com.hlu.server. ACIDLock (implements com.hlu.server.Lock) class com.hlu.server. ACTALock (implements com.hlu.server.Lock) class com.hlu.information. BuildingComponent class com.hlu.corba.information. Buildin gDetails (implements org.omg.CORBA.portable.IDLEntity) class com.hlu.corba.information. BuildingDetailsHelper class com.hlu.corba.information. BuildingDetailsHolder (implements org.omg.CORBA.portable.Streamable) class com.hlu.corba.information. BuildingIDLH elper class com.hlu.corba.information. BuildingIDLHolder (implements org.omg.CORBA.portable.Streamable) class com.hlu.corba.information. CatIDLHelper class com.hlu.corba.information. CatIDLHolder (implements org.omg.CORBA.portable.Streamable) class com.hlu. client. Client class java.awt.Component (implements java.awt.image.ImageObserver, java.awt.MenuContainer, java.io.Serializable) o class java.awt.Container o class javax.swing.JComponent (implements java.io.Serializable) o class javax.swing.JPanel (implements j avax.accessibility.Accessible) o class com.hlu.gui. JLabelField o class java.awt.Panel (implements javax.accessibility.Accessible) o class com.hlu.gui. LabelField o class java.awt.Window (implements javax.accessibility.Accessible) o class java.awt.Frame (implements ja va.awt.MenuContainer) o class javax.swing.JFrame (implements javax.accessibility.Accessible, javax.swing.RootPaneContainer, javax.swing.WindowConstants) o class com.hlu.starter. StarterFrame class com.hlu.client. CorbaAdaptor class com.hlu.client. Decorder class com.hlu.client. Dispatcher class com.hlu.information. Material
68 class com.hlu.information. Message class com.hlu.corba.information. MessageCapsule (implements org.omg.CORBA.portable.IDLEntity) class com.hlu.corba.information. MessageCapsuleHelper class com.hlu. corba.information. MessageCapsuleHolder (implements org.omg.CORBA.portable.Streamable) class com.hlu.transaction. MTransaction class com.hlu.util. Num class org.omg.CORBA.portable.ObjectImpl (implements org.omg.CORBA.Object) o class com.hlu.corba.information. _ BuildingIDLImplBase (implements com.hlu.corba.information.BuildingIDL, org.omg.CORBA.portable.InvokeHandler) o class com.hlu.server. Building o class com.hlu.corba.information. _BuildingIDLStub (implements com.hlu.corba.information.BuildingIDL) o class com.hlu.cor ba.information. _CatIDLImplBase (implements com.hlu.corba.information.CatIDL, org.omg.CORBA.portable.InvokeHandler) o class com.hlu.server. Catalogue o class com.hlu.corba.information. _CatIDLStub (implements com.hlu.corba.information.CatIDL) o class com.hlu.corba. information. _OtherIDLImplBase (implements org.omg.CORBA.portable.InvokeHandler, com.hlu.corba.information.OtherIDL) o class com.hlu.server. Dummy o class com.hlu.corba.information. _OtherIDLStub (implements com.hlu.corba.information.OtherIDL) o class com.hlu.corba .sentry. _SentryIDLImplBase (implements org.omg.CORBA.portable.InvokeHandler, com.hlu.corba.sentry.SentryIDL) o class com.hlu.client. Sentry o class com.hlu.corba.sentry. _SentryIDLStub (implements com.hlu.corba.sentry.SentryIDL) class com.hlu.tools. ObjectMapper class com.hlu.corba.information. OtherIDLHelper class com.hlu.corba.information. OtherIDLHolder (implements org.omg.CORBA.portable.Streamable) class com.hlu.information. ProjectInfo class com.hlu.corba.information. ReaderInfo (implements org.omg.CORBA.portabl e.IDLEntity) class com.hlu.corba.information. ReaderInfoHelper class com.hlu.corba.information. ReaderInfoHolder (implements org.omg.CORBA.portable.Streamable) class com.hlu.corba.information. readersHelper class com.hlu.corba.information. readersHolder (imp lements org.omg.CORBA.portable.Streamable) class com.hlu.tools. remoteObjectBuilder class com.hlu.information. Resource class com.hlu.corba.sentry. SentryIDLHelper class com.hlu.corba.sentry. SentryIDLHolder (implements org.omg.CORBA.portable.Streamable) clas s com.hlu.util. SimpleReader class com.hlu.starter. Site class com.hlu.starter. Starter class com.hlu.starter. StarterHelper class com.hlu.transaction. Step class com.hlu.transaction. STransaction class com.hlu.util. Sys class java.lang.Thread (implements java.la ng.Runnable)
69 o class com.hlu.server. Server class com.hlu.client. TransactionBuilder class com.hlu.util. Writer Interface Hierarchy interface com.hlu.corba.information. BuildingIDLOperations interface com.hlu.corba.information. BuildingIDL (also extends org.o mg.CORBA.portable.IDLEntity, org.omg.CORBA.Object) interface com.hlu.corba.information. CatIDLOperations interface com.hlu.corba.information. CatIDL (also extends org.omg.CORBA.portable.IDLEntity, org.omg.CORBA.Object) interface com.hlu.server. Lock interf ace org.omg.CORBA.Object interface com.hlu.corba.information. BuildingIDL (also extends com.hlu.corba.information.BuildingIDLOperations, org.omg.CORBA.portable.IDLEntity) interface com.hlu.corba.information. CatIDL (also extends com.hlu.corba.information .CatIDLOperations, org.omg.CORBA.portable.IDLEntity) interface com.hlu.corba.information. OtherIDL (also extends org.omg.CORBA.portable.IDLEntity, com.hlu.corba.information.OtherIDLOperations) interface com.hlu.corba.sentry. SentryIDL (also extends org.omg .CORBA.portable.IDLEntity, com.hlu.corba.sentry.SentryIDLOperations) interface com.hlu.corba.information. OtherIDLOperations interface com.hlu.corba.information. OtherIDL (also extends org.omg.CORBA.portable.IDLEntity, org.omg.CORBA.Object) interface com. hlu.corba.sentry. SentryIDLOperations interface com.hlu.corba.sentry. SentryIDL (also extends org.omg.CORBA.portable.IDLEntity, org.omg.CORBA.Object) interface java.io.Serializable interface org.omg.CORBA.portable.IDLEntity o interface com.hlu.corba.inf ormation. BuildingIDL (also extends com.hlu.corba.information.BuildingIDLOperations, org.omg.CORBA.Object) o interface com.hlu.corba.information. CatIDL (also extends com.hlu.corba.information.CatIDLOperations, org.omg.CORBA.Object) o interface com.hlu.corba.i nformation. OtherIDL (also extends org.omg.CORBA.Object, com.hlu.corba.information.OtherIDLOperations) o interface com.hlu.corba.sentry. SentryIDL (also extends org.omg.CORBA.Object, com.hlu.corba.sentry.SentryIDLOperations)
70 REFERENCES [ALO97] G. Alonso, and C. Mohan. "Workflow Management Systems: the Next Generation of Distributed Processing Tools," Advanced Transaction Models and Architectures, S. Jajodia and L. Kerschberg, eds., pages 35 62, Kluwer Academic Publishers, Bo ston, 1997. [BAD92] B. R. Badrinath, and K. Ramamritham. "Semantics based Concurrency Control: Beyond Commutativity," ACM Transactions on Database Systems, 17(1):163 199, March 1992. [BAL00] H. Balen. Distributed Object Architecture with CORBA, Cambridg e University Press, Cambridge, UK, 2000. [BER96] A. J. Bernstein, and P. M. Lewis. "Transaction Decomposition Using Transaction Semantics," Distributed and Parallel Databases, 4(1):25 47, 1996. [BER99a] A. J. Bernstein, D. S. Gerstl and P. M. Lewis. "Conc urrency Control for Step decomposed Transactions," Information Systems, 24(8):673 698, December 1999. [BER99b] A. J. Bernstein, P. M. Lewis, S. Lu. "The Correct Execution of Transactions at Different Isolation Levels," Technical Report TR 99/22, SUNY at St ony Brook, 1999. [BER00] A. J. Bernstein, P. M. Lewis, and S. Lu. "Semantic Conditions for Correctness at Different Isolation Levels," Proceedings of the 16th International Conference on Data Engineering (ICDE'2000), pages 57 66, San Diego, Californi a, February 2000. [BIL94] A. Biliris, S. Dar, N. Gehani, H.V. Jagadish, and K. Ramamritham. "ASSET: A System for Supporting Extended Transactions," Proceedings of the ACM SIGMOD International Conference on Management of Data, pages 44 54, Minneapolis, Minnesota, May 1994. [BRA97] P. Brandon, and M. Betts. "Creating a Framework for IT in Construction," the Armathwaite Initiative, the Formation of a Global Construction IT Network, P.S. Brandon, and M. Betts, eds., Construct IT Centre of Excellence, Univ ersity of Salford, Anglija 1997.
71 [BUC92] A. Buchmann, M. T. Ozsu, M. Hornick, D. Georgakopoulos, and F. A. Manola. "A Transaction Model for Active Distributed Object Systems," Database Transaction Models for Advanced Applications, A. K. Elmagarmid, eds., pages 123 158, Morgan Kaufmann, San Mateo, California, 1992. [CHR90] P. Chrysanthis and K. Ramamritham. "ACTA: A Framework for Specifying and Reasoning about Transaction Structure and Behavior," Proceedings of ACM SIGMOD International Conference on Manage ment of Data, pages 194 203, Atlantic City, New Jersey, May 1990. [CHR91] P. Chrysanthis, K. Ramamritham. "A Unifying Framework for Transactions in Competitive and Cooperative Environments," IEEE Office and Knowledge Engineering, 4(1):3 22, February 1991. [CHR94] P. Chrysanthis and K. Ramamritham. "Synthesis of Extended Transaction Models Using ACTA," ACM Transactions on Database Systems, 19(3):450 491, 1994. [COO98] R. Cooper, M. Kagioglou, G. Aouad, J. Hinks, M. Sexton, and D. Sheath. "The Development o f a Generic Design and Construction Process," Proceedings of Product Data Technology Days 1998: 7th PDT Symposium, Building Research Establishment, Garston, Watford, UK, March 1998 [DAS97] S. Das, K. Kochut, J. Miller, A. Sheth, and D. Worah. "ORBWork: A R eliable Distributed CORBA based Workflow Enactment System for METEOR_2," Technical Report UGACS TR 97 001, Department of Computer Science, University of Georgia, February 1997. [ELM90] A. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. "A Multida tabase Transaction Model for Interbase," Proceedings of the 16th International Conference on Very Large Databases, pages 507 518, Brisbane, Australia, August 1990. [ELM92] A.K. Elmagarmid, (ed.), Database Transaction Models For Advanced Applications, Morga n Kaufmann, San Mateo, CA, March 1992. [FAR89] A. Farrag and T. Ozsu, "Using Semantic Knowledge of Transactions to Increase Concurrency," ACM Transaction on Database Systems, 14(4):503 525, December 1989. [FRO00] T. M. Froese, K. Yu, K. Liston, M. Fischer . "System Architectures for AEC Interoperability," Proceedings of Construction Information Technology 2000, pages 28 30, Reykjavik, Iceland, June 2000. [GEO94] D. Georgakopoulos and M. Hornick. "A Framework for Enforceable Specification of Extended Transa ction Models and Transactional
72 Workflows," International Journal of Intelligent and Cooperative Information Systems, 3(3): 599 617, September 1994. [GEO95] D. Georgakopoulos, M. Hornick and A. Sheth. "An Overview of Workflow Management: from Process Modelin g to Workflow Automation Infrastructure," Distributed and Parallel Databases, 3(2):119 153, April 1995. [GEO96] D. Georgakopoulos, M. F. Hornick, and F. Manola. "Customizing Transaction Models and Mechanisms in a Programmable Environment Supporting Reliabl e Workflow Automation," IEEE Transactions on Knowledge and Data Engineering, 8(4):630 649, August 1996. [GAR90] G. Molina, D. Gawlick, J. Klein, K. Kleissner, and K. Salem. "Coordinating Multi transaction Activities," Technical Report CS TR 247 90, Depart ment of Computer Science, Princeton University, February 1990. [GRA96] E. Grasso. "An Extended Transaction Service for Real time and Telecom Object Request Brokers," Proceedings of the 2 nd International Workshop on Distributed Object Oriented Computing, Frankfurt, Germany, November 1996. [HAM01] J. Hammer, S. Bai, J. P. Geunes, W. O'Brien, D. G. Conway, and R. R. Issa, "Theory and Methodologies to Support the Operation of Flexible Production Networks," research proposal, University of Florida, 2001. [HEM 00] T. Hemi. "XML based product model server," Proceedings of Product Data Technology Europe 2000: 9th PDT Symposium, European Space Research and Technology Centre (ESTEC), Noordwijk, The Netherlands, May, 2000. [KRI95] N. Krishnakumar, and A. Sheth. "Man aging Heterogeneous Multi system Tasks to Support Enterprise wide O perations," Distributed and Parallel Databases, 3(2):155 186, April 1995. [LU02] H. Lu. "Extended Production Integration for Construction (EPIC) An Integration System for Building Constru ction," PhD Dissertation, University of Florida, in preparation, 2002. [MCC79] J.T. McClave, and F.H. Dietrich, II.. Statistics, Dellen Publishing Co., San Francisco, 1979 [MIL96] J. A. Miller, A. Sheth, K. J. Kochut, and X. Wang. "CORBA based Run time Arc hitectures for Workflow Management S ystems," Journal of Database Management, 7(1):16 27, 1996. [MOH95] C. Mohan, G. Alonso, R. Gunthor, M. Kamath, and B. Reinwald. "An Overview of the Exotica Research Project on Workflow Management
73 Systems," Proceedings of the Sixth International High Performance Transaction Systems Workshop (HPTS), Asilomar, California, 1995. [MOS87] J. E. B. Moss. "Nested Transactions: an Introduction," Concurrency Control and Reliability in Distributed Systems, B. Bhargava, ed., pages 39 5 425. Van Nostrand Reinhold, New York, 1987. [OMG01a] Object Management Group (OMG), "About the Object Management Group (OMG)," 2001, http://www.omg.org/gettingstarted/gettingstartedindex.htm, January 1, 2002 verified. [OMG01b] Object Management Group (OMG), "What's Coming in CORBA 3," 2001, http://www.omg.org/technology/corba/corba3releaseinfo.htm , January 1, 2002 verified. [ORF97] R. Orfali, and D. Harkey. Client/Server Programming with Java and CORBA, second edition, John Wiley & Sons, New York, 199 7. [PAU97] S. Paul, E. Park and J. Chaar. "RainMan: a Workflow System for the Internet," Proceedings of USENIX Symposium on Internet Technologies and Systems, Monterey, California, November 1997. [RAN99] F. Ranno, S. Shrivastava. "A Review of Distributed Workflow Management Systems," C3DS Project, Newcastle University, UK, 1999. [SHE93] A. P. Sheth, and M. Rusinkiewicz. "On Transactional Workflows," IEEE Data Engineering Bulletin, Special Issue on Workflow Systems, 16(2):34 40, 1993. [SUN01] Sun Microsyst ems, Inc. "Java TM IDL", 2000, http://java.sun.com/j2se/1.3/docs/guide/idl/, January 1, 2002 verified. [WEI92] G. Weikum, H. J. Schek, "Concepts and Applications of Multilevel Transactions and Open Nested Transactions," Database Transaction Models for Ad vanced Applications, A.K. Elmagarmid, ed., pages 515 553, Morgan Kaufmann, San Mateo, California, 1992. [WIX00] J. Wix , and T. Liebich. "Industry Foundation Classes: Some Business Questions Examined," 2000, http://www.iai na.org/files/ECPPM 2 Business Ques tions.pdf, January 1, 2002 verified. [WOD96] D. Wodtke, J. Weissenfels, G. Weikum, and A. K . Dittrich. " The Mentor P roject: S teps t owards E nterprise w ide W orkflow M anagement ," Proc eedings o f the 12th IEEE Int ernational Conf erence o n Data Engineering, p ages 556 565, New Orleans, Mar ch 1996.
74 [WOR97] D. Worah and A. Sheth. "Transactions in Transactional Workflows," Advanced Transaction Models and Architectures, S. Jajodia and L. Kerschberg, eds., pages 3 34, Kluwer Academic Publishers, Boston, 1997. [ZHA94] A . Zhang, M. Nodine, B. Bhargava, and O. Bukhres. "Ensuring Relaxed Atomicity for Flexible Transactions in Multidatabase Systems," Proceedings of the ACM SIGMOD International Conference on Management of Data, pages 67 78, Minneapolis, May 1994.
75 BIOGRAPHICAL SKETCH Huanqing Lu was born in Heilongjiang, China. He received his bachelor's degree in civil engineering and master's degree in project management from Tianjin University, China. He is going to receive a master's degree in computer engineer ing from the University of Florida in May 2002. At the same time he is working on a Ph.D. degree in design, construction and planning. His research interests are integration research in building construction and transaction systems.