1. Project Overview

1.1 Introduction

The Merriam-Webster collegiate Dictionary describes plagiarism as follows:

Plagiarize:

Transitive senses: to steal and pass off (the ideas or words of another) as one's

own: use (another’s production) without crediting the source.

Intransitive senses: to commit literary theft: present as new and original an idea

or product derived from an existing source

Plagiarism remains one of greatest temptations facing students and the only

barrier to its frequent use is the fear of detection. With the spread of the Internet,

the ability to share bodies of work has increased many folds and the risk of

detection has diminished almost proportionally. A search of the Internet reveals

many stores for plagiarizable papers. There are many sites that sell papers and

several other smaller ones that provide smaller collections available for free. As a

direct consequence of the alarming increase in plagiarism, writers and scholars are

getting discouraged from directly sharing their works over the Internet.

Several tools are available to combat plagiarism.

1

Turn-it-in.com: A very well respected tool and used widely by many

institutions. The University of Dayton has a site license for this plagiarism

tool.

Essay Verification Engine (EVE): Available at www.canexus.com, it

accepts popular formats such as Word and plain text and returns a report

with the URL suspected of plagiarism and other statistical data. However

it has a subscription fee.

Moss: A tool developed at university of Berkeley to detect similarities in

software programs.

Our aim at Kansas State University was to develop our own version of a

plagiarism detection tool. The tool was to use the Google search engine for the

web search for related documents and should have an intuitive Graphical User

Interface that was simple yet attractive. It should be able to reduce complex

remote file system operations to simple drag and drop operations on the GUI and

should be able to analyze source documents by just the click of a mouse button.

1.2 Architecture

Figure1-1 shows the basic architecture for the entire application.

2

Fig 1-1 Architecture.

The web server acts as an interface between the client and the database/file

system. Most of the middle tier comprises of SOAP services running on the web

server. The client end will be running an application delivered via Java Web Start.

The client end application authenticates user login, fetches file system data from

the server in the form of XML data and displays it as a tree structure at the client

end. The application also recurses through the client end file system to produce

another tree structure representing a hierarchical view of the client file system.

The user can then move files from his local directory to his web directory at the

server end, feeds files into the IDM search engine and start the search operation

using simple drag and drop operations and mouse button clicks.

3

2 The Existing Scenario

2.1 Current IDM Interface

In the fall of 2001, Sorel Robeldo of Kansas State University, under the guidance

of Dr. Daniel Andersen developed a web-based tool capable of searching the

Internet for any document(s) that could have been totally or partially copied by a

student.

Figure 2-1 Screen shot of the old systems index page

4

Figure 2-2 Screen shot of the old systems search start page

Figure 2-2 shows a sample Screen shot of the old IDM tool. The start page is a

simple HTML page with text boxes, where the user can select files from his file

system to upload. When the upload button is pressed, the files are uploaded to the

server using JSPSmartUpload and the next screen is presented to the user

indicating what files have been uploaded and a search button. Hitting the search

button starts the search operation and the results generated are presented to the

user.

While the IDM tool is easy to use, it has some inherent drawbacks. There is no

provision for user customization with respect to a persistent file store so that a

user can upload and store documents to his web directory before adding them to

5

the search engine. The need was also felt to limit users to this tool and therefore

the ability to create user accounts and logins. Moreover, the current interface was

thought to be too simplistic and a newer graphical user interface was proposed

whereby the user can view his local system and his web directory in a windows-

like hierarchical view. Instead of using a simple upload mechanism as shown in 2-

1, it was proposed to have a drag and drop interface for the user to upload files for

searching.

The other main issue to be addressed was obtaining permission from Google

before running the search. Due to the large number of search queries generated by

the system, Google blocked the IP address from where the requests were

originating after a maximum number of automated requests were served. It was

resolved to use the Google API as against the current method of querying the

Google web-site directly. Every user of the API is provided with a license key,

which entitles him to a maximum limit of 1000 queries per day.

2.2 The Intended Audience

The intended audience for the new IDM system is mainly instructors and their

assistants in Kansas State University and universities throughout the United

States. The user is assumed to have a minimal knowledge of file system

operations like in windows type GUI and should be able to install or already have

installed Java Web Start on their machines.

6

For UNIX users, Netscape is expected to be in the user’s classpath. The tool is

pretty easy to use and the user interface quite intuitive so that people with

minimal computer knowledge can use the tool.

7

3. Tools and Technologies Used

3.1 J2SE/JDK1.3

Java was the natural choice of programming language to use since the application

is a Graphics intensive one and because it is to be delivered via the web. As Sun

Microsystems advertises on its web site “Java 2 Platform, Standard Edition

(J2SETM) software is the premier solution for rapidly developing and deploying

mission-critical, enterprise applications. Version 1.4.1 builds upon Java

technology's cross-platform support and robust security model with new features

and functionality, enhanced performance and scalability, and improved reliability

and serviceability. Version 1.4.1 advances rich client application development

and provides the foundation for standards-based, interoperable Web services that

can be built and deployed today!”

J2SE 1.4.1or the Java 2 Standard edition is Sun Microsystems’ latest release and

JDK 1.1.8 is the development kit that is associated with J2SE. Java is fairly easy

to understand and has a rich set of API’s for application development. In

particular, our application draws heavily from the Java Swing API for its

rendering and functioning.

3.2 Java Web Start

Java Web Start provides the technology to greatly simplify development of Java

applications. It includes the security features of the Java platform and allows the

8

user to use the latest Java 2 Technology with any web browser. It automatically

downloads any files required to run an application and caches them locally for

faster deployment.

Java Web Start can also run applications independent of a web browser.

Applications can also be launched through desktop shortcuts making the

launching of a web-deployed application similar to launching a native application.

From the security point of view, Java Web Start applications can bypass the

typical Sandbox Environment that an applet is subjected. Thus, applications

deployed via Web Start have access to system resources.

3.3 Webserver (Resin)

Resin is a fairly lightweight easy to configure webserver from Caucho

Technologies. Resin includes a full-featured HTTP/1.1 web server dedicated to

serving fast Java dynamic content. It supports the latest Servlet 2.3 specification

from Sun. Resin simplifies creating Java classes by automatically recompiling and

reloading the java when the source changes. It has a very short response times and

most importantly it is free.

3.4 SOAP

SOAP is an XML based lightweight protocol for exchange of information in a

decentralized, distributed environment. Data encoded in a SOAP message can be

used in a variety of situation such as Message Passing and Remote Procedure

9

Calls. SOAP can be potentially used in combination with a variety of other

protocols. SOAP itself does not define any programming model or

implementation specific semantics. It instead defines a simple mechanism by

providing a modular packaging model and encoding mechanisms for encoding

data within modules. SOAP consists of three parts.

1) The SOAP envelope - the top level XML element or the root element in a

XML encoded SOAP message.

2) The SOAP encoding rules – which define a serialization mechanism.

3) The SOAP RPC representation defines a convention that can be used to

represent remote procedure calls and responses.

3.4 JavaMail API

The JavaMail API provides a set of abstract classes that model a mail system and

can be used to build Java Technology based mail and messaging applications.

3.5 JavaBeans Activation Framework (JAF)

Java Activation Framework enables developers to take advantage of standard

services to determine the type of an arbitrary piece of data encapsulate access to

it, and to instantiate appropriate bean to perform the required operations.

10

3.5 Database (oracle)

Oracle is a robust relational database management system. It was the automatic

choice for our system since it was already installed on the CIS system in Kansas

State University.

3.6 XML

Extensible Markup Language (XML) is the universal format for data on the Web.

XML allows developers to easily describe and deliver rich, structured data from

any application in a consistent way. Structured information contains both content

as well some indication about what role that content plays. More and more

developers are migrating towards XML in their applications.

XML helps in creating richer indexes, databases and content management

systems, it lowers switching costs by letting software systems talk to each other

such a car manufacturers system talking to a parts suppliers system. Data

represented using XML can be displayed on a variety of target devices. The same

XML script can be used to target a PDA or a PC.

3.7 Old IDM System

Rather than develop an all-new backend for the document matching system, we

have used the backend of the document matching system developed by Sorel

Robeldo with some changes. The IDM system, written mainly in Java, uses a mix

of Java Servlet technology, Java Server Pages and static HTML files.

11

This system is described in detail in his report “Internet Document Matching

(IDM)” submitted as part of the requirements for his Master of Science Degree at

Kansas State University.

3.8 Rational Rose

Rational Rose Enterprise Edition was used to generate class diagram.

12

4. Detailed Architecture and Implementation

4.1 Database Configuration

The database has a single table called the login table. The login table stores

information about the users of the system. It currently has 4 fields: Username,

Password, Social Security Number(SSN) and Date-of-Birth.

Of the four fields in the login table, only two are used to authenticate the user

when the application starts. These are the Username and the Password fields. The

other two field, namely the Social Security Number and the Date-of-Birth fields

currently are only used as additional information about the user and can be used to

validate a user incase he forgets his Username or Password.

4.2 Web-Server Configuration and Database Connectivity

The system can be broadly divided into the following: static HTML pages, JNLP

files, jar files, the backend IDM system, SOAP Services running on the server end

and the client end application packaged as a jar file.

4.21 HTML pages

There is just one static HTML page, which is basically the index page that

contains a link to the main JNLP file

4.2.2. JNLP files

13

A JNLP file is basically an XML document. The following shows a complete

example of the Login.jnlp file:

Login.jnlp

<?xml version="1.0" encoding="utf-8"?> <!-- JNLP File for Login Demo Application --> <jnlp spec="1.0+" codebase="http://acrux.cis.ksu.edu:7070/test/SOAPlogin/" href="Login.jnlp"> <information> <title>Login Window</title> <vendor>shahid, Inc.</vendor> <description> Login Frame</description> <description kind="short">Login into the IDM search .</description> <offline-allowed/> </information> <security>

<all-permissions/> </security> <resources> <j2se version="1.4.0-beta3" max-heap-size="256M" href="http://java.sun.com/products/autodl/j2se"/> <j2se version="1.4.0-beta2" max-heap-size="256M" href="http://java.sun.com/products/autodl/j2se"/> <j2se version="1.4" max-heap-size="256M" href="http://java.sun.com/products/autodl/j2se"/> <j2se version="1.3+" max-heap-size="256M" href="http://java.sun.com/products/autodl/j2se"/> <j2se version="1.3+" max-heap-size="256M"/> <j2se version="1.3+"/> <j2se version="1.3.1" max-heap-size="256M" href="http://java.sun.com/products/autodl/j2se"/> <j2se version="1.3" max-heap-size="256M" href="http://java.sun.com/products/autodl/j2 <j2se version="1.4.1+" max-heap-size="256M" href="http://java.sun.com/products/autodl/j2se"/> <jar href="Login.jar" main="true" download="eager"/> <extension name = "Additional Jars" href = "additional.jnlp"/> <extension name = "Additional Jars"

14

href = "additionaltwo.jnlp"/> </resources> <application-desc main-class="LoginUser"/></jnlp>

Some of the attributes as defined by the Java Web Start developers guide are

specified below:

The JNLP Element

codebase attribute: All relative URLs specified in href attributes in the JNLP file

is using this URL as a base.

href attribute: This is a URL pointing to the location of the JNLP file itself. The

Java Web Start software requires this attribute to be set in order for the

application to be included in the Application Manager.

The Security Element

Each application is, by default, run in a restricted execution environment, similar

to the Applet sandbox.  The security element can be used to request unrestricted

access.

If the all-permissions element is specified, the application will have full access to

the client machine and local network. If an application requested full access, then

all JAR files must be signed. The user will be prompted to accept the certificate

the first time the application is launched.

15

The Resources Element

The resources element is used to specify all the resources, such as Java class files,

native libraries, and system properties that are part of the application.

Extension attribute: If the application needs to use more than one Jar files signed

by different authorities, the extension attribute is used to indicate the JNLP file

that contains the description of the additional jar files.

A detailed description of all the attributes of a JNLP file can be obtained from

Sun Technologies website. All JNLP files must be encoded in UTF-8 encoding.

The server must return “application/x-java-jnlp-file” MIME type for JNLP files in

order for the Java Web Start software to be invoked.

4.2.3 Jar Files

The client application that is sent to the user in the form of a signed jar file as

prescribed by java web start needs the following jar files in order to execute:

soap.jar: Downloadable from http://xml.apache.org/SOAP/

mail.jar: Downloadable from http://java.sun.com/products/javamail/

activation.jar: Downloadable from

http://java.sun.com/products/javabeans/glasgow/jaf.html

16

xercesImpl.jar and xmlParserAPIs.jar: Downloadable from

http://xml.apache.org/xalan-j/

These files need to be sent along with Login.jar (the client application) and

therefore need to be in the same directory as the client application at the server

end and must be mentioned in the JNLP files specified in the extension tag of

Login.jnlp.

4.2.4 SOAP Services:

There are three SOAP services running on the server each with its own

deployment descriptor.

LoginService: This class accepts the user name and password from the client

application, connects to the database and if the username is a valid one. If the

username password combination is an authentic one, the LoginService class

generates a pseudo-random session-id consisting of the username and a random

number appended together and returns it to the calling application. If user

authentication fails, it returns null.

The LoginService is deployed using the soaplogin.xml deployment descriptor. It

runs under the id “urn:loginService

ServerXMLgen: This SOAP service generates an XML file corresponding to the

user web directory at the server end and sends it to the requesting application.

17

The ServerXMLgen is deployed using the xmlgen.xml deployment descriptor and

runs under the id “urn:xmlGenerator”

OperationManager: This SOAP service runs the file system operations at the

server end. All file system operations are modeled as drag-and-drop operations

and mouse click operations at the client end. Each such client end operation sends

a message to this service with the necessary parameters in order to execute a

matching operation on the file system at the server end. The operations on the

client and server end are mapped on a one-to-one basis.

The operation manager also handles file uploads to the IDM system upload

directory and is also responsible for creating and later deleting the temporary

directory at the server end to store the files that the user uploads for a search.

The OperationManager is deployed using the operation.xml deployment

descriptor and runs under the id “urn:operationService”.

4.2.5 The Backend IDM system

The description of the files used in the backend IDM system can be obtained from

Sorel Robledo’s report.

4.3 Modifications to the IDM system.

The following files of the original IDM system have been rendered redundant.

index.html - The original starting HTML page.

18

sample2.jsp – The JSP application responsible for uploading files to the IDM

upload directory and storing the file names as a value of the user session.

The following files have been modified:

Test.java – Originally Test.java was invoked from sample2.jsp. It picked up the

names of the files to be uploaded from the session and proceeds to initiate the

search from there on. It has been modified so that the session now contains the

value of the new session_id that corresponds to the directory name under the

upload directory that contains the user files to be uploaded.

IntSearch.java – This class has been modified extensively to use the Google API

so as to carry out searches with Google’s permission.

DocComp2.java - This is the class that produces the output when the document

comparison button on the results page is hit. It generates a side-by-side

comparison of the source document with the plagiarized version found on the net.

Since originally the source file names were present in the session as a parameter,

it located the files from these filename values. In the new version, the new

session_id is passed as a parameter in the session and the DocComp2 class uses

this session_id variable to find the uploaded user documents.

4.4 The Client Application

The client application is packaged as a jar file (Login.jar) and is deployed via Java

Web Start at the client end. Along with Login.jar, Java Web Start also downloads

19

other jar files required for the application to run namely activation.jar, soap.jar,

mail.jar, xercesImpl.jar and xmlParserAPIs.jar.

The client application frame contains the following 3 components:

DirectoryTree – It is basically a JTree that displays the client file system in a tree

like structure. The tree has two types of nodes corresponding to Files and

Directories. The directory nodes can be expanded to view the files within and

conversely they can be collapsed. The DirectoryTree recognizes DragEvents and

any node of this tree can be dragged and dropped into the XTree2.

XTree2 – Also extends JTree and is a representation of the client’s files in his

web directory. It supports both Drag and Drop operations. Once again, the nodes

of this tree are of two types indicating weather the modeled object is a File or a

directory. Files from the client’s local system can be moved to his web directory

by simply dragging the required node in the DirectoryTree and dropping it into

his Web Directory tree (XTree2). Nodes in XTree2 can be added, deleted and

renamed and moved. There is also an option to delete all the files in the client’s

web directory by hitting the clear button. The files in XTree2 serve as the source

documents for the IDM search. Any file that needs to be searched can be simply

dragged from XTree2 and dropped into the Droppable List.

DroppableList – It extends JList and models a list of the files that need to be

searched. XTree2 serves as the source for the Drop enabled DroppableList. The

user can simple drag a node from XTree2 and drop it into the DroppableList.

20

Once the files are present in the list, the user needs to hit the Search button to start

the search. The Clear button can be used to purge files.

There are several other classes that are packaged in the Login.jar jar file that are

used by these three components and these are listed along with the class diagram

in the next section.

The main thing to note in the client application is that bye default, JTrees do not

support Drag and Drop operations, so instead, each of the trees must implement

the suitable Drag listeners and when the corresponding event is fired, take the

necessary course of action.

Another thing of interest is that Windows does not lend itself well to the java

File.listRoots() method that is used to get the roots of the system. It inexplicably

gets stuck trying to access A: and other removal drives and throws up a window

asking if you would like to abort, retry or ignore which refuses to go away in spite

of any amount of clicking. To get around this we use the

WindowsAltFileSystemView written by Steve Bohne of the Java Web Start

Engineering group.

21

5 Class Diagram

Figure 5-1 UML class diagram.

Figure 5-1 shows the UML class diagram for the entire application. Of the classes

shown, the OperationManager, ServerXMLgen and LoginService are the SOAP

22

services running on the server side. The rest of the classes are packaged as

Login.jar to run on the client side.

The main method is in LoginUser and therefore this is the class that gets

instantiated first. LoginUser makes user of the LoginDialog class to get the client

information. It then uses the verifyUser() method of the SOAP service

LoginService to authenticate the user. If the user is verified, LoginService

generates a session id and returns it to LoginUser. If the session id is not null,

meaning that the user has been verified, LoginUser then queries the

createDirModel() method of the SOAP service ServerXMLgen which returns an

XML document as a string corresponding to the users web directory.

LoginUser then instantiates the XTreeTester frame and passes the XML string to

it as a parameter. XTreeTester in turn creates instances of DirectoryTree, XTree2

and the DroppableList. DirectoryTree recurses through the user’s local machine

and populates itself with this data. XTree2 uses the XML string corresponding to

the user’s web directory to populate itself.

DirectoryTree, XTree2 and the DroppableList have various Drag and Drop

Listeners to listen to drag and drop events that are translated to File System

operations. XTree2 and the DroppableList use the SOAP service

OperationManager to carry out these File System operations. Finally

DroppableList uses BrowserControl to generate an instance of a web browser.

23

6 User Interface

The user interface starts with the index page as shown below.

Figure 6-1 The index page.

After the user clicks on the link, it starts Java Web Start which then proceeds to

download the jar files from the server. After the jar files are downloaded, the user

authentication dialog box pops up

24

Figure 6-2 The Login Dialog.

On entering the correct user name and password, the applications main UI is

displayed as shown below

Figure 6-3 Screen shot of the User Interface.

As can be seen, the application shows the users current system and his web

directory in a tree structure.

Nodes in both the Trees can be expanded and contracted at will.25

Figure 6-4 Screen shot of nodes being expanded.

Nodes (Files and Directories) can be copied from the Local Machine to the web

directory. Consider the node D:\190 moved over to shahid\girish\

26

Figure 6-5 Screen shot of nodes being moved.

The Web directory Tree also allows us to rename a node, add and delete a

Directory Node and delete a File node.

Figure 6.6 and 6.7 show the operation of renaming a node. The node shahid\girish

is renamed to shahid\gary

27

Figure 6-6 Screen shot of a node being modified.

Figure 6-7 Screen shot of node modification complete.

28

The figure 6.8 and 6.9 below show the operation of deleting a File node shahid\

gary\190\README.txt

Figure 6-8 Screen shot of node selected to be deleted.

Figure 6-9 Screen shot of node deletion completed.29

A node can be moved to any level in the hierarchy as long it satisfies the rules of

the underlying File System. Consider the moving of the node shahid\gary\190 to

shahid\florida\cgiwig\190

Figure 6-10 Screen shot before moving the node.

30

Figure 6-11 Screen shot after node has been moved.

Finally, files that need to be searched can be copied into the DroppableList that is

entitled “Files to Upload”. At this time only text files can be moved into the

search list and the files must be in the client’s web directory to be uploaded into

the search engine.

Consider moving the file shahid\test_files\EinsteinShort.txt into the upload

directory.

31

Figure 6-12 Screen shot before moving a file to Upload List.

Figure 6-13 Screen shot after files have been moved to Upload List.

32

Clicking the clear button under the list can purge the files uploaded in the search

list. To start the document search, the search button has to be pressed. This calls

the Test.java Servlet of the IDM system and when the search is complete an

HTML page is invoked in the default web browser which contains a link to the

results page.

Fig 6-14 Screen shot of the page with the results link for the search.

When the link is clicked, the results page is shown.

33

Figure 6-15 Screen shot of the Results Page.

Clicking on details brings up a web page corresponding to the following.

34

Figure 6-17 Screen shot of the Details Page.

Clicking on the Document Comparison button brings up the following page.

Figure 6-18 Screen shot of the Document Comparison page.

35

7. Testing and Results

The application has been tested on both Sun Solaris and Windows Operating

system using Java Web Start version 1.0.1_02. While it runs seamlessly on the

Solaris terminals, there is one slight glitch on the windows system. While

generating the DirectoryTree structure in the windows environment, the user will

encounter a window saying that the A: had no disk and asking if you would like to

abort, retry or ignore. This window may pop up a couple of times and will

disappear after that.

The application will take a while to load the first time around because of the large

number and size of jar files that need to be downloaded but on every next

invocation, it will start of almost instantaneously since it caches information since

the last access.

There is no compatibility issue with Web Browsers because the application runs

independent of a Web Browser. Browsers are only used to display HTML pages.

While the system is robust in general, there is one key area that is prone to errors

and that is the Google API. There are key words like “of” that cause the Google

API to throw and error. In addition to this, after the quota of 1000 searches is

exhausted, the Google API throws an error saying that the search quota has been

exceeded and every subsequent search request will be denied.

36

8. Future Enhancements

There are several enhancements that could make this tool a more viable option.

The underlying IDM system that compares the documents using Google could use

a faster more efficient algorithm to break the documents down into meaningful

chunks. As of now, some of the chunks generated are often meaningless with

respect to comparison with other documents. Chunks like “of” and “the” and

sometimes even blank strings seem to be able to find their way into the search.

Such chunks have to filtered out because they contribute toward slowing the

system down and increase the number of searches that we have to carry out using

Google.

Another key area of concern is the high amount of searches that the system

generates. Test documents between 5-10 KB are generating about 300 searches

each. Either the number of searches has to be toned down which again refers to

the fact that the chunking algorithm has to be more efficient, or permission needs

to be obtained from Google to be able to run a much higher number of searches

preferably both.

Currently the system allows only 5 documents to be uploaded to search at one go

because of the search limitations mentioned above. Once the previous issue has

been resolved, this issue can also be addressed.

37

The entire tool could be packaged as an application that can be run from the

user’s local machine thereby increasing speed of execution and distributing

computation amongst users rather that concentrating computation onto a single

server. Rather that the administrator using his search key to run the searches, each

user could also register with Google and obtain his own private key to the Google

API.

Another useful addition to the tool would be to compare all the files with the users

own directories for possible plagiarism. The search mechanism can be enhanced

to accept a richer variety of input files as against just plain text files.

38

9. Conclusion

With the growing incidences of Plagiarism, we feel that this tool will go a long

way in helping instructors concentrate on the quality of work rather than worry

about its source and the fact that a document may have been plagiarized.

The new GUI adds a lot of features to the IDM system developed by Sorel

Robeldo and adds some sorely needed user customization. Moreover, since the

user’s web directory serves as a persistent file store, once the user has uploaded

files, he can always terminate the application and come back at a later time login

and continue from where he left of.

Since the application is delivered online, the user is not geographically

constrained from using the tool. We have used the most recent Internet

technologies and have ensured that the application will lend itself well to

upgrades at a future time.

39

10. References

- Rob Kenworth, “Improve JTree usability with Drag and Drop”, Java

World Java Tip-97,June 30 ,2000, http://www.javaworld.com/javatips/jw-

javatip97.html

- Kyle Gabhart, “Roll Your Own Swing-based XML Editor”, DevX

10

MinuteSolutions,http://gethelp.devx.com/techtips/java_pro/10MinuteSolut

ions/Gabhart10min03/Gabhart10min03-1.asp

- Kathy Walrath - Mary Campione “The JFC Swing Tutorial: A Guide to

Constructing GUIs”, Addison-Wesley Pub Co, July 1999, ISBN:

0201433214

- Java Web Services Tutorial, “Reading XML Data into a DOM”,

http://java.sun.com/webservices/docs/1.0/tutorial/doc/JAXPDOM3.html

- Eric Armstrong - Tom Santos, - Steve Wilson, “Understanding the

TreeModel”, Nov. 02, 2002,

http://java.sun.com/products/jfc/tsc/articles/jtree/

40

- David Geary, “Drag and Drop with Swing”, Nov. 1, 2002,

http://java.sun.com/products/jfc/tsc/articles/dragndrop/

- Steve Bohne, “Using JFileChooser in WebStart-deployed application”,

Java Web Start and JNLP Forum, Oct. 18 2000,

http://forum.java.sun.com/thread.jsp?forum=38&thread=71491

- Steve Spencer, “Control Browsers from your Java Application”, Java

World Java Tip-66, January 01, 1999,

http://www.javaworld.com/javatips/jw-javatip97.html

- Samudra Gupta, “Using SOAP With Java”, Java Boutique Tutorials,

http://javaboutique.internet.com/tutorials/SOAP/

- Brett McLaughlin, “Java and XML”, 2nd Edition, O’Reilly Publications,

ISBN: 0-596-00197-5

- Sun Microsystems, “Java Web Start Technology Guide”,

http://java.sun.com/products/javawebstart/docs/developersguide.html

41