Distributed Database Storage Solution in Java

(1)

Distributed Database Storage Solution in Java

Johan Funck

May 4, 2010

Bachelor’s Thesis in Computing Science, 15 credits Supervisor at CS-UmU: Jerry Eriksson

Examiner: Jonny Petterson

Ume˚ a University

Department of Computing Science SE-901 87 UME˚ A

SWEDEN

(2)

(3)

Abstract

Car sales companies have in the last couple of years discovered that there is a big market in storing their customer’s summer and winter tires for a small fee. For the customers it is very convenient to get rid of the all known storage problem with season tires. Burlin Motor Ume˚a is one of these companies and they are offering seasonal storage and change of tires in autumn and spring as well as washing of tires.

The main problem for this kind of storage is how to make the storage easy to overview and how to keep track of all tires. This paper is a report on a distributed storage solution in Java for summer and winter tires based on criteria from Burlin Motor Ume˚a.

(4)

ii

(5)

List of Figures

3.1 System design client-server-database communication . . . 8

3.2 Server threading . . . 8

3.3 Client threading . . . 9

4.1 Main client window . . . 13

4.2 Main window menu . . . 14

4.3 Connect to server pop up . . . 15

4.4 Successful connection pop up . . . 15

4.5 Unsuccessful connection pop up . . . 15

4.6 Search on registration number . . . 16

4.7 Search on storage location . . . 16

4.8 Displaying customer info . . . 17

4.9 Storage listing . . . 17

4.10 Quick menu . . . 18

4.11 New customer window . . . 18

4.12 File chooser . . . 19

4.13 Current customer . . . 19

4.14 Update customer window . . . 20

4.15 Printed label . . . 20

4.16 Delete customer pop up 1 . . . 21

4.19 Log file pop up . . . 22

v

(8)

vi LIST OF FIGURES

(9)

Chapter 1

Introduction

The task of this thesis work was to develop a prototype of a distributed database storage solution for car tires. Car companies nowadays usually offer winter and summer storage for their customer’s tires. To keep track of the tires it is becoming more and more advisable to have a computerized solution instead of a pen and paper solution.

The main criteria were that it should be a network solution i.e. the storage should be able to be reached from any computer on the intranet and that the application was to be run in WinXP.

Burlin Motor Ume˚a is a part of the Burlin Group, which has its main office in Skellefte˚a. Burlin Motor Ume˚a is the local vendor in Ume˚a of Toyota and Lexus and they offer a full service establishment for these cars. Used cars and rental cars are also a part in their business concept as well as tire storage for their customers.

1.1 Paper outline

This paper is divided in six chapters. Here is a brief description of each chapter.

Introduction A brief introduction of this thesis contents to the reader.

Problem Description An in-depth explanation of the projects various parts and problems.

Accomplishment An explanation of how the work was done and how the project proceeded.

Results Describes the outcome of the practical work.

Conclusions What have I learned? Could I have done things otherwise?

Acknowledgments Credit to people who have been of great help during this thesis.

1

(10)

2 Chapter 1. Introduction

(11)

Chapter 2

Problem Description

The Burlin Group has outsourced their IT section to a company named Exait.

Exait’s main office is located in Pite˚a but they have departments in Lule˚a Skellefte˚a and Stockholm as well. Burlin Motor Ume˚a has their main server in Skellefte˚a in Exait’s care. The plan was to implement a Java server and a Microsoft SQL database on that server and install Java client applications on Burlin Motor Ume˚a’s computers here in Ume˚a.

2.1 Problem Statement

The focus of this project was to implement a prototype software application, which handles Burlin Motor Ume˚a’s customer tire storage.

I had free hands in deciding programming language, system design and appearance (GUI). The only criteria regarding the actual system design was that it would be developed to run in WinXP and that the storage should be able to be reached from any computer within the intranet at Burlin Motor Ume˚a i.e. it was to be a distributed system.

2.2 Methods

The project was mainly divided into five steps. Gathering information and requirements, system design / programming language, GUI, implementation and report writing. Of course the steps were somewhat overlapping so problems faced during higher steps resulted in stepping down to overlook the whole project and make suitable changes[6].

The gathering of information and requirements was mainly done with in- terviews with staff at Burlin Motor Ume˚a conversations with my supervisor Jerry Eriksson and with P-O ¨Ostberg at CS-UmU. I also had some contact with Exait in the beginning of the project to establish what kind of software that was available on the main server.

3

(12)

4 Chapter 2. Problem Description

The second step was to design the system and choosing platform. Re- garding the system design, I initially had two different strategies. One was a client/server solution in Java or C++ and the other was a web-based solution with JSP and Apache TomCat. After discussing these two designs with Burlin Motor Ume˚a it became obvious they did not want a web-based solution and thus it was settled to be a client/server solution.

In the process of deciding programming language, I narrowed down the choices to Java or C++. Although I was very close to go with any of Microsoft’s Visual languages. In the end, I decided to go with Java. Both because it is platform independent and because I felt most familiar with it. Because it has been almost six years since I programmed on a regular basis as a student, I reckoned that I should go with the language I felt most comfortable with.

The third step consisted of designing the GUI[5]. The design should be easy to understand and easy to use. Because some of the staff in the workshop will only use this program when it is time for the annual tire changing seasons, it could take up to 6 months between usage. Therefore, the GUI should be intuitive and straightforward.

The implementation step consisted of different smaller steps such as set- ting up a SQL database, implementing the server and client applications and designing the GUI. On two occasions, I visited Burlin Motor Ume˚a showed my work, and took in feedback so I knew I was on the right track regarding both the implemented functions and the GUI. The tools I used¹to develop this project were Java NetBeans 6.8, JCreator LE 4.5, Jasc Paintshop Pro 7, Zebra Setup Utilities, ZebraDesigner and MySQL Server 5.1. All software tools used were free or bought at a previous occasion.

Writing the report was done continuously throughout the whole project both in a work diary and on an online blog[1]. The blog’s purpose was mainly an easy way to keep diary of my work progress and to display my work for those of interest .

2.3 Goals

The main goal was to have a fully working and stable application with all the extra functions working as well. However, it quickly came apparent that this might not be doable within 10 weeks. Therefore I divided the goal into two steps, must-have and optional. Step one was to have a basic storage solution ready with the most important functions available. Step two was to have all extra functions working, or at least as many functions as possible.

1Java NetBeans and JCreator to implement GUI and server, Paintshop for designing logotypes and images, Zebra software for installing the label printer and for designing the printer labels. MySQL is the database used in this project.

(13)

2.4. Purposes 5

2.3.1 Step one: Must-have

The most fundamental requirements was to have a working application with full database support and basic functions as ”Create new customer”, ”Update”,

”Delete” and search functions for registration number and storage location. A complete list of the basic functions is shown below.

– Search on registration number or storage location.

– Print tire labels.

– View current customers in storage.

– Create, update and delete customers.

– Sign and log changes in customer information.

2.3.2 Step two: Optional

The optional requirements were sorted out together with Burlin Motor Ume˚a and not necessary to manage the tire storage.

– Add pictures of tires and rims.

– Print worksheet and customer receipt.

– Print warehouse.

– View list of available storage spaces (almost the same as viewing storage).

– Check for bad tires (tire pattern less than 3 mm) and produce a list of these customers.

– Manage database GUI (monitor, see section 3.3.5).

2.4 Purposes

The purpose of this application is to make available an easy way to manage and overlook Burlin Motor Ume˚a’s customer tire storage. For the salespersons it will be a lot easier to log on to the storage application and retrieve pictures of a specific car’s tires and rims and show them to a customer on the computer screen. Instead of finding the guy with the keys, physically walk the customer out to the warehouse, unlock the doors, find the tires, climb up and get all four tires (winter or summer tires depending on season) and show them to the customer, put the tires back, lock up and go back into the store.

There also is a major time gain for the workers in the recondition department who are responsible for the keys to the actual tire storage. As it is now, one of the two reconditioning men must, for safety reasons, follow the salesper- son and customer to the storage, unlock and lock the storage. Every time the

(14)

6 Chapter 2. Problem Description

reconditioning men must leave their work to show tires for customers, they lose about 15 minutes of work. Since the customer always comes first, this could be in lunchtime or any other unsuitable moment.

2.5 Related Work

There are mainly two big competitors out on the market regarding tire storage solutions.

– Hjulius c by Formac AB – Kobra II c by Fordonsdata.

Burlin Motor Ume˚a has used Hjulius c in the last years but is not com- pletely satisfied with the software. Mainly because there is no network support in the version they are using. Formac has released newer versions, which of- fers better usability, but the price tag and the former version’s letdowns is a disadvantage.

Kobra II c is widely used among car companies and is a wide system for handling all kinds of things. Like billing, spare parts, workshop bookings and more. Fordonsdata has recently released a module for handling tire storage to their Kobra II c system. One of Fordonsdatas main advantages is that Burlin Motor Ume˚a is already using their Kobra II c system in a wide extent. Their main disadvantage is the price tag.

(15)

Chapter 3

Accomplishment

The following chapter describes the methods used, design paths and implementation strategies to accomplish this project[6].

3.1 Method

The development phase of this project was quite similar to the method de- scribed in section 2.2.

1. Gather requirements and information. Conversations with Burlin Motor Ume˚a, Exait and my supervisor to narrow down the project into what re- alistically could be done in 10 weeks. Sorting out must-have and optional goals.

2. Defining the system design and choosing programming language based on my own programming skill, estimated learning curve, estimated difficulty and of course the 10 week time limit.

3. Installing necessary software.

4. Implement client, client GUI, server, monitor and database prototypes.

5. Evaluate and analyze prototype.

6. In case of problems and things not thought of, loop back to point 4 and possibly re-think system design.

7. Finalize application.

3.2 Design

The system design of the client-server-database communication is shown in figure 3.1 below[4]. The client sends upon startup a connection request to

7

(16)

8 Chapter 3. Accomplishment

the server. If the connection is accepted, the server sends a connection OK message to the client and adds the client to the client list. When the client sends a question, the server handles it and tries to connect to the database[3]. If a connection was successfully made, a query is sent to the database. The server handles the database result and if it was a successful query, an OK message is sent to the client along with the desired information. The client then handles this information and displays it. Upon an unsuccessful connection or query to the database, the server sends a NOK message to the client, which then takes the appropriate action.

Figure 3.1: System design of client-server-database communication The same design applies to the monitor-server-database communication.

3.2.1 Server

The server was designed as a multi threaded server[3] (figure 3.2).

Figure 3.2: The server threading design

This design was chosen to let the server’s main thread and listener thread

(17)

3.3. Implementation 9

spend as much time possible listening for incoming connections instead of handling the communication issues[5].

3.2.2 Client

The client threading design is very simple (figure 3.3). The main GUI starts upon a successful connection to the server a listener thread which handles incoming and outgoing communication[3].

Figure 3.3: The clients threading design

3.3 Implementation

All work on implementing this application has been done in my own home office, were I set up a small home network similar to the intranet at Burlin Motor Ume˚a. The label printer was installed on one computer, the server and database on a second computer and the client on a third computer.

3.3.1 Database

The database installed on Burlin Motor Ume˚as server in Exait’s care is Mi- crosoft SQL Server. However, to be able to do all the programming at home I installed MySQL, which is very easy to manage. Thus, the application at this point is for use with MySQL although it can easily be converted to MS SQL.

The database design is quite simple and consists of only one table, which holds all customer information. The primary key is the storage location and the registration number of the customer’s vehicle is a unique identifier. This makes it impossible to accidentally have two customers stored in one storage location. It also makes it impossible to have duplicate entries for one customer, as the customer number is the registration number of the customer’s vehicle.

3.3.2 Server

The server is threaded and consists of a main thread that starts a new thread for incoming client connections and then listens for incoming monitor connections.

The client listener holds a client list and upon a successful connection with a client, it adds the client to the list and starts a new client handler thread for

(18)

handling this client. When the client disconnects or the connection is lost, the client is removed from the list and the client handler thread is terminated[2].

The main thread, after it started the client listener thread, is now listening for incoming monitor connections. A monitor connection is handled the same as a client connection and starts a new monitor handler thread. A monitor is a GUI, which is used to monitor the server’s communication with clients and database. Also, it can be extended to manage the database but this has not yet been implemented.

3.3.3 Client

The client was mainly built in NetBeans as a desktop application, which was a great time saver. Designing GUI’s in NetBeans turned out to be a lot easier than I thought as there is pre-built event-handlers for almost everything.

The design of the GUI changed somewhat during the implementation of more functions.

The client application itself consists of a main thread that starts the GUI.

When a connection is made to the server, it starts up a new thread that handles the communication with the server.

3.3.4 The customer object

The main things passed from server to client are customer objects. The customer object holds all information for a specific customer such as registration number, storage location, image locations and more. A customer object is created when the user creates a new customer (figure 4.11). Upon creation, all entered information and images in the new customer window are inserted into a customer object and sent via an ObjectStream to the server. The server parses out images, creates a log file, and stores them on disc. Then the server sends the rest of the customer’s information along with the paths to the saved images and log file to the database for storage.

When the client sends a request for a specific customer’s information, the server queries the database for that customer. The returned information (if the customer was found) is inserted into a customer object. Images and the log file are retrieved from their physical disc location and inserted into the customer object. If all went well the customer object is sent to the client via an ObjectStream. The client displays the customer object for the user.

The customer object can be seen in appendix A

3.3.5 Monitor

The monitor is a GUI that allows for example an administrator to monitor the events occurring in the server. The administrator can then see all communication and message handling. This is very useful for debugging and as future work, it can easily be extended to manage the database and server.

(19)

3.3. Implementation 11

3.3.6 Label printer

The label printer to be used with this application was a Zebra TLP-2844 from Zebra Technologies Corporation. Drives and manuals were downloaded from their website together with a design tool and a setup utility. Since the printer did not support network printing, the simplest way to be able to print from different computers was to install the printer on one computer and then share the printer over the network.

The labels were to contain mainly two things, the storage location and the customer’s registration number. In addition, I added the current date so you can tell witch date the tires were stored

(20)

(21)

Chapter 4

Results

4.1 Client

4.1.1 Main window

The main window looks as shown below in figure 4.1. The idea was to make it intuitive and straightforward. All of the functions for daily use can be reached without accessing the menu.

Figure 4.1: Main client window 13

(22)

14 Chapter 4. Results

The menu (figure 4.2) holds some more functions that are not used very often, like different printing options. It also holds some of the most basic functions as create new customer. Below is a list of the menus different options.

Figure 4.2: The menu layout in the main client window.

– ”Anslut” - Connect to the server.

– ”Koppla fr˚an” - Disconnect from the server.

– ”Ny kund” - Create a new customer. Pops up a new window.

– ”Skriv ut...” - Sub menu for printing functions.

• ”Etiketter” - Prints tire labels for the current customer on the label printer.

• ”Arbetsunderlag” - (Not implemented) Prints worksheet for workshop personnel when its time for example a tire change.

• ”Kundkvitto” - (Not implemented) Prints a receipt for the customer upon changing of tires.

• ”Hela lagret” - (Not implemented) Prints out the whole storage with registration number, storage location and customer info.

– ”Avsluta” - Closes the client application.

4.1.2 Connecting to the server

A dialog that makes it possible to choose connection settings is not yet implemented and therefore the connection settings is currently hard coded default values.

To connect to the server the user either uses the menus ”Anslut” option or simply clicks any of the buttons in the main window. Since all button events requires that the client is connected they detect the connection status. If the client is not connected, a pop up window displays (figure 4.3) and asks whether the user wants to connect to the server.

(23)

4.1. Client 15

Figure 4.3: Connect to server pop up.

Upon a connection attempt from the client, the server either accepts the connection or refuses it[4]. Upon a successful connection, the client pops up a window saying the connection was successful (figure 4.4). If no connection was made a pop up saying the connection was unsuccessful is shown (figure 4.5).

Figure 4.4: A connection to the server was successfully established

Figure 4.5: Connection to server could not be obtained.

Disconnecting from the server is done either via the menu’s ”Koppla fr˚an”

or by simply closing the window, which exits the application, disconnects, closes all threads and cleans up.

4.1.3 Searching

To search for a specific customer’s tires the user simply types in the customer registration number in the field ”Reg Nr” in the search box up in the right corner (figure 4.6) and then clicks on the search button ”S¨ok”. There is a document filter wrapped on the text field that converts all typed characters to uppercase. It also limits the number of typed characters and numbers to six. This is because a Swedish registration number consists of exactly six

(24)

characters (ex ABC123). A function to select a different countries registration number format is yet to be implemented. When the search button is clicked, the registration number is checked if it consists of exactly three letters followed by exactly three digits. If not, there is no search performed. Instead, a blipping sound is heard and the incorrect typed registration number is highlighted.

Figure 4.6: Searching on registration number.

It is also possible to search which customer that holds a specific storage location. To do this the user types in the color code of the location in the field ”F¨arg” and the number of the location in the field ”Plats” (figure 4.7).

These text fields also have document filters wrapped around them allowing only uppercase characters in the ”F¨arg” field and only two characters in the ”Plats”

field. Allowing only uppercase characters simplifies searching and comparison.

This approach to input was chosen because Burlin Motor Ume˚as storage is based on locations that consist of a color and a number like ”GR ¨ON 12”.

Figure 4.7: Searching on a storage location.

If the search was successful i.e. there was a matching registration number or storage location in the database, the client displays the information for this customer in the tab ”Kunduppgifter” (figure 4.8). By clicking on one of the thumbnails, a window pops up and displays a bigger picture of the thumbnail clicked.

4.1.4 Displaying the storage

To display the whole storage in a list the user simply clicks the button ”Visa lager” in the ”Alternativ” box located to the right in the main window. The

(25)

4.1. Client 17

Figure 4.8: How the customer info is displayed.

storage is then displayed in the tab ”Lager” in the center of the main window (figure 4.9). By double clicking on a customer’s entry in the list, this customer’s information is displayed in the ”Kunduppgifter” tab.

Figure 4.9: A list of the current storage.

Also the user can right click a customers entry in the storage list to pop up a quick menu (figure 4.10). The quick menu consists of four entries, which are:

– ”Skriv ut etiketter” - Prints tire labels for this customer (section 4.1.7).

– ”Uppdatera kund” - Brings up the update customer window (section 4.1.6).

– ”Uppdatera lager” - Updates the storage listing (not yet implemented).

– ”Ta bort kund” - Deletes this customer (section 4.1.8).

(26)

Figure 4.10: The quick menu.

4.1.5 Creating a new customer

Creating a new customer is done by clicking on the button ”Skapa ny kund”.

A new window pops up (figure 4.11) and the user simply fills in all the details about the customer. Pictures are added by clicking the buttons in the picture sections of summer and winter tire details, and then selecting the picture to be inserted in the file chooser dialog that pops up (figure 4.12). A filter only showing pictures is used by default in the file chooser dialog.

Figure 4.11: The window for creating a new customer.

The only things actually required when creating a new customer is registration number, storage color, storage place and a signature. The storage color and place is chosen by first selecting the storage color and then the storage place. When choosing storage color the values in the storage place combo box changes to the actual numbers available in Burlin Motor Ume˚as physical storage. A function to change these values by for example an administrator is yet to be implemented. Also, a function that only displays the storage locations

(27)

4.1. Client 19

Figure 4.12: Add pictures by selecting the picture in the file chooser.

that is not occupied is yet to be implemented.

4.1.6 Updating a customer

To update a customer there has to be a current customer. If there is a current customer, it is shown in the box ”Aktuell kund” (figure 4.13 ) located in the center top of the main window. The current customer is set when a successful search on a registration number or on storage location is made. In addition, the current customer is set when the user double clicks on a customer in the

”Lager” tab.

Figure 4.13: The current customer.

When the update customer button is clicked a new window pops up (figure 4.14). This window is quite similar to the window shown when creating a new customer. The only thing that differs is that the registration number and the storage location are not editable. If the user wants to edit this, creating a new customer is advised.

The update window displays all current information about the customer.

In order to update the user simply changes the values that is outdated or adds new pictures. As in the new customer window, the user has to sign the changes before clicking the update (”Uppdatera kund”) button located in the lower right corner.

(28)

Figure 4.14: The update customer window

4.1.7 Printing labels

To print labels for a customer there also has to be a current customer selected. If so, the user clicks on the button ”D¨acketiketter” in the bottom of the customer information tab. The client then searches for an installed Zebra TLP-2844 printer and if it is found, four labels are printed. One for each tire. A picture of a printed label is shown below in figure 4.15. Labels can also be printed from the storage tab by right clicking on a customer’s entry in the list and choosing

”Skriv ut etiketter”.

Figure 4.15: A printed label.

(29)

4.1. Client 21

4.1.8 Deleting a customer

To delete a customer the user either uses the quick menu (section 4.1.4) in the ”Lager” tab or clicks the ”Ta bort kund” button in the bottom of the

”Kunduppgifter” tab. When using either of these possibilities to delete a customer, a pop up displays asking if the user really wants to delete this customer (figure 4.16).

Figure 4.16: Really delete?

If the user clicks yes another pop up shows asking the user to sign the deletion of this customer (figure 4.17). This is for security reasons so no customer is accidentally deleted.

Figure 4.17: The user must sign the deletion of a customer.

If a customer was successfully deleted a third pop up displays saying deletion was a success (figure 4.18).

Figure 4.18: Deletion of a customer was successful

4.1.9 Show log

Each customer has a log file. To view this log file the user clicks the button

”Visa logg” in the bottom of the ”Kunduppgifter” tab. The log file for the

(30)

current customer is then display in a new window (figure 4.19).

Figure 4.19: Displaying the log file for the current customer.

4.2 Problems

4.2.1 Data passing

The biggest problem I had was how to pass the data in an efficient way. I came up with the customer object idea at the very beginning but the implementation of the ObjectStreams caused a lot of time spill. It just would not work. After several hours trying to figure out what was wrong, with the aid of various search sites on the internet, I finally found that the ObjectInputStream must be instantiated after the ObjectOutputStream. Before I found this out, I had almost made a brand new design for the data passing which took me all too long.

4.2.2 Handling images

The passing of images back and forth also took some extra time. Since sending objects requires that the object to be sent is serializable, it not possible to just add images to the customer object and then send it through the ObjectStream.

This because the Image class is not serializable. To come around this problem I first recreated the picture as a two dimensional integer array list, which is serializable, and then sent it through the ObjectStream and recreated the Image on the other side. I found this very complicated and the images lost some quality in the process. Then I discovered that the ImageIcon class was in fact serializable and the problem was solved. Images can easily be converted to ImageIcons and vice versa. Unfortunately, I had already spent a lot of time on the other solution that set me back a day or two.

(31)

Chapter 5

Conclusions

To have free hands regarding system design, programming language etc. turned out to be a problem rather than an advantage. There are many different ways in designing and implementing an application. Narrowing down which way I should follow took a great deal longer than I anticipated and caused quite a bit of headache.

To follow the design path I had chosen also proved to be somewhat difficult as problems I had not foreseen forced me to reconsider the design in a few occasions.

5.1 Restrictions

There are a few restrictions and the greatest is that the prototype is not fully working with all extra functions. I had to skip the print-outs of worksheet and the entire storage. There is also no support for viewing which storage locations that are not occupied. There is no function for checking for pore tire patterns and the monitor management is not yet implemented either. Finally, I discovered that when updating a customer’s information I could not change the pictures of tires and rims. A code related issue and since the adding of images was the last function I added, it is not properly bug tested.

5.2 Limitations

The storage is at this point restricted to the actual size of the physical storage at Burlin Motor Ume˚a. However, storing the size of the storage in a .txt file and allowing the administrator to change these values is not too far away.

The storage is also limited to consist of a color and a place, which may not be the most optimal solution. However, since the physical storage at Burlin Motor Ume˚a has this solution today, that was the way I decided to implement it.

23

(32)

24 Chapter 5. Conclusions

5.3 Thoughts

Overall, I am quite satisfied with the achieved results although I wish I had been able to finish all extra functions and all other ideas I had.

5.4 Future work

I hope that Burlin Motor Ume˚a finds this prototype worth its while and decides to go with this solution. If so, the first things to do is to perform some serious bug testing[6], implement all optional requirements and extend the monitor to a management utility for the database and the server.

(33)

Chapter 6

Acknowledgments

I would like to thank my supervisor at CS-UmU Jerry Eriksson for making me start on the thesis report at an early stage and helping me out with whom to talk to with my programming problems.

I would also like to thank P-O ¨Ostberg at CS-UmU for helping me with platform issues and the system design of this application.

At last, I would like to thank Jan Hellgren at Burlin Motor Ume˚a for this great opportunity to finally do my thesis work and hopefully claim my degree in computer science.

25

(34)

26 Chapter 6. Acknowledgments

(35)

References

[1] J. Funck. Johan Funcks Blogg. http://johanfunck.blogg.se, 2010.

[2] Tamassia Goodrich. Data Stuctures and Algorithms in JAVA. Wiley, 4th edition, 2005.

[3] Horstmann. Big Java. Wiley, 4rd edition, 2007.

[4] Ross Kurose. Computer Networking - A Top-Down Approach Featuring the Internet. Addison-Wesley, 4th edition, 2008.

[5] Lewis. Java Software Solutions. Addison-Wesley, 2008.

[6] Pfleeger. Software Engineering Theory and Practice. Prentice Hall, 3rd edition, 2006.

27

(36)

28 REFERENCES

(37)

Appendix A

CustomerObject

public class CustomerObject implements Serializable {

private static final long serialVersionUID = 5884436479064623012L;

// storage info private String regnr;

private String color;

private int place;

private String carbrand;

private String carmodel;

// customer info private String name;

private String address;

private String zip;

private String postal;

private String phone;

// summer tire info

private String sTireBrand;

private String sTireDimension;

private String sRimType;

private String sFrontLeft;

private String sFrontRight;

private String sBackLeft;

private String sBackRight;

private String sNote;

private String sRimPicture;

private String sRimThumbPicture;

private String sTirePicture;

private String sTireThumbPicture;

29

(38)

30 Chapter A. CustomerObject

// winter tire info

private String wTireBrand;

private String wTireDimension;

private String wRimType;

private String wNail;

private String wFrontLeft;

private String wFrontRight;

private String wBackLeft;

private String wBackRight;

private String wNote;

private String wRimPicture;

private String wRimThumbPicture;

private String wTirePicture;

private String wTireThumbPicture;

// images

private ImageIcon sRimIcon;

private ImageIcon sRimThumbIcon;

private ImageIcon sTireIcon;

private ImageIcon sTireThumbIcon;

private ImageIcon wRimIcon;

private ImageIcon wRimThumbIcon;

private ImageIcon wTireIcon;

private ImageIcon wTireThumbIcon;

// logging

private String sign;

private String logFile;

private byte[] logfileArray;

... getters and setters...

}

Distributed Database Storage Solution in Java