1

ANALYZING TRANSACTIONS ON JINI AND JAVASPACE

by

Kun Song

A Thesis Presented in Partial Fulfillment of the Requirements for the Degree

of Master of Science

Arizona State University

May 2003

2

ABSTRACT

The availability of the Internet today has led computing into a new era. It

augmented the power of the computer to include everything that is connected to the

Internet. This has enabled extensive and complex distributed applications. JINI

technology addresses the need to connect services to consumers in a flexible network.

This thesis presents an analysis of transactional JINI and JavaSpace application.

Transactions provide a powerful tool for writing distributed applications that operate

correctly in the presence of partial failure. The goal of this research is to design a monitor

space that supervises the transactional space and increase the performance of a

transactional JavaSpace by using local transaction mechanism. To achieve this goal, Java

programming language was chosen since it is platform independent and it is more

compatible with JINI and JavaSpace. In this thesis, I develop a new school admission

system to demonstrate the local transaction mechanism. The prototype uses JINI

technology, The JINI look up service publishes new services and discovers available

services. JavaSpace is a dynamic student database with transaction service, while the

monitor space supervises the overall system activities. By implementing some examples

in the school admission system, the prototype is mainly analyzed from reliability and

efficiency.

iii DEDICATION

3

This work is dedicated to my parents Wenbin Song, Yajie Chen, my brother Xiaofeng Song, my sister-in-law Qingyu Mu and my husband Hengwei Liu for always believing in and supporting me! iv ACKNOWLEDGMENTS Many thanks to my committee chair, Dr. Timothy E. Lindquist, for his encouragement and help throughout the course of this research. I also thank the committee members, Dr. Bruce Millard and Prof. Richard Whitehouse, for their valuable suggestions and encouragement. v TABLE OF CONTENTS

Page

4

LIST OF TABLES……………………………………………………………………..ix LIST OF FIGURES…………………………………………………………………….x CHAPTER 1 INTRODUCTION TO JINI AND JAVASPACES……………………………..1

1.1 JINI……………………………………………………………...1 1.1.1 JINI Technology Overview…………………………….1 1.1.2 JINI Components……………………………….………2

1.2 JavaSpaces………………………………………………………4 1.2.1 JavaSpace Basic……………………………………….4 1.2.2 Characteristics of JavaSpace…………………………..6 1.2.3 JavaSpace supports Transaction……………………….7

1.3 Thesis Objectives………………………………………………...8 1.4 Thesis Organization……………………………………………...8

2 BACKGROUND LITERATURE………………………………………………10 2.1 ACID Properties…………………………………………………10 2.2 Various Transactions…………………………………………….11

3 METHODOLOGY ……………………………………………………………...15 3.1 JINI Transaction Overview………………………………………16 3.2 The Two-Phase Commit Protocol………………………………..17 3.3 JINI Transaction Life Cycles…………………………………….19

vi CHAPTER .Page 3.3.1 Transaction Lifecycles: The Client’s View………………20

3.3.2 Transaction Lifecycles: A Participant’s View…………..21 3.3.3 Transaction Lifecycles: The Manager’s View…………..23

3.4 Local Transaction……………………………………………….25 3.5 IBM T-Space……………………………………………………28

3.5.1 Something New in T-Space……………………………….28 3.5.2 Something Borrowed and Something New………………..28

4 DESIGNED ARCHITECTURE…………………………………………………30 4.1 Architectural Overview………………………………………….30 4.2 Monitor Space and Local Transaction…………………………...32

5 IMPLEMENTATION AND ANALYSIS……………………………………….38

5.1 System Requirements……………………………………………38 5.2 Running Monitor Space………………………………………….38

5.2.1 Start JINI Services……………………………….38 5.2.2 Start the Server…………………………………..41 5.2.3 Start the clients…………………………………..42

5.3 Results and Analysis……………………………………………..44 5.3.1 Transaction Implementation……………………..45 5.3.2 Transaction Analysis…………………………….48

6 CONCLUSIONS AND FUTURE WORKS…………………………………….51

5

6.1 Conclusions……………………………………………………...51 vii 6.2 Future Works…………………………………………………….52

7. REFERENCES…………………………………………………………………..54

viii

LIST OF TABLES Table Page

3.1 Using Local Transaction Manager……………………………………………27 3.2 Method Summary……………………………………………………………..27 4.1 Remote Transaction vs Local Transaction……………………………………33 5.1 Quantitative Data of the Outputs……………………………………………...50 6.1 Extended API………………………………………………………………….53

6

ix LIST OF FIGURES

Figure Page 1.1 Discovery…………………………………………………………………..2 1.2 Join…………………………………………………………………………2 1.3 Look Up………………………………………………………………….…3 1.4 Communication……………………………………………………………..3 3.1 Transaction Creation and Use……………………………………………..18 3.2 Client’s View of Transaction………………………………………………20 3.3 Participant’s View of Transaction………………………………………….21 3.4 Manager’s View of Transaction……………………………………………24 4.1 Architecture Overview……………………………………………………...31 4.2 Monitor Space Overview…………………………………………………...31 4.3 Class LocalTransactionManaerImpl I………………………………………35 4.4 Class LocalTransactionManagerImpl II……………………………………36 5.1 Starting httpd………………………………………………………………..39 5.2 Starting JINI Services………………………………………………………40 5.3 Starting Server……………………………………………………………...41 5.4 Student Interface……………………………………………………………42 5.5 Feedback of the Students’ Input……………………………………………42 5.6 Department Interface……………………………………………………….43 5.7 Graduate College Interface…………………………………………………43 x

Figure Page 5.8 Monitor Space………………………………………………………………45 5.9 Graduate College Set Approval…………………………………………….46 5.10 Department Output After Transaction Committed………………………..47 5.11 Student Output Before Transaction Committed………………………….48 5.12 Monitor Space Running Local Transaction………………………………49

7

xi

8

1 INTRODUCTION TO JINI AND JAVASPACES

1.1. JINI

JINI technology was first announced in 1998 by Sun Microsystems. It extends the Java

application environment from a single virtue machine to a network of machines.

1.1.1 JINI Technology Overview

JINI technology is a simple infrastructure for providing services in a network, and for

creating spontaneous interactions between programs that use these services. Services can

be connected to a network and announce their presence.lients that wish to use such a

service can then locate it and call it to perform the tasks. JINI supports this higher level of

Interactions. There are a large number of scenarios where this would be useful (Arnold &

Scheifler 2000):

1. A new printer can be connected to the network and announce its presence and

capabilities. A client can then use this printer without having to be specially configured to

do so.

2. New capabilities extending existing ones can be added to a running system without

disrupting existing services, or without any need to reconfigure clients.

3 A configuration file that is copied and modified on individual machines can be made

into a network service from a single machine, reducing maintenance costs.

9

1.1.2 JINI Components

JINI is just one of a large number of distributed systems architectures, including industry-

pervasive systems such as CORBA and DCOM. It is distinguished by being based on

Java, and deriving many features purely from this java basis. In a running JINI system,

there are four main players. There is a device or service, such as printer, a program, a

storage etc. There is a client, which would like to make use of this service. Thirdly there

is a lookup service, which acts as a broker, trader and locator between services and

clients. Let’s look at the following figure (Sun Microsystems inc. 1999):

Figure 1.1 Discovery

Figure 1.2 Join

LookUp Service

ServiceProvider

ServiceObj

Client

discovery

LookupService

ServiceObj ServiceAttr

ServiceProvider

ServiceObj ServiceAttr

Client

A service provider registers a serviceObj and its serviceAttr with the lookup service

A service provider seeks a lookup service

10

Figure 1.3 Look up

Figure 1.4 Communication

When a service is first booted up, it uses a discovery protocol to find the lookup services.

The server first sends “looking for lookup services” message to the network. The

applicable lookup service on the network responds with a proxy for itself. The service

registers with each lookup service using its proxy by providing the service’s proxy object

LookupService

ServiceObj ServiceAttr

Service Provider

Client

ServiceObj

A client requrests a service by java type. A copy of the serviceObj is moved to the client and used by the client to talk to the service

LookupService

ServiceObj ServiceAttr

Service Provider

Client

ServiceObj

The client interacts directly with the service provider via the serviceObj

11

and any desired attributes, which might be used by the clients in locating the

corresponding services (Lindquist 2001).

The clients send “looking for lookup services” messages to the network as well. Each

lookup service in the network responds with a proxy for itself. The clients search for

types of services they need by matching attributes or service id. The lookup service

returns one or more matching proxy objects, whose code is downloaded to the clients if

necessary.

1.2 JavaSpaces

JavaSpace is a powerful JINI Service. It provides a simple unified mechanism for

dynamic communication, coordination, and sharing of objects between Java technology

based network resources like clients and servers.

1.2.1 JavaSpace Basic

JavaSpace is a loosely coupled, based on the metaphor of Linda like models. The Linda

model is a general model of parallel computing based on distributed data structures. It has

Fortran-Linda and C-Linda versions. Fortran-Linda uses Fortran programming languages

and C-Linda uses C programming languages. JavaSpace uses Java language. Producers

store objects in a shared working space and consumers look up and retrieve objects from

this shared medium. The shared medium is effectively a networked repository of java

12

objects where the later exist in the form of entries and their lookup is done via templates.

JavaSpace is pure java-based and provide a simple solution to lightweight distributed

applications. Furthermore it decouples consumers from producers thus relieving

responsibilities and complexity and reducing the difficulty of building the distributed

applications and maintaining them (Li 2000). JavaSpace has five typical operations:

• write, puts a copy of an entry into the space.

• read & readIfExists, (blocking and non-blocking versions) return a matching entry

from the space.

• take & takeIfExists, (blocking and non-blocking versions) remove the matching

entry from the space.

• notify, sends an event when the matching entry is written to the space.

• snapshot, returns another entry object that contains the snapshot of the original

one

A JavaSpace acts as a virtual space between providers and requesters of network

resources or objects. It holds entries, which are a typed group of objects. As shown in

processes use the JavaSpace as a persistent object storage and exchange mechanism.

Processes perform simple operations such as writing new objects into a space, taking

objects from a space, or reading objects in a space. Entries in a JavaSpace service can be

looked up using templates, which are entry objects that have some or all of its fields set to

specified values that must be matched exactly. Remaining fields are left as wildcards. An

entry can be retrieved from the JavaSpace by either a read or take operation. A read

request to a space returns either an entry that matches the template on which the read is

13

done, or an indication that no match was found. A take operating is similar to the read but

if a match is found, the entry is removed from the space.

Another facility that JavaSpace provides is that of notification. Users can request a

notification if an entry that matches a specified template is written to the JavaSpace. An

entry cannot exist in a JavaSpace service perpetually. When an entry is written to space,

it must obtain a lease that dictates how long the entry may remain valid in the space. The

lease expires in a finite amount of time, and objects can renew leases.

All operations that modify a JavaSpace service are performed in a transactionally secure

manner with respect to that space. The JINI transaction services are used to provide a two

phase commit protocol that can be used by objects that wish to perform operations within

a transaction scope and span operations that allow multi-operation and/or multi-space

updates to complete atomically

1.2.2 Characteristics of JavaSpace

Spaces are network-accessible “shared memories” that many remote processes can

interact with each other concurrently. A space itself handles the details of concurrent

access, leaving users to focus on the design of high-level protocol between processes (Yu

2001).

14

JavaSpace is persistent. It provides reliable storage for objects. When an object is stored

in a space, it will remain there indefinitely or till the lease expired. Objects may remain in

the space even after the processes have been terminated. This property is significant

necessary for supporting uncoupled protocols between processes. Persistence allows

processes to communicate even if they run at non-overlapping times (Yu 2001).

JavaSpace makes use of JINI’s transaction service to ensure that an operation on a space

is atomic. Transactions are supported for single operations on a single space, as well as

multiple operations over one or more spaces (Yu 2001).

JavaSpace stores not only data but also objects. When clients read or take an object from

a space, a local copy of the object is created. As with any other local object, this object

can be modified and its methods can be invoked (Yu 2001).

1.2.3 JavaSpace supports Transaction

Transactional systems ensure a set of operations performed atomically (more on

atomicity are in the following chapter). Without this transactional ability, the states of

distributed systems can easily become inconsistent. Systems that support transactions,

such as a database management system, typically build transactions into the system’s

core. JINI take a more lightweight and flexible approach: It provides a transaction service

that manages a set of participants through a transaction process. The transaction uses a

15

two-phase commit protocol, which is covered in the next chapter to ensure that all

participants complete their transaction or none of them does (Elmarsri 1999).

The JavaSpaces application interface integrates JINI transactions in a very clean manner.

It introduces transactional security into JavaSpaces applications. To use transactions with

space-based operations, a transaction manager will be created at first and pass the

transaction to each space operation. The transaction is committed if there are no

problems, which result the completion of all the operations. Otherwise, the transaction

aborts and it leaves the space unchanged. The transaction might also be aborted by the

transaction manager if, for instance, the transaction’s lease expires.

1.3 Thesis Objectives

The primary objective is to design, analyze and monitor a transactional javaSpaces

application. Using JavaSpaces can lead to a lower level of confidence in the system’s

overall behavior and some times inefficient performance because of the high network

traffic. Based on these two ideas I designed a monitor space, which supervises a

JavaSpace application (School Admission System). Further, the JavaSpace use a new

transaction mechanism – local transactions which greatly increase the performance.

16

1.4 Thesis Organization

The remainder of this thesis is organized as follows. Chapter 2 covers the background

information of the various transaction models. Chapter 3 mainly talked about transactions

in JINI and JavaSpaces and provides methodology for developing JavaSpace application

with local transaction mechanism. Chapter 4 defines the basic architecture for JavaSpace

monitor system. Chapter 5 implements and analyzes the results based on the timing

difference showed by the monitor system. Finally, chapter 6 presents the conclusion on

the research carried out in this thesis and possible future works.

17

2 BACKGROUND LITERATURE

The reliable and correct execution of programs is a key concern in the engineering of

distributed systems. Transactions represent one of the mechanisms commonly used to

ensure reliability and correctness. This chapter addresses: ACID properties, various

transaction models and two-phase commit protocol.

2.1 ACID properties

A transaction groups a set of actions as one single unit of work for which reliability and

correctness properties hold. Each transaction has four key characteristics: Atomicity,

Consistency, Isolation, and Durability, known collectively by their initial letters as ACID.

ACID properties make a transaction different from a normal, unprotected type of

program execution:

Atomicity: is the atomic unit of processing, it is either performed completely or not at

all. It’s a very important property guaranteed by the DBMS for all transactions. A user

can think of a transaction as always executing its actions in one step, or not executing any

actions at all.

Consistency: A transaction always leads to a correct transformation of the system state

by preserving the state invariance. For example, a transaction adding an element to a

doubly linked list, all four forward and backward pointers are updated.

18

Isolation: Concurrent transactions are isolated from the updates of other incomplete

transactions. This property is also called serializability. For example, a second transaction

traversing the doubly linked list already undergoing modification by the first transaction

will see only completed changes, and is isolated from any non-committed changes of the

first transaction.

Durability: If a transaction commits, its effect will be permanent. In fact the effects will

remain even in the face of system failures. It is up to the transaction manager to provide

consistent, isolated and durable transformations of objects they manage (Freeman &

Hupfer 2001).

2.2 Various Transactions

A variety of transaction models and technologies supporting transaction processing have

been proposed over the last years. These models and technologies differ in how they

address and support some or all of the ACID properties Here I address a few of them as

followed:

• Integrated database transactions, as promoted by database management systems

(DBMS), for instance, PostgreSql database server,

• Component container-managed transactions, as suggested by component

technology such as Sun’s Enterprise Java Beans (EJB),

• Transactions in .Net

• Distributed object transactions, as defined by JINI and javaSpace Technology

19

In a database context, the transaction model encompasses all of the ACID properties.

DBMS use an integrated system architecture where the state of manipulated entities is

under full control of the DBMS. This is the basis for integrated concurrency control

and recovery. Transaction demarcation is either explicit, spanning several data

manipulation statements, or implicit per statement. PostgreSql offers true ACID

semantics for transactions, given some reasonable assumptions about the behavior of

the underlying Unix kernel and hardware (Roman & Ambler 2001).

Component technologies such as Sun’s Enterprise Java Beans follow the distributed

object-computing model, but introduce and emphasize the concept of a “container” to

manage the interactions between object instances and the server. A container is

responsible for tasks such as creating new object instances, and it supports the

mapping between objects and records in a database and generates code for persistent

storage. With component container-managed transactions, transactions also become

the responsibility of the container. The container creates new or accepts existing

client transaction contexts, and performs the invoked operations in those contexts. A

major difference to distributed object transactions exist in the way a transaction is

demarcated and managed. Explicit transaction demarcation as proposed by the

CORBA object transaction service allows a client to fully control scope and behavior

of transactions. However, the explicit model typically requires the use of complex

application program interface, and to write transactional code within the business

logic. This may reduce the clarity and reusability of the code. Declarative transaction

20

management as proposed with container-managed transactions separates transaction

behavior from business logic, thus promises for better reuse of the same business

logic code in different transactional or non-transaction environments. Declarative

transaction management simplifies the coding of the transaction, as all that is required

is to set transactional attributes for a component’s operations. These transactional

attributes are set at deployment time on the server side. However this also implies that

the transactional behavior of a server can easily be overridden and changed at

deployment, which may interfere with the transitional requirements and expectations

of clients (Bertino, Jajodia, Mancini & Ray 1996).

. NET Enterprise servers are Microsoft's comprehensive family of server applications

for building, deploying, and managing scalable, integrated, Web-based solutions.

Transactions in ASP .Net are normally managed by declaring boundaries around a

set of operations. Operations that execute in the context of the transaction boundary

then succeed or fail as a unit. For ASP.NET, the transaction boundary is the

execution of a single request to a page, which might contain nested components that

participate in the same transaction. A transaction can explicitly committed or aborted

by calling the methods setComplete() or setAbort() within the

System.EnterpriseServices.ContextUtil class (Bortniker & Conard 2002).

A distributed transaction includes one or more statements that, individually or as a

group, update data on two or more distinct nodes of a distributed system. The two-

phase commit protocol is a distributed algorithm which lets all sites in a distributed

21

system agree to commit a transaction. The protocol results in either all nodes

committing the transaction or aborting, even in the case of site failures and message

losses.

2.3 Two-Phase Commit Protocol

The two-phase commit protocol is a distributed algorithm, which lets all sites in a

distributed system agree to commit a transaction. As its name it divides the process

into two phases. During phase 1, initially the resource manager sends a query to

commit message to all the participants. Then it waits for all the participants to report

back with the agreement message. The participants, if the transaction was successful,

write an entry to the undo log and an entry to the redo log. Then the participants

reply with an agree message, or an abort if the transaction failed at a participant

node. During phase 2, if the resource manager receives an agree message from all

the participants, then it writes a commit record into its log and sends a commit

message to all the participants. If all agreement messages do not come back the

resource manager sends an abort message. Next the resource manager waits for the

acknowledgement from the participants. When all the acknowledgements are

received from all the participants the resource manager writes a complete record to

its log.

The two-phase commit protocol defines how a transaction is created and later driven to

completion by either committing or aborting. It is neutral with respect to semantics of

locking under the transaction or other behaviors that impart semantics to the use of the

22

transaction. More on two-phase commit protocol and the implementation are in the

following chapters.

23

3 METHODOLOGY

Transaction has been a hot topic for years. In this chapter we’ll address the details of

transactions on JINI and JavaSpace, its tradeoff and the concepts of local transaction.

3.1 JINI Transactions overview

JINI transaction mechanism provides support for, and is consistent with, specific

application implementations that might well guarantee ACID properties. JINI doesn’t

insist on these, it fulfills ACID properties on needed basis.

JINI transaction mechanism provides just enough plumbing for services and clients that

want to use the transactions, but does not place restrictions on how the plumbing should

be utilized, and whether it should be implemented using ACID guarantees or not. By not

enforcing classic transaction semantics, the utility of JINI’s support is increased

impressively. The distributed transaction manager provides multiple system

synchronicity, allowing a group of independently computing servers to come together at

certain points in time, in known and consistent system states. The co-ordination of such a

non-ACID distributed transaction can be applied, in an infinite variety of ways, to many

distributed computing problems (Li 2000).

A distributed transaction manager exists to manage and co-ordinate the two-phase

commits protocol.

24

3.2 The two-phase commit protocol

The two-phase commit protocol is a distributed algorithm, which lets all sites in a

distributed system agree to commit a transaction. The protocol results in either all nodes

committing the transaction or aborting, even in the case of site failures and message

losses.

There are three important roles involved in two-phase commit protocol: transaction

manager, transaction participant and the client.

• Transaction Manager: A transaction manager creates new transactions ad

coordinates the activities of the participants. The transaction manger interface is

implemented by servers that manage the two-phase commit protocol.

• Transaction Participant: When an operation is performed under a transaction, the

participant must join the transaction, providing the manger with a reference to a

Transaction Participant object that will be asked to vote roll forward, or roll back.

• Client: The client is the one who initiates a transaction and it could either join the

transaction to perform some activities or not join at all.

25

3. long id

2. create manager

7.join 8.join 1. create 4.transaction

5. Operation A

6. Operation B

Figure 3.1 Transaction creation and use

The client follows these steps to initiate a new transaction:

• It discovers the transaction manager service. Since it’s just a regular JINI service,

you can follow the normal JINI service discovery mechanism.

• Since different objects could represent various transaction semantics, you create a

Transaction via a factory class. Like many JINI entities, a transaction is a leased

resource. Calling TransactionFactory’s Create() method produces a

ServerTransacton.Create Object, which bundles a new transaction with its lease.

• If the client is also a transaction participant, it can at this point join the

transaction.

• If then passes the transaction object as a parameter in method calls to other

participants as shown in figure 3.1.

All participants wish to participate under the same operation need to join the transaction

as participants and must implement the Transaction Participant interface. Particular

operations associated with a given transaction are performed under that transaction.

Manager TransactionFactory

Participant A

Participant B Client

26

On a high level, this is what happens during two-phase transaction:

• Transaction Participants join the transaction manager to perform operations under

a certain transaction

• Transaction manager tells every participant to prepare for the commit

• Participants prepare by performing the required work in a manner that can be

rolled back or committed

• Any of the participants that cannot prepare for the commit will signal abort

• If all of the participants report successful preparation, the transaction manager

will tell every participant to commit

• All the participants move to commit state the manager commits the operation

(Halter 2002).

3.3 JINI transaction life cycles

The Transaction Constants interface defines the transaction life cycles: active, voting,

prepared, not changed, committed and aborted. These states correspond to the states that

participants and managers go through during the lifecycle of a given transaction (IBM

2000).

27

3.3.1 Transaction Lifecycles: The Client’s View

In the client’s view, a transaction goes through the following states:

Clean up Figure 3.2 Client’s view of transaction For the client the transaction lifecycles starts active as soon as the client receive the

transaction created by the transaction factory. The client drives the transaction to

completion by invoking commit or abort on the transaction manager. The transaction

could go to abort state either by canceling the lease, letting the lease expire or other

unexpected conditions.

The transaction successfully reaches the commit state as soon as the commit method

returns. If the transaction reaches the Aborted state, or is known to have previously

reached that state due to an earlier commit or abort, then commit throws

CannotCommitException.

Both commit and abort can throw UnknownTransactionException, which means the

transaction is unknown to the manager. This may be caused by incorrect transaction id or

the transaction has been finished and has been forgotten.

Active Voting committed

Aborted

28

The commit and abort can also throw TimeoutExpiredException. Overloads of the

commit and abort methods can cause the exception. If the time out expires before the

transaction reaches the committed or aborted state, the manager must wait until one o

those states is reached before throwing the exception. The committed field in the

exception is set to true if the transaction committed or to false if it aborted.

3.3.2 Transaction Lifecycles: A Participant’s View

Figure 3.3 Participant’s view of transaction

In a participant’s view, a transaction life cycle are showed in figure 3.4

As soon as the participant joins the transaction the transaction lifecycle starts out active.

The participants could only perform operations under a transaction at transaction active

state. When the manager asks the participants to prepare, the participants are voting until

it decides what to return. There are three possible return values for prepare:

active voting

Not changed

Aborted

Prepared

committed

Clean up

29

Under a certain transaction the participant has no changes. It should release any internal

state associated with the transaction and signals with a return of not changed, then the

participant enters not changed state successfully.

If the participants have some changes under the transaction it must attempt to prepare to

roll those changes forward in the event of a future incoming commit invocation. When

the participant is ready to roll its changes forward it must signal prepared to the manager

therefore entering the prepared state.

The participant did have some changes under the transaction but unable to roll forward

for various reasons, e.g. system failure, time out, etc. It must signal aborted then enter the

aborted state.

The only bridge leads to commit state is prepare state. The participants must signal

prepared before they could enter commit effectively. Once the participants are in the

commit state the record of changes must be at least as durable as the overall state of the

participant. The record must also be retrieved during recovery.

Nested transactions are not considered in this thesis but I’d like to cover it a little bit here.

For nested transactions, when a participant returns prepared it is stating that it is ready to

roll the changes forward into the parent transaction. The record of changes must be as

durable as the record of changes for the parent transaction.

30

If a participant is executing an operation under a transaction when the manager invoked

the prepare method for that transaction the participant must wait until the operations is

complete before returning from prepare or skip it if the transaction is read only to the

participant.

If the participant lost communication with the manager it can call getState() method.

When encounters unknown transactions the participant may infer that the transaction has

been aborted. If remote exception throws the manager might crash and abort its state in

the transaction. A participant should drop out of a transaction only of the manager is

unreachable over an extended period. However, in no case should a participant drop out

of a transaction it has prepared but not yet rolled forward.

When a participant gets an abort call for a transaction, no mater which states it is

currently in it should move to the aborted state and roll back all changes made under that

transaction. On the other hand when a participant receives a commit call for a prepared

state, it should move to the committed state and roll forward all changes made under the

transaction (Arnold & Scheifler 2000).

31

3.3.3 Transaction Lifecycles: The Manager’s View

In the manager’s view a transaction goes through the following states:

Clean up

Figure 3.4 Manager’s view of the transaction

When the transaction is created by the create method the transaction is active. The

participants could only join a certain transaction at this state. Attempt to join the

transaction at any other state will cause CannotJoinException.

The transaction moves to the voting state if the manager’s commit method is called by

the client. In the voting state the manager attempts to complete the transaction by rolling

forward and the participants which are under the same transaction have their prepare

method invoked to vote on the outcome of the transaction. The participants may return

one of three votes as mentioned in the last section: NOTCHANGED, ABORTED, or

COMMITTED. During voting, if any of the participant votes aborted the manager must

abort the transaction thus moves to the aborted state. Invoking the manager’s abort

method, canceling the transaction’s lease or allowing the lease to expire also moves to the

transaction to the aborted state. In the aborted state the manager should invoke abort on

Active Voting committed

Aborted

32

all participants that have voted prepared. If any of the participant votes not changed, it is

dropped from the list of participants, and no further communication needed. If all the

participants vote not changed or prepared the transaction moves to the committed state. In

the committed state the manager must notify each participant that returned prepared to

roll forward by invoking the participant’s commit method. When the participant’s

commit method returns normally the participant has rolled forward successfully and then

the manager can immediately move the transaction to clean up, in which all the resources

are released and cleaned up.

If a transaction is a nested one and the manager is prepared to roll the transaction

forward, the members of the nested transaction must become members of the parent

transaction. This promotion of participants into the parent manager must be atomic. The

manger for the nested transaction should remain available until it has successfully driven

each participant to completion and promoted its participants into the parent transaction.

3.4 Local Transaction

It is flexible to use two-phase commit protocol to control over transactional JavaSpace

applications. However, if the transaction is made on a single space, the overhead is too

much. Let’s review the process. There are quite a few remote calls involved, which

severely decrease the performance of JavaSpace.

33

• The remote call from the client to the transaction manager

• The remote call from the space to the transaction manager

• The remote call from the client to the transaction manager to commit the

transaction

These three remote calls are completely eliminated when performing local transactions,

However, local transactions are limited to work against a single space. This optimization

is required because in many applications, a large number of transactions are performed on

a single space.

The local transaction manager is a lightweight object inside the client application. It is

not remote object. When you instantiate the local transaction manager you pass it a

reference to the space proxy. This associates the transaction manager with the space. No

remote calls are involved in this stage.

After creating a local transaction manager you could use it almost like a standard

transaction manager. You use a standard transaction factory to create a transaction,

passing it a reference to the transaction manager. Since the transaction manager is local,

no remote calls are involved. You get back a transaction object and use it in subsequent

calls to the space.

Finally you commit the transaction. This involves one and only one remote call to the

space. Thus, three remote calls on standard JavaSpaces transactions are eliminated.

34

The partial code on how to use local transaction manager and the method summary are

showed in table 3.1 and 3.2

Table 3.1 Using local transaction manager

Table 3.2 Method summary

Constructor Summary

LocalTransactionManager (JavaSpace space)

Method Summary

Void abort (long id)

Void abort (long id, long waitFor)

Void commit (long id, long waitFor)

/Net.jinni.core.transaction.server.TransactionManager.Created create(long lease)

Int getState (long id)

// get a instance of javaSpace JavaSpace space = …; // create a local transaction manager LocalTransactionManager trManager = new LocalTransactionManager(space); // obtain transaction through TransactionFactory Transaction.Created created = TransactionFactory.create(trManager,lease); Transaction tr = created.transaction; // using the transaction space.write(…,tr,…); // commit the transaction

35

It is important to note that all operations inside a local transaction must be directed to the

same space instance – the space instance that was given to the local transaction manager

constructor.

3.5 Related Work: T-Space

Sun’s JavaSpaces and IBM’s TSpaces are both attempts to provide developers with a

Java-based distributed object architecture. Both of them are based on tuple spaces of the

famous Linda prototype, which were originally developed to be a global communication

buffer for parallel processing system. T Space provides group communication services,

database services, URL-based file transfer services and event notification services.

3.5.1 Something New in T-Space:

T-Space has a built-in database that provides data integrity, transaction support, indexing

support and a simple query language. A T-Space server houses potentially billions of

spaces. It is up to the application writer to decide whether to use server spaces or just one

space and it provide local transaction for single space applications (IBM 2000).

3.5.2 Something Borrowed and Something New

Based on the local transaction concept proposed in T-Space I applied the local transaction

mechanism to my JavaSpace application successfully. My other contribution is the

36

monitor mechanism. JavaSpace is loosely coupled so it is important to introduce the

monitor mechanism. More on this topic and how local transactions are more efficient

than remote transactions are verified in the following chapters.

4. DESIGNED ARCHITECTURE

37

This Chapter presents the architecture prototype for the transactional JINI and JavaSpace

application. The prototype uses JINI technology as the look up service, JavaSpace as the

storage repository, local transaction as the transaction mechanism and notification

functionalities as the monitor tool.

4.1 Architectural Overview

Figure 4.1 presents the architecture of the prototype that was developed in this research.

The Application is for school admission system. The server side broadcasts its service

and registers its proxy with JINI look up services. The GradServerAdmin class registers

GradServerImpl with rmi deamon. It initiates the JavaSpace, local transaction and

GradServerProxy.

There are four clients involved in this application: the student, the department, graduate

college and the testing client. They all download the space proxy and share the same

space. The students write student entries into the space. The department and graduate

college read the student entries from the space, set recommendations and write student

admission information entries back to the space. The students could know their final

admission status by reading the student admission information entry through the

JavaSpace. How does the monitor client comes into play? The details are showed in

figure 4.2:

JINI Lookup Service Attributes Proxy <gradServerEntry> <gradServerProxy> Attributes Proxy

Publishes its service with JINI lookup service

Client downloads

38

Figure 4.2 Monitor space overview

4.2 Monitor Space and Local Transaction

Clients

Students

GradCollege

Figure 4.1 Architecture overview

JavaSpace

TestClient

RemoteEventListener

Student

Department

GraduateCollege

All clients do event registration and request notify

Notify response Monitor

Space

39

In many cases, we have found building distributed systems with JavaSpaces lets us reach

solutions quicker than with traditional techniques. With the right approach, JavaSpaces

can help alleviate problems common to many distributed systems, such as partial failure

and tight coupling between clients and services. Although using JavaSpaces provides us

with a means to build loosely coupled systems, using JavaSpaces can lead to a lower

level of predictability and confidence in the system’s overall behavior. Or, to put it

another way, by using JavaSpaces you can give up some control and visibility over the

system’s activities as a whole and it could decrease the performance as well.

The above problems were solved by local transaction and the monitor system developed

in this thesis. The overview architecture as showed in figure 4.2 clearly states the

relationship between the four clients. The student, department, and graduate college all

register Test Client with the JavaSpace as the remote event listener and request for

notifications for all the entries written into the space. The test client on the other hand

implements notify method and get all the notify responses once the entries are writen to

the space. By using this mechanism, the test client will know clearly which client writes

something to the space at what time period, thus make the space activities visible and

very well organized. The second problem is the transaction performance. After using

local transaction we can use Timer class offered by Java API to call current system time

before transaction started and call the system time again after the transaction has been

committed. The time difference will be the total time used for a particular transaction. We

could apply the same thing to the remote transaction and conclude that the local

40

transaction is a lot faster. The most significant difference between local transaction and

remote transaction implementation are how to locate the transaction manager as showed

in table 4.1:

Table 4.1 Remote transaction vs Local transaction

Remote Transaction: Local Transaction: Interface TransactionManager Interface LocalTransactionManager Extends Remote, TransactionConstants { { } } class TransactionImpl class TransactionImpl { { findTransactionManager() localTransactionManager tr; private TransactionManager findTransactionMgr() } { TransactionManager tranMgr = null; try{ //Find the TransactionManager service. Entry[] attrs = new Entry[1]; attrs[0] = new Name("TransactionManager"); ServiceTemplate tmpl = new ServiceTemplate(); tranMg=(TransactionManager)serviceRegistrar.lookup(); System.out.println("Found TransactionManager: "); } catch (Exception ex){} return tranMgr; }//----------------------------------------------------

41

In remote transaction application, you have to search transaction manager on JINI Look

up services and there are many remote calls involved during the transaction application.

Local transaction is a lot simple. Create a local transaction manager object and you can

use it as a standard transaction. The partical code of the localTransactionManagerImpl is

shown in figure 4.3 and 4.4 (Sun Microsystems 2000).

42

class LocalTransactionManagerImpl implements LocalTransactionManager { public LocalTransactionManagerImpl (JavaSpace space) { } private void createTran( String stuID) { Transaction txn = null; try{ if(studentTrans.containsKey(stuID) ) System.out.println("Already has Tran obj for stuID: "+stuID+ " Report at createTran()."); else { Transaction.Created trans = TransactionFactory.create( tranMgr, Lease.FOREVER); txn = trans.transaction; System.out.println("create Tran obj: "+txn +" for stuID:"+stuID); studentTrans.put(stuID, txn ); } }catch( Exception ex) {System.out.println("Exception in createTran(): " +ex.getMessage()); } public Transaction getTransaction(String stuID) throws RemoteException { Transaction reTran = null; if( studentTrans.containsKey( stuID) ) { reTran = (Transaction) studentTrans.get( stuID ); } else { System.out.println("No Tran obj for stuID: " +stuID); } System.out.println("reTran: " +reTran ); return reTran; }

43

Figure 4.4 Class LocalTransactionManagerImpl

public String commitTran(String sID, String departID) throws RemoteException { String msg=""; Transaction tran = null; try{ tran = (Transaction) studentTrans.get(sID); if( tran == null) { msg="Admission Transaction already completed"; } else { studentEntry templ= new studentEntry("ASU", departID, sID); studentEntry wfse = (studentEntry)space.readIfExists(templ, tran, 5000); studentAdmEntry templA= new studentAdmEntry("ASU", departID, sID); studentAdmEntry wfsae=(studentAdmEntry)space.readIfExists( templA,tran,5000); if(wfse==null || wfsae==null) msg= "Error!! Cannot Commit Transaction"+ "\nEither studentEntry or studentAdmEntry with ID: "+sID+"is null."; else { wfse = (studentEntry)space.takeIfExists(templ, tran, 5000); wfsae=(studentAdmEntry)space.takeIfExists(templA,tran,5000); String recomm= wfsae.getRecomm(); String approval = wfsae.getApproval(); if( recomm != null && approval !=null ) { if( recomm.equalsIgnoreCase("Yes") && approval.equalsIgnoreCase("Yes") ) { wfsae.setFinalResult("Admitted"); wfse.setFinalResult("Admitted"); wfse.setStatus("Admission Result Granted"); space.write(wfsae, tran, Lease.FOREVER); space.write(wfse, tran, Lease.FOREVER); tran.commit();

44

The details of the implementation and analysis are in the following chapter.

5 IMPLEMENTATION AND ANALYSIS

45

There is some overhead in running this application but I believe it is worth it since you’ll

have a robust and scalable space. The client and the server code could be complied

separately, they share no code at compile time and will have no special knowledge of one

another, other than some shared interfaces that the service’s proxy may implement.

5.1 System Requirements

Before running the school admission system there are some software requirements:

• JDK 1.2.2 or later. It is available to download from http://java.sun.com/j2se

• JINI technology starter kit JINI 1_2 and it is available to download from

http://java.sun.com/JINI

• Windows 98/2000/NT/XP operating system

• At least 128 MB of memory

• The system must have TCP/IP and a network card installed (Sun Microsystems

2001)

5.2 Running Monitor Space

46

5.2.1 Start JINI Services

JINI services include: a HTTP server, a RMI registry, a RMI daemon, a JINI lookup

service and a javaSpace outrigger (Sun Microsystems 2001).

First, we need to start a HTTP server that will export the downloadable class files that

clients will need to use the service. Figure 5.1 shows how to start the HTTP server.

Figure 5.1 Starting httpd

starting httpd on port 8081 and directory JINI_home Simple http server \H:\JINI1_2\lib\mahalo-dl.jar \H:\JINI1_2\lib\mahalo.jar \H:\JINI1_2\lib\mercury-dl.jar \H:\JINI1_2\lib\mercury.jar \H:\JINI1_2\lib\norm-dl.jar \H:\JINI1_2\lib\norm.jar \H:\JINI1_2\lib\outrigger-dl.jar \H:\JINI1_2\lib\outrigger.jar \H:\JINI1_2\lib\transient-outrigger.jar \H:\JINI1_2\lib\pro.zip \H:\JINI1_2\lib\pro.zip \H:\JINI1_2\lib\reggie-dl.jar \H:\JINI1_2\lib\reggie.jar \H:\JINI1_2\lib\sharedvm.jar \H:\JINI1_2\lib\space-examples-dl.jar \H:\JINI1_2\lib\space-examples.jar \H:\JINI1_2\lib\JINI-examples.jar \H:\JINI1_2\lib\JINI-ext.jar \H:\JINI1_2\lib\JINI-core.jar \H:\JINI1_2\lib\space-examples.zip \H:\JINI1_2\lib\sun-util.jar \H:\JINI1_2\lib\tools.jar

47

Secondly, start rmi registry. The JINI remote event is based on RMI. The event listener

class must inherit from UnicastRemoteObject, so that its method can be called by an

object in another JVM to deliver events. It implements RemoteEventListener, which

includes the notify() method. This method will be invoked whenever an event occurs.

Remote objects that are to be called from external JVMs have to running all the time.

However, it could potentially be a huge drain on resources if there are a large number of

object running at one time. Activation brings a way for objects to be activated on

demand. The RMI activation daemon (rmid) is the entity that handles activating objects.

It does this by spawning new JVMs as needed to run the objects it is activating. External

JVMs are spawned as child processes of rmid, and multiple objects can share these JVMs

with its associated security policies and resources.

Thirdly, it is ready to run JINI lookup service while the http server is running somehwere

on the network. The same http server can be used to export the code for JINI service and

the code for other sevices. The JINI service is called reggie. Figure 5.2 shows the start of

JINI services.

Figure 5.2 Starting JINI services

Fourthly, start JavaSpace and TransactionManager (Sun Microsystems 2002).

starting JINI look up services using absolute policy path: H:\grad\gradAdm\policy.all using absolute logdir path: H:\grad\gradAdm\reggie_log

48

To use JavaSpace-aware clients, JavaSpace service and JINI transaction manager have to

be bother running. Both of these services make use of RMID framework, so each should

be run on the machine with an instance of rmid running on it. Since we already started

rmid and reggie in the former sections, we can start trnasaction manager and JavaSpaces

service. The startup arguments for the transaction manger and javaSpace look like the

JINI service. The following figures show the details.

5.2.2 Start the Server

After the JINI environment is set up, it is ready to run the server and clients. Invoke the

server by invoking runServer.bat http number, rmi registration number and port number

as showed in figure 5.3

Figure 5.3 Starting the server

starting runServer H:\grad\gradAdm>runServer 8081 2575 9998 This file uses features new in windows 2000. Others may require editing. calling setEnvt with argument: . calling java for cet.workflow.server.gradServerAdmin policy:.\policy.all codebase:file:\H:\JINI1_2\lib Stub for cet.workflow.server.gradServerImpl Registered with rmid using absolute logdir path: H:\grad\gradAdm\.\txn_log locator property is: null looking for JINI at: JINI://localhost/ JINI lookup found java space service Found TransactionManager: com.sun.JINI.mahalo.TxnManagerImpl_Stub[RemoteStub [re f: sun.rmi.server.UnicastRef2@9b5217]] create Tran obj: net.JINI.core.transaction.server.ServerTransaction@801159ad for

49

5.2.3 Start the Clients

Lastly start all the clients by invoking studentManger.bat follwed by http number and

host name. The same to graduateManager, departmentManager and TestClients. Look at

the following figures (figure 5.4, 5.5 and 5.6) to have a overview of all the client

interfaces.

figure 5.4 Student interface

50

figure 5.5 Feedback of the students’ input

figure 5.6 Department interface

51

figure 5.7 Graduate college interface

Here is how the clients cooperate with each other.

• The students enter their personal information and click ‘set data’ then all the data

are written into the JavaSpace. A dialog box will pop up and shows the

confirmation of receiving the data.

• The department clicks ‘get data’ and reads all the information currently in the

space. It will select a particular student ID and click ‘get application content’ then

retrieve the application materials for that student from the JavaSpace. It then starts

a transaction to process the student application. Finally it writes its

recommendation back to the JavaSpace.

• The graduate college does the similar thing with the department and they share

the same transaction. The graduate college has one more step. After it heard from

52

department it will set its own recommendations and finally announce the students’

admission status then commit the transaction.

• The student can keeps reading its application status by clicking view result and

only after the graduate college commit the transaction should the students access

their admission information. More on that are showed in the following section.

5.3 Results and Analysis

Figure 5.7 shows the running monitor space. Every client who shares the same space with

each other registers a remote event listener in this case test client with JavaSpace. Once

one of the clients write an entry into the space. The test client will be notified and the

notification message is showed in JavaSpace as shown in figure 5.7

Figure 5.8 Monitor space

Got entries from space Event Source: com.sun.JINI.outrigger.SpaceProxy@0 Event Id: 3178203351531651085 Event Sequence Number: 2 Event Handback: java.rmi.MarshalledObject@9ff4685f Transaction Started... Department starts a write operations write successfully Got entries from space Event Source: com.sun.JINI.outrigger.SpaceProxy@0 Event Id: 253327058132795411 Event Sequence Number: 1 Event Handback: java.rmi.MarshalledObject@9cad593d Graduate College starts a write operations write successfully Transaction Committed. Total time used 38

53

5.3.1 Transaction Implementation

When using transactions in JavaSpace clients that participate the transaction process are

able to see the entry objects within that transaction. The graduate college and the

department are designed to share the same transaction while the students are outside of

the transaction. Therefore, the department and graduate college could read the student

data all the time and see the immediate changes before the transaction commits. The

students on the other hand could only see the admission results after the transaction has

been commited. These have been verified by this application. The transaction result has

been showed in figure 5.8, 5.9 and 5.10. By using the transaction mechnism provided by

JINI and JavaSpace technologies, the school admission system can always generate

consistent results (Lee 2002).

figure 5.9 Graduate college set approval

54

After the graduate college sets approval, the department could get the message right away

as showed in the department interface (figure 5.12). But the students still could not access

the admission information before the graduate college announces its admission and also

commits the transaction as showed in figure 5.13:

Figure 5.10 Department could see the admission result before the transaction committed

55

Figure 5.11 Students ‘s admission result is null before the transaction committed

5.3.2 Transaction Analysis

As discussed in previous chapters, there are two kinds of transactions, which could

achieve the same result in JavaSpace: remote transaction and local transaction. Here in

this section we will verify that local transaction is faster than remote one. Look at figure

5.7 and 5.14. The former runs the remote transaction and the later runs local transaction.

Each transaction is measured by a system timer. The department calls the system timer

56

right after it starts a new transaction. The graduate college records the system time again

right after it commits the transaction. (The time after the department set their

recommendations and before the graduate college start to read the students’ applications

does not count) The total time used is the difference of the two timing period divided by

the iterations. We can see that local transaction processing time is much faster. There is

high variability in times obtained but the local transactions are always much faster. I

summarized four outputs as showed in table 5.1.

Figure 5.12 Local transaction

Got entries from space Event Source: com.sun.JINI.outrigger.SpaceProxy@0 Event Id: 3178203351531651085 Event Sequence Number: 2 Event Handback: java.rmi.MarshalledObject@9ff4685f Transaction Started... Department starts a write operations write successfully Got entries from space Event Source: com.sun.JINI.outrigger.SpaceProxy@0 Event Id: 253327058132795411 Event Sequence Number: 1 Event Handback: java.rmi.MarshalledObject@9cad593d Graduate College starts a write operations write successfully Transaction Committed. Total time used 14

57

Table 5.1 Quantitative data of the outputs

Local Transaction

(Time in seconds)

Remote Transaction

(Time in seconds)

First Output 14 41

Second Output 8 26

Third Output 9 29

Fourth Output 11 36

58

6 CONCLUSIONS AND FUTURE WORK

This thesis develops a JavaSpace application with local transaction mechanism and

presents a monitor space, which supervises the space activities. It is built based on the use

of JINI technology. Services are registered with one ore more JINI look up services in a

JINI community. Graduate college, department and student find the service by multicast

discovery. They share the same JavaSpace. Students input their personal data to the

space. The graduate college and the department take the student records out of the space

by doing read and write the suitable recommendations according to individual’s

background. The students can finally check their admission status by reading their

records from the space. The remote event listener test client acts as a monitor, which

supervises the flow events within the space. By combining local transaction and monitor

space the transactions with the same space process faster and we are getting more

confident by reading the monitor system and know the flow events of the whole system.

6.1 Conclusions

The conclusions of the work are as follows:

1. For certain applications, local transactions provide sufficient transactional support

and are more efficient

2. Local transactions are very useful in single space application and where

transactions are not nested.

59

3. The remote transaction suffers from inefficient performance. In this program, a

local transaction interface as well as transaction implementation classes have been

provided. And the application could create local transaction instead of remote

ones so that it could achieve better performance.

4. By using JavaSpaces you can give up some control and visibility over the

system's activities as a whole. At design and build time it is easy for developers

make errors based on false assumptions about the way a space-based system will

operate. Therefore a monitor space has been designed in this thesis that lets you

record the operations performed on the spaces.

5. The monitor space could also used for expecting new entries. For example, If you

are waiting for a particular client’s response you do not need to keeps retrieving

data from the space which could decrease the space overall performance. By

reading the monitor space you will know exactly when that client responds get the

data in timely manner.

6. Overall, compared to other approaches to building distributed applications,

JavaSpace with transaction mechanism is more flexible, robust, scalable, neutral

to the platform, and easy to use. The java and JINI technology are still maturing.

More functions are being added to them and the compatibility is improving.

6.2 Future Work

In this research, I implement the local transaction mechanism for my JavaSpace

application and I design a monitor space, which could supervise the space activities

60

so that the performance and the reliability can both be guaranteed. The performance

of JavaSpace applications could be further improved by providing some more

functionalities. E.g. read multiple entries from the space write multiple entries into

the space and take multiple entries out of the space, etc. The general ideas are showed

in the following table: It could be possible to extend JavaSpace API and makes

JavaSpace application more flexible. I wish further work could be done in this area in

the future.

Table 6.1 Extended API

There is also an interesting area: nested transactions. If local transactions could be

nested it will be much more widely used.

writeBatch(): entries can be written to the space in batches. All the entries written are transmitted to the space in one remote call. This reduces the overhead of multiple remote calls readBatch(): maybe used to match a group of entries that match a specific template. If the application wishes to receive all or some of the entries that match a given template this method could be used. TakeBatch(): maybe used to take a group of entries that match a specific template. If the application wishes to take all or some of the entries that match a given template in one call this method could be used.

61

7. REFERENCES

Arnold, K., Scheifler, R., Waldo J., & Wollrath, A. (2000). The JINI

Specifications Second Edition, NJ: Sun Microsystems Press.

Bertino, E., Jajodia, S., Mancini, L., & Ray, I. (1996). Multiform Transaction

Model For Workflow Management,

http://lsdis.cs.uga.edu/activities/NSF-workflow/multiform.html (1996).

Bortniker, M., & Conard, J. (2002). Visual Studio .Net Transactions, US: Wrox

Press Ltd.

Edwards, W. K., & Rodden, T. (2001). JINI Example by Example, New York,

Upper Saddle River: Prentice-Hall, Inc.

Elmasri, R. A. (1999). Fundamentals of Database System Third Edition, New

York, NY: Addison-Wesley.

Freeman, E., & Hupfer, S. (2001). Explore JINI Transactions With JavaSpaces,

http://www.javaworld.com/javaworld/jw-04-2000/jw-0421-JINIology.html (2001).

Halter, S. L. (2002). JavaSpaces Example by Example, US: Sun Microsystems.

62

IBM (2000). Tspaces Technology,

http://www.almaden.ibm.com/cs/TSpaces/ (2000).

Lee, P. L. (2002). Applied Project Transactions with JINI and JavaSpace, US:

Arizona State University.

Li, S. (2000) Professional JINI, UK: Wrox Press Ltd.

Lindquist, T. E. (2001). JINI and JavaSpaces Class Notes,

http://pooh.east.asu.edu/Cet427/classNotes/JINI/ (May, 2001).

Roman, E.& Ambler, S. (2001). Mastering Enterprised Java Beans Second

Edition, US: Wiley Computer Publishing.

Sun Microsystems Inc. (1999). JINI Architecture Specification 1.01,

http://www.sun.com/JINI/specs/ (1999).

Sun Microsystems Inc. (1999). JavaSpaces Specification v1.1,

http://www.sun.com/JINI/specs/js1_1.pdf (1999)

Sun Microsystems Inc. (2000). The source of Java technology,

http://java.sun.com (2000).

63

Sun Microsystems Inc. (2001). The Nuts and Bolts of Compiling and Running

JavaSpaces Programs,

http://developer.java.sun.com/developer/technicalArticles/JINI/javaspaces/ (2001).

Sun Microsystems Inc. (2001). JINI Network Technology,

http://www.sun.com/JINI (2001).

Sun Microsystems Inc. (2001). The community Resource for JINI Technology,

http://www.JINI.org (2001).

Sun Microsystems Inc. (2002). JavaSpaces Technology,

http://java.sun.com/products/javaSpaces/ (2002).

Yu, H. L. (2001). Using Java Beans for distributed configuration management on

JINI and JavaSpaces US: Arizona State University.

64