E-voting system

CHAPTER 1: INTRODUCTION
Introduction
Motivation
Objectives
The aim of this project is to design an e-voting system that makes use of Java and Bluetooth technologies. The specific objectives of this project are:

To create voting software that using Java 2 Micro Edition (J2ME) that can run on any mobile devices which will act as server and clients.
To develop Java 2 Micro Edition (J2ME) based voting system that able to fully utilize the functionality of Bluetooth technologies by transferring data (voter database, voting records, etc.), between two mobile devices.
To build a low cost and reliable client-server based voting system.

Outline of Thesis
The content of this thesis is organized according to the chapter. Chapter 1 is mainly about the brief introduction of the project done with some motivation and objectives. Chapter 2 is generally about the literature review of Java 2 Micro Edition (J2ME), Bluetooth and JSR-82 technologies, and also overview about the BVote itself. Next, Chapter 3 is about the methodology and details of the design whereas Chapter 4 is about the implementation of program through simulator and hardware devices since it is the output of the work done on Chapter 3. Chapter 5 is in relation to the presentation of data of the program with some program module hierarchy and classes used for Java programming. Then, Chapter 6 is concerning the discussion about the program outcome and its limitation. Finally, Chapter 7 is the final part of any reports or thesis which is the conclusion and some recommendations for future research.
CHAPTER 2: LITERATURE REVIEW
Overview of Java Micro Edition (Java ME)
Introduction
Java is a programming language originally developed by James Gosling at Sun Microsystems, which is now a subsidiary of Oracle Corporation. It was released in 1995 as a core component of Sun Microsystems’ Java platform. Java is general-purpose, concurrent, class-based, and object-oriented, and is specifically designed to have as few implementation dependencies as possible. It is intended to let application developers “write once, run anywhere”.
Recognizing that “one size doesn’t fit all”, Sun has defined and supports four editions of Java aiming different application environments and segmented many of its APIs so that they belong to one of the platforms. The platforms are:

Java Card – aimed for smartcards.
Java Platform, Micro Edition (Java ME) – aimed at small and memory constrained devices by means of environments with limited resources.
Java Platform, Standard Edition (Java SE) – aimed at standard desktop and workstation environments.
Java Platform, Enterprise Edition (Java EE) – aimed at heavy duty server systems, large distributed enterprise or Internet environments.

Java ME was formerly known as Java 2 Platform Micro Edition (J2ME), is a Java platform designed for mobile devices and embedded systems. Java ME technology was originally created in order to deal with the constraints associated with building applications for small devices with as little as 128KB of RAM and with processors a lot less powerful than those used on typical desktop and server machines. Thus, Sun defined the basics for Java ME technology to fit such a limited environment and make it possible to create Java applications running on small devices with limited memory, display and power capacity.
There are three core concepts in the Java ME technology:

Configuration – provides the most basic set of libraries and virtual machine capabilities for a broad range of devices.
Profile – set of APIs that support a narrower range of devices.
Optional package – set of APIs in support of additional, common behaviours that don’t really belong in one specific configuration or profile

J2ME consists of a set of profiles. Each profile is defined for a particular type of device and consists of a minimum set of class libraries required for the particular type of device and a specification of a Java virtual machine required to support the device. A profile itself does not do anything; it just defines the specification. Since profiles are subsets of configurations, profiles are implemented with a configuration. Ultimately, Java ME platform has been divided into two base configurations which is Connected Device Configuration (CDC) and Connected Limited Device Configuration (CLDC).
Java ME was designed to use profiles and configurations to enables devices of varying ability to able to run Java ME applications on the Kilobytes Virtual Machine (KVM), which is the micro version of Java Virtual Machine (JVM). Figure 1 illustrates how the CDC and the CLDC together make Java ME. The diagram also shows an overview of the components of Java ME architecture, and how it fits in the overall Java model.

Get Help With Your Essay
If you need assistance with writing your essay, our professional essay writing service is here to help!
Essay Writing Service

Configurations
Configuration is a preliminary Java platform for devices with similar requirements with respect to total memory, processing speed, power and display constraints. Specifically, a configuration consists of Java language features, JVM features and a limited set of generalized APIs. Configurations are closely linked with JVM. In fact, configuration is a term identifying Java language features as a set of APIs and a specific JVM for that particular configuration. The dividing line as to what configuration applies to a device is for the most part, dependent on the memory, processing power, network connectivity and display constraints of a device.
Connected Limited Device Configuration (CLDC).
The Connected Limited Device Configuration (CLDC) is a fundamental part of the architecture of the Java ME that targeting resource-constraint devices like mobile phones. It is specifically designed to meet the needs for a Java platform to run on devices with limited memory, processing power and graphical capabilities. CLDC contains a strict subset of the Java-class libraries, and is the minimum amount needed for a Java virtual machine to operate. CLDC is basically used to classify myriad devices into a fixed configuration. When coupled with one or more profiles, the CLDC gives developers a solid Java platform for creating applications for consumer and embedded devices.
CLDC is designed to bring the many advantages of the Java platform to network-connected devices that have limited processing power, memory, and graphical capability. Target devices typically have the following capabilities:

A 16-bit or 32-bit processor with a clock speed of 16MHz or higher.
At least 160 KB of non-volatile memory.
At least 192 KB of total memory available for the Java platform.
Low power consumption, often operating on battery power.
Connectivity to some kind of network, often with a wireless, intermittent connection and limited bandwidth.

On top of the different configurations Java ME platform also specifies a number of profiles defining a set of higher-level APIs that further define the application. A widely adopted example is to combine the CLDC with the Mobile Information Device Profile (MIDP) to provide a complete Java application environment for mobile phones and other devices with similar capabilities.
Connected Device Configuration (CDC)
CDC is a specification of a framework for Java ME applications describing the basic set of libraries and virtual-machine features that must be present in an implementation. The targets for CDC-based technology comprise a broad range of consumer and embedded devices like smart communicators, pagers, high-end personal digital assistants (PDAs), and set-top boxes. Within this range, CDC is the basis for several standard API bundles that address the needs of developers of applications for specific categories of devices.
Devices that support CDC typically include a 32-bit microprocessor/controller and make about 2 MB of RAM and 2.5 MB of ROM available to the Java application environment. The CDC configuration was designed to bring the many advantages of the Java platform to a broad range of network-connected consumer and embedded devices.
CDC versus CLDC
The CLDC is different from, yet also a subset of the CDC. The two configurations are independent of each other, however, so they should not be used together to define a platform. The CLDC is a proper subset of the CDC. Neither the CLDC nor the CDC is a proper subset of the J2SE platform, however, because both of these configurations add new classes necessary to deliver services on their respective families of devices. Like the CDC, the CLDC specifies the level of support of the Java programming language required, the required functional support of a compliant Java VM, and the set of class libraries required. Figure 2 shows the relationship between the two configurations and the J2SE platform.
Profiles
Profiles are an extension of its underlying configuration. A profile simply is a set of APIs but unlike configurations, profiles are closer and specific to the target device capabilities. They are intended to include device specific APIs providing those functionality missing at configuration level such as user interface, persistence, etc. Profiles obtain the required foundation from configuration and hence are layered above configurations.
Currently, there are a handful profiles available and a few more are being finalized. MIDP is a profile supported by CLDC while CDC support three different profiles namely the Foundation Profile (JSR 219), Personal Basis Profile (JSR 217) and Personal Profile (JSR 216).
Foundation Profile (FP)
Foundation Profile is the most basic of the CDC family of profiles. It is a skeleton upon which a developer can create a new profile. The FP APIs, together with CDC APIs provides a complete Java ME JRE for consumer electronics and embedded devices. It is a set of Java APIs tuned for low-footprint devices that have limited resources that do not need a graphical user interface system. It provides a complete Java ME application environment for consumer products and embedded devices but without a standards-based GUI system. Version 1.1.2 is specified in JSR 219 and implements a subset of Java SE 1.4.2, including a set of security-related optional packages, such as Java Authentication and Authorization Service (JAAS), Java Secure Socket Extension (JSSE), and Java Cryptography Extension (JCE).
The Mobile Information Device Profile (MIDP)
The Mobile Information Device Profile (MIDP), combined with the Connected Limited Device Configuration (CLDC), is the Java runtime environment for today’s mobile information devices such as phones and entry level PDAs. MIDP provides the core application functionality required by mobile applications – including the user interface, network connectivity, local data storage, and application lifecycle management.
Currently, there are three version of MIDP which are MIDP 1.0, MIDP 2.0 and MIDP 3.0. With the configuration and profiles, the actual application then resides, using the different available APIs in the profile.
Following in the tradition of Java parlance, MIDP applications are called MIDlets. A MIDlet is a Java application that uses the MIDP profile and the CLDC configuration, created by a Java ME software developer, such as a game, a business application or other mobile features. These MIDlets can be written once and run on every available device conforming to the specifications for Java ME technology. The MIDlet can reside on a repository somewhere in the ecosystem and the end user can search for a specific type of application and having it downloaded over the air to another device.
Kilobyte Virtual Machine (KVM)
The Kilobyte virtual machine (KVM) is a virtual machine derived from the Java Virtual Machine (VM) specification. The VM that comes with the CLDC reference implementation is called the Kilobyte Virtual Machine (KVM) because it uses only a few kilobyte of runtime memory as opposed to megabyte. It is a reference implementation that adheres to the CLDC specification’s description of a compliant VM. It is designed for small devices as it has a small memory footprint. It supports a subset of the features of the higher end JVM.
For low-end, resource-limited products, Java ME and the KVM support minimal configurations of the Java virtual machine and Java APIs that capture just the essential capabilities of each type of device. KVM can be deployed flexibly to address a range of trade-offs between space and functionality. The KVM is engineered and specified to support the standardized, incremental deployment of the Java virtual machine features and the Java APIs included in the Java ME architecture.
Overview of Bluetooth Technology
Introduction
Bluetooth is a proprietary open wireless communication protocol for exchanging data over short distances by using short length radio waves from fixed and mobile devices, creating personal area networks (PANs). The Bluetooth wireless connectivity technology was originally envisioned in 1994 by Ericsson as a way for mobile devices to communicate with each other at short ranges — up to 30 feet, or 10 meters. While Bluetooth is positioned as a replacement for cable, infrared, and other connection media, it offers a variety of other services, and creates opportunities for new usage models. It can connect several devices, overcoming problems of synchronization and it works quietly, unconsciously, and automatically in the background.
Bluetooth has client-server architecture. In client-server architecture, the one that initiates the connection is the client, and the one who receives the connection is the server. Bluetooth is a great protocol for wireless communication because it’s capable of transmitting data at nearly 1MB/s, while consuming 1/100th of the power of Wi-Fi. In order for Bluetooth devices to communicate properly, they all need to conform to the Bluetooth specification. The Bluetooth specification, like any other specification, defines the standard that a Bluetooth device should adhere to, as well as rules that need to be enforced when communicating. The Bluetooth protocol stack and profiles together comprise the Bluetooth specification.
Bluetooth Protocol Stack
Bluetooth uses a variety of protocols. Core protocols are defined by the trade organization Bluetooth Special Interest Group (SIG). Additional protocols have been adopted from other standards bodies. The Bluetooth stack is the software or firmware component that has direct access to the Bluetooth device. The Bluetooth protocol stack is split in two parts: a “controller stack” containing the timing critical radio interface, and a “host stack” dealing with high level data. It has control over things such as device settings, communication parameters, and power levels for the Bluetooth device. The stack itself consists of layers, and each layer of the stack has a specific task in the overall functionality of the Bluetooth device. Since Bluetooth device manufacturers are not required to use all of the layers in the stack, listed below are the overview of the core protocols and those adopted protocols that are widely used and implemented in almost every Bluetooth device:

L2CAP: The “Logical Link Controller and Adaptation Protocol” used to send packets between host and client. This layer is the multiplexer of all data passing through the unit. It receives application data and adapts it to the Bluetooth format. Qualities of Service (QoS) parameters are exchanged at this layer.
LMP: The “Link Manager Protocol” uses the links set up by the baseband to establish connections and manage piconets. Responsibilities of the LMP also include authentication and security services, and monitoring of service quality.
SDP: The “Service Discovery Protocol” is used to find services on remote Bluetooth devices.
HCI: The “Host Controller Interface” is the interface between the radio and the host computer. HCI is the dividing line between software and hardware. The HCI is the driver interface for the physical bus that connects these two components.
RFCOMM: The “Radio Frequency COMMunication” is very easy and uncomplicated. Widely known as the virtual serial port protocol, it is used to stream simple data.
OBEX: The “Object Exchange” communication protocol is used to exchange physical data such as files, images, and so on in binary format.

Bluetooth Profiles
Bluetooth profiles are intended to ensure interoperability among Bluetooth-enabled devices and applications from different manufacturers and vendors. A Bluetooth profile is a designed set of functionality for Bluetooth devices that defines the roles and capabilities for specific types of applications. If Bluetooth-enabled devices want to interact, having the bare minimum Bluetooth stack is not enough. It also needs to conform to a particular profile. Listed are some of the Bluetooth profiles:

The Generic Access Profile defines connection procedures, device discovery, and link management. It also defines procedures related to use of different security models and common format requirements for parameters accessible on the user interface level. At a minimum all Bluetooth devices must support this profile.
The Service Discovery Application and Profile defines the features and procedures for an application in a Bluetooth device to discover services registered in other Bluetooth devices, and retrieves information related to the services.
The Serial Port Profile defines the requirements for Bluetooth devices that need to set up connections that emulate serial cables and use the RFCOMM protocol.
The LAN Access Profile defines how Bluetooth devices can access the services of a LAN using PPP, and shows how PPP mechanisms can be used to form a network consisting of Bluetooth devices.
The Synchronization Profile defines the application requirements for Bluetooth devices that need to synchronize data on two or more devices.

Bluetooth Network Topology
Bluetooth-enabled devices are organized in groups called piconets or also known as Personal Area Network (PAN). A piconet consists of one master and up to seven active slaves. The slaves in a piconet can only link to the master. Slaves cannot directly transmit data to one another. In fact, the master acts as a switch for the piconet and all traffic must pass through the master. A master and a single slave use point-to-point communication. If there are multiple slaves; point-to-multipoint communication is used. A master unit is the device that initiates the communication. A device in one piconet can communicate to another device in another piconet, forming a scatternet. A Bluetooth unit can be a slave in two or more piconets, but only one Bluetooth can be a master. Devices that participate in two or more piconets may act as gateways, forwarding traffic from one piconet to another.Notice that a master in one piconet may be a slave in another piconet:
The basic concepts of any Bluetooth application consist of the following five components:

Stack Initialization
Device Management
Device Discovery
Service Discovery
Communication

Bluetooth vs. Infrared
The major difference between the two methods of data transmission is that Bluetooth is based on radio technology (from 2.4GHz bands upwards), while Infrared utilizes invisible light in the 400 – 700nm wavelength. Infrared is fairly reliable and doesn’t cost much to build into devices but it does have drawbacks:

It’s line-of-sight, so a sender must align with its receiver.
It’s one-to-one, so a device can’t send to multiple receivers at the same time.

Infrared’s advantages are consequences of its disadvantages:

Because it’s line-of-sight, interference is uncommon.
Because it’s one-to-one, message delivery is reliable: each message sent goes to the intended recipient no matter how many infrared receivers are in the room.

Bluetooth vs. 802.11b
Both Bluetooth and IEEE 802.11b are wireless communication protocols and both operate in the 2.4GHz band, but they are designed to accomplish different goals. A major difference is that 802.11b was not designed for voice communications, while any Bluetooth connection can support both data and voice communications.
The 802.11b protocol is designed to connect relatively large devices with lots of power and speed, such as desktops and laptops. Devices communicate at up to 11 Mbit/sec, at greater distances (up to 300 feet, or 100 meters). By contrast, Bluetooth is designed to connect small devices like PDAs, mobile phones, and peripherals at slower speeds (1 Mbit/sec), within a shorter range (30 feet, or 10 meters), which reduces power requirements.
Overview of Java APIs for Bluetooth Technology (JSR-82)
Java APIs for Bluetooth Wireless Technology
Bluetooth is an important emerging standard for wireless integration of small devices. The specification standardizes a set of Java APIs to allow Java-enabled devices to integrate into a Bluetooth environment. Previously, there has been no standardized way to develop Bluetooth applications until JSR 82 came into play JSR-82 is a standard defined by the Java Community Process for providing a standard to develop Bluetooth applications using the Java programming language. It is the first open and non-proprietary standard for developing Bluetooth applications. The JSR-82 API hides the complexity of the Bluetooth protocol stack behind a set of Java APIs that allow to focus on application development rather than the low-level details of Bluetooth, by exposing a simple set of Java API’s. JSR 82 is based on version 1.1 of the Bluetooth Specification.
JSR 82 consists of two optional packages: the core Bluetooth API and the Object Exchange (OBEX) API. The latter is transport-independent and can be used without the former. The Java APIs for Bluetooth do not implement the Bluetooth specification, but rather provide a set of APIs to access and control a Bluetooth-enabled device. JSR 82 concerns itself primarily with providing Bluetooth capabilities to J2ME-enabled devices. Java APIs described in the JSR-82 interface for following Bluetooth Protocols/Profiles:

SDAP – Service Discovery Application Profile
RFCOMM – Serial Cable Emulation Protocol
L2CAP – Logical Link Control and Adaptation Protocol
GOEP – Generic Object Exchange (OBEX) Profile

The API Architecture
The goal of the specification was to define an open, non-proprietary standard API that can be used by all J2ME-enabled devices. Therefore, it was designed using standard J2ME APIs and CLDC/MIDP’s Generic Connection Framework.
JSR 82 requires that the Bluetooth stack underlying a JSR 82 implementation be qualified for the Generic Access Profile, the Service Discovery Application Profile, and the Serial Port Profile. The stack must also provide access to its Service Discovery Protocol, and to the RFCOMM and L2CAP layers. The APIs are designed in such a way that developers can use the Java programming language to build new Bluetooth profiles on top of this API as long as the core layer specification does not change. JSR 82 includes APIs for OBEX and L2CAP so that future Bluetooth profiles can be implemented in Java, and these are already being used for that purpose. Figure 4 shows where the APIs defined in this specification fit in CLDC/MIDP architecture.
Capabilities of JSR-82
These are the properties and capabilities of JSR-82 in a nutshell. The JSR-82 API is intended to provide the following capabilities options:

Manage the Local Bluetooth Device settings.
Discover other Bluetooth devices in the neighbourhood.
Search for Bluetooth services on the discovered Bluetooth devices.
Connect to any of those Bluetooth services and communicate with it.
Register a Bluetooth service on the Local Bluetooth Device, so that other Bluetooth devices can connect to it.
Establish RFCOMM, L2CAP, and OBEX connections between devices
Manage and control the communication connections.
Provide the security to all of the above options.

Reasons on Using Java Platform Micro Edition (Java ME)
Java ME has significant advantages over other languages and environments that make it suitable for Bluetooth Voting System (BVote). The advantages of Java are as follows:

Most of mobile devices nowadays are compatible and supports Java ME application development. Java ME has a particularly high market penetration. According to Morales and Nelson, approximately 68% of mobile phones are Java ME capable, which equates to more than 350 million Java ME capable mobile devices worldwide.
Java ME is an open source and free. There are no licensing expenses needed for the SDK.
Java ME is platform-independent. Java has the ability to move easily from one computer system to another.Java is a platform-independent at both the source and binary levels. It can run on any operating system without modification
Simplicity and ease-of-use. Java was designed to be easy to use and is therefore easy to write, compile, debug, and learn than other programming languages. Java uses automatic memory allocation and garbage collection. In addition, the I/O and network library is very easy to use.
Java ME is robust. Java compilers are able to detect many problems that would first show up during execution time in other languages.
Java ME is interpreted. An interpreter is needed in order to run Java programs. With Java, the program need only be compiled once, and the bytecode generated by the Java compiler can run on any platform.

Reasons on Using Bluetooth Technology
There are various reasons to use a Bluetooth technology. These reasons are mainly based on the advantages of the Bluetooth technology itself that it offers to users.

Availability of Bluetooth connectivity wireless technology in mobile devices. Bluetooth has already become a standard inclusion and important feature on most mobile phones nowadays.
No cost per transmission. As an alternative for the current Short Message Services (SMS) that would be charge per transmission, Bluetooth cost no charge for its communication.
Low energy consumption as Bluetooth uses low power signals. Thus, the technology requires little energy and hence uses less battery or electrical power.
Standardize technology. Since Bluetooth is a standardized wireless specification, a high level of compatibility among devices is guaranteed. In addition, Bluetooth is a universal, world-wide, wireless standard.
Ability to keep information private. In order to make a transfer or allow someone to access the files in the phone, it will need to give the access by accepting or rejecting the request through the phone. Therefore, authentication will prevent unauthorized access to important data and make it very difficult to listen in.
Signals are omni-directional and can pass through walls. Communicating devices do not need to be aligned and do not need an unobstructed line of sight. Besides, Bluetooth uses frequency hopping. Its spread spectrum approach greatly reduces the risk that communications will be intercepted.

Overview on Bluetooth Voting System (BVote)
The name of this project is BVote. BVote is being developed using Java 2 Micro Edition (J2ME) programming language in order to create an open source, freely available and platform-independent mobile voting platform with basic connectivity options to expedite the process of data transfer and multi-user collaboration. It consists of two parts which are server and client. The server is the one that become the administrator. The administrator is responsible to manage all the registration of the voters and set the question(s) of the voting. As for the client, it can only log in the voting system as a voter and vote for the question that is being sent.
In order to create such a program like BVote, it must meet some basic requirements before the application can be run. Firstly, as BVote is being developed using J2ME, therefore both server and client must use mobile devices as their platform. In addition, both server and client must be able to communicate with each other through Bluetooth technology. Last but not least, since BVote is voting system application software, BVote must accept processing, storing, and updating functions especially for the server part.
Research on E-Voting System

http://en.wikipedia.org/wiki/Electronic_voting
http://en.wikipedia.org/wiki/Electronic_voting_examples
http://en.wikipedia.org/wiki/Indian_voting_machines
http://www.topbits.com/e-voting.html
http://www.howstuffworks.com/e-voting.htm
http://avirubin.com/vote/analysis/

CHAPTER 3: DESIGN METHODLOGY AND DETAILS
This chapter addressed issues that arise when implementing and using the Java APIs for Bluetooth Wireless Technology and designing the software application using Java 2 Micro Edition (J2ME). Lastly, this section discusses issues on the hardware and technology that involved on the implementation and development of Bluetooth Voting System.
Hardware
Mobile Phone
Mobile phone is acting as the main hardware for Bluetooth Voting System, both for server and client part. Nowadays, a mobile phone in market is growing up rapidly with respectively to mobile technology. The fast growing of the mobile technology has benefited and improved the quality of life. In addition, the Bluetooth technology has become the main features in all the latest product of mobile devices available on market. With this specification, the objective to develop a low cost system has been met. As this project make the most of the Bluetooth as a connection medium for voting process, mobile phone has been fully utilized due to its ability in supporting Bluetooth.
PC or Laptop
In the development work, PC has been used as a workstation for programming and simulation process. For the simulation purpose, it had been perform in PC by using Java IDE and mobile phone emulator generated by Sun Wireless Toolkits. After the simulation work is done, a .jar executable file will be installing in mobile phones for real time hardware testing.
Software and Development Toolkit
The following software will be used:

J2SDK1.5.0
Eclipse 3.0.1: one of the best Java IDE 😉
J2ME Wireless toolkit 2.2
EclipseME 0.7: Eclipse plugin to help develop J2ME code
ProGuard 2.1: class file shrinker and obfuscator.

Wireless Toolkit 2.5.2
The Sun Java Wireless Toolkit for CLDC (formerly known as Java 2 Platfo