a thesis presented in partial fulfillment of the...
Post on 14-Mar-2020
2 Views
Preview:
TRANSCRIPT
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
top related