In Copyright - Non-Commercial Use Permitted Rights / License: … · 2020. 3. 26. · Object-oriented databases have gained popularity by supporting persistent data storage in mobile

Research Collection

Master Thesis

Event-based information sharing

Author(s): Lins, Christoph

Publication Date: 2009

Permanent Link: https://doi.org/10.3929/ethz-a-005779071

Rights / License: In Copyright - Non-Commercial Use Permitted

This page was generated automatically upon download from the ETH Zurich Research Collection. For moreinformation please consult the Terms of use.

ETH Library

https://doi.org/10.3929/ethz-a-005779071

http://rightsstatements.org/page/InC-NC/1.0/

https://www.research-collection.ethz.ch

https://www.research-collection.ethz.ch/terms-of-use

Event-based Information Sharing

Master Thesis

Christoph Lins<[email protected]>

Prof. Dr. Moira C. NorrieAlexandre de Spindler

Global Information Systems GroupInstitute of Information Systems

Department of Computer Science

22nd March 2009

Copyright© 2009 Global Information Systems Group.

iii

Our ultimate goal is extensible programming. By this, we meanthe construction of hierarchies of modules, each module adding newfunctionality to the system.

Niklaus Wirth

iv

Abstract

The ongoing miniaturization of electronics has brought us to the stage where most of us carrycomputing devices all the time. Their enhancement with wireless networking capabilitiesallows versatile communication among mobile users. The resulting ad-hoc nature of establi-shing direct network connections between personal mobile devices gives rise to opportunitiesand challenges for different modes of information sharing.This thesis identifies different modes of sharing and presents an implementation platformthat makes them available to developers. As a proof of concept, a showcase application hasbeen developed demonstrating the correctness of the implementation and the usefulness ofthe concepts.

v

vi

Contents

1 Introduction 11.1 Goals of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Related Work 52.1 Information Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Database Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Mobile Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Underlying Models and Systems 113.1 OM Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Type Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.2 Classification Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.3 Graphical notation and OML . . . . . . . . . . . . . . . . . . . . . . 123.1.4 Query Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 OM Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.1 OMS Avon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.2 OMS Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Unified Event Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.2 Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.3 Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3.4 Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Sharing Modes 254.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.1 Collection-based Sharing Model . . . . . . . . . . . . . . . . . . . . 27

5 Implementation 315.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.1.1 Avon Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2.1 Data Exchange Framework . . . . . . . . . . . . . . . . . . . . . . . 335.2.2 Object Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2.3 Conversation-based Data Exchange . . . . . . . . . . . . . . . . . . 415.2.4 Typing versus Classification . . . . . . . . . . . . . . . . . . . . . . . 42

vii

viii CONTENTS

5.3 Event Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3.1 Model Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3.2 Event Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3.3 Site Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.3.4 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4 Vicinity Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.4.1 Client Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.4.2 Server Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.5 Sharing Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.5.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.5.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 Showcase Application 636.1 Avonopolis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.1.1 Application Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.1.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.2 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.2.1 Persistent Synchronization . . . . . . . . . . . . . . . . . . . . . . . 666.2.2 Transient Synchronization . . . . . . . . . . . . . . . . . . . . . . . . 676.2.3 Persistent Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.2.4 Transient Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.2.5 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7 Conclusions 717.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.1.1 Sharing Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717.1.2 Implementation Platform . . . . . . . . . . . . . . . . . . . . . . . . 71

7.2 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

8 Future Work 738.1 Object Equality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738.2 Forced Conversation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738.3 Event System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748.4 OML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748.5 Vicinity Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748.6 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748.7 P2P Data Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

A Algorithms 77A.1 Serialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77A.2 Deserialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

A.2.1 Type Visitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79A.2.2 Value Visitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

B XML Schema 83B.1 Vicinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

1Introduction

The ability to share information easily and in a timely manner is an important requirementfor every business and cooperative working environment. Consequently, many mechanismsexist that are supporting Information Sharing, ranging from direct human-human interactionsto computer-based solutions.As portable devices have experienced a dramatic increase in processing power and storagecapacity, the average mobile device has the potential to store significant amounts of usefuldata and to run sophisticated applications. Additionally, with the evolution of wirelesscommunication technology, users are facing new opportunities and challenges in makingdirect connections with other users in order to share relevant information. The latter isespecially true, given the dynamic nature of potential interactions between typical mobileusers: resources can be shared opportunistically upon established network links. Theseconnections are likely to be short-lived as devices move out of range. The question arisesas to what happens to the data when the connection with an external source is closed. Towhat extent are activities on data such as the editing of particular information reflected byits former receivers, if at all? In light of such diversity, different modes of opportunisticinformation sharing can be identified.

The possibility to form ad-hoc workgroups and exchange data in a dynamic fashion can beexploited by developers in order to design novel classes of applications. We believe that aninformation system providing support for such advanced functionality can serve as an elegantand powerful implementation platform. It allows developers to focus on the applicationdomain model without having to consider the underlying mechanisms including informationsharing, data persistence and vicinity sensing.

Object-oriented databases have gained popularity by supporting persistent data storage inmobile and embedded applications. They can be used to manage various kinds of data. Inorder for a database instance to be able to propagate data to another instance, a protocolfor point-to-point data exchange needs to be established. Shortcomings can be found in the

1

2 1.1. GOALS OF THE THESIS

little support for proactive behavior. Proactive systems adhere to two premises. First, theywork on behalf of the user and second, they act on their own initiative. This feature turnsout to be necessary since the sharing process is triggered by the appearance of a device invicinity. Event-driven architecture (EDA) is an architectural software pattern that meets thisrequirement based on the production and consumption of events and their handling. Anapplication may cause a change in a database, which can signal an event that is of interestto other applications. Many mobile applications also require the possibility to trigger eventsfrom outside of the database. The reception of an event can result in a change in databasestate as well as in the execution of specified actions.

In this thesis, we extend an existing database technology to realize EDA. Furthermore, it isenhanced with communication capabilities to enable the exchange of information as well asvicinity awareness. A single platform that consolidates these functionalities enables develo-pers to take advantage of opportunistic information sharing along with its different modes.

1.1 Goals of the Thesis

The task of this project is to identify the different sharing modes in terms of connected da-tabase instances. Based on the investigated concepts, the goal is to design and implementmodular extensions for the OMS Avon [1] database in order to support these forms of connec-tivity and to provide developers a flexible way of using them according to their needs. Thefollowing results can be expected from this project:

• The exchange of data between database instances turns out to be the fundamental re-quirement for the success of the project as the final architecture relies heavily on thatfunctionality. Therefore, the design and implementation of a flexible and reliable low-level component that takes care of sending and receiving data is anticipated.

• Based on the reconditioning of a previous work on triggers, events and handlers, anevent system shall be integrated with the intention to proactively notify registered ob-servers about events that occur within the database, covering issues such as being noti-fied when a new user is in vicinity. Other projects that are currently under developmentas well as future work will depend on this module.

• Another module shall provide high-level primitives to support vicinity sensing. Its taskis to detect the appearing and disappearing of devices nearby.

• The final module is focused on the implementation of the different sharing modes. Inorder to provide the required functionality, it makes use of the components mentionedbefore.

• A showcase application should be developed as a proof of concept for the event-basedinformation sharing architecture. It should demonstrate the correctness of the imple-mentation and the usefulness of the concepts.

CHAPTER 1. INTRODUCTION 3

1.2 Specifications

Within the above mentioned directives the environment is predetermined including the follo-wing elements:

• Java SE 6 is used as the programming language.

• The communication utility shall rely on the transmission control protocol (TCP). Ta-king the previous point into consideration, this leads to Java sockets [4] that offer aninterface between an application process or thread and the TCP/IP protocol stack pro-vided by the operating system.

• OMS Avon acts as the object-oriented database management system featuring a corethat implements the concepts specified by the OM meta model. Everything developedin this thesis is designed as an extension to OMS Avon.

• The showcase and demonstrator application should offer a graphical user interface ba-sed on Swing, a widget toolkit for Java.

1.3 Document Structure

The remainder of this thesis is organized as follows: Chapter 2 starts with an overview of themain issues in the area of information sharing and migration. Insight into related work is pro-vided as well. Chapter 3 discusses the concepts and technologies that build the foundation forthis project. The OM data model and its corresponding implementation is described togetherwith the module-extension mechanism on which the developed system is based. Afterwards,a simplified version of the unified event model is introduced. In Chapter 4, we investigate thevarious kinds of sharing patterns that arise in the context of the mobile environment. Afterhaving covered the different sharing modes, our implementation approach is presented. Thedesign and implementation of the development platform is examined in Chapter 5. It includesthe component that handles data exchange between database instances as well as the remai-ning modules responsible for vicinity sensing, event handling and opportunistic informationsharing. The showcase application and its design are illustrated in Chapter 6. Concludingremarks and a brief discussion of research directions are given in Chapter 7 and Chapter 8respectively.

4 1.3. DOCUMENT STRUCTURE

2Related Work

This chapter covers the different aspects related to the term information sharing. We willconsider different points of view and provide insight into work that has been done in thefields of databases and mobile computing.

2.1 Information Sharing

As a result of the United States government’s lack of response to information known aboutplanned terrorist attacks, the term information sharing gained popularity. Various recom-mendations and efforts have been made with the intention of improving information sharingamong government entities at all levels. From a technical point of view, an attempt to imple-ment a one-to-one exchange model can be found in the National Information Exchange Mo-del (NIEM)1 whose mission statement is the bridging of information systems. Following thistheme, we will survey computer-supported information sharing in different research areas.

2.1.1 Database Challenges

Database systems are deployed to manage business-critical information and to make it acces-sible to clients. In the past, much of the work that has been done by the database research com-munity has focused on improving data storage, management and access. The emergent issueof information sharing has led to numerous tools that support (mainly relational) databaseswith communication facilities. For example, database administrators use extract-transform-load (ETL) tools such as Informatica’s PowerCenter2 and Sunopsis’ DataConductor3 for theextraction of operational data. After transforming the data against a common schema, theresult is loaded for subsequent querying. Similarly, data federation tools such as DB2 Infor-

1http://www.niem.gov2http://www.informatica.com/products services/powercenter3http://www.oracle.com/sunopsis/index.html

5

6 2.1. INFORMATION SHARING

mation Integrator4 and Informix Enterprise Gateway Manager5 integrate multiple databasesby setting them up as data sources for a global query federation engine. Nowadays, the In-ternet and the need to share information in real time with remote systems make these toolsless attractive. In particular, enterprises are enhancing cross-enterprise communication in atimely manner with their partners, suppliers and customers in order to achieve their businessgoals.

Message-Oriented Middleware

Most enterprise application integration (EAI) architectures today are based on message-oriented middleware (MOM) among which Java Message Service6 and WebSphere MQ7

are popular representatives. It allows messages to be passed asynchronously to one anotherand therefore enables the building of loosely coupled systems. In general, different deliverysemantics such as exactly-once and at-least-once are offered as well as reliability guaran-tees. Apart from providing message queuing and point-to-point communication, MOM alsosupports many-to-many communication patterns following the publish/subscribe paradigm.Point-to-point messaging ensures that there is a unique copy of the message which is passedto a single recipient. Publish/subscribe messaging defines a sort of multicast, where everysubscriber of a particular service will receive the same message. At a low level, this requiresa communication protocol for sending and receiving messages from the database. Recentinitiatives for the standardization of information sharing protocols include extensible mar-kup language (XML), simple object access protocol (SOAP), and web services descriptionlanguage (WSDL) [15].

Integrated Queuing System

Messaging and database technology have evolved independently. Designing and implemen-ting database-messaging systems require bringing together concepts and functionality fromtwo separate worlds. There have been early attempts to use databases to store messages wi-thout adapting the database technology to the messaging environments. In 1995, the argumentwas made that queues are tables with special characteristics [9]. Inspired by this idea, the im-plementation of queue-based messaging features inside the database systems was considered.Oracle started providing a solution by delivering the first queuing system fully integrated intothe database. Oracle Streams [8] manages the sending, receiving, and processing of messagesto and from queues within the database system. Such integration not only brings operationalsimplicity to the system but also allows new levels of functionality, security, scalability, andreliability.

Enhanced Active Support

Facilitating information sharing within the database causes the demand for active conditionalexpressions to describe activites of interest such as changes of database content. On the onehand, data providers could determine these expressions by defining what information is of

4http://www.ibm.com/software/data/integration/info server/5http://www.ibm.com/software/data/informix/tools/egm/6http://java.sun.com/products/jms/7http://www.ibm.com/software/integration/wmq/

CHAPTER 2. RELATED WORK 7

interest and make it available for consumers. On the other hand, it could be specified viadirect subscriptions on the database. A lot of important work in the area of active databaseshas been made between the mid 80s and the mid 90s [22]. Such databases allow reactivecomponents to be declared by defining event-condition-action (ECA) rules. New rules canbe added, enabling objects to react on their own changes as well as to the changes made onother objects. In other words, active technology provides information sharing with the meansto detect interesting events in the database. But, in order for the system to proactively notifyregistered observers, including remote ones of events that occur within the database, the goalis to extend the detection with mechanisms for functional, reliable and scalable propagationand consumation of information. Section 3.3 introduces a unified event model that attemptsto address these issues.

Object-Based Sharing Systems

So far, we have mainly assumed databases complying with the relational model. By contrast,object-oriented databases management systems (OODBMS) combine object orientation withdatabase capabilities. OODBMS evolved from a need to satisfy the demand for a moreappropriate representation and modeling of real world entities. Therefore, OODBs provide amuch richer data model than conventional relational databases [3]. In this context, solutionsare offered in terms of dedicated systems that address the requirements of data sharingand migration. Previous approaches typically relied on the use of a global, integrated andconceptual database schema where users and applications had to make queries to accessremote information.

A different mechanism for the transparent sharing of objects in an environment of networked,autonomous database systems is presented in [5]. Users import remote objects directly andtransparently into their local database: their access is virtually the same as the access to localobjects. The system that is implemented on top of the Iris and Omega OODBMS supportsthe sharing of data and metadata objects as well as units of behavior. Since their datamodel treats every object uniformly, they investigate the sharing of individual data objects(instances), structural objects (types), and behavioral objects (functions). Overall, sharingis based on creating surrogate objects in a database for each remote object that is imported.Surrogates are simply objects that are created locally and serve as place holders for remoteobjects.

Thor [14] is a distributed object-oriented database system acting as an object store with apowerful programming model. It allows applications to safely share objects across bothspace and time by ensuring that objects are only accessed by calling their methods. Thor isimplemented as a client/server system in which servers provide persistent storage for objectsand applications run on client machines using cached copies of persistent objects.

Notably, both systems do not support mobile clients. The next section discusses issues relatedto that context.


2.1.2 Mobile Environment

The ongoing miniaturization of electronics, together with advances in processing power, me-mory capacities and wireless communication systems, has brought us to the stage where mostof us carry computing and communication devices around all the time. Wireless networkingenhances the use of a portable computing device by offering mobile users versatile com-munication facilities with other people and expedient notification of important events. Thecombination of networking and mobility along with the capabilities of modern mobile de-vices enable new classes of applications to exploit the ability to form ad-hoc workgroups andexchange data in a dynamic fashion. Such applications - including collaboration software -support meetings, electronic bulletin boards with their contents adapted to current viewers[20], lighting that adjusts to the needs of the present people, and navigation software guidingthe users in unfamiliar places and on tours.

Ubiquitous Computing

The wireless application features, inherent to the mobility and wireless communicationmedium, create a unique class of emerging novel applications striving to achieve the anytime-anywhere paradigm of pervasive computing. Ubiquitous access and computing was stressedfor the first time by Mark Weiser [24]. It refers to an environment where users are everywheresurrounded by computational power and applications. The hardware environment consistingof smart and mobile phones, PDAs, different miniaturized devices, micro computers andembedded devices enables the execution of applications supporting ubiquitous services andcomputing. These devices are connected to each other and equipped with sensing capabilitiessuch as sensors, making them reactive to their context of use. Research has picked up on thistopic about a decade earlier and today many groups spend considerable amounts of effortand funding on the investigation of various aspects of ubiquitous computing.

Projekts like Aura [7] present an appealing vision of a world of integrated systems. Thecore part of the Aura system is a task manager called Prism which tries to minimize thedistraction of the user in the following four cases: the user moves to another environment,the environment changes, the task changes and the context changes. Prism has the followingcomponents available and it communicates with them: one or more context observer, anenvironment manager as the gateway to the environment and file access, and several servicesuppliers. Furthermore, Prism can also communicate with other Prisms to allow the seamlessrelocation of the user and its tasks to another environment. Aura uses a task-centeredapproach with a platform-independent description and migration of tasks. The project basesitself on the assumption that a constant connection with the core system components is given.Many of these approaches are green-field developments that define their own world withoutputting the focus on the integration of existing systems or they are only partial solutionsthat need further integration into other systems. Yet, the original framing of the ubiquitouscomputing vision still occupies an important place in much of the discourse on ubiquitouscomputing research.

Today’s mobile computing devices and communication technologies are only an intermediatestage in this evolution. They still suffer from various shortcomings in technical, social andorganizational areas.

CHAPTER 2. RELATED WORK 9

Disconnected Operation

Wireless communication faces more obstacles than wired connection because the surroun-ding environment interacts with the signal thereby blocking signal paths and introducingnoise and echoes. As a result, network failure is an important concern in mobile computingas wireless communication tends to be susceptible to disconnection. Despite this reality,users still want to be able to access and update shared data independently from each otherduring disconnection.

The Coda file system provides an example of handling this requirement, although it is de-signed for today’s notebook computers in which disconnections may be less frequent, morepredictable, and longer lasting than in mobile computing. As defined in [11], disconnectedoperation is a mode of operation that enables a client to continue accessing critical data duringtemporary failures of a shared data repository.Its solution to the lack of communication is hoarding, in which non-local files are cachedon the local disk prior to disconnection. After updating the local copies, Coda attempts toreconcile the cache with the replicated master repository upon re-connection.

The following system also addresses the above mentioned issues. [26] characterizes Xmiddleas an information sharing middleware for a mobile environment. It provides an approachto data sharing that allows off-line data manipulation, synchronization and application-dependent data reconciliation. On each device, a set of possible access points for the cor-responding data tree are so defined that other devices can link into these points in order togain access to the information. In order to share data, a host needs to explicitly link to ano-ther host’s exported data branches. The data (and associated metadata) is cached on to thetarget host, allowing disconnected operations on the information. Xmiddle can automaticallyreconcile any changes to shared data, using application metadata to resolve conflicts.

Co-presence

The term co-presence denominates the spatio-temporal condition under which humans caninteract with each other. The most natural state of co-presence is where all parties are inphysical proximity. Thus, when co-present, instant two-way human interactions can takeplace e.g. in order to conduct a conversation. There are two types of proximity: physical andelectronic. Physical proximity is an area which is delimited by the scope of human senses,and electronic proximity is an area that electronically extended human senses can reach.Wireless connectivity is increasingly available within restricted areas such as restaurants,airports and public areas by means of 3G networks. Additionally, short range connectivitytechnology such as Wi-Fi and Bluetooth enables devices to directly connect to each other.In order for a user to sense its vicinity, each person is required to make themselves visible -either by carrying a particular device, activating a software application on their mobile phoneor connecting to a centralized service. It is not even required that the parties engage in anydirect interaction. They may just be walking past each other or sitting in the same room. Theresulting ad-hoc nature of establishing network connections between personal mobile devicescan be viewed as a means of sharing information opportunistically based on spatio-temporalproximity. Projects such as AIDE [13], intended to form social networks, have investigatedthese issues with regard to co-presence.


3Underlying Models and Systems

In this chapter we will discuss the Object Model (OM) data model starting with a descriptionat the logical level. The following sections examine existing OM implementations and theirfeatures. Finally, an introduction to the unified event model is given. The presented modelsand systems build the conceptual and technical groundwork for this master thesis.

3.1 OM Data Model

The OM model can be seen as an evolution of the extended Entity-Relationship (E/R) modeland of semantic data models [16]. It constitutes an object-oriented model supporting bothoperational and structural components which make the model not only capable of describingdata, but also of managing them. Apart from building on the notions of application entitiesand relationships, OM distinguishes typing from classification by means of a two-layered mo-del. Typing should only be concerned with the representation of an object inside a database,while classification should capture the real world categories and their dependencies [17].

3.1.1 Type Layer

On the lower level, types define the representation of entities by specifying their attributesand methods. Attributes can be of any type that is supported by the type model. Along withthe existence of the concept of object as a placeholder for data and operations, a subtypingprinciple enhances the model’s expressiveness. Type hierarchies can be formed that are builtusing inheritance between supertypes and subtypes. OM supports multiple inheritance, na-mely a type can be a subtype of multiple supertypes, as well as multiple instantiation whichstates that objects can have types within the type hierarchy and types that are completelyunrelated. Furthermore, objects can gain or lose these types dynamically at runtime. TheOM type model differentiates between four kinds of types: base types like strings, dates ornumeric types, object types that have an identity and define representations of objects withattributes and methods, structured types that are record values without an identity, and bulk

11

12 3.1. OM DATA MODEL

types that define collection behavior.

3.1.2 Classification Layer

The next basic concept of OM is the collection. Collections can be seen as some kind ofcontainer that is intended to assort objects. The layer built on top of the type model capturesthe semantics of entities using collections to represent semantic groupings. Due to the factthat an object can be a member of multiple collections at the same time, multiple classifi-cation is supported, which enables role modeling capabilities. Role modeling cannot justbe expressed through the addition and removal of types to objects but also through addingobjects to collections or removing them.The characteristics of a collection in OM are the name, the member type and the extent.The latter is the list of the objects contained in the collection. The member type defineswhich objects may be present in the extent: only instances of the member type are allowed.An extent is described by a bulk type. There exist four different bulk types for the extentof a collection. Their difference lies in the capability of possessing an order, i.e. keepingtrack of the order of the objects inside the collection and in the capability of storing multipleoccurrences of the same object. In a fashion similar to types and subtypes, OM defines thesubcollection concept to represent a specialization of roles. Restrictions are allowed to beapplied to such relationships.All the constraints provided by the OM model are not limited to two subcollections or super-collections. They can be naturally extended to encompass more collections. Classificationconstraints such as disjoint, cover, partition and intersect may be placed above these collec-tion families. One recognizes that constraints make an important contribution to raise thesemantic expressiveness of the model. In contrast to most object-oriented models and pro-gramming languages, collections are a first-order concept in OM, as well as associations.An association is a separate construct used to describe relationships between objects by lin-king pairs of objects from two collections. The basic features are its name, the source col-lection, the range collection and the cardinality constraints. Although the domain and rangecollections imply a direction of the association, associations are bi-directional. An associa-tion is modeled by means of a so-called relation collection. Its member type is a structuredtype with two values.

3.1.3 Graphical notation and OML

As for E/R, a graphic notation exists that allows data models to be specified in OM. Theexample in Figure 3.1 shows the graphic representations of most of the concepts describedabove. Additionally, a textual definition language is offered which acts as a subset of theObject Model Language (OML) and encompasses a data manipulation and query language.

3.1.4 Query Operators

The query language defines a set of operators for the manipulation and process of collectionsand associations. This section introduces a proper subset of available operations that are usedin the implementation of the event-based sharing system. The set-operators union, intersectand difference are available over collections. A union operation (

S) between two collections

forms a collection containing all their elements, while an intersect operation (T

) results in

CHAPTER 3. UNDERLYING MODELS AND SYSTEMS 13

personType

Persons worksFor

organisationType

Organisations(0:*) (0:*)

name: stringage: string

personType

address: sAddress

privateType

activities: set of string

ethPersonType

name: stringdescription: stringowner: personType

getOwnerName: () (name: string);

organisationType

privateType

Privates

ethPersonType

ETHPersons

cover

Typi

ngC

lass

ifica

tion

Figure 3.1: OM Example

a collection consisting only of elements which are in both operand collections. In contrast,a collection containing the elements being in the first operand, but not in the second can berealized by the difference operator (–). These means described so far apply to all forms ofcollections and hence to both unary and binary collections. In addition, there are a number ofoperations which only apply to binary collections undertaking associations. These operationsutilize the fact that the members of the collections are pair values. Generally, the domainoperation forms a collection of the left elements of pair values in a binary collection and,correspondingly, a range operation is available to build a collection of the right elements.These operators find the elements which refer to the source and target elements of anassociation. The algebra provides the possibility to perform selections on associations byrestricting the membership of the source and target collection. In particular, such a selectionis performed based on a filter given by a subcollection of its domain or range, respectively.For example, the domain restriction (dr) operation produces a collection that contains allthose pairs of a binary collection whose domain (left) value resides also in the applied filtercollection.

It is beyond the scope of this thesis to describe all the aspects of the OM model in detail,especially the generalized semantics of the constraints over collections, the constructs definedby OML, as well as the remaining operators of the algebra. Further details of the OM modelcan be found in [25].

14 3.2. OM SYSTEMS

3.2 OM Systems

Over the last decade, there have been a number of implementations of the OM model ba-sed on different storage technologies, including native, relational and object storage systems[12, 25] implemented for different platforms. OMS Pro was the first full implementation ofthe OM model as described in [2]. In this section we will examine two other existing OMimplementations. The description of these systems will provide useful background informa-tion and an insight into the evolution of the concepts underlying the event-based informationsharing system which is the subject of this thesis.

3.2.1 OMS Avon

The OMS Avon framework can be seen both as a multi-tier object management system andas an object-oriented application framework for Java. From a programming point of view,following the layered architecture, the separation of typing and classification is facilitated asthe OM model claims. Figure 3.2 depicts the two main tiers which will be covered in turn.Further information on the OMS Avon architecture and design can be found in [18].

OID InfoUnit Value

TypeDesc

Object Instance Value

Type Attribute

Model

Storage

OMObject OMModuleOMExtent

IdentifierDescriptor

- create- dress- set/get- delete

CRUD

OMS Avon

Figure 3.2: OMS Avon Architecture

Storage Layer

The lowest level offers the means to create, retrieve, update and delete persistent data.There exists a storage manager maintaining a list of available storage instances and methodsto open and close them. Apart from creating type descriptors, objects and extents, thedressing and stripping of objects with types as well as the capability to set and get attributevalues of objects are supplied by the storage interface component. Regarding the matters of


persistence, various storage providers are at one’s disposal, e.g. Berkeley DB8, db4o [21] andan in-memory variant which is used for testing purposes. Next to the support of transactions,concurrency control and recovery, application programming interfaces (API) for creatingand managing indexes and posting queries are available. When data is passed to the storageinterface component, they follow the concepts defined within the storage data model formingthe core of this layer.

In this model, all information - both data and metadata - is represented as objects. Eachobject is uniquely identified by a system-defined identifier (called here OID or ObjectId)which cannot be modified by the application. As pointed out in [10, 27] the notion of objectidentity provides a separate and consistent notion of identity, which is independent of thefact of how an object is accessed or modeled with descriptive data. Therefore, two objectsare different if they have different OID’s, even if they have the same structures and thesame values for all their properties. In OMS Avon, object representations are composed ofInformation Units - one for each type of which the object has an instance, thus enablingmultiple instantiation as explained later. An information unit is an array of values complyingwith a Type Descriptor that specifies the values in terms of attribute declarations.

The OM data model distinguishes Base Values, Object Values, Structured Values as wellas Bulk Values that are described with the corresponding type descriptors visualized in Fi-gure 3.3.

+ Identifier

TypeDescriptor

ReferenceTypeDescriptorValueTypeDescriptor

+ BuiltInType

BaseTypeDescriptor

+ BulkType

ExtentTypeDescriptor

ObjectTypeDescriptor

RecordTypeDescriptor

Figure 3.3: Type Hierarchy in Storage Layer

A type descriptor can either be a ReferenceTypeDescriptor or aValueTypeDescriptor. The first one is structured into an ObjectTypeDescriptoras well as an ExtentTypeDescriptor. Every ObjectTypeDescriptor contains anumber of ValueTypeDescriptors, describing the attribute types of the object value.Every ExtentTypeDescriptor is composed of exactly one ValueTypeDescriptorspecifying the type of the members that the actual extent contains. It is referred toas BulkType. The latter one can be structured into BaseTypeDescriptors andRecordTypeDescriptors. A BaseTypeDescriptor contains a global reference

8http://www.oracle.com/technology/products/berkeley-db/index.html

16 3.2. OM SYSTEMS

oid17 PersonUnit

"Christoph"

24

0

1

PersonDescriptor

String

Integer

0

1

oid23 PersonTypeUnit"personType"

{ "name": String, "age": Integer }

0

1

PersonTypeDescriptor

String

Set<Attribute>

0

1oid23

Figure 3.4: Information Units together with Type Descriptors

to its BuiltInType, describing the base value. All storage layers support the same set ofbuilt-in types, in such a way that two separate OMS Avon databases can access a specificBuiltInType based on a global identifier. Every RecordTypeDescriptor comprisesa number of ValueTypeDescriptors describing a structured value.

In Figure 3.4, we illustrate the basic concepts outlined in the first part of this section. Further-more, we will use it as the example of choice when introducing new concepts in the remainderof this thesis. Let us assume we create an instance of the personType shown in Figure 3.1 andset the name to ”Christoph” and its age to the value ”24”. According to the the data model,an ObjectId, namely oid17, is provided that points at the PersonUnit holding the two speci-fied values. Note that the position of the values within the unit corresponds to the sequenceof attribute declarations in the type descriptor. Following the other reference leads to the Per-sonDescriptor declaring the attribute types of the person type. Taken into consideration thefact that all data are represented as objects, we are able to generate the object structure of theperson type shown on the right side. The value at position 0 contains the name of the type,while the other field describes its attributes in terms of their name and type.

Model Layer

This level makes use of the low-level API and implements the functionality associated withthe OM data model. Instead of having application domain classes working directly on thelow-level API, another approach consists of using one generic Java abstraction representingall kinds of objects uniformly such as types, collections, persons and so forth. The singleclass OMObject represents the notion of an object whose attribute values can be accessedand manipulated. It contains a reference to an object identifier used in the low-level API.Attribute value manipulation methods merely forward the requests to the storage module.The achieved flexibility affords benefits for database evolution. It also turns out to be be-neficial for recovery issues due to the central control for transactions. In order to make theconcepts represented by OMObject accessible to an application developer, CRUD classespermitting the creation and deletion of a generic object as well as the manipulation and inter-pretation of its attributes are placed at the disposal.The fact that an object can have multiple types from unrelated type hierarchies is referredto as multiple instantiation. As opposed to the Java object model, where an object is of aparticular type including all its super types, this model distinguishes between an object andits instances. An instance gives access to values for attributes declared by a particular typeincluding its supertypes.


Database Modules

OMS Avon integrates the idea of database modules that can extend or adapt the system forspecial application domains. Each layer mentioned above can be composed of separate mo-dules that share the layer-specific meta model. The specification of a database module in-cludes the following components:

• A meta model extension to define new concepts.

• Functionality that manages the new concepts (CRUD classes).

• A query language extension to interact with the new concepts.

Therefore, an OMS Avon database consists of a set of modules and data. The core mo-dule, i.e. the system module, is always loaded first and contains the core meta model, thecorresponding CRUDs and basic database language. Additional modules can be loaded iffurther functionality is required. Figure 3.2 indicates the module extension mechanism withthe block-shaped and triangle-shaped margins of the model layer.The entry point of a module that uses the extension mechanism of the OM layer is a class thatimplements the interface OMModule. OMS Avon searches for the modules to load in theproperties file ommodules.properties. This properties file must be located in the class path ofthe application and its content must be specified in the XML properties format whose contentlooks approximately as follows:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd"><properties>

<comment>OM module definition file.</comment><entry key="MyModule">

my.project.packages.MyModule</entry>

</properties>

In this example, the entry point of a module represented by the class MyModule is set to beloaded when the database is opened. Its task is to register the CRUD classes of the accordingmodule and to load the associated schema into the database.

3.2.2 OMS Connect

OMS Connect [19] is an extended version of the OMS Pro system and introduces a mo-del of database connectivity that allows the controlled sharing and migration of informationacross database instances. It provides the facilities for databases to connect to remote onesand display their information. This data can then be processed and copied locally in a waythat maintains the local consistency. The remote object may also be extended locally withadditional attributes, methods and classifications. OMS Connect furthermore supports dis-connected operations which are especially useful when working in mobile environments withnon-permanent network connections.Each database in the system may act as a client or as a server. There are four categories ofobjects in a local database:

• Local objects that are created in the local database.

18 3.3. UNIFIED EVENT MODEL

• A remote copy means that the local system creates a local copy of the remote object.This local copy is now independent from the remote server with local modifications notbeing propagated to the server and remote modifications not being propagated to thelocal system.

• Remote objects reside on another server but remain visible locally as long as theconnection with the remote server is active.

• Remote persistent objects overcome the latter restriction by being copied locally, ma-king disconnected operation possible. If there is no network connection available, theclient will focus on its local copy.

In the case of remote and remote persistent objects, the remote server keeps track of changesapplied to such objects and, when they are updated, sends the appropriate notifications to theclients.

3.3 Unified Event Model

In this thesis, we will make use of an event system in order to provide notifications forregistered observers about events that occur within the database. Event-driven architecture(EDA) is an architectural pattern built on the production and consumption of events andtheir handling. An event is defined as a happening of interest in the system. Events aregenerated by event producers. Based on its characteristics, an event is delivered to one orseveral event consumers which process it and optionally execute an action. The architectureis loosely-coupled as producers and consumers do not require any knowledge about eachother.

An event system for OMS Avon has been developed in [23]. A unified event model combinesmechanisms found in notification systems and modern programming languages with the no-tion of traditional database triggers. The approach integrates the publish/subscribe paradigmwith database triggers and transactions. The issue of embedding decentralization aspectswas addressed by the same project. This section outlines the core concepts and introduces asimplified version of the model that is tailored to the goals of this thesis.Figure 3.5 shows an overview of the event entities and the interactions between them. EventTriggers pass arguments to the subscribed Event Handlers when firing events of a given EventType. Note that none of the interactions between the different entities are direct interactions,but are rather performed through the event run-time system - the Event Manager - shown inthe center of the figure. Event types can be seen as the puzzle pieces of the event system:while event arguments provided by triggers are passed to subscribed event handlers, they arenot directly related. The event type builds the glue between triggers and handlers.

3.3.1 Event Types

Event types comprise what represents an observable in programming languages and anaction type in database systems respectively. Generally, an event type indicates a certainhappening, which can be a low-level event such as a database action. In other words, eventtypes are used to describe a certain class of events. Besides, they act as a registration point


Event Type

Event Handler Event Trigger

EventManager

Figure 3.5: Unified Event Model

for interested subscribers. An event type is always associated with a scope which can eitherbe the global scope that models global database triggers or a class of objects, an arbitrarycollection of objects, a single object instance as well as a transaction.

There exist two main classes of event types, user-defined and system-defined types. Figure 3.6presents the different classes of supported event types. The figure is a simplified OM modeland is intended to highlight the associated parts of an event type rather than be a specificationof the actual implementation. Generally, associations to meta objects such as types and col-lections are omitted and indicated by dashed lines only. Similarly, the figure does not defineany collection constraints.From a design point of view, this distinction is introduced to categorize the event types.System-defined event types cannot be created by a user. Instead, they are automaticallygenerated by the system as well as associated with subscribers. This accounts for caseswhere the system should take over functionality that was formerly implemented by meansof temporary hacks. For instance, dressing an object with an object type should result ininserting the object into the proper type collection. While Figure 3.6 illustrates a separationof the entities, Figure 3.7 depicts the inherent dependency between them. System eventtypes form the groundwork based on which user event types can be built. Every user-definedevent type relies on one or several system-defined event types, except for the global one thatcan exist on its own. This way, a more general class of event type can be realized as part ofmultiple specific ones.

Apart from the formal descriptions of the different classes, examples demonstrating their useare given in the following subsections. Some of them might refer to the schema representedin Figure 3.1.


eventType

Event Types

userEType

User ETypes

systemEType

System ETypes

typeEType

Type ETypes

attributeEType

Attribute ETypes

objectEType

Object ETypes

typeEType

Type ETypes

attributeEType

Attribute ETypes

extentEType

Extent ETypes

globalEType

Global ETypes

collectionEType

Collection ETypes

bulkEType

Bulk ETypes

globalEType

Global ETypes

Figure 3.6: Event Types

System-Defined Event Types

• Global Event Types (GE): A global system event type models global database triggers,such as COMMIT, ROLLBACK or ABORT. Furthermore, it can be used to signal certainevents to application components and allow them to take appropriate actions, such asclosing open database connections on a system shutdown.

• Type Event Types (TE): Types of this class are bound to an OM type and are usedto model common database triggers. A possible event type defined for an OM typepersonType could be personType.DRESS. This exemplary event type covers allscenarios where objects get dressed with the personType.

• Attribute Event Types (AE): In order to be able to observe single attribute value changesof an OM type, attribute event types are created. If an observer is interested in changesof the name of personType, it could subscribe to personType.@name.

• Extent Event Types (EE): Insertions to or deletions from extents can be observedthrough extent event types. Since both OM collections and attributes whose type cor-responds to a set, such as given with the ethPersonType, are mapped to OM extents,we define only one event type that covers both cases. Such a type for the collectionPersons could be Persons.INSERT.


Figure 3.7: Dependency between User and System Types

User-Defined Event Types

• Global Event Types (GE): Global user-defined event types allow propagating eventswithout the need to bind the event type to a certain object. This group of event typecan exist with and without a corresponding system event type. For example, on the onehand we could focus on the COMMIT of a transaction. As transactions are regarded assystem concepts, a system type is in place describing this type of event. Therefore, theuser defined type is based on this system type. On the other hand, a user can definesome global state independently of the subsystem: FIRE DETECTED.

• Type Event Types (TE): This class of event type can be seen as a traditional event de-finition as we know them from programming languages. The event type is alwaysbound to an OM type. A subscription results in general notifications about the typeas well as attribute changes. A particular object can be specified additionally there-with restricting this event class to a smaller subset: oid17.personType.DRESS,oid17.personType.STRIP and oid17.personType.UPDATE.

• Attribute Event Types (AE): In order to be able to observe single attribute valuechanges of an object type, attribute event types are created. If an observer is inter-ested in changes of the last name of a particular person object, it could subscribe tooid17.personType.@name. The declaration of the person object is optional.

• Collection Event Types (CE): Event types bound to an OM collection as well as to anobject allow observing whether the specified object is inserted or removed from thecollection: Persons.oid17.INSERT and Persons.oid17.REMOVE. Not indi-cating an object leads to a class whose sources are determined by the system-definedextent event types for Persons.INSERT and Persons.REMOVE.


• Bulk Event Types (BE): This type acts analogously to the collection event type. Insteadof considering collections, it is confined to attributes whose type is a set.

• Object Event Types (OE): Object event types rely on all system-defined event types thatdeal with particular objects. An observer will be informed about any possible changeto a specified object.

After having looked at the different classes of event types, one needs to introduce the mode-ling of occurrences of events for a specific type. For this purpose, the unified event modelproposes the concept of event triggers.

3.3.2 Event Triggers

In contrast to events programming where an event is generally fired by the observable entity,the unified model defines a distinct entity, a so-called event trigger. Triggers are created andfired whenever events occur. Their meaning must not be mistaken with that of triggers indatabases as they permit events not only to be fired by the database but also by external pro-cesses such as client applications. Upon creation of an event trigger, one needs to define theevent type that the trigger fires. A similar separation as with event types is given, namely a se-paration into system-defined and user-defined triggers. User-defined triggers can thereby onlyfire user-defined event types, whereas system-defined triggers are allowed to fire any eventtype. Figure 3.8 shows the different trigger classes. A major challenge is the consolidation ofthe publish/subscribe event model with the requirements of transactional behavior expectedfrom databases. We allow triggers to be executed either synchronously or asynchronously.

ETrigger

Event Triggers

userETrigger

User Triggers

systemETrigger

SystemTriggers

syncETrigger

Synchronous Triggers

asyncETrigger

Asynchronous Triggers

Figure 3.8: Event Triggers

System-Defined Triggers

System triggers are always fired synchronously. Considering a transactional environment,this means that associated handlers are executed within the same transaction. Note that theexecution of the event handlers blocks the event trigger. If the base transaction is aborted, theoperations performed as a result of the event handler executions are undone as well. A systemtrigger cannot be created by a user but is automatically created by the system when needed.


System triggers were introduced to fire system-defined event types which in turn are used toobserve traditional database events. As seen in Figure 3.7, user-defined and system-definedevent types are connected. After firing a trigger of a specific system event type, triggers forall the associated user event types are fired accordingly.

User-Defined Triggers

Apart from supporting the synchronous way of firing a user trigger, an asynchronous fashionis provided as well. A trigger that is fired asynchronously is in general less time-critical.Therefore asynchronous triggers are fired when the transaction that created the trigger isbeing committed. The execution of the subscribed event handlers will then be performed in aseparate transaction. In this manner, the event trigger is not blocked.

3.3.3 Event Handlers

Handlers represent observer entities which register for certain event types and get notifiedif a trigger fires an event of a registered type. The main part of the handler constitutes theevent action that performs operations as a result of an event. Operations can range from theexecution of a database macro, notification of the application or firing of other triggers. Inthe previous section about event triggers we have seen that they can be fired synchronously(within the given transaction) or asynchronously (in a separate transaction) thereby determi-ning in what transaction the event action is executed. Depending on the kind of trigger, theaccording handler will be called - the synchronous or asynchronous one. Figure 3.9 illustratesthe different parts of the event handler.

EHandler

Event HandlerhasAction

EAction

Event Action

asyncEHandler

Asynchronous Handler

syncEHandler

Synchronous Handler

Figure 3.9: Event Handlers

3.3.4 Event Sites

The event manager (Figure 3.5) forms the basis for decoupling the three concepts of theevent model which is an important requirement to facilitate access to the event systemfrom remote sites. The model proposes what entities can be distributed. As event types aregenerally bound to a database object and are usually designed together with the application,it was decided that there is no need to allow event types to be created remotely. So far, wehave discussed that a trigger is fired if either the system recognizes an event or a user-definedcomponent creates a trigger. This is independent from whether the component resides onthe local or a remote site. As a consequence, the creation and firing of an event trigger at aremote site for a particular event type is possible and it enables the execution of the registered


handlers at the given remote site. The creation of a handler for a remote event type allows forthe listening of events happening at the remote site, and, if such events happen, the executionof the appropriate handler action at the local site.

This chapter introduced two systems: OMS Avon constitutes a Java implementation of theOMS database management system, relying on the object-oriented database db4o, whileOMS Connect introduces a distribution model for OM which allows the sharing of remoteobjects. Furthermore, we have given insight into a previous project on triggers, events andnotification and we provided a simplified version of the proposed unified event model.

4Sharing Modes

Today’s mobile devices constitute a single handheld mobile platform that provides featuresranging from storing significant amounts of useful information to establishing wireless net-work connections across a number of channels. This includes gadgets such as MP3 playersand DVD players since they are already or about to be equipped with interfaces for short tomedium range wireless communications. Based on this platform, applications will be enabledwith the sharing and exchange of documents, pictures, music and movies. It is possible forusers to interact with content via established avenues, such as Internet connectivity, but alsoto share a variety of useful content and services directly with other mobile users via techno-logies such as Wi-Fi and Bluetooth. This is giving rise to new opportunities and challengesin making dynamic connections directly between mobile users in order to share information.This chapter focuses on identifying the different modes of sharing between mobile devices inclose proximity. Apart from that, we will present our conceptual approach that shows howthese sharing modes can be realized. In the remainder of this chapter, we use the term data,information and object interchangeably. In the same manner, the terms user and peer willdenote the same.As previously stated, the resulting ad-hoc nature of establishing network connections betweenpersonal mobile devices can be viewed as a means of sharing information opportunisticallybased on spatio-temporal proximity. Given the mobile nature of the environment, connec-tions are likely to be short-lived as devices move out of range. The question arises as to whathappens to exchanged data when the connection is closed and whether former receivers arenotified about changes on data in order to apply the changes accordingly. Taking these sta-tements into consideration, two orthogonal concepts can be highlighted: data continuity anddata coupling. The first one refers to the issue whether the lifetime of an object is limited,while the latter investigates if objects on different machines are interconnected. The compo-sition of both dimensions comprises four modes of sharing as depicted in Figure 4.1. Theaxis of abscissae covers the data coupling concept and the ordinate is related to the conceptof data continuity. The illustration sketches the situation where two devices are within reach,taking part in a uni-directional data exchange scenario.

25

26

Upon Connection

COPY SYNCHRONIZATION

PER

SIST

ENT

TRA

NSI

ENT

Upon Disconnection

send

Upon Connection

Upon Disconnection

sendpropagate changes

Upon Connection

Upon Disconnection

send

Upon Connection

Upon Disconnection

sendpropagate changes

Figure 4.1: Sharing Modes

• Persistent Copy: This mode is regarded as the default mode because it is the simplestone and it is likely to be the one most used. Upon connection, objects are copied tothe remote side. The resulting objects are not linked to the original ones. Instead, theoriginal and the remotely created object will be two distinct entities that can be inde-pendently manipulated. After disconnection, the received data remains visible allowingfurther access.

• Transient Copy: As opposed to the previous case, received objects vanish as a resultof the connection breakdown. Access to information on the receiver’s device is there-fore restricted by the state of network connectivity. Furthermore, while data is visible,manipulations on the data do not affect other peers: changes are not propagated.

• Persistent Synchronization: When hosts get in touch with each other, data is transferredto the remote side. As long as the connection is established, any change on the originalobject is directly forwarded in order to update the remote version of the object. Clearly,object synchronization cannot take place after disconnection. However, data will besynchronized later when connection is re-established. The access to local data is alwayspossible, hence allowing disconnected operation.

• Transient Synchronization: In this mode, data on the receiver is only visible while bothusers are connected. However, when this is the case, changes on the original datais forwarded to the remote peer. Manipulations of the original data do not need tobe tracked during disconnection because meanwhile the data on the remote side hasalready been deleted. Upon connection, the updated objects are exchanged as a whole.

CHAPTER 4. SHARING MODES 27

4.1 Approach

One of the main challenges applications in a mobile environment must overcome is tocompensate for the lack of user attention. For example, when connections occur betweendevices, if the user is not on hand to initiate certain processes, then the opportunity providedby the connection is lost. In order to address this issue, we propose designing our sharingmodes in a way that they mainly operate in an automatic manner. That is, the applicationcarries out the process of data sharing on behalf of the user. Taking initiative autonomouslywithout the user’s explicit command is referred to as proactivity.

Object-oriented databases have become a popular choice for storing data in mobile systems.Applications that rely on this storage technology are mostly restricted to synchronous com-munication patterns based on request and response. Clearly, an asynchronous approach en-abling the database to inform the applications as soon as new information is available wouldbe more efficient and thus preferable. As part of this master thesis, the object-oriented data-base management system OMS Avon is extended with event handling facilities sophisticatedenough to support the desired proactive behavior.An additional point is that the user’s proximity needs to be scanned for devices which arecapable of taking part in the exchange of data. Connection technologies such as Bluetoothand Wi-Fi are used to scan the physical environment of a peer and discover other peers nearby.The support for vicinity awareness enables the reaction upon appearance or disappearance ofpeers in the physical surrounding, therewith providing the basic requirement to opportunisticinformation sharing. Note that proactive behavior is intended to cause changes rather thanjust to react to changes.

4.1.1 Collection-based Sharing Model

The collection concept of the OM meta model is the central component of our approach.It features the insertion, removal and retrieval of data items. Apart from providing thesebasic data management facilities, the event system in place supports events that are triggeredwhenever elements are added to, or removed from a collection. We refer to these kinds ofhappenings as collection activities. Handlers can be registered with the event system to benotified about activities which in turn can execute some action.The members of the so-called vicinity collection represent those peers that are currently inphysical vicinity. Whenever a new peer is detected, a new object is created and added to thevicinity collection. When a peer moves away, the respective member is deleted and removedfrom the collection.Basically, this collection drives the whole sharing process. Shared objects could be dressedwith a shared object type that allows attaching additional information by means of itsattributes. As object equality on the remote site is defined over the types it is dressed with,we only need to focus on the classification concept. The implementation of the four sharingmodes is based on the OM collections shown in Figure 4.2.

The left hand side indicates which mode a shared object is associated with. Every sharedobject resides at least in the Shared Objects collection. This collection corresponds to thedefault form of sharing, namely persistent copy. Taking into account the two subcollections,the remaining modes can be covered by choosing the proper combination of collection

28 4.1. APPROACH

object

Objects

object

Shared Objects

object

Transient

object

Synchronized

Sender peerType

Users

peerType

Vicinity

Receiver

Figure 4.2: Model of Sharing Module

membership. The number of subcollections is related to the number of orthogonal conceptsthat we have identified. The provided model constitutes a simple and flexible solution toincorporate even more than these two dimensions. The introduction of a new orthogonalconcept would be faced with the creation of a new subcollection. On the opposite hand,a collection of users is given. By using the Receiver and the Sender association, one candenote which objects were sent to and received from respectively.

After having examined the needed components, we outline what their interaction looks like inorder to realize the four different modes of sharing. The event system maintains a handler thatgets notified whenever activities on the Vicinity collection occur. Depending on the appliedmode and activity, the handler starts a different sequence of operations related to the objectsthat are shared. Note that a peer simultaneously functions as both client and server to otherpeers on the network. Tasks are divided between these two roles thereby achieving separationof concerns.For all sharing modes, the objects that are about to be exchanged are inserted into the SharedObjects collection upon appearance of a new user. Additionally, a new entry in the Receiverassociation will be added stating that these objects have been sent to the linked user. Thus, wecan avoid exchanging objects that have already been sent in case of persistent data continuity.In contrast, the remote site makes use of the Sender association to indicate the receptionof the data items from a specific user. This information can be exploited to extend a peer’sresponsibility with the forwarding of objects. Since the transience of objects only affects thereceiver, the Transient collection comes into play when the peer acts as a receiver. Upondisappearance of a user, the handler queries for all objects that reside within the Transientcollection belonging to that user. The items in the resulting set are deleted to guarantee thatthey are neither visible nor accessible anymore.A further handler is installed to observe changes on the objects that are contained in thecollection called Synchronized. Only the sender side needs to take care of synchronization

CHAPTER 4. SHARING MODES 29

Sender Receiver

Persistent Copy

Upon connection: Insert into Shared Objects Insert into Receiver Association

Insert into Shared Objects Insert into Sender Association

Transient Copy

Upon connection: Insert into Shared Objects Insert into Receiver Association Upon disconnection:

Insert into Transient Insert into Sender Association Delete from Transient

Persistent Synchronization

Upon connection: Insert into Synchronized Insert into Receiver Association Handler on synchronized objects Propagate changes Upon disconnection: Track changes

Insert into Shared Objects Insert into Sender Association Apply changes

Transient Synchronization

Upon connection: Insert into Synchronized Insert into Receiver Association Handler on synchronized objects Propagate changes Upon disconnection:

Insert into Transient Insert into Sender Association Apply changes Delete from Transient

Figure 4.3: Operations associated with Sharing Modes

concerns due to the fact that only manipulations on the original objects are considered9. Whenupdates on the original data are performed while former receivers are not within range, thehandler is forced to keep track of the changes. After re-establishing the connection, theupdates need to be propagated and applied. Figure 4.3 summarizes the described proceedingsin tabular form.

9see Section 8.6 for additional information

30 4.1. APPROACH

5Implementation

This chapter presents the architecture for the event-based information sharing system and itsintegration into OMS Avon. It consists of several building blocks whose design and imple-mentation are discussed in turn. This involves among other things the description of selectedalgorithms as well as solutions to raised issues.

5.1 System Architecture

One of the deliverables of this project should include the implementation of a platform thatsupports the previously identified modes of sharing. Such a system can serve as a frameworkfor developers to create newly distributed and mobile applications. OMS Avon exposes itselfas a good foundation because this database management system brings some suitable featureswith it as presented in Section 3.2.1. The translation from the conceptual approach depictedin Chapter 4 to its technical realization is achieved by extending the database core with addi-tional functionality. Figure 5.1 shows the resulting architecture where four new componentscan be recognized.The Connectivity component is concerned with the exchange of data between connected da-tabase instances and provides the means for migrating objects. Apart from that, the simplifiedversion of the unified event model (see Section 3.3) is integrated into the system labeled EventModule. Above, a further component called Vicinity Module is responsible for sensing the vi-cinity of a user and reporting the coming and going of other users. On the opposite side, theSharing Module dedicates itself to the execution of the different sharing concepts. As op-posed to the Connectivity component which solely makes use of the storage layer, the otherbuilding blocks are realized as modules that hook into the model layer of OMS Avon. Theproper combination of all these elements constitutes the desired implementation platform.

31

32 5.1. SYSTEM ARCHITECTURE

OID InfoUnit Value

TypeDesc

Object Instance Value

Type Attribute

Storage

OMObject OMModuleOMExtent

IdentifierDescriptor

SharingModule

Connectivity

VicinityModule

EventModule

Model

- create- dress- set/get- delete

CRUD

OMS Avon

Figure 5.1: Architecture of the Event-based Information Sharing System

5.1.1 Avon Modules

OMS Avon comes along with a mechanism that can load modules when a database instanceis opened as seen in Section 3.2.1. Every upcoming module defines its own schema and in-troduces CRUD facilities for the manipulation of the concepts of its schema. All the CRUDs,as well as the other parts of the modules use the API of OMS Avon to access the database.Every Java project that implements such a module is composed of the following parts:

• crud: set of CRUD classes that allow the management of the extended meta model.

• module: contains a class that is the entry point of the module mechanism as defined inthe properties file. The task of this class is to register the CRUD classes and to load theassociated schema into the database.

• core: the fundamental functionality of a module is located in this package.

• exception: every module defines its own exceptions in order to identify the source ofproblems.

Additional (sub-)packages might be in place to cover other aspects or to guarantee a betterdistinction between different concepts. OMS Avon uses the Maven10 build tool for managingbuilds and compiling artifacts. Dependencies of a project are listed in POM files of therespective project. In the following sections, we will mention which artifacts and libraries amodule depends on.

10http://maven.apache.org

CHAPTER 5. IMPLEMENTATION 33

5.2 Connectivity

Traditional information sharing refers to one-to-one exchanges of data between a sender andreceiver. These information exchanges are implemented via dozens of open and proprietaryprotocols, message and file formats. OMS Avon also needs to provide a way of supportingthis functionality as other applications and modules heavily rely on this feature. Therefore,the design and implementation of an extensible and reliable low-level component that takescare of sending and receiving data is required.

5.2.1 Data Exchange Framework

As part of this thesis a framework for exchanging data between different database instances ofOMS Avon has been developed that is characterized by its ease of use and its expandability.Simplicity was achieved by keeping the system manageable, more precisely by keeping thenumber of classes small. Figure 5.2 gives an overview of the whole framework. Note thatevery class other than the manager appears twice in such a way that the illustration becomessymmetric. This is due to fact that we want to point out an interaction between two databasesusing the framework. On the right hand side in Figure 5.2, we assume a remote machine andon the left hand side a local one.

Thread

Server

+activePart()+passivePart()

-utility: ConversationUtility

Conversation

+send()+read()

Connection

+send()+request()

- storage: Storage

PeerImpl

+activePart()+passivePart()

-utility: ConversationUtility

Conversation

+send()+read()

Connection

ConnectivityManagerImpl

FunnyTalk FunnyTalk

<<Runnable>>Sender

(a) (b) (c)

(d)

Thread

<<Runnable>>Receiver

+send()+request()

- storage: Storage

PeerImpl

Server

remotelocal

Figure 5.2: Data Exchange Framework

34 5.2. CONNECTIVITY

Communication

The project specifies that the communication utility shall be based on the transmission controlprotocol (TCP). TCP is a reliable stream delivery service that guarantees delivery of a datastream sent from one host to another without duplication or data loss. In computer net-working, a stream socket is a type of Internet socket which provides a connection-oriented,sequenced, and unduplicated flow of data, with well-defined mechanisms for creating anddestroying connections and for detecting errors. Traditionally, stream sockets are implemen-ted on top of TCP as it is the case for Java Sockets. This enables distributed applicationsto run across any networks using TCP/IP protocol. Socket classes are used to represent theconnection between a client and a server.In order for a system to send data through a stream, the data must first be transformed into anintermediate representation. This process is called serialization. It involves saving the currentstate of an object to a stream. Restoring an equivalent object from that stream is referred toas deserialization. The stream functions as a container for the object. Its contents include apartial representation of the object’s internal structure, including variable types, names, andvalues. For a Java object to be serialized, it must be an instance of a class that implementseither the Serializable or Externalizable interface. The Serializableinterface relies on the Java runtime default mechanism to save an object’s state. Writingan object is done via the writeObject method in the ObjectOutputStream classwhile reading the serialized object is accomplished using the readObject method of theObjectInputStream class. Other objects that may be referred to by the object thatis serialized are also written into the stream. Using the Serializable interface, thesereferences (and their associated data) are converted and written into the stream as well.

As we are not allowed to touch the existing database core of OMS Avon, we cannot guaranteethe successful exchange of objects because they might not be flagged as serializable. In orderto face this issue, we chose another approach. XStream11 is a simple library that serializesobjects to XML and back again. It requires no modifications to objects and it features a fullobject graph support. This way, we can send whatever object we desire without having tomake further considerations.The resulting XML format can be compressed before being sent to the socket. Note thatstandard ZipOutputStream and GZIPOutputStream are useless for this purpose dueto their insufficiently strong flushing semantics: they do not guarantee that flush sends outall the data that has been written so far, which leads to deadlocks in request-response-basedprotocols. The alternative approach is to create stream classes that use the Deflator andInflator classes directly in order to tackle the above mentioned problem12. Unfortunately,XStream introduces another bug that forces us to recreate the ObjectOutputStreamand ObjectInputStream on every send and read. We are therefore dealing with thefollowing tradeoff: recreating the stream on every operation when using XStream versus thedependency on the Serializable interface. By applying compression to the output ofthe XStream, we still have an efficient and fast exchange of data. On this account and as weintend to send objects of the database core, we decided to stick to the first possibility.

11http://xstream.codehaus.org/12http://javatechniques.com/blog/compressing-data-sent-over-a-socket/


The Connection class in Figure 5.2 implements the functionality to exchange Java ob-jects. It wraps an end-point of a two-way communication link and encapsulates the sendand receive methods accordingly following the approach that has been described in thisparagraph.

Conversation

From the point of view of a computer scientist, there are different kinds of communicationpatterns starting from the uni-directional transmission of data. This is the simplest way ofachieving information sharing, but it suffers from certain shortcomings. One might want toplace a request to which a reply is expected. This request-response model can be seen as asimple form of dialog. Furthermore, one might ask for extensions to include several request-response iterations in one instance of a dialog. The structure and order of dialog instancesshould be flexible and adapt to the dynamics of a conversation. We introduce the notion ofa conversation to denote a dialog as well as one or multiple dialog instances. Depending onthe answer of a request, the initiator of the conversation can react in different ways. It can beregarded as the most flexible and extensible communication pattern. For our framework, wedefine a novel concept called forced conversation.

Definition 1 (Forced Conversation) A forced conversation is a communicational patternwhose workflow is fully determined by its creator. The initiator of such a conversation speci-fies its own actions as well as the ones taken by the interlocutor. The resulting protocol forcesthe receiver to follow the instructions given in the conversation.

The downside is that it causes security concerns since the author of such a conversation hasalmost full control over the dialog partner. This thesis does not focus on these issues. Instead,we consider its inherent features: flexibility and extensibility.The next step is to map this approach into our framework. The abstract classConversation dictates two methods, activePart and passivePart. In orderto create a new conversation, i.e. FunnyTalk, one needs to extend the abstract class andimplement these methods. They contain the operations executed by the initiator and theinterlocutor respectively. The framework takes care of the rest. Let us point this out bymeans of Figure 5.2. The Sender-Thread on the left hand side sends the FunnyTalkobject to the remote site and calls its activePart method. On the right hand side, theReceiver-Thread is designated to execute the passivePart of the conversation. Thisworks because the concept of forced conversation is known through the abstract classConversation. The system casts the received object to a Conversation objectand therefore does not need to consider the concrete runtime implementation. Finally,FunnyTalk uses the Connection object to facilitate the data exchange as part of thedialog.

In order to give a first impression of what is possible when using the forced conversationconcept, we provide the description of an exemplary scenario together with its implementa-tion documented in Figure 5.3:

Some user intends to go to the movies. He decides to use the cinematic database called Avo-nopolis that holds information about current movies and offers the means to order tickets.


public class FunnyTalk extends Conversation {

public void activePart() throws Exception {// database and connection utility (local)final OMDatabase db = this.getUtil().getDatabase();final Connection con = this.getConnection();

// receive current programfinal List<Movie> movies = (List<Movie>) con.read();

// calculate movies that I haven’t seen yetfinal List<Movie> notYetSeen = db.notYetSeen(movies);con.send(notYetSeen);if (notYetSeen == null) return;

// receive top moviefinal Movie candidate = (Movie) con.read();

// try to order ticket or let it beif (candidate.getRating() > 9.0) con.send(candidate);else {

con.send(null);return;

}

// hopefully get a ticketfinal Ticket ticket = con.read();if (ticket == null) System.out.println("No!");else System.out.println("Yes!");

}

public void passivePart() throws Exception {// database and connection utility (remote)final OMDatabase db = this.getUtil().getDatabase();final Connection con = this.getConnection();

// send current programcon.send(db.getMovieProgram());

// receive the user’s favorite moviesfinal List<Movie> favorites = (List<Movie>) con.read();if (favorites == null) return;

// calculate ratings and send top moviedb.orderMoviesRating(favorites);con.send(favorites.get(0));

// if seats are available for the movie, send ticketfinal Movie order = (Movie) con.read();if (order == null) return;if (db.existsSeat(order)) con.send(db.createTicket(order));else con.send(null);

}}

Figure 5.3: Concrete Implementation of a Forced Conversation


When he connects to the Avonopolis server, the current movie program is placed at the dis-posal. After having figured out which movies he had already seen, the user wants to knowwhich of the remaining movies is rated highest, given that this list of movies is not empty. Ifthe rating is higher than 9.0, he tries to order a ticket for that specific movie. Provided thatthere is still a seat available, he succeeds in getting his ticket. Summarized: subject to thecondition that there exists at least a movie which the user has not yet seen, which is rated hi-gher than 9.0 and whose screening still offers available seats, the user is going to the movies.Otherwise he stays at home.

Interfaces

The connectivity API provides the interfaces ConnectivityManager and Peer asshown in Figure 5.4. The entry point to the connectivity framework forms the manager in-terface. It allows the creation of a peer based on a user and a particular storage. Whenevera peer is created, the ConnectivityManagerImpl will insert the mapping between theprovided storage and the created peer in his map. The User interface enables the retrieval ofthe host name and the port. Apart from the functionality to start and stop a peer which cor-responds to starting and stopping the associated server that listens to incoming connections,the ConnectivityManager allows a peer to be removed given the storage reference ordirectly through the peer reference.

+send(Conversation, User): void+sendSync(Conversation, User): Object+sendObject(Identifier, User): void+sendObjectSync(Identifier, User): Identifier+requestObject(Identifier, User): void+requestObjectSync(Identifier, User): Identifier

<<interface>>Peer

+createPeer(User, Storage): void+deletePeer(User): void+deletePeer(Storage): void+startPeer(User): Peer+stopPeer(Peer): void+stopPeer(User): void

<<interface>>ConnectivityManager

Figure 5.4: Entry points for the Connectivity Framework

The core functionality is wrapped by the Peer interface. It provides dedicated functionalityto send objects either synchronously or asynchronously to a particular user. The same holdsfor the request for objects. Every method is bound to a forced conversation enabling theexpected functionality. A generic send method takes a conversation object as an argumentand enables various user-defined kinds of interactions. Returning to Figure 5.2, we illustratethe interactions between two database instances: calling any of the methods mentionedbefore results in the creation of a sender thread (1) which in turn connects to the serverinstance of the specified user (2). For every incoming connection, a worker thread, hereReceiver, comes into existence (3). From this point on, these two threads interact witheach other following the instructions of the assigned conversation (4).

This framework stands out due to its simplicity and extensibility. In order for a developerto provide more customized and dedicated methods for a given application domain, he onlyneeds to write his own conversation and upgrade the interface with a new name or he justuses the generic send method.


5.2.2 Object Migration

OMS Avon implements the OM data model as a basis for inter-component sharing and in-formation unit exchange. This model supports the usual object-oriented constructs and isenriched with additional semantic expressiveness as seen in Section 3.1. The constructs pro-vided in this data model serve as a reference point from which we describe our techniquesfor data migration. The presented connectivity utility is implemented as a low-level moduleand uses the concepts and interface defined by the storage layer. Consequently, it providesthe means to share objects, extents, base values and structured values.Since every object is treated uniformly, it is natural to investigate the sharing of individualdata object instances. As mentioned during the introduction of the storage layer in Sec-tion 3.2.1, the storage model represents all objects through a unique identifier. On this ac-count, the methods responsible for exchanging objects given in the Peer interface take suchan identifier as argument. The granularity of sharing is determined by the identifier and itsreferenced object graph. A major goal of the sharing mechanism and its implementation istherefore to achieve database transparency for object sharing, so that clients of the frameworkdo not need to consider the underlying object structures and the involved operations. We aregoing to present the conceptual approach and then explain its final implementation in OMSAvon.

Conceptual Approach

Suppose we want to send an object from one database instance to the other database instance.Whenever one performs this action, the corresponding information units are sent rather thansending the object itself. On the receiver site, a new object will be created to which the unitsreceived will be attached in case this object does not already exist. Note that, as a result,the original and the remotely created object will be two distinct entities. However, it maybe possible that an object has previously been sent and therefore already exists in the remotedatabase. In that case, it is important to recognize the object to prevent the system fromcreating a new one. Figure 5.5 highlights the conceptual algorithm.

Algorithm 5.1: local side: exchangeInput: Identifier oidbegin

if oid == typeOf (oid)then

// meta modelsend (getUnits(oid),metaModel)

elsesend (getUnits(oid))exchange (typeOf (oid))

end

Algorithm 5.2: remote side: getObjectOutput: Identifier oidbegin

units receive ()if metaModel(units) then

// meta modelreturn query (TypeExtent,units)

elseoid getObject ()

return query (extent (oid),units)

end

Figure 5.5: Conceptual Exchange Algorithm

Earlier, we outlined the concepts of the storage layer by means of Figure 3.4. On the basis of


"Christoph" 24

"personType" { "name": String; "age": Integer }

"Type" { "name": String; "att": Set<Att> }

typeOf

typeOf

typeOf

Storage Layer

local remote

query(TypeExtent, v3)

query(<TypeExt>, v2)

query(<PersonTypeExt>, v1)

extent

extent

v2

v1

v3

Figure 5.6: Exchange Algorithm Concepts

that example we present our approach in more detail. Instead of sending the whole objectgraph attached to identifier oid17, we focus on minimizing the overhead while continuingto guarantee the supposed semantics. We avoid sending type descriptors and attempt toexchange information units only.

In the upper left corner of Figure 5.6, the content of the information units of the object refe-renced by oid17 are shown.In the first step, the values of the unit referenced as v1, are sent to the remote side, wherea query for an equivalent object is performed. The query operator requires two arguments,namely an extent and an array of values. The execution of a query attempts to match theobjects’ information units residing in the extent with the provided pattern of values held bythe second parameter. If a match occurs, we have been successful in finding an object that isidentical. Otherwise, a new object is created which the units of information are attached to.The last step presumes the dressing of the object with the right type. This issue is related tothe question what the proper extents are and where to get them from. It turns out that we needan extent of all objects that are dressed with the particular type.As seen in Figure 3.4, starting from oid17, we are able to follow the path to the identifieroid23 pointing to the information units of its associated person type. The same behavior canbe achieved by the typeOf function. Due to the fact that all information - both data and meta-data - is represented as objects, both schema and data can be handled uniformly with regardto distribution and sharing. The same mechanism of sending data is applied to the currentinformation units, namely v2. In order for the remote site to execute the query, it demands anextent. Here, we reach the point of departure as described above and hence continue recursi-vely.The typeOf operation is applied as long as we reach a situation where the source and destina-tion of the method is identical. This event is regarded as termination condition. The algorithmoperates on types of the OM meta model known on any OMS Avon database instance. Wetherefore supply the query operator on the remote site with a hard coded reference to an extent


of the meta model, namely TypeExtent. After having sent v3, the query runs on the providedextent and the array v3. The result is an identifier referencing a type. The extent methodforms a collection of all objects being dressed with that particular type and is then used asinput for the previous called query. Finally, the first initiated query returns the identifier tothe copy of the original object.

Technical Realization

In order to keep explanatory parts as simple as possible, only values for base types havebeen taken into consideration for the issue of data exchange so far. But the complexity ofan object grows as it can be dressed with several types whose attributes can comprise oneof various value types: Base Values, Object Values, Structured Values and Bulk Values. Anintermediate and self-contained representation of an object is proposed that gets rid of allidentifiers. Identifiers are system-generated entities that would lose their meaning outside thesystem and hence become useless on a remote machine.

+accept(Visitor): void

<<interface>>Node

+accept(Visitor)+getValue(): Object+getType(): BuiltInType

- value: Object- type: BuiltInType

BaseValueNode

+accept(Visitor)+getChildren(typeName: String)+addChildrenList(typeName: String, lst: List<Node>)

- children: Map<String, List<Node>>

ObjectNode

+accept(Visitor)+getChildren(typeName: String)

- children: List<Node>

RecordNode

+accept(Visitor)+getChildren(): List<Node>+setChildren(lst: List<Node>)+getTypeName: String+getBulkType: BulkType

- children: List<Node>- typeName: String- bulkType: BulkType

ExtentNode

+visit(BaseValueNode)+visit(ObjectNode)+visit(RecordNode)+visit(ExtentNode)

<<interface>>Visitor

ValueVisitor TypeVisitor

Figure 5.7: Visitor Pattern and the proposed Node Structure

ObjectEquality In OODBMS, different types of equality can be defined [10]. Traditionally,two objects are identity equal if they are the same object i.e., they are referenced by the sameOID. As we have to dispense with the use of identifiers, another equality indicator needs tobe in place. Our definition of object equality looks as follows:

Definition 2 (Object Equality) Two objects o1 and o2 are equal, if the following conditionshold:

• Both objects are dressed with the same object types: dressTypes(o1) == dressTypes(o2)

• For every object type ti of o1 and o2, the value of every attribute aj must be identical:8i 8j: o1:ti:aj == o2:ti:aj


It’s important to mention, that the current implementation excludes the equality checking onattributes whose type is a bulk. This is due to the fact that no equality operator in the algebraexists that works on the content of extents.

Serialization The serialization process transforms the above mentioned value types intoNode objects. Using object streams, these nodes can be sent from one database to the otherdatabase. Figure 5.7 illustrates the different node types. An instance of the Node class caneither be a BaseValueNode representing a base value, an ObjectNode representing anobject value, an ExtentNode representing a bulk value or a RecordNode representing astructured value. The ObjectNode consists of a map from the name of a type to a list ofnodes. This serialized representation reflects the fact that a given object instance may be dres-sed with several types. The ExtentNode is in possession of a bulk type (defining collectionvalues of given member type), the type name of the extent as well as a list of nodes represen-ting the serialized contents of the extent. The RecordNode is composed of a list of childrenrepresenting the contents of a structured value. Finally, the BaseValueNode comprises aBuiltInType together with the corresponding value as object. The algorithms to serializeobjects, extents, structured values as well as base values are listed in Appendix A.1.

Deserialization The deserialization mechanism makes use of the Visitor Pattern [6], whichis well-known in the field of compiler design. It represents an operation to be performed onthe elements of an object structure. Visitor lets you define a new operation without changingthe classes of the elements on which it operates. As visible in Figure 5.7, we provide twooperations: the TypeVisitor generates the type out of the node tree. As a side effect, alltypes that are necessary to build the initial type are created as well, if not already existent.After this preliminary work, the parsing through the ValueVisitor recreates the object towhich the contained values are attached. The algorithms to deserialize BaseValueNodes,RecordNodes, ObjectNodes as well as ExtentNodes are listed in the Appendix A.2.

5.2.3 Conversation-based Data Exchange

In general, no assumptions about the content of a remote database can be made. This regardsamong others the used application schemas and instances of the existent types. Despite thisfact, the successful exchange of objects should be assured. Whenever a user initiates thesending of an object to a remote OMS Avon database, some preparations run first. At thebeginning, it needs to be clarified in advance whether all types associated with the objectare known on the other machine. This is necessary in order for the receiver to be capable ofcreating the new object. If some types are missing, they will be transferred with the samesend method responsible for sending an object.The ValueVisitor takes care of building the needed types. After this step, the actualobject is finally copied to the remote site. These considerations are implemented in our dataexchange framework by means of the forced conversation concept. The whole workflow in-cluding single operations is drafted in Figure 5.8. The pictured utility corresponds to the classSharingUtility which is in possession of a range of useful methods such as serializa-tion and deserialization. It forms an indispensable part of every conversation as it providesthe access to collections and types of the meta model as well as transaction-related issues.


ActivePart Utility PassivePart

existTypes(<type names>)

Send <unknown type names>

opt

[<unknowntype

names> notempty?]

transformTypes(<types>)

<type trees>

Send <type trees>

Send <type names>

parseTypes(<type trees>)

Send <value tree>

transfromObject()

<value tree>

parseObject(<value tree>)

<type names>

<unknown type names>

getTypeNames(<Identifier>)

Figure 5.8: Sequence Diagram of Conversation-based Data Exchange

5.2.4 Typing versus Classification

Since the framework is realized as a low-level component working on the storage API, itonly covers the aspects of typing. The reception of data at this level guarantees the creationof types and their instances. We have faced the following issues: when sending informationunits, it needs to be determined which type is the appropriate one as there can be several typeshaving the same attribute type declarations. The second issue concerns the way to determineif an object already exists. As a solution for that, we have provided our own definition ofobject equality.At that time, classification concerns have not yet been taken into account. For example, whe-never an object is dressed with a type, it should automatically be added to the correspondingtype collection. In general, all the operations that follow the execution of the CRUD methodsdefined in the OM layer should be applied to low-level generated entities as well. We needto introduce a mechanism that notifies the classification layer of newly created objects andtypes in order that it accomplishes the task of putting these entities in to the right collections.The solution to this issue is to install an event system that is capable of informing interestedsubscribers, such as the OM layer, about events that occur within the storage layer. This hasbeen done as part of this thesis. The next section will describe the implementation of the


unified event model presented in Section 3.3.Last, but not least, the user needs to be able to specify in which collections an object shouldreside on the remote site, especially thinking of custom collections of an application domain.In order to meet this requirement, we extend our object-exchange conversation to support theinsertion of the sent object into the specified extents. Figure 5.9 offers a graphic impressionof the discussed issues. Starting from the upper layer, an object represented as an OMObjectinstance shall be migrated. The request is forwarded to the storage layer which transformsthe data attached to the object identifier into the intermediate presentation. This is indicatedby the orange box wrapping the actual object. On the remote side, the deserialization processis performed resulting in notifications for the OM layer. Afterwards, the copy process iscompleted and the object is available within the desired collections.

OM

API

TypingC

lassification

- create- dress- strip- delete- get/set

OMObjectCollectionAssociation

notif

y

send(OMObject)

local remote

send(Identifier)

notif

y

Figure 5.9: Typing versus Classification

44 5.3. EVENT MODULE

5.3 Event Module

In Section 3.3, we have introduced the customized version of the unified event model. Itsintegration into OMS Avon as database module is now presented together with the illustrationof the chosen architecture for the event system and the discussion of the implementationissues. It is shown how the event entities are mapped to Java classes, as well as how thesystem manages the event objects.

5.3.1 Model Classes

Before having a look at the event architecture, we will first introduce the model classes.

General Structure

In order to support the manipulation of the meta model concepts stored in the event schema, aCRUD class called EventCRUD was implemented. As the standard CRUD classes of OMSAvon, the EventCRUD is registered with the database and can be retrieved from an instanceof the class OMDatabase. As event model classes have certain structural similarities, wewill start by pointing out what they have in common.Using the given CRUD, we have always to provide the object, type and attribute name asarguments in order to manipulate its current value. The access to the attributes of an event en-tity should be simplified. In order to achieve this, every event entity whose data is intended tobe persistent, is realized through an implementation class. The class PersistentObjectwraps an object and a type object, both represented by an OMObject, and provides methodsto get and set attribute values. Herewith, we follow the approach of the Data Access Object(DAO) design pattern13. Its purpose is to abstract and encapsulate the entire access to thedata source and therefore to allow data access mechanisms to change independently of thecode that uses the data. The business object is regarded as the client and it requires accessto the data source to obtain and store data. It corresponds to all the Java classes that extendthe PersistentObject class. The business object delegates load and store operationsto the data access object. It abstracts the underlying data access implementation for thebusiness object to enable transparent access to the data source. This task is undertaken bythe EventCRUD.

Each concept defined by the unified event model is associated with an OM type that specifiesits properties through attribute declarations. These types are subtypes of the named objecttype which guarantees them to be unique and to allow easy retrieval by a dedicated CRUDworking on the named object collection. The event entities are identified by a unique name.Independent of the fact whether the state of a system entity is transient or made persistent,it implements an interface that defines those methods which need to be accessible for auser of the event system. An additional abstract class implements common behavior forall subclasses and extends the external interface by enriching it with those functionalitieswhich are needed by the runtime system to control the event entity. Figure 5.10 provides anoverview over the type hierarchy.

13http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html


<<interface>>EventEntity

<<abstract>>AbstractEventEntity

EventEntityImpl

+getBaseObject(): OMObject+getBaseObjectType(): OMObject

-baseObject: OMObject-objectType: OMObject

<<abstract>>PersistentObject

Figure 5.10: Event Entity Structure

As we operate directly on a database, we need to take into account the necessity of the transac-tional environment. Hence, all of the provided methods require a transaction as an argument.For reasons of simplicity, from now on only the abstract class and the interface together withits implementation will be shown, while the PersistenObject class and the transactionargument for methods will be omitted.

Event Type

Event types are the central event entity and will therefore be discussed first. Figure 5.11shows the supported event types and their common interface. It allows retrieving the uniquename and the current class of event type an instance resides in. The use of the ID will beexplained later.The design of the event model has focused on decoupling triggers and handlers from theevent type which they fire and subscribe to. This was achieved by introducing the EventManager as a central registration point where triggers and handlers can define their rela-tionship to existing event types. Whereas this separation considers the conceptual level, theimplementation itself needs to couple triggers and handlers with the appropriate event types.Both UserEventType and SystemEventType provide a list of synchronous handlersas can be seen in the abstract class they extend. Asynchronous ones are only provided byuser-defined types. This reflects the design decision that we allow user-defined triggers tobe executed either synchronously or asynchronously while system-defined triggers are al-ways executed synchronously. The latter type provides a list of user-defined types therewithenabling the one-to-many relationship between them.

Event Trigger

Figure 5.12 depicts the event trigger hierarchy. The LocalTrigger class combines thenotion of synchronous and asynchronous triggers that are fired by the local event system.One can see that a trigger holds a reference to the event type which it fires. The separationbetween user- and system-defined triggers is achieved through the associated event type.In general, an instance of the Java class representing this event entity encapsulates thecontext of its creation in form of references to involved objects. It is referred to as thedefinition context. Hence, a trigger is regarded as an information source that delivers data


+getName(): String+getEventTypeID: String

<<interface>>EventType

+setEventTypeID(String)+addHandler(Handler)+removeHandler(Handler)+getHandlers(): List<Handler>

- syncHandlers: List<Handler>

<<abstract>>AbstractEventType

+getUserTypes(): List<UserEType>+addUserType(UserEventType)+removeUserType(UserEventType)

-userTypes: List<UserEventType>

<<abstract>>SystemEventType

+getObject(): OMObject+setObject(OMObject)+addAsyncHandler(Handler)+removeAsyncHandler(Handler)+getAsyncHandlers: List<Handler>

-asyncHandlers: List<Handler>

<<abstract>>UserEventType

+setObjectType(OMObject)+getObjectType(): OMObject

SystemTypeEventType

+setObjectType(OMObject)+getObjectType(): OMObject+setAttributeName(String)+getAttributeName(): String

SystemAttributeEventType

+setExtent(OMObject)+getExtent(): OMObject

SystemExtentEventType

SystemGlobalEventType

+setObjectType(OMObject)+getObjectType(): OMObject

UserTypeEventType

+setObjectType(OMObject)+getObjectType(): OMObject+setAttributeName(String)+getAttributeName(): String

UserAttributeEventType

UserObjectEventType

+setCollection(OMObject)+getCollection(): OMObject

UserCollectionEventType

+setBulk(OMObject)+getBulk(): OMObject

UserBulkEventType

UserGlobalEventType

Figure 5.11: Event Type Hierarchy


+getName(): String

<<interface>>EventTrigger

-name: String-object: Identifier-objectTypeName: String-attributeName: String-collection: Identifier-hostName: String-port: int

RemoteTrigger

-name: String-eventType: EventType-object: OMObject-objectType: OMObject-attributeName: String-collection: OMObject-oldValue: Object-newValue: Object

LocalTrigger

<<abstract>>AbstractEventTrigger

Figure 5.12: Event Trigger Hierarchy

to handlers for further use. As distinguished from the previous implementation of the eventsystem [23], triggers are transient entities that are not stored in the database because theirlifetime is extremely short and the gain of functionality would be insignificant; this de-cision also has good effects on the performance since triggers reside in the main memory only.

The event system is enhanced with distributed capabilities. That applies to triggers in particu-lar which support the migration of event data to remote event sites. The RemoteTriggerclass is a wrapper for such information intended to be sent across the network. In contrast tothe local trigger, the attributes differ with respect to their type declarations. Remember thatthe OMObject loses its meaning outside the system as the identifier that it holds correspondsto a database-dependent construct. The types are chosen in such a way that they can be ea-sily exchanged between different event sites and still suffice to restore the actual content: thereceiver of a remote trigger is urged to use the connectivity framework to get the objects andvalues referenced by the provided identifiers. That is why the host name and port are listedas well.

Event Handler

Having covered event types and triggers, we now have a closer look at the event handlers andthe event actions. There are basically two types of handlers which can be accessed throughthe interface: synchronous and asynchronous ones. When a handler is attached to an eventtype, it is added to the appropriate list of handlers which is determined by its responsiveness toeither synchronous or asynchronous triggers. However, the system also needs to distinguishlocal from remote handlers for which a different site needs to be called if a handler is invoked.Therefore, when using remote handlers, local handlers are wrapped both on the source as wellas on the target site. The wrapper created locally is called Remote Listener, the one createdat the remote site is the Remote Handler.


+getName(): String+getHandlerTypeID: String

<<interface>>EventHandler

SyncEventHandler

+getAction(): Action+setAction(Action)+getObject(): OMObject+setObject(OMObject)+getEventType(): EventType+setEventType(EventType)

<<abstract>>AbstractEventHandler

+remoteExecute(RemoteTrigger)+getEventSite(): EventSite+setEventSite(EventSite)

RemoteEventHandler

+localExecute(RemoteTrigger)+getEventSite(): EventSite+setEventSite(EventSite)

RemoteEventListener

+getRuntimeAction: Action+setRuntimeAction(Action)

-runtimeAction: Action

AsyncEventHandler

Figure 5.13: Event Handler Hierarchy

Figure 5.13 points out how this is realized as part of the class hierarchy. A remote handleris executed as a result of synchronous occurrences of events, whereas the remote listener isinformed asynchronously from outside the system. If the event system fires a trigger andinvokes the subscribed event handlers, it does not need to distinguish between local or remotehandlers. If the remoteExecute method is called on a remote handler, the handler willautomatically create a remote call and inform the origin site about the event. At the originsite, the event system will get hold of the matching remote listener and invoke its local action.The idea behind this approach stems from the Proxy Pattern14. Its target is to define a sur-rogate, the RemoteEventHandler, that functions as an interface to a real subject, theRemoteEventListener, to control access to and manipulate the real subject.

EventAction The handler class is designed in such a way that the handler and the action thatis called upon the notification of an event are separated. With this approach, it is possible toeasily extend existing event actions without having to deal with the question of how handlerssubscribe to event types or when handlers are called. Since saving the implementation codeof a Java method in an OMS Avon database demands a complex and more sophisticatedsolution, we address this issue in a different manner.An abstract class, as shown in Figure 5.14, is provided whose methods need to be implemen-ted as part of a subclass in order for the developer to define its own action. The synchronous

14http://en.wikipedia.org/wiki/Proxy pattern


action is executed whenever a synchronous event is fired, while the asynchronous action isinvoked when an asynchronous trigger is fired. Note that the latter method includes remotetriggers.

+Action(OMDatabase)+getDatabase(): OMDatabase+syncAction(LocalTrigger)+asyncAction(EventTrigger)

-database: OMDatabase

<<abstract>>Action

Figure 5.14: Event Action

The path together with the name of the concrete implementation is saved in the database asa string. Calling the getAction function results in the retrieval of the fully qualified classname. Using this string, an instance can be created at runtime by means of Java Reflection15.

Event Site

Upon the reception of a remote trigger, registered observers will be notified along with theidentifier of the manipulated or created object and the source from which the data has been re-ceived. The term event site denominates such a source. It provides the necessary informationto allow the local event system to contact another one at a remote site. Various communi-cation channels can be considered for data exchange, e.g. Bluetooth and TCP sockets. Thefact that they come along with different interfaces must be taken into account. As a result, theclass hierarchy for event sites shown in Figure 5.15 reflects this fact by introducing a concreteimplementation for every interface.

+getName(): String+getSiteTypeID: String

<<interface>>EventSite

<<abstract>>AbstractEventSite

+getHostName(): String+getPort(): int

SocketEventSite BluetoothEventSite

Figure 5.15: Event Site Hierarchy

15http://java.sun.com/docs/books/tutorial/reflect/index.html


5.3.2 Event Manager

The EventManager constitutes the core class of the system and thus encompasses an in-terface which lets local routines control the event system. Figure 5.16 shows the list of itsmembers and the available functionality. To improve readability, the transaction argument isomitted. The previously introduced event model classes are used by the event system itself.

+startEventSystem(port: int)+stopEventSystem()+addSystemType(SystemEventType)+addUserType(UserEventType)+removeType(EventType)+getType(String): EventType+fireSystemTrigger(LocalTrigger)+fireSyncUserTrigger(LocalTrigger)+fireAsyncUserTrigger(LocalTrigger)+addHandler(EventHandler)+removeHandler(EventHandler)+getHandler(String): EventHandler+executeAction(EventHandler, EventTrigger)

-database: OMDatabase-siteManager: SiteManager-typeMap: Map<String, EventType>-handlerMap: Map<String, EventHandler>-remoteHandlerQueue: List<HandlerWrapper>-asyncTriggers: List<EventTrigger>-objectMap: Map<OMObject, UserObjectEventType>-listener: StorageListener

EventManager

Figure 5.16: Event Manager

Remember that any attempt to read the attributes of an event entity leads to an operationon the underlying database and that its manipulation results in the direct forwarding of thechanges to the database in order to make them immediately persistent. Using this approachavoids some difficulties in terms of synchronization which would arise when simultaneouslymanaging both a runtime data structure and a persistent data structure that can be accessedindependently. It is more likely that the system remains in a consistent and up-to-date state,especially after a crash or an unexpected shutdown.

Runtime Structure

For performance reasons, the event objects are held in hash maps which are also referred toas tables. The event type table will contain the largest number of objects, as for every objecttype the system inserts predefined event types that model database triggers. Even takingapplications with about a hundred object types into account, the memory consumption due tothese tables is still negligible.

• Type Table: The event types are kept in a hash table where the key is the event typename and the value holds the event type object. As mentioned previously, event typenames must be unique, if they are not, we cannot make use of a map to hold the eventtypes.

• Handler Table: The handler table contains all handler objects and is represented as ahash map, too. Its key is a system-generated handler identifier.


• Handler Queue: A queue of handlers whose execution has not yet been successful.

• Trigger List: Collection of triggers that are intended to be executed asynchronouslywithin a separate transaction.

• Object Table: Whenever a user creates an event type for a specific object, it will bestored together with the event type.

Every time an event type is added, it will be inserted in the type table. Apart from that,the addUserType method takes care of linking user-defined event types with the system-defined ones they rely on.

Event Execution

The EventManager class is responsible for firing triggers and notifying subscribed hand-lers. The method fireSystemTrigger constitutes the entry point for the explanationof that functionality. It takes a system trigger as the argument which holds all the neces-sary information for further processing. First of all, the associated system event type isretrieved that holds a list of handlers which will be executed synchronously in turn: uponcalling the executeAction method, the associated Action instance is created whosesynchronous operation will be invoked. Every system-defined event type holds references touser-defined counterparts. For every user-defined event type, a user trigger is created and thefireSyncUserTrigger method will be called. Similar to the previous case, the actionsdefined by its handlers are performed. But additionally, the user triggers are added to theasynchronous trigger list.Beside the EventManager class itself, there is another class involved in the execu-tion of events. Whenever it is recognized that a transaction has been committed, theAsyncEventExecutor class comes into play. This class is concerned with the asyn-chronous execution of triggers. After handing over the current trigger list, a separate threadis started which notifies all observers in a similar fashion as before, but with the differencethat it invokes the asyncAction method.During this whole process, it is possible that the execution of a remote handler could not beperformed, e.g. due to disconnection. As a consequence, the proxy object and the fired triggerare saved within a wrapper object called HandlerWrapper and added to the handler queue.Another attempt to execute the handler action is postponed until the next invocation of thefireSystemTrigger method.

Scenario We have mentioned that updates on event model classes are directly propagated tothe storage in order for the system to immediately reflect the current runtime state. Aside fromthe advantages, it also carries inherent dangers. One problem is visualized in Figure 5.17.Let’s assume that a user starts a transaction tx4 whose first operation creates some event typecalled eType8. The following events, namely dress and update, create triggers that are firedon eType8. As a next step, the event type is deleted. As a consequence, the created triggerof the next action has no receiver. As part of the commit of the current transaction, a newseparate thread will be started that fires the triggers once again in an asynchronous manner,but at this point in time, the event type eType8 does not exist anymore and hence the triggerscannot be executed. Our event manager faces these issues by relying on the runtime system.


It caches certain references that allow retaining event entities, in particular the eType8 in thisscenario.

time

create event type eType8 dress update delete

eType8 strip committx4

starttx4

starttx7

committx7

trigger foreType8

trigger foreType8

start async transaction tx7

triggers foreType8

Figure 5.17: Event Execution Scenario

5.3.3 Site Manager

The SiteManager class holds information about known remote sites in a correspondingtable. It also contains data that describes the local site. In case of socket event sites, thiscorresponds to the host names and to the question on what port the sites can be reached.Furthermore, the site manager is responsible for sending commands to remote sites. Thefunctionality covered by the commands includes the means to create and delete remote hand-lers, to execute a remote listener and to fire a trigger on a remote site.We have already discussed how the event system supports the definition of a remote handleron a remote site, namely by introducing a local part, called the remote listener, as well asa remote part, called remote handler. Whereas the remote handler is treated like a normalhandler, the remote listener must be invoked by the event system when a remote event hashappened.

+startSiteManager()+stopSiteManager()+createRemoteHandler(EventSite, EventType)+deleteRemoteHandler(EventHandler)+fireRemoteTrigger(EventSite, EventType, Object)+addEventSite(EventSite)+removeEventSite(EventSite)+getEventSite(String): EventSite

-localSite: EventSite-eventManager: EventManager-connectivity: ConnectivityManager-peer: Peer-siteMap: Map<String, EventSite>

SiteManager

Figure 5.18: Site Manager

Communication

As denoted in Figure 5.18, for communication purposes, we make use of the connectivitycomponent introduced in Section 5.2. The commands are implemented and wrapped by mes-sages in order to send them over the network. Basically, a message object defines the com-


munication end points. Additionally, it is provided with data that is needed for the successfulexecution of the corresponding command. We define our own forced conversation which bothaccepts the available messages and initiates the appropriate operations on the remote site.

5.3.4 Integration

Having introduced the event model classes followed by the manager classes, we go on topresent the architecture of the event system.

Type

Handler Trigger

Storage

Event Manager

Site Manager

Event System API

Storage Listener

Persistent Object

OM

Model

CR

UD

Connectivity

Client Applications

Figure 5.19: Event System Architecture

Figure 5.19 depicts its composition consisting of the event entities together with other mo-dules and components. The bottom layer constitutes the low-level layer that deals with net-work and communication issues as well as persistency concerns. The event system is realizedas a modular extension of OMS Avon. There are two additional boxes as part of the mo-dule that have not been mentioned yet. The storage listener can be regarded as a connectorbetween the storage events and the event system. In contrast, the event system API resideson a higher level which is building the entry point of the module. Based on this interface,developers can design their own applications in making use of the functionality that the eventsystem supports. They will be discussed in turn.

Event Hooks

Another task of this thesis was to attach a source to the system which feeds it with events.The event manager subscribes to ”hooks” that are part of the extension points defined bythe core database module. Using these hooks, the event manager can subscribe listeners forthe detection and propagation of events as they occur. Figure 5.20 illustrates the two listenerinterfaces and their most important methods. Besides, all data associated to storage andtransaction events is wrapped by the StorageEvent class and the TransactionEventclass respectively.The StorageEventListener interface specifies various kinds of callbacks. Object typecallbacks are used to manage the DRESS, UPDATE and STRIP event types which are crea-ted for every OM object type that came into existence while the event system was running.The UPDATE activity indicates a change of an attribute of an object type. The interface alsocontains the methods which allow the event system to trigger the above mentioned activities


+objectCreated(StorageEvent)+objectDeleted(StorageEvent)+objectDressed(StorageEvent)+objectStripped(StorageEvent)+objectUpdated(StorageEvent)+objectTypeCreated(StorageEvent)+objectTypeDeleted(StorageEvent)+extentCreated(StorageEvent)+extentDeleted(StorageEvent)+extentInsert(StorageEvent)+extentRemove(StorageEvent)

<<interface>>StorageEventListener

+transactionStarted(TransactionEvent)+onCommit(TransactionEvent)+onAbort(TransactionEvent);

<<interface>>TransactionEventListener

Figure 5.20: Event Hooks

of the corresponding object types. Similarly, the extent observers allow managing the cor-responding event types for storage extents, namely the INSERT and REMOVE event types.The event system gets informed when objects are added to or removed from extents. As seenbefore, the system uses these callbacks to create triggers for the corresponding event types.As defined by the TransactionEventListener, it observes actions such as the start,abort and commit of a transaction.

System Startup

When a new database instance is created, the core module is loaded first. As soon as the coresystem is running, the event module is started and the event manager class is instantiated. Itis responsible for creating the global runtime structure and hence the event model runtimeobjects.The initiated bootstrap process needs to follow a specific order starting with loading thesystem-defined event types. Here, the event type ID comes into play. It tells us which class ofevent type it belongs to. According to this information, the Java class representing that eventtype is instantiated. Afterwards, the user-defined event types need to be integrated into theruntime system. The next task can be found in the bootstrapping of the event handlers. Thepurpose of the event handler ID matches the one that has been explained before. Before theevent manager finally registers an observer that listens to event hooks that are integrated inthe storage layer, the communication endpoints are created by the site manager. It loads theknown event sites from the database and initializes the connectivity component.

Event System Interface

The UML diagram in Figure 5.21 presents the available methods that users of the eventsystem module are offered. In general, it covers the creation and deletion of the evententities. In particular, the manipulation of the various kinds of event types and event handlersis supported. As the event model is enhanced with distributed capabilities, the interfaceincludes the handling of remote handlers. Besides, the firing of remote triggers is enabled aswell. The methods demand a reference to the database which the event system is running onand a valid transaction. These two arguments are not shown in the UML diagram.

This section has outlined the implementation of the customized version of the event model.


+startEventSystem(port: int)+stopEventSystem()+createTypeEventType(type: OMObject): EventType+createTypeEventType(type, object: OMObject): EventType+createAttributeEventType(type: OMObject, attName: String): EventType+createAttributeEventType(type, object OMObject, attName: String): EventType+createCollectionEventType(collection: OMObject): EventType+createCollectionEventType(collection, object: OMObject): EventType+createObjectEventType(object: OMObject): EventType+createGlobalEventType(status: String): EventType+deleteUserEventType(eventType: EventType)+createSyncHandler(type: EventType, action: Action): EventHandler+createAsyncHandler(type: EventType, action: Action): EventHandler+createRemoteHandler(site: EventSite, type: String, action: Action): EventHandler+deleteEventHandler(handler: EventHandler)+fireRemoteTrigger(site: EventSite, type: String, someArg: Object)+createSocketEventSite(host: String, port: int): SocketEventSite+deleteEventSite(site: EventSite)

<<interface>>EventSystem

Figure 5.21: Event System API

The proposed model focuses on simplifying the implementation as well as on using it. It hasbeen reduced in its complexity in such a way that it only covers the necessary functionalityfor our work. In this way, a clear and reliable realization of the event module has beenachieved. The following use case should give an impression of how easy it is to developa distributed application based on our event module. The benefit of the decentralizedcomponents, namely triggers and handlers, shall also be illustrated:

There exist the four event sites s1 to s4. Site s1 runs a smoke detector application, while sites2 acts as the central authority responsible for the maintenance of the building in which thesmoke detector is installed. Site s3 corresponds to a fire department and s4 is associatedwith a newspaper which intends to inform the public about fires in the surroundings as soonas such an incident occurs. In this scenario, an event type FIRE DETECTED would bedefined at the maintenance authority and site s3 as well as s4 would create a handler at sites2 that listens for the latter event type. Imagine the situation where a careless person lights acigarette within the building, not complying with the legal requirements. Upon the detectionof smoke, site s1 creates an event trigger at site s2 to signal that a possible fire has beenidentified. The event system at the maintenance authority processes the trigger and informsthe fire department at s3 and the newspaper at site 4. One day later, the story about theirresponsible culprit is printed in the newspaper.

Its realization in Java is documented in Figure 5.22. For the sake of readability, allcode parts dealing with transactions are omitted. The three different action instancesMaintenanceAction, FireDepartmentAction and NewspaperAction imple-ment the activities of the corresponding sites that are triggered as a result of the fire detection.


public class UseCase {

// OMDatabaseprivate OMDatabase detector;private OMDatabase maintenance;private OMDatabase fireDepartment;private OMDatabase newspaper;

// Site for fire detectorprivate EventSite siteMaintenance;...

public void setupEventSites() {final EventSystem eventSystem = new EventSystemImpl();

// start event system for every entityeventSystem.startEventSystem(this.detector, 7667);eventSystem.startEventSystem(this.maintenance, 7777);eventSystem.startEventSystem(this.fireDepartment, 7887);eventSystem.startEventSystem(this.newspaper, 7997);

// Fire detectorthis.siteMaintenance = eventSystem.createEventSite(

this.detector, "localhost", 7777);

// Maintenancefinal EventType type = eventSystem.createGlobalEventType(

this.maintenance, "FIRE_DETECTED");eventSystem.createAsyncHandler(this.maintenance, type,

new MaintenanceAction(this.maintenance));

// Fire departmentEventSite site = eventSystem.createEventSite(

this.fireDepartment, "localhost", 7777);eventSystem.createRemoteHandler(this.fireDepartment, site,

"FIRE_DETECTED",new FireDepartmentAction(this.fireDepartment));

// Newspapersite = eventSystem.createEventSite(this.newspaper,

"localhost", 7777);eventSystem.createRemoteHandler(this.newspaper, site,

"FIRE_DETECTED", new NewspaperAction(this.newspaper));

}

public void startUseCase() {// remote trigger - fire detectedeventSystem.fireRemoteTrigger(this.detector,

this.siteMaintenance, "FIRE_DETECTED");}

}

Figure 5.22: Implementation of a Use Case


5.4 Vicinity Module

The opportunity to exchange data with other users demands the knowledge about currentlyavailable users in physical proximity. Chapter 4 has introduced the Vicinity collection whichcontains all the devices currently in physical proximity. This section describes the design andimplementation of a module that provides high-level primitives to support vicinity sensing.In a real-world setting, wireless communication technologies such as Bluetooth would scanthe environment on a periodic basis reporting on the detected devices. In this thesis, since wehave no real vicinity as we work with desktop computers, we have to simulate the enteringand leaving of peers. Remember that the appearance and disappearance of peers in vicinityare the driving forces to the sharing process.We define a vicinity API consisting of methods to initiate and stop the scanning of the envi-ronment. As we program to this interface, its concrete implementations can easily be exchan-ged. In this particular case, the interface is implemented in such a way that a central serveris requested to provide a list of peers in vicinity for a given point in time. The central serverreplies by looking up an XML file defining this list for each participant peer. The intentionof the client/server architecture is to simulate the usual separation between users and theircommon environment.

5.4.1 Client Side

First, we will take a look at the Vicinity API and its concrete implementation. The scanmethod initiates a single scan of the vicinity, whereas the same method together with the ar-gument is supposed to sense the close environment on a regular basis. The argument definesthe time period in seconds between single scan attempts. The VicinityImpl class relieson Java’s timer facility to schedule tasks for one-time or repeated execution. Every invoca-tion results in the instantiation of a thread that contacts the server. Before the execution ofthe thread finishes, it reports the set of peers that are available. As it has been defined withinthe opening paragraph, the term peer refers to devices capable of taking part in an exchangeof data. The interface Peer specifies that the host name and the port of a particular peershould be retrievable. Beside this contact information, a unique ID is in place for identifica-tion purposes. Furthermore, Vicinity makes use of the observer pattern. The set of peersis forwarded to all observers that are interested in this information. The consumer of this kindof information is the representative of the VicinityCollection class. As the name al-ready suggests, it is related to the Vicinity collection. It is responsible for synchronizing thereceived set of peers with the actual Vicinity collection in such a way, that newly availablepeers are inserted, and peers that are no longer visible are removed. Only the appearance anddisappearance of peers between two scanning instances must be considered in order to gua-rantee that information sharing is triggered in a proper manner. To stop this whole process, ahomonymous method is given. The client side classes together with the introduced interfacesare illustrated in Figure 5.23.The communication between the client side and the central server is based on the TCPobject stream. Whenever a scan request is launched, the vicinity implementation sends aVicinityRequestMessage to the central server. It contains the reference to the peeron behalf of which the request was submitted. In turn, the central server responds with aVicinityMessage containing the set of peers which reside in the requester’s vicinity atthat particular point of time. We have not yet covered how an answer to an inquiry is compo-

58 5.4. VICINITY MODULE

+scan()+scan(period: int)+stop()

<<Observable>>Vicinity

+updateVicinity(Set<Peer>)+getPeer: Peer

-vicinityServerHost: String-vicinityServerPort: int-peer: Peer-timer: Timer

VicinityImpl

<<Runnable>>VicinityImplThread

*

+getHost(): String+getPort(): int+getPid(): String

<<interface>>Peer

VicinityPeer

+update(arg: Object)

-db: OMDatabase-crud: VicinityCRUD-vicinity: Set<Peer>

<<Observable>>VicinityCollection

notifies

Figure 5.23: Client Side of Vicinity Implementation

sed. This issue is covered in the following section.

5.4.2 Server Side

On startup, the vicinity server is supplied with an XML document containing all necessaryinformation to define an environment of peers for any particular point of time. Below, a smallexample of such a document is illustrated:

<?xml version="1.0" encoding="UTF-8"?><vicinities>

<vicinity start="2" end="5"><peer pid="u1" host="localhost" port="7777">

<neighbour pid="u2" /></peer><peer pid="u2" host="localhost" port="8888">

<neighbour pid="u1" /><neighbour pid="u3" />

</peer><peer pid="u3" host="localhost" port="9999" />

</vicinity></vicinities>

The document needs to conform to the schema defined in Appendix B. The schema definesthe vicinities tag to be the root element of the document containing an arbitrary number ofvicinity elements. The content of such an element determines which peers are available forthe period of time specified by the start and end attribute. These values can be interpretedas any discrete time step such as seconds. A peer is introduced with the corresponding hostname, port and the unique ID as part of his attributes. Every peer element can hold a numberof neighbour elements representing the peers in its vicinity. As a consequence, it is possibleto create a situation where visibility is not considered as a symmetric property which reflectsreal world scenarios.During the bootstrap of the server, the referenced XML document is parsed and a properruntime structure is created that allows easy retrieval of the contained data. As visualized inFigure 5.24, the VicinityServer class is provided with a list of VicinityWrapper


+start()+stop()

-threadPool: ExecutorService-server: ServerSocket-port: int-startTime: long-xmlParser: VicinityXML

<<Runnable>>VicinityServer

+addPeer(key: Peer, p: Peer)+getVicinity(key: Peer): Set<Peer>+getStartTime(): int+getEndTime(): int

-vicinity: Map<Peer, Set<Peer>>-startTime: int-endTime: int

VicinityWrapper

*

<<Runnable>>VicinityWorker

*

Figure 5.24: Server Side of Vicinity Implementation

objects. Their purpose is to capture information associated with vicinity elements. Afterhaving built the runtime structure, a timer is initiated, starting to count from zero upwards.Whenever a request comes in, a separate worker thread, namely VicinityWorker, isstarted. Its task is to make a lookup on the runtime structure taking into account the currentserver time and the requesting peer. The query returns the set of peers that are detected in itsvicinity.

5.5 Sharing Module

We have outlined the design and implementation of the components that build the foundationwhich the final module is based on. It dedicates itself to the execution of the different sha-ring modes. By using OMS Avon as the data management layer, developers have implicitlydecided to design their application by means of the OM data model. Within this setting, thenotion of collection plays a crucial role as it comprises the basic building block of the model.As a consequence, the granularity of sharing is defined through collections and their contai-ned objects. A set of methods is given that can be used to make a collection available forsharing, connect it to other peers and exchange its members. In order for two different peersto share data, both peers have to make the collection to be shared available. When the twopeers reside in each other’s vicinity, available collections with the same name and membertype can be connected. All members or a proper subset can be sent. Such a subset can bedetected by means of a query expression attached to the collection. For instance, a selectionquery can be bound to a collection to filter data exchanged with remote peers. It is expressedand evaluated based on OMS Avon’s query facilities.

5.5.1 Functionality

Translating this approach to our programming environment results in the API pictured inFigure 5.25. The Sharing interface provides the main feature makeAvailable. As thefirst argument, it takes the collection intended to be shared, referenced by an OMObject. Thesecond one is the query that is registered along with the collection. Finally, we can choosewhich mode of sharing is applied: persistent copy, transient copy, persistent synchronizationand transient synchronization. In order to simplify common usage, two additional methods

60 5.5. SHARING MODULE

directly specify that all or no collection members are shared. This functionality is coveredby the makeAllAvailable and the makeVisible method respectively. Note that thelatter one does not send any objects but is made available for reception.

+startSharingSystem(host: String, port: int, sID: String)+stopSharingSystem()+makeAvailable(collection: OMObject, root: QueryNode, mode: SharingMode)

+makeAllAvailable(collection: OMObject, mode: SharingMode)+makeVisible(collection: OMObject)+makeUnavailable(collection: OMObject)+setSharingMode(collection: OMObject, mode: SharingMode)

<<interface>>Sharing

+processArrival(user: OMObject)+processDeparture(user: OMObject)+processPassive()

-db: OMDatabase-crud: SharingCRUD-eventSystem: EventSystem-peer: Peer-localPeer: VicinityPeer-queryUtil: QueryUtil-sharing: Map<String, SharingWrapper>-sync: Map<Identifier, Identifier>-syncEventType: EventType

SharingImpl

Figure 5.25: Sharing Interface and its Implementation

As can be seen in the class SharingImpl, a map from the collection name toSharingWrapper objects is provided. This will be filled with entries, every time one ofthe previous mentioned methods is invoked. The SharingWrapper holds all informationthat was supplied in terms of arguments. Furthermore, it is enhanced with facilities enablingthe execution of the query on the associated collection. The method setSharingModeallows to dynamically adapt the sharing mode at runtime.

Bootstrap

Before the actual sharing of objects can take place, the module needs to be started. The corres-ponding method asks for a host name, a port and an ID. The first act of the bootstrap processconsists of starting the event system on the specified port. Its server component constitutes asingle point of access for remote peers covering distributed event handling concerns as wellas the matters of data sharing. In order for the sharing system to be able to react upon theappearance or disappearance of peers in the vicinity, a collection event type is created forthe Vicinity collection. Additionally, a synchronous handler coupled with the event type isinstalled along with an instance of the action class VicinityAction. The bootstrap endswith the creation of a global event type. Its use is explained in the following section.


Data Exchange

The action method of the VicinityAction class gets a trigger object that allows distin-guishing whether a peer has entered or left the scene. Depending on the activity, the methodprocessArrival or processDeparture is invoked respectively. In the first case, forall available collections, the attached query is executed and the result is sent to the new peerby means of a forced conversation. It guarantees that all objects are inserted into the properapplication-specific collections unless they are not made available on the remote site. It alsohandles the insertions into the model-based collections according to the sharing mode beingused. The guideline for every mode is defined in Figure 4.3. The task of the second methodis to delete all transient objects that have been sent by the vanished peer. The QueryUtilclass helps in achieving that goal as it provides the facility to search for objects of the desiredkind. Having covered the part that deals with the concept of data continuity, we now go on toexamine how data coupling is realized.

Data Synchronization

Whenever a peer is faced with the discovery of another one that has never been detectedbefore, it attempts to create a remote handler that listens to the already mentioned globalevent type. Triggers for this kind of type are fired in case of changes to objects that residewithin the Synchronization collection of the sharing model. Updates on these objects aredirectly forwarded to all former recipients that are still in vicinity. The synchronous actionmethod of the SyncAction class is assigned with this task, while the asynchronous methodapplies received updates to the corresponding objects. As explained in Section 5.3.2, actionsmight not have been successfully executed due to network disconnections. Reattempts arescheduled by the event system so that all destinations might be reached once.

5.5.2 Summary

Event SystemConnectivity

SharingModel

VicinityAction

Sharing API

SyncAction

OM

Mod

el CRUD

Mobile Applications

Vicinity

QueryUtil

Wrapper

Conversation

Event Type

Figure 5.26: Sharing System Architecture

When the module’s perspective is considered in terms of its architecture, one would obtaina view similar to the one depicted in Figure 5.26. At the bottom, the three building blocks,namely the Vicinity Module, the Event Module as well as the Connectivity component, state

62 5.5. SHARING MODULE

the fundament. The vicinity sensing utility combined with the event system triggers theinformation sharing process. All interchanges with systems outside are performed throughthe connectivity component that was initiated as part of the event system. The core of thesharing module constitutes the entities that have been identified in the previous sections.On top of the module, developers can make use of its API to implement innovative mobileapplications.

6Showcase Application

To test and validate the implementation of the event-based information sharing system, ashowcase application named Avonopolis has been developed. One of the main challengesconsists in coming up with an idea of a single application that incorporates and unifies thefour sharing modes. Besides demonstrating the usefulness of the concepts, the applicationitself should be useful. By this we mean that the experimental system could be migrated to areal world environment and has the potential to be deployed as part of a business solution.

6.1 Avonopolis

The vision behind Avonopolis is to enhance movie theaters with technical facilities in orderto provide new ways of interaction with the customer. When a customer intends to watch amovie, he orders a ticket at the booth. This usual course of action requires that one needsto be physically present and that the user spends time waiting in the queue. To avoid theseshortcomings, we propose an approach which makes use of the computing and communica-tion devices that most people carry around all the time. Before the user effectively is goingto buy a ticket, he first needs to be provided with a list of available movies together withadditional information, e.g. the start time. This process along with the order and delivery oftickets can be performed through a single handheld device. As the application is embeddedin a business context, the ability to advertise special offers is supported as well.

6.1.1 Application Schema

Throughout the thesis, we have followed the principle to keep things as simple as possible.This still holds for the meta model of the Avonopolis application. Figure 6.1 depicts the typesand corresponding collections. All types come along with a unique ID similar to the conceptof primary keys in the relational model.The movieType consists of a name, a start time and a description. A ticketType has asattributes a peer and a movie item as well as a status which indicates whether the ticket is

63

64 6.1. AVONOPOLIS

movieType

Movies

id: stringname: stringtime: datedescription: string

movieType

id: stringuser: peerTypemovie: movieType

orderType

id: stringuser: peerType movie: movieTypestatus: string

ticketType

id: stringtext: stringimage: blob

advertType

ticketType

Tickets

orderType

Orders

advertType

Advertisements

Figure 6.1: Model of the Avonopolis Application

valid or has already expired. An orderType contains a peer and a movie object. In terms ofadvertisements, an image together with a catchy phrase can be specified when an object oftype advertType is created.

6.1.2 Architecture

Two roles can be identified when investigating the domain requirements: on the one hand,there are administrators managing the tickets and list of movies. On the other hand, there arecustomers which want to buy tickets. Our architecture reflects this separation by distingui-shing clients, the customers, and a server component, the theater. Furthermore, we considera software design pattern called three-tier architecture model16. It segments the componentsof an application into three tiers of services: a presentation tier, a business tier and a datatier. These tiers do not necessarily correspond to physical locations on various computers ina network, but rather to logical layers of the application. How the pieces of an applicationare distributed in a physical topology may change, depending on the system requirements.Following are brief descriptions of the services allocated to each tier:

• The presentation tier gives a user access to the application. In our case, this layerpresents data to the user via a graphical user interface (GUI). The GUI also permitsmanipulation and entry of data.

• The business tier consists of business and data rules. It controls the functionality of ourapplication and serves as connector between the presentation and data tier.

• The data tier interacts with persistent data stored in a database or in permanent storage.Here, we deal with the OMS Avon database extended with the modules that have beenimplemented and designed as part of this thesis.

Figure 6.2 shows the overview of the architecture. The horizontal dimension distinguishesclient and server, while the vertical dimension separates the three tiers.

Usually, when designing and programming an application that provides a GUI, the Model-View-Control (MVC) [6] design pattern is considered. Model-Delegate is a variation of the

16http://www.linuxjournal.com/article/3508

CHAPTER 6. SHOWCASE APPLICATION 65

ClientServer

Pre

sent

atio

n Ti

erB

usin

ess

Tier

Dat

a Ti

er

Avon DatabaseAvon Database

Vicinity Server

Connectivity

View/ControllerView/Controller

Model Classes

SharingModule

EventModule

SharingModule

EventModule

Model Classes

Figure 6.2: Architecture of Avonopolis

66 6.2. SCENARIO

MVC pattern. Two of the three responsibilities from MVC, namely the view and controllerpart, are brought together in a so-called User Interface (UI) Delegate. The communicationbetween the UI and the database is restricted to synchronous interaction based on request andresponse. An application required to react to changes to the state of a database has to pollfor this information by repeated querying. Clearly, an asynchronous approach enabling thedatabase to inform the application as soon as new information is available would be moreefficient and thus preferable. Our event system undertakes the task of updating the graphicaluser interface according to the applied changes.A client and a server component can exchange data using the connectivity module. At thebottom of the figure, the vicinity server can be found which manages information about thephysical proximity of the server and its clients. Note that this server has been deployed forsimulation purposes.

6.2 Scenario

Our use case comprises four steps. Every step handles a different sharing mode and covers aclient/server interaction scenario. The background story is simple: a user called Bob intendsto go to the movies. He decides to visit an Avonopolis cinema center. Being aware of thenew facilities that Avonopolis offers to its customers, he installs the necessary software onhis mobile phone. Afterwards, he heads to the nearest center.

6.2.1 Persistent Synchronization

When Bob enters the building, his device automatically connects to the Avonopolis server.As a result, the current movie program is presented to him. The application running on Bob’shandheld device specifies the Movie collection as visible, while the server application makesits entire content available.

Figure 6.3: Persistent Synchronization

Whenever changes on the movie items are carried out on the server, the updates are forwardedto all visitors including Bob. Bear in mind that only the owner of the original objects can


manipulate them. In this manner, the administrators of Avonopolis may add, update andremove movie items. The UI of Bob’s handheld directly reflects the change (see Figure 6.3).

6.2.2 Transient Synchronization

The range of movies makes it difficult for Bob to choose the appropriate one. Suddenly,an advertisement pops up that states that he won a free ticket for Benjamin Button (see Fi-gure 6.4). The Advertisement collection is made visible on Bob’s device and made availableon the server side. As long as Bob resides within the Avonopolis building, advertisementscan be distributed and updated at any time.

Figure 6.4: Transient Synchronization

6.2.3 Persistent Copy

Due to this advertisement, Bob decides to watch Benjamin Button. After having selected thisparticular movie, he clicks on the order button. The functionality to order a ticket is alsoimplemented based on the notion of shared collections. This time, the Order collection ismade available on Bob’s device. The server application acts as a client and receives orderitems. The reception of an order item can be regarded as a request. Upon inserting the orderobject into the Order collection, a trigger is fired that informs the subscriber of that event.The associated handler action is executed resulting in the creation of a ticket object that isadded to the Ticket collection. The last step initiates the response in terms of a ticket (seeFigure 6.5).A ticket is a unique item that cannot be changed by the client nor by the server application.It stays visible independently of the fact whether a connection is established or not.

Bob recognizes that the movie starts in two hours. To bridge the time gap, he decides totake a walk outside. When he leaves the building, his application indicates that there is noconnection with the server anymore and hence switches to an offline mode. As a consequence,the previously received advertisements vanish.

68 6.2. SCENARIO

Figure 6.5: Persistent Copy

6.2.4 Transient Copy

He returns on schedule and watches the movie. Meanwhile, the Avonopolis server applicationlets his ticket expire. This is done by updating the sharing mode of the Ticket collection totransient copy. Our implementation allows adapting sharing modes at runtime. This way, itis guaranteed that the ticket is deleted when Bob leaves the movie center (see Figure 6.6).

Figure 6.6: Transient Copy

After having arrived at home, Bob notices that he forgot his glasses. That is why he headsback to the Avonopolis center. Since the appearance of customers drives the sharing process,it leads to the case where the content of the Ticket collection is migrated to Bob’s device.This effect is not desirable. The solution is already provided by our sharing module, as itallows a query to be attached to the collection. The query acts as a filter on the items residing


in the collection. In this particular scenario, the query is defined such that tickets for Bob thatare expired are not taken into account for exchange.

6.2.5 Review

The Movies collection is made visible on the client and made available on the server. Themovie list is sent from the server to its clients and all updates on the Movies collection aswell as on the contained items are forwarded to all former receivers. This scenario covers thepersistent synchronization mode. The Advertisements collection follows the same pattern:advertisements are sent from the Avonopolis server to all its clients. In contrast to movieitems, advertisement objects on the handheld devices are deleted upon disconnection. Itcovers the transient synchronization mode.The order of a ticket is based on a collection Orders which is made available on the client andmade visible on the server component. The reception of an order object results in the creationof a ticket object and its insertion into the Tickets collection. Since the Tickets collection ismade available on the server side and made visible on the client side, tickets are migrated tothe customer. Both collections are attached with the persistent copy mode. Finally, the modeof the Tickets collection is changed to transient copy at runtime. This way, it is guaranteedthat expired tickets are deleted when customers leave the building. The entire progress isillustrated in Figure 6.7.

1 3

2 4

Synchronization

Pers

iste

nt

Copy

Tran

sien

t

AvonopolisServer

send/synchronize

movie list order

ticke

t

deliv

er tic

ket

ticket expiredad

vertis

emen

t

adap

t mod

e

Figure 6.7: Showcase Scenario

70 6.2. SCENARIO

7Conclusions

In this thesis, we have identified and investigated different modes of data sharing present ina mobile environment where direct connections between typical mobile users can be esta-blished via short-range wireless technologies such as Bluetooth. We have argued that thesemodes can be exploited by developers to design novel classes of applications. An implemen-tation platform has been developed that provides support for such an advanced functionality.Based on this platform, a showcase application has been implemented demonstrating the use-fulness of the concepts.

7.1 Contributions

As this study has covered a conceptual and implementation part, we will also discuss theresults accordingly.

7.1.1 Sharing Modes

Two orthogonal concepts have been highlighted: data continuity and data coupling. Datacontinuity refers to the issue whether the lifetime of a shared object is limited. A receivedobject can be transient meaning that it is deleted upon disconnection. On the other hand, ifthe object is declared persistent, it stays visible independent of the state of connectivity. Datacoupling deals with the dependency of objects residing on different machines. When objectsare interconnected, updates are forwarded in order to keep the data synchronized. The otherpossibility is to create a copy of the original data. This way, they are regarded as two distinctentities which are no longer updated.

7.1.2 Implementation Platform

The solution developed in this thesis has been integrated into the object-oriented databasemanagement system OMS Avon that implements the OM data model. It profits from the

71

72 7.2. CONCLUDING REMARKS

functionality that this database system offers in terms of data management and extensibility.Four modules have been designed in order to support the different modes of sharing:

First of all, the requirement of data exchange between database instances has been metby the connectivity module. We have designed and implemented a flexible and reliablelow-level component that takes care of sending and receiving data. It makes use of the forcedconversation concept that allows defining protocols in a simple manner.

Based on the reconditioning of a previous study on triggers, events and handlers, OMSAvon has been extended with an event system that intends to proactively notify registeredobservers about events that occur within the database. The distributed nature of the eventsystem supports different databases to exchange information about the state of their objects,thereby acting as an enabler for loosely-coupled data distribution.

We have mentioned that the peers appearing in vicinity are the driving force of opportunisticinformation sharing. A vicinity module has been introduced that provides high-levelprimitives to support vicinity sensing. Its task is to detect the appearing and disappearing ofdevices nearby.

Afterwards, we have given insight into the implementation of the sharing module. Theunderlying functionality to share information includes the aspect to let an applicationdeveloper express its own sharing behavior. Therefore, we have introduced the approach toallow any application developer to register a query along with a collection in such a waythat only the result of the query will be shared, therefore providing a powerful way to let theapplication developers express their own sharing behavior. Besides this query, the sharingmode can be specified.

The value of the implementation platform as a basis for the realization of mobile applicationshas been demonstrated by means of a showcase application that covers the scenario of afuturistic cinematic environment. All four sharing modes are used in this application.

7.2 Concluding Remarks

Data sharing in general can be described with two different approaches. First of all, a diffe-rence in the way they are processed can be recognized. Data can be provided for peers withouta specific request, i.e. proactively. On the other hand, data can be shared reactively, whichmeans that resources are shared on demand. The second approach consists of examiningthe way the resources are transmitted from the provider-peer to the user-peer. In multi-hoptransmission data is delivered via other intermediate peers, whereas single-hop transmissionallows communication only between adjacent nodes in the ad-hoc network.Sharing has been enabled among Internet users by the advent of peer-to-peer (P2P) applica-tions. This form of content provision differs from the traditional client/server model whereusers are either contributors or consumers, but generally not both. Peer-to-peer applicationsallow all users on a network to both contribute and consume contents. The outcome of thisthesis builds the groundwork for such kinds of information sharing among mobile users.

8Future Work

This section covers parts of the event-based information sharing system which could be ex-tended into future versions, but also parts which could not be completely implemented, eitherdue to timely constraints or due to the fact that required features are not yet available in thecurrent version of OMS Avon.

8.1 Object Equality

We have seen that different types of object equality can be defined. Our definition has beengiven in Section 5.2.2. It has been stated that the current implementation excludes the equalitychecking on attributes whose type is a bulk. The algebra could be extended with an equalityoperator for the content of extents in order to comply with our specifications. In additionto this system-defined object equality, developers should be able to define their own objectequality. Instead of comparing all the attributes, a subset of attributes can be provided whichdetermines the equality of objects similarly to the concept of primary keys in the relationalmodel. This enables the developer to create application-specific equality constraints. Otherapproaches could be examined such as the incorporation of equality over associations as wellas queries as uniqueness indicators.

8.2 Forced Conversation

In Section 5.2.1, we have introduced the concept of a forced conversation and pointed out itsbenefits. The downside is that there is no mechanism in place yet that prevents the author ofsuch a conversation to gain full control over the dialog partner. To face this issue, an accesscontrol system could be implemented that allows the usage of the system including access tospecified data and methods to be restricted.

73

74 8.3. EVENT SYSTEM

8.3 Event System

As part of this thesis, a simplified version of the unified event model defined by [23] hasbeen implemented. The system could be extended in such a way that it provides the fullfunctionality like the original version. This includes, among other things, the incorporationof so-called subscriptions. Inspired from active databases where ECA rules can define acomposition of events that need to occur before the handler is invoked, the model allowsarbitrary boolean expressions to be defined as subscriptions, supporting the logical operationsand, or and not. This provides a powerful tool as a handler can compose a semanticallyhigher event with the help of normal event types.Two main aspects of notification systems have not been dealt with. Notification systemsintroduce the notions of fallback actions and time constraints specifying when a notificationis allowed to be performed. A possible field of application for fallback actions comprisesalert systems, where it is indispensable that the next person in the chain of command is beingnotified if a person in charge is not available. In contrast, temporal constraints can be used toreflect working hours of employees, for example to avoid a participant getting a phone callon weekends or during holidays.

8.4 OML

Based on the notion of database modules present in OMS Avon, new functionality can beadded to the system. Section 3.2.1 has outlined the characteristics of a module. In thisthesis, modules have covered the first two aspects, but the OML extensions are still missing.OML needs to be extended in order to make the new operations available to the applicationprogrammer or end-user.

8.5 Vicinity Awareness

This research has centered on the issues involved in developing information sharing environ-ments for wireless-enabled mobile users. In particular, there are a number of advantages inselecting Bluetooth. Its networking model naturally lends itself to mobile ad-hoc environ-ments. Bluetooth is gaining wide acceptance and it provides for security and service disco-very as part of the protocol. Implementing vicinity sensing based on this technology mightbe an interesting task. Having implemented our module using interface definitions, such aBluetooth application could be realized without changes to any other code.

8.6 Synchronization

Data synchronization (or data replication) is the process of establishing consistency amongdata in two or more replicas. Our sharing module has been designed in such a way that it onlyattempts to synchronize objects when updates on the original object are applied. As a result,synchronization works only in one direction. A useful extension would be to incorporate bi-directional synchronization. Conflicts need to be detected and reconciled. The conflict canbe resolved automatically or manually or it can just be reported.

CHAPTER 8. FUTURE WORK 75

8.7 P2P Data Sharing

Based on the implementation platform developed in this thesis, peer-to-peer applicationscould be deployed in a mobile environment. In contrast to peer-to-peer applications thatrun on desktop machines with access to the Internet, the networks formed via Bluetooth havea dynamic topology and are constantly changing as devices move in and out of range. Manyother issues and characteristics will first have to be identified, before the current implemen-tation can be extended in such a way that it meets the requirements of P2P applications inmobile ad-hoc networks.

76 8.7. P2P DATA SHARING

AAlgorithms

A.1 Serialization

Algorithm A.1: Serialize ObjectValue (transformObject)Input: Identifier ObjectIdOutput: ObjectNode

beginObjectNode new ObjectNode()DressTypes getObjectTypeDescriptors(ObjectId)foreach type 2 DressTypes do

attributeNodes new NodeList()attributeTypes getValueTypeDescriptors(type)attributeV alues getAttributeValues(type, ObjectId)for i = 1 to length(attributeV alues) do

Node transform (attributeTypes[i], attributeV alues[i])add Node to attributeNodes

typeName getTypeName(type)add typeName associated with attributeNodes to ObjectNode

return ObjectNode

end

77

78 A.1. SERIALIZATION

Algorithm A.2: Serialize BaseValue (transformBase)Input: BaseTypeDescriptor and BaseValue ObjectOutput: BaseV alueNode

beginbuiltInType getBuiltInType(BaseTypeDescriptor)BaseV alueNode new BaseValueNode(Object, builtInType)return BaseValueNode

end

Algorithm A.3: Serialize ExtentValue (transformExtent)Input: Identifier ExtentIdOutput: ExtentNode

beginnodeList new NodeList()bulkType getBulkType(ExtentId)type getType(ExtentId)typeName getTypeName(type)ExtentNode new ExtentNode(bulkType, typeName)Extent getContent(ExtentId)foreach object 2 Extent do

Node transform (getMemberType(type), object)add Node to nodeList

set nodeList in ExtentNode

return ExtentNodeend

Algorithm A.4: Serialize StructuredValue (transformRecord)Input: RecordTypeDescriptor and StructuredValue ObjectsOutput: RecordNode

beginRecordNode new RecordNode()fieldTypes getFieldTypes(RecordTypeDescriptor)nodeList new NodeList()for i = 1 to length(fieldTypes) do

Node transform (fieldTypes[i], Objects[i])add Node to nodeList

set nodeList in RecordNode

return RecordNodeend

APPENDIX A. ALGORITHMS 79

Algorithm A.5: Common Serialization Method (transform)Input: V alueTypeDescriptor and value ObjectOutput: Node

beginswitch V alueTypeDescriptor do

case BaseTypeDescriptorNode transformBase (BaseTypeDescriptor, Object)

case ObjectTypeDescriptor/* value is an object id */Node transformObject (Object)

case ExtentTypeDescriptor/* value is an extent id */Node transformExtent (Object)

case RecordTypeDescriptor/* value is an array of objects */Node transformRecord (RecordTypeDescriptor, Object)

return Nodeend

A.2 Deserialization

A.2.1 Type Visitor

Algorithm A.6: Creation of ObjectType (createObjectType)Input: Node ObjectNode

Output: Type referenced by ObjectIdbegin

AttributeNodes getAttributeNodes(ObjectNode)typeIds ;

for i = 1 to length(AttributeNodes) dotypeIds[i] createType (AttributeNodes[i])

ObjectId createObject()objectType create object type with typeIdsassociate ObjectId with objectTypereturn ObjectId

end

80 A.2. DESERIALIZATION

Algorithm A.7: Creation of ExtentType (createExtentType)Input: Node ExtentNode


nodeList getNodeList(ExtentNode)typeIds ;

for i = 1 to length(nodeList) dotypeIds[i] createType (nodeList[i])

ObjectId createObject()bulkType getBulkType(ExtentNode)extentType create extent type with bulktypeassociate ObjectId with extentTypereturn ObjectId

end

Algorithm A.8: Creation of RecordType (createRecordType)Input: Node RecordNode


NodeTypes getNodeTypes(ExtentNode)typeIds ;

for i = 1 to length(NodeType) dotypeIds[i] createType (NodeTypes[i])

ObjectId createObject()recordType create record type with typeIdsassociate ObjectId with recordTypereturn ObjectId

end

Algorithm A.9: Creation of Type (createType)Input: Node

Output: Identifierbegin

type getType(Node)switch type do

case ObjectType/* Object Type Descriptor */Identifier createObjectType (ObjectNode)

case BulkType/* Extent Type Descriptor */Identifier createExtentType (ExtentNode)

case StructuredType/* Record Type Descriptor */Identifier createRecordType (RecordNode)

return Identifier

end

APPENDIX A. ALGORITHMS 81

A.2.2 Value Visitor

Algorithm A.10: Deserialize ObjectNode (parseObject)Input: Node ObjectNode

Output: ObjectValue ObjectIdbegin

TypeNames getTypeNames(ObjectNode)V alueSet ;

foreach typeName 2 TypeNames donodeList getNodeList(typeName, ObjectNode)objects ;

for i = 1 to length(nodeList) doobjects[i] parse (nodeList[i])

add typeName associated with objects to V alueSetObjectId 0if existsObjectFor(ResultSet) then

ObjectId getIdentifier(V alueSet)else

ObjectId createObject(V alueSet)return ObjectId

end

Algorithm A.11: Deserialize ExtentNode (parseExtent)Input: Node ExtentNode

Output: ExtentValue ExtentIdbegin

type getType(ExtentNode)nodeList getNodeList(ExtentNode)objects ;

for i = 1 to length(nodeList) doobjects[i] parse (nodeList[i])

ExtentId new Extent(type, objects)return ExtentId

end

Algorithm A.12: Deserialize RecordNode (parseRecord)Input: Node RecordNode

Output: StructuredV aluebegin

nodeList getNodeList(RecordNode)StructuredV alue 0for i = 1 to length(nodeList) do

StructuredV alue[i] parse (nodeList[i])return StructuredV alue

end

82 A.2. DESERIALIZATION

Algorithm A.13: Deserialize BaseNode (parseBase)Input: Node BaseNode

Output: BaseV aluebegin

BaseV alue getValue(BaseNode)return BaseV alue

end

Algorithm A.14: Common Deserialization Method (parse)Input: Node

Output: V aluebegin

switch Node docase BaseNode

/* BaseValue */V alue parseBase (BaseNode)

case ObjectNode/* ObjectId (ObjectValue) */V alue parseObject (ObjectNode)

case ExtentNode/* ExtentId (ExtentValue) */V alue parseExtent (ExtentNode)

case RecordNode/* StructuredValue */V alue parseRecord (RecordNode)

return V alueend

BXML Schema

B.1 Vicinity<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified"><xs:element name="vicinities">

<xs:complexType><xs:sequence><xs:element maxOccurs="unbounded" ref="vicinity"/>

</xs:sequence></xs:complexType>

</xs:element><xs:element name="vicinity">

<xs:complexType><xs:sequence><xs:element maxOccurs="unbounded" ref="peer"/>

</xs:sequence><xs:attribute name="end" use="required" type="xs:integer"/><xs:attribute name="start" use="required" type="xs:integer"/>

</xs:complexType></xs:element><xs:element name="peer">

<xs:complexType><xs:sequence><xs:element minOccurs="0" maxOccurs="unbounded" ref="neighbour"/>

</xs:sequence><xs:attribute name="host" use="required" type="xs:string"/><xs:attribute name="pid" use="required" type="xs:string"/><xs:attribute name="port" use="required" type="xs:integer"/>

</xs:complexType></xs:element><xs:element name="neighbour">

<xs:complexType><xs:attribute name="pid" use="required" type="xs:string"/>

</xs:complexType></xs:element>

</xs:schema>

83

84 B.1. VICINITY

List of Figures

3.1 OM Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 OMS Avon Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Type Hierarchy in Storage Layer . . . . . . . . . . . . . . . . . . . . . . . . . 153.4 Information Units together with Type Descriptors . . . . . . . . . . . . . . 163.5 Unified Event Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.6 Event Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.7 Dependency between User and System Types . . . . . . . . . . . . . . . . . 213.8 Event Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.9 Event Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1 Sharing Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2 Model of Sharing Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3 Operations associated with Sharing Modes . . . . . . . . . . . . . . . . . . 29

5.1 Architecture of the Event-based Information Sharing System . . . . . . . . 325.2 Data Exchange Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3 Concrete Implementation of a Forced Conversation . . . . . . . . . . . . . 365.4 Entry points for the Connectivity Framework . . . . . . . . . . . . . . . . . 375.5 Conceptual Exchange Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 385.6 Exchange Algorithm Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 395.7 Visitor Pattern and the proposed Node Structure . . . . . . . . . . . . . . . 405.8 Sequence Diagram of Conversation-based Data Exchange . . . . . . . . . 425.9 Typing versus Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.10 Event Entity Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.11 Event Type Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.12 Event Trigger Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.13 Event Handler Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.14 Event Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.15 Event Site Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.16 Event Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.17 Event Execution Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.18 Site Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.19 Event System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.20 Event Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.21 Event System API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.22 Implementation of a Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 565.23 Client Side of Vicinity Implementation . . . . . . . . . . . . . . . . . . . . . 58

85

86 LIST OF FIGURES

5.24 Server Side of Vicinity Implementation . . . . . . . . . . . . . . . . . . . . . 595.25 Sharing Interface and its Implementation . . . . . . . . . . . . . . . . . . . 605.26 Sharing System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.1 Model of the Avonopolis Application . . . . . . . . . . . . . . . . . . . . . . 646.2 Architecture of Avonopolis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.3 Persistent Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.4 Transient Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.5 Persistent Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.6 Transient Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.7 Showcase Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

List of Algorithms

5.1 local side: exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2 remote side: getObject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38A.1 Serialize ObjectValue (transformObject) . . . . . . . . . . . . . . . . . . . . . 77A.2 Serialize BaseValue (transformBase) . . . . . . . . . . . . . . . . . . . . . . 78A.3 Serialize ExtentValue (transformExtent) . . . . . . . . . . . . . . . . . . . . . 78A.4 Serialize StructuredValue (transformRecord) . . . . . . . . . . . . . . . . . . 78A.5 Common Serialization Method (transform) . . . . . . . . . . . . . . . . . . . 79A.6 Creation of ObjectType (createObjectType) . . . . . . . . . . . . . . . . . . . 79A.7 Creation of ExtentType (createExtentType) . . . . . . . . . . . . . . . . . . . 80A.8 Creation of RecordType (createRecordType) . . . . . . . . . . . . . . . . . . 80A.9 Creation of Type (createType) . . . . . . . . . . . . . . . . . . . . . . . . . . 80A.10 Deserialize ObjectNode (parseObject) . . . . . . . . . . . . . . . . . . . . . . 81A.11 Deserialize ExtentNode (parseExtent) . . . . . . . . . . . . . . . . . . . . . . 81A.12 Deserialize RecordNode (parseRecord) . . . . . . . . . . . . . . . . . . . . . 81A.13 Deserialize BaseNode (parseBase) . . . . . . . . . . . . . . . . . . . . . . . . 82A.14 Common Deserialization Method (parse) . . . . . . . . . . . . . . . . . . . . 82

87

88 LIST OF ALGORITHMS

Acknowledgements

First and above all, I want to express my gratitude to Alexandre de Spindler. During the courseof this master thesis he always took the time to answer my questions and he gave me valuableinput on both the implementation, as well as when writing the report. Then I also would liketo thank Prof. Norrie for being my mentor and leveraging my interest in information systemsduring my master’s studies. Although I was initially planning to write the thesis in industry,her advice led me to reconsider and I am happy to have made the right decision. She was verysupportive in finding a topic that suits my interests and knowledge thereby leaving a certaindegree of freedom. My thanks also go out to Dr. Michael Grossniklaus for giving advice andpractical support whenever required.This work is dedicated to my family and friends. I would like to thank my parents and mysister for the enormous support during my studies at ETH. I am also grateful to my friends forreminding me to not forget about other, non-academic (and probably more important) thingsin life.Finally, I would like to thank my fellow students in the laboratory for the great atmosphereand the inspiring conversations: Matthias, Katinka, Philip and Christoph.

89

Bibliography

[1] OMS Database Technologies. http://maven.globis.ethz.ch/projects/avon.

[2] OMS Avon, 2009. http://www.globis.ethz.ch/research/oms.

[3] Malcolm Atkinson, David DeWitt, David Maier, Francois Bancilhon, Klaus Dittrich,and Stanley Zdonik. The object-oriented database system manifesto. pages 1–20, 1992.

[4] Kenneth L. Calvert and Michael J. Donahoo. TCP/IP sockets in Java: practical guidefor programmers. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2002.

[5] Doug Fang, Shahram Ghandeharizadeh, and Dennis McLeod. An experimental object-based sharing system for networked databases. The VLDB Journal, 5(2):151–165, 1996.

[6] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns:abstraction and reuse of object-oriented design. pages 701–717, 2002.

[7] David Garlan, Daniel P. Siewiorek, and Peter Steenkiste. Project Aura: Towarddistraction-free pervasive computing. IEEE Pervasive Computing, 1:22–31, 2002.

[8] Deiter Gawlick and Shailendra Mishra. Information sharing with the Oracle database. InDEBS ’03: Proceedings of the 2nd international workshop on Distributed event-basedsystems, pages 1–6, New York, NY, USA, 2003. ACM.

[9] Jim Gray. Queues are databases. In In Proceedings 7th High PerformanceTransaction Processing Workshop. Asilomar CA, page 496. Prentice Hall, 1995.http://research.microsoft.com/apps/pubs/default.aspx?id=68494.

[10] Setrag N. Khoshafian and George P. Copeland. Object identity. SIGPLAN Not.,21(11):406–416, 1986.

[11] James J. Kistler and M. Satyanarayanan. Disconnected operation in the Coda File Sys-tem. ACM Trans. Comput. Syst., 10(1):3–25, 1992.

[12] Adrian Kobler and Moira C. Norrie. OMS Java: Lessons Learned from Building aMultiTier Object Management Framework. In In Proceedings of the Workshop on Javaand Databases: Persistence Options, 1999.

[13] Jamie Lawrence, Terry R. Payne, and David De Roure. Co-Presence Communities:Using Pervasive Computing to Support Weak Social Networks. In WETICE ’06: Pro-ceedings of the 15th IEEE International Workshops on Enabling Technologies: Infra-structure for Collaborative Enterprises, pages 149–156, Washington, DC, USA, 2006.IEEE Computer Society.

91

92 BIBLIOGRAPHY

[14] Barbara Liskov, Mark Day, and Liuba Shrira. Distributed object management in Thor.In Distributed Object Management, pages 79–91. Morgan Kaufmann, 1993.

[15] Kevin J. Ma. Web Services: What’s Real and What’s Not? IT Professional, 7(2):14–21,2005.

[16] Moira C. Norrie. An Extended Entity-Relationship Approach to Data Management inObject-Oriented Systems. In ER ’93: Proceedings of the 12th International Conferenceon the Entity-Relationship Approach, pages 390–401, London, UK, 1994. Springer-Verlag.

[17] Moira C. Norrie. Distinguishing Typing and Classification in Object Data Models. InIn Information Modelling and Knowledge Bases, volume VI, chapter 25. IOS, 1995.

[18] Moira C. Norrie, Michael Grossniklaus, Corsin Decurtins, Alexandre de Spindler, An-drei Vancea, and Stefania Leone. Semantic Data Management for db4o. In In Pro-ceedings of ICOODB 2008, 1st International Conference on Object Databases, Berlin,Germany, March 2008.

[19] Moira C. Norrie, Alexios Palinginis, and Alain Wurgler. OMS Connect: SupportingMultidatabase and Mobile Working through Database Connectivity. In COOPIS ’98:Proceedings of the 3rd IFCIS International Conference on Cooperative InformationSystems, pages 232–240, Washington, DC, USA, 1998. IEEE Computer Society.

[20] Je Lan Ong. Using Bluetooth as Context for Public Displays. Master’s thesis, ETHZurich, 2009.

[21] Jim Paterson, Stefan Edlich, Henrik Horning, and Reidar Horning. The Definitive Guideto db4o. Apress, Berkely, CA, USA, 2006.

[22] Norman W. Paton and Oscar Dıaz. Active database systems. ACM Comput. Surv.,31(1):63–103, 1999.

[23] Julian Sgier. A Unified Model for Triggers, Events and Notifications. Master’s thesis,ETH Zurich, Switzerland, 2006.

[24] Mark Weiser. The computer for the 21st century. Human-computer interaction: towardthe year 2000, pages 933–940, 1995.

[25] Alain P. Wurgler. OMS Development Framework: Rapid Prototyping for Object-Oriented Databases. PhD thesis, ETH Zurich, Switzerland, 2000.

[26] Stefanos Zachariadis, Licia Capra, Cecilia Mascolo, and Wolfgang Emmerich.XMIDDLE: information sharing middleware for a mobile environment. In ICSE ’02:Proceedings of the 24th International Conference on Software Engineering, pages 712–712, New York, NY, USA, 2002. ACM.

[27] Stanley B. Zdonik and David Maier, editors. Readings in object-oriented databasesystems. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1990.

Documents

In Copyright - Non-Commercial Use Permitted Rights / License: … · 2020. 3. 26. · Object-oriented databases have gained popularity by supporting persistent data storage in mobile