This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Mobile secuirty involves securing the various confidential data that we transfer from our mobile phones to other devices via the internet. The most ubiquitous application platform for wireless, mobile, and embedded devices are Java Platform, Micro Edition, and Java ME.
Java Card refers to a technology that permits small Java-based applications to be run securely on smart cards and similar small memory footprint devices. Java Card, being the smallest in java technology, is used in embedded devices and mobile phones. Java Card allows the user to program the device and make them specific to the application used. It is widely used in SIM cards (used in GSM mobile phones) and ATM cards. 
Originally, Java Card technology was developed to secure highly confidential information that is stored on smart cards. Security can be determined by various aspects, few of them being:
- Data encapsulation - All data is stored within the application. The Java Card applications are always executed in an environment that is isolated (the Java Card VM), that is, separate from the operating system and hardware of the system.
- Applet Firewall - Unlike other Java VMs, the work of a Java Card VM is to manage the various applications, each of which control sensitive and confidential data. Therefore, different applications are separated from one another by an applet firewall. This restricts and checks the accessible data elements from one applet to another.
- Cryptography - The most common encryption algorithms that are supported are DES, Triple DES and RSA (including elliptic curve cryptography). The other cryptographic services like signing, key exchange and key generation are also supported.
- Applet -The applet is a state machine and it processes only the incoming command requests and responds by sending response status words or data back to the device.
1.1. Historical Background
Java ME was designed by Sun Microsystems. Sun Microsystems is the platform which replaced a similar technology, PersonalJava. Initially developed under the Java Community Process as JSR 68, the different applications of Java Micro Edition have evolved in separate JSRs. Sun provides an implementation used as a reference of the specification, but Sun has decided not to provide any free binary implementations of Java Micro Edition runtime environment for mobile phones, rather depending on third parties to provide their own runtime environment. 
Since 2006, the source code of Java ME has its licensing under the General Public License (GNU), and the project name given to it is phoneME.
As of 2008, all platforms of Java ME are currently only restricted to JRE 1.3 features and it uses only one version of the class file format (which is internally known as version 47.0). If a totally new round of Java ME configuration versions would have to be declared, that supported the language features and later class file formats, such as those corresponding JRE 1.5 or 1.6, it would mean extra work for platform vendors to get their JREs updated. 
The first Java Card was introduced by 1996 by the card division of Schlumberger's which later merged with Gemplus to form Gemalto. Based on the Java Card Platform specifications developed by Sun Microsystems, the Java Card products are building.
This report focuses on how the data can be securely sent from one mobile device to any other device via the internet as well as development of a mobile application using J2ME. A sample mobile application is created to present the working of a mobile banking, that is, the user gets the display of this bank account details when he enters his/her username and password. The report includes detailed study of the following:
- Java Card
- J2ME applications
- NetBeans 6.7.1
- Mobile Banking (Implementation)
The objectives of this report are:
- To describe the methods of securing information on Java Cards which are used in mobile phones.
- To clearly understand the use of J2ME applications in mobile phones.
- To get familiar with the working of the software, NetBeans 6.7.1.
- To build a J2ME application in Netbeans used for mobile banking.
Considering the popularity of the internet in today's world, we can be very sure of its major drawbacks, one of them being unsecure data. Let us see how mobile phones work. A cellular network consists of base stations (cell sites) and switching points which are owned by a mobile network operator. Most mobile devices are connected to this network. Currently, most mobile devices also support many additional services, such as emails, SMS for text messaging and many more along with the standard voice function. Mobile phones use a small microchip, that is, a Subscriber Identity Module (SIM Card), to carry out all the functions. The SIM card is activated by using a unique identifier of numerical value. Once activated, the numeric identifier is locked down and the SIM card is permanently locked into the activating network. 
2.1 Java Technologies
2.1.1 Smart Cards Technology
Many people think of smart cards as a recent invention. In 1968, Jurgen Dethloff (a german inventor) and Helmet Grotrupp filed a patent by using plastic to manufacture microchips. Then, in 1970, a Japanese inventor, Kunitake Arimura, did a similar thing as Jurgen Dethloff. Smart Cards were introduced in Japan in the following year. In the year 1974, Frenchman Roland Moreno registered his smart card patent in France.
In the wireless marketplace, smart cards provide the following:
- An improved network security through user identification.
- A facility for storing user data.
- A mechanism for recording different kinds of service data events.
Smart cards comply with the standard, ISO 7816. They have a silicon chip embedded on the plastic. They are used in SIM cards and credit cards in mobile devices. The silicon chip on a smart card has as much memory as required to possibly permanently hold smart card applications and data.
Smart Cards are generally used in along with a smart card reader device. Also, it provides the electrical input to power up the smart card. Various applications reside on the smart card with which the host applications may communicate with. 
2.1.2 Smart Cards versus Magnetic Strip Cards
Smart Cards are a higher version of the magnetic strip cards. The main advantages of smart cards over magnetic strip cards:
- A smart card's storage capacity is hundred times compared to that of a magnetic strip card.
- The processing capability of a smart card can in no ways be possible in a magnetic strip card.
- As a result of its high processing capability, powerful authentication mechanisms can be implemented to access the data stored in a smart card. Thus we can conclude that data security is much well taken care of in a smart card as compared to a magnetic strip card.
- The life span of a smart card is much longer.
2.1.3 Java Card Technology
All Java Cards with an additional feature are categorized as smart cards. Smart cards are developed by the various vendors who use the Java language allowed by the Java Card technology. Let us consider an example, suppose the SIM card of my mobile phone is a Java card, it could could further manage my insurance policy, my medical records, my electronic wallet and so on as it would contain value-added Java card applications.
2.2 Implementing Java Card Technology using J2ME applications:
Java Card technology is not limited to the J2ME platform. But in my report, I would focus on the use of Java Card technology in J2ME devices only. The Security and Trust Services API (STASA) enables us to do so. Before getting into the implementation of J2ME, lets learn some more about the J2ME platform.
2.2.1 J2ME Platform
1. Java 2 Platform, Micro Edition or J2ME technology allows Java programming language and the related tools to be used by the programmers. The language further helps in the development of programs for mobile wireless applications such as personal digital assistants (PDAs) and cellular phones. J2ME also includes specifications to be used in the programs. Also, a special virtual machine, called the K-Virtual Machine allows the mobile device to run a J2ME-encoded program. 
Two programming specifications are required, namely,
- Connected, Limited Device Configuration (CLDC) - It uses the Application User Interface (API) which is needed to support a mobile device.
- The Mobile Information Device Profile (MIDP) - It uses messaging details, networking and user interface which is added to the CLDC to interface with the mobile user. Also, it includes a MIDlet which is a java application. It differs from an applet but is similar to CLDC and MIDP.
A virtual machine (called a Java Card Virtual Machine, or JCVM) and a set of APIs (Java Card API) are components of a Java Card Technology. Few interfaces and classes in the set of APIs are exposed for use by J2ME MIDlets and other client applications. 
2.3 The Architecture of an E-Banking Application:
In today's world, a user can use its mobile phone to access their bank accounts and even use it to make and receive payments or check their balances. Java Card features added to Kerberos application, which helps in increasing the security of a mobile phone which uses J2ME applications. 
2.3.1 Kerberos-based J2ME applications
People these days using Java Card applications need to be assured that the wireless applications they are using would allow their highly confidential data to be disclosed. This is done by using industry-standard protocols like Kerberos to ensure security. 
Kerberos, being a network authentication service, provides various ways of verifying the identities of people using the network. It provides mutual authentication, data integrity and privacy.
Kerberos tickets help in the verification of one's identity. The two types are:
- Ticket-Granting Ticket (TGT) - it is used only for initial identity request. It is like a password which is needed when one logs into any host system.
- Service Ticket - After you have the TGT, it then sends it to request service tickets for specific services.
This two-ticket method is often called the trusted third-party of Kerberos. Your ticket-granting ticket authenticates a user to the Kerberos server.
The trusted third-party in Kerberos is called the Key Distribution Center (KDC) which uses KDC to issue all of the tickets to the respective clients.
The JavaCardKerberosKey is used as a secret key manager which contains the Kerberos secret key, required for secure communication between a J2ME cell phone user and the bank's business logic. A portion of TGT is encrypted which contains the session key which is required to decrypt the service ticket. Thus, the secret key is mandatory for using a TGT.
The secret key is 8 bytes long. The e-banking application fragments this key into two portions of four bytes each:
- USER'S Key - Both the e-bank and the user make use of this key. The e-bank installs this key on to the account holder's Java Card. Also, it installs the JavaCardKerberosKey applet.
The key is an alphanumeric PIN code which is always asked for whenever the user wishes to access her account. Both the user's key and the specific card in which the user's key is installed by the e-bank are needed if the customer needs to access her e-bank account. This is a cautionary measure and is done so that, if the user's key is stolen, it would not operate unless the same individual has also stolen the Java Card for that very account. This process of securing an e-bank account is also called Dual Factor Security. The authentication is based on two things, the user key (already known by the user) and the Java Card (something carried by the user).
- E-BANK'S Key - only the E-bank has access to this key which is installed only when the e-bank installs the Java Card applet. Any other Java card application is not allowed to access this key.
Both keys are set in the applet, JavaCardKreberosKey, by the e-bank. This is done before installing the applet on the java card.
2.3.2 Loading the JavaCardKerberosKey applet onto the Java Card
Top-level class which is used in most of the Java Card applications is also extended to the JavaCard.framework.Applet class, which is also part of the Java Card framework.
126.96.36.199 Java Card Applications
A Java Card application consists of:
- A back-end application and systems
- A host (off-card) application
- An interface device (card reader)
- The on-card applet, user credentials, and supporting software.
All these elements together are required to ensure a secure end-to-end application.
A block diagram explaining the same is given below.
FIG. 188.8.131.52 Java Card Application 
- The Back-End Application and Systems - Java applets provides the services which support in-card. For example, a back-end application is used to allow security systems to connect and along with in-card credentials, they are also used to provide better security. In an electronic payment system, the back-end application is allows access to credit-card and all other types of payment. 
- The Reader-Side Host Application - The host application rests on the desktop or a terminal like a PC, a cellphone, an electronic payment terminal or a security system. The host application takes care of the communication within the users, the provider's back-end application, and the Java Card applet. It was recently discovered that the J2ME technology makes it possible to realize the host application in Java. For example, it could run on a mobile phone that supports the Security and Trust Services API and MIDP. 
- The Reader-Side Card Acceptance Device - The Card Acceptance Device, also called the CAD, is the interface device that connects the Java Card device and the host application. CAD provides power to the java card by providing it with electrical or RF communication as well. A CAD is considered to be a card reader which is attached to the desktop computer via a serial port. Also, it may be integrated into a terminal like an electronic payment terminal at any public place like a petrol station or maybe a restaurant. The interface device further forwards the Application Protocol Data Unit (APDU) commands from the host application to the card. It also forwards the responses from the card to the host application. Some CADs may have a display as well as a keyboard for PIN entry purpose.
- The Card-Side Applets and Environment - The Java Card platform supports multiple applications. As seen in Fig. 2.2.1, one or more Java Card applets are present on the card, along with some software to support the applets, that is, the Java Card Runtime Environment (JCRE) and the operating system. The JCRE includes the APIs, the Java Card VM, the Java Card Framework and some extension APIs as well. All Java Card applets extend the Applet base class. They essentially implement the process() and install() methods. The JCRE calls install() while installing the applet, and the process() method when there is any incoming APDU for that particular applet. 
Java Card applications are compiled in the usual Java 2 platform, Standard Edition (J2SE) applications. The Java Card application which is compiled by the ebanking application is its JavaCardKerberosKey applet. After the Java Card application code compiles it into a set of .class files, the e-bank will pack up the .class files into a just one .cap file, which will consist of the complete Java Card application. This is done using the converter tool in JCDK. 
Either of two models can be used for permitting the communication between a host application and a Java Card applet. The first model being the fundamental message-passing model, and the second model is based on the Java Card Remote Method Invocation (JCRMI), which is a subset of the J2SE RMI distributed-object model. In addition, SATSA allows the use of either message passing or JCRMI to reach the smart card via a more abstract API based on the Generic Connection Framework (GCF) API. 
The main objective of implementing the above concepts of java is to create an e-banking application using a mobile interface. The user should be able to access his/her account details when he/she logs in from his/her mobile. This makes it possible for any mobile user having an internet connection on his/her mobile to access the bank account without even visiting the bank in person. The person can view his balance, his/her deposit details and his/her withdrawal details.
3.2 Detailed Description of the E-Banking Application:
The e-banking application software has been developed for the ease of access to the person's bank account. This has been done using J2ME as it applies to the mobile interface. The various aspects of the software developed are:
- A user-interface which would allow the user to feed in his/her username and password in order to login to his bank account. The password is a sensitive and highly confidential piece of information because of which it needs to be secure. Various methods for securing the password as used in the real life application.
- The servlet interface which connects the user to the e-bank. The servlets act as a medium to transfer the information entered by the user and the output provided by the e-bank.
- The banking interface which consists of all the database of the user. After the username and password are entered by the user and passed on to the bank by the servlets, the bank checks for the corresponding data of that user and passes on the information back to the user via the servlets.
The above description is a very brief outline of how the e-banking application is suppose to work.
3.3 Interface Design:
a. Visual Mobile Designer
J2ME in NetBeans IDE 6.7 consists of a Visual Mobile Designer which was used to create a Visual MIDlet. The palette available consisted of the various components like Login Screens, Wait Screens, Text Boxes, Splash Screens and many commands like Item commands, Exit commands etc. These components were used to build this MIDlet.
The visual MIDlet created using the Visual Mobile Designer interacts with the servlets created in NetBeans IDE 6.7. The servlets created are for login validation and also for displaying the bank account details of the user.
The database was created using MySQL which is a build in MySQL editor of NetBeans 6.7. The four tables were created, namely, Users table, Deposits table, Withdrawal table and Balance Table. Any other data, that is, if a username and password different from the inputted data is fed in, the application would show a failed login.
3.4 Software Used
NetBeans IDE 6.7.1 is the software used to develop this project. The Visual Mobile Designer was used to create the user interface. The database was created using the SQL editor in NetBeans 6.7.1.
3.5 Detailed Description of the Concepts Used:
3.5.1 NetBeans IDE 6.7.1
NetBeans 6.7.1 is a new version of NetBeans that provides developers with an environment to build java applications on different platforms. The various platforms supported by this version are J2SE, J2EE, J2ME, Java FX 1.2, Glass Fish 3 and many more. The platform to be used in my project is J2ME (Java 2 Micro Edition) and Glass Fish 3. The components of NetBeans 6.7.1 are:
- An Object Browser
- A syntax coloring editor (uses various programming languages)
- A component debugger
3.5.2 Mobile Information Device Profile (MIDP)
Mobile Information Device Profile (MIDP), along with the Connected Limited Device Configuration (CLDC), is the runtime environment using Java for the latest mobile information devices (MIDs) such as phones and other small cellular devices. It provides the users with the core application functions that are required by all mobile applications - including the user interface, data storage, network connectivity, and application management system - all this is packaged as a standard Java runtime environment and a set of APIs. Games, any kind of messaging (chat, sms, emails), remote access directory, geographical services (maps, road directions), financial applications (stock quotes, banking), consumer applications (online auctions, online news, online reservation techniques) and many more are built by MIDP. 
3.5.3 Visual Mobile Designer
It is a graphical user interface build within NetBeans which allows the user to develop mobile applications. The flow chart for the applications is developed by dragging and dropping various components present on the available palette.
These are modules that use the java language and run as server applications. They are responsible for responding to the client's request. They extend the capabilities of a server and make use to the Hyper text Transfer protocol (HTTP). It can also provide dynamic content with the help of HTML forms.
A MIDlet is a Java class. It extends the javax.microedition.midlet.MIDlet class which implements following methods; the startApp(), pauseApp() and destroyApp(). It is further implemented on an emulator. During the existence of an application, the MIDlet is always in one the three states listed below:
- Active state - In this state, the MIDlet functions normally. It is put to use when the method, startApp is called.
- Paused state - In this state, the MIDlet releases all its states which can be activated again if required. It is invoked by pauseApp method.
- Destroyed state - In this state, the MIDlet permanently releases all its states. It is invoked by destroyApp method.
The lifecycle of a MIDlet is shown in fig. 3.1
An emulator is a description used by NetBeans 6.7.1 to simulate the working of the developed application on a mobile device.
3.6 Creating the Application:
Listed below are the steps required in building the e-banking application:-
3.6.1 Creation of the mobile application
- Click on File> New Project, select JavaME under Categories. Under Projects, select Mobile Application and click next.
- Enter “e-banking5” in the Project Name field. Uncheck the Create Hello MIDlet checkbox. Click Next.
- Select the Sun Java Wireless Toolkit as the Target Platform. If the wireless toolkit is not present, you need to add the platform by clicking on 'Add Platform' and selecting the Sun Java Wireless Toolkit. It is assumed that the required toolkit is downloaded on your PC. Click Next, and then Finish.
- Adding Java packages and a Visual Midlet
- Right-click on the “e-banking5” project in the Project Window on the left hand side and select Java Package. Click Next.
- Let the Package Name field be “e-banking5” and click on Finish.
- Enter “e-banking5” in the MIDlet Name and MIDP Class fields. Click Finish.
- Click on the 'Flow' icon in order to drag and drop components from the palette window. This is done to complete the algorithm.
The complete algorithm of my application can be seen in fig. 3.4
184.108.40.206 Creation of the Login Screen :-
- Click on 'windows' in the menu bar and select 'palettes'.
- In the palette window, drag the 'login screen' component from the displayables panel. This component is for the user to login to his/her account.
- From the commands panel in the palette window, drag a 'login commend' and an 'exit command' to the Login Screen box. The Login command is to allow the user to go to the next screen after he/she has entered the password and username. The exit command is to exit from the login screen.
A screenshot of the appearance of the Login Screen is shown in fig. 2.4.1
220.127.116.11 Creation of the Wait Screen
Each of the Login Screen components is connected to a Wait Screen component, which is dragged from the palette. To each of the Wait Screen, a task is assigned which will the required the call method for login validation of users.
For user validation, this component is assigned to a task method, which will call the userlogin() function. This function provides its URL with username and password as its inputs to the servlet. The servlet checks with the User Database if the username and password entered by the user matches with the username and password present in the database. If the username and password are valid, then the user is given access to the available functionalities. If the username and password are invalid, then the user will have to enter the correct username and password. The servlet used here is Login.java.
18.104.22.168 Creation of the Alert Screens
The Wait Screen component is connected to two Alert Screens. The first Alert Screen is named “AlertSuccess” and is connected to the SUCCESS_COMMAND of the Wait Screen component. The second Alert Screen is named “AlertError” and is connected to the FAILURE_COMMAND of the Wait Screen component. If the username and password entered by the user matches with the database content, then the AlertSuccess Screen will appear with the message “LoginSuccesfull” otherwise the AlertError Screen will appear with the message “Enter Username and Password again”. The AlertSuccess Screen is connected to the Form component containing the functionalities for account of the user. The AlertError Screen is connected back to the Login Screen Component which displays the username and password fields to be re-entered by the user.
22.214.171.124 Creation of Splash Screen
A splash screen is created to tell the user that his request is being processed. A progress bar is present in the screen which shows that the program is being loaded. A splash screen component is dragged from the components palette onto the flow screen. A command is dragged into the splash screen component which is further connected to the login screen component. So while the username and password are being verified by the processor, the splash screen is displayed which indicates that the user needs to wait.
126.96.36.199 Addition of the Form Box
The form box is used to connect the alert screens to the various text boxes according to the required functionality. A form component from the palette is dragged into the flow screen and four commands are dragged into the form box. The commands are named wcommand, dcommand, bcommand and the last command is an exit command which is connected to the mobile device component. The wcommand, dcommand and bcommand are further connected to the withdrawal, deposits and balance text boxes respectively. If the username and password entered by the user is valid, the form component connects to the respective text box, gets the data from the database and displays the content.
188.8.131.52 Addition of Text Boxes
The Text boxes are dragged onto the flow screen and connected back to the form component. The following three text boxes are introduced:
- Withdrawal Text Box - A text box is dragged onto the flow screen and named 'Withdrawal'. This component is connected to the respective servlet which consists of the database for the withdrawal function. When a user asks for this function, the date of withdrawal and amount withdrawn last is displayed on the emulator screen. A back command is dragged into the text box which is again connected to the form component. The purpose of this command is that when the user has seen the data displayed and opts for the back button, the back command leads it to the form component. The servlet connected to the text box is withdrawal.java
- Deposits Text Box - A text box is dragged onto the flow screen and named 'Deposits'. This component is connected to the respective servlet which consists of the database for the deposits function. When a user asks for this function, the date of deposit and amount deposited last is displayed on the emulator screen. A back command is dragged into the text box which is again connected to the form component. The purpose of this command is that when the user has seen the data displayed and opts for the back button, the back command leads it to the form component. The servlet connected to the text box is deposits.java
- Balance Text Box - Again, a text box is dragged onto the flow screen and named 'Balance'. This component is connected to the respective servlet which consists of the database for the balance function. When a user asks for this function, the balance amount of the account on the emulator screen. A back command is dragged into the text box which is again connected to the form component. The purpose of this command is that when the user has seen the data displayed and opts for the back button, the back command leads it to the form component. The servlet connected to the text box is balance.java
3.7 Compilation of the mobile application
After the MIDlet is created with the help of the Visual Mobile Designer, the project is compiled. The server side application should be deployed and running before the MIDlet is run. Then finally click on Run > Run Main Project for the execution of the MIDlet. An emulator appears which will visually show the implementation of the MIDlet.
3.8 Creation of Servlets
The MIDlet created in the above steps, will interact with the servlets created for user login validation and also with servlets created for obtaining information of the three functionalities for the bank account users.
The creation of servlets is as follows.
i. Creation of the Loginservlet Web Application Project
- Click File> New Project, select Java Web under the various listed option of Categories. Under the Projects column, select Web Application and click Next.
- Enter “LoginServlet” as the Project Name and click Next.
- GlassFish V2 is selected as the server. Then click Next, and then Finish.
ii. Adding Java packages and Servlets
- Right-click on the “LoginServlet” project in the Project Window, select Java Package. Click Next.
- Under the Package Name field, type “LoginServlet” and click on Finish.
- Right-click on the package name and select Servlet. Enter “LoginServlet” as the Class Name and click Next, then Finish.
The servlet for user login validation is LoginServlet.java. This servlet will run the validation process of the username and password, and if the username and password entered by the user, matches with the values in the database, then, an AlertSuccess screen will appear with the message “Login Successful”. Separate servlets have been created for each of the three functionalities in order to handle the user's requests. These servlets interact with the database created and retrieve the data and display it on the mobile. The source code for all the servlets created, can be found in the appendix.
3.9 Creation of database
The mobile application requires the functionalities of databases for the collection of user details, withdrawal details, deposits details and balance details. A JDBC URL is created to built a database by the administrator which is done by clicking on Services> Database. Then, right click on 'Select New Database'. A window is displayed requesting for the name of the new database to be created. After this, the administrator has to add tables by right clicking on the database icon. The administrator will be asked to decide on a primary key for each of the tables.
Four tables have been created for this mobile application:
- Users table - This table consists of the name, password, contact number and address of all the users who have an account in the particular bank. These would be the attributes of the table and user_name and password are the primary keys. All the attributes are of type Varchar and their size varies according to their need.
- Withdrawal table - This table consists of the name, password, date of withdrawal and the amount withdrawn by the user as attributes. The user_name and password are selected as the primary keys.
- Deposits table - This table consists of the name, password, date of deposit and amount deposited by the user as its attributes. The user_name and password are the primary keys.
- Balance table - This table consists of the name, password and the balance amount of the user's account in a particular bank. Again, the user_name and password are the primary keys.
J2ME known as Java 2 Platform, Micro Edition is a highly developed Java run-time environment specially built for small devices such as mobile phones. J2ME incorporates Java's cross-platform functionality to mobile devices thereby enabling these devices to share applications. This is used to implement the e-banking software using a mobile interface.
The Mobile Information Device Profile (MIDP) is a profile defined for J2ME. It is associated with cellular devices and is built upon Connected Limited Device Configuration (CLDC), which is a type of configuration. An MIDP Application is used to built the mobile application in this project.
A MIDlet is a Java class that extends the javax.microedition.midlet. MIDlet abstract class. For this project, a Visual MIDlet is created using the Visual Mobile Designer in NetBeans IDE 6.5 RC2. Here a MIDlet is implemented on an emulator with Sun Java Wireless Toolkit as the selected Target Platform.
NetBeans IDE 6.5 highly facilitates the creation and deployment of servlets, which are Java-language modules, which run in a server application to respond to client requests. It does enable developers to create and run MIDlets with the help of the Visual Mobile Designer. The Visual Mobile Designer (VMD) is a graphical interface within NetBeans which facilitates the creation of mobile applications by means of drag and drop components. The VMD describes the application flow and also allows the user to plan out his/her own GUI using the components of the IDE.
The NetBeans IDE 6.5 RC2 uses the application server, GlassFish V2. The database for this project has four tables - Users Table, Withdrawal Table, Deposits Table and Balance Table. The servlets created will interact with the database to bring about login validation as well as display of user's details for the various functionalities.
The above features have been implemented in this project, which aims at the creation of a e-banking software having mobile interface. This software targets the users who have an account in a particular bank. They can access their account details which include the amount of balance left un their account, the date of their last withdrawal or deposit, the amount last withdrawn or deposited, all done using the mobile phone. Hence NetBeans IDE 6.5 is an extraordinarily versatile tools platform, which can be used for the implementation of mobile based applications.
LIST OF REFERENCES
 Li, Sing and Jonathan Knudsen. Beginning J2ME: from novice to
Professional. California: Apress, 2005.
 java.sun.com ââ‚¬° ... ââ‚¬° Java Technology ââ‚¬° Java Card ââ‚¬° Reference