mobile control o

7/31/2019 Mobile Control o

1/35

ACKNOWLEDGEMENT

The satisfaction and euphoria thataccompanies the successful completion of any taskwould be incomplete without the mention ofpeople who made it possible, whose constantguidance, support and encouragement crown allthe efforts with success.

First I express immense pleasure to thankGod, my Parents and my Friends to whom I owe allmySuccess.

I would like to express my heartfelt thanks toMr.Asif Patel, Project Guide, Soft Musk Solutions,Belgaum. For giving me such a wonderful

opportunity to do this project work.

I express my sincere gratitude to Dr.R.H.Fattepur, Head of Department of computerscience, Basaveshwar Science College, Bagalkot,for his encouragement and valuable suggestionsduring the project time.

In the same way I express my sincere thanks to

our internal guide Mrs. Vidya Hungund,Basveshwar Science College, Bagalakot.


2/35

I am grateful to the faculty of the departmentof computer science for the training imparted tome during the entire B.C.A. course. My sincerethank to the non teaching staff of department for

their constant help and support.

Also I thank all my Friends for their help andsupport they extended to me during my B.C.Acourse.

Dedicated

To my

Beloved

Parents,

Teachers


3/35

And

My friends


4/35

INTRODUCTION

Abstract:

This project demonstrates how to control electronic devices likeComputers through cellular phone using J2ME, Here the user will not only beallowed to control the computer but also the applications running on it, thisapplication can further be extended to control any kind of electronic devicesapart from computer. The explanation of this project is divided into two parts

namely Present Dilemma and The Solution, The first part explains thepresent functioning of the system and the problems on it, whereas thesecond part provides the solution for the problems by incorporating mobilein to it.

Present Dilemma:

Let us assume that person X has a company with three branches indifferent cities named as a1, a2 and a3. Person X is trying to remotelyaccess data at branch a1 from branch a2 but he is unable to do so because

the database service at branch a1 is not started, so now the way out forperson X would be contact branch a1 and ask the concerned person tostart the database service and if the concerned person is not present thenthe work would be on hold which may result in loss to the company.

If person X is trying to establish connection with a particular computerat branch a1 through Internet but again he is unable to do so because thecomputer at branch a1 may not connected to the Internet so again the only


5/35

way out is to contact the branch a1 and ask the concerned person to connectthe particular computer to the Internet and once again if the concernedperson is not present then there is a problem.

Imagine you come back home after the days work at office and

then you realize that you have forgot to shutdown youre computer at officewhile leaving, so now will you again go back to office to shutdown thecomputer?

The Solution:

The solution for the above problem will be incorporating a mobileapplication wherein through your cellular phone you will be able tocommunicate with the remote machine via server and execute theapplication in it like starting the database service, making the dialupconnection to connect to the Internet or shutdown the computer etc, as if

you were not physically present in front of the computer.The above said solution can be achieved by using J2ME on the cellular

phone, which will send instructions to the servlets at the server and there onthe servlets will pass on the instructions to the particular computer usingremote method invocation(RMI) and once the instructions are executed theremote machine will acknowledge the sever about successful completion ofinstructions and in return the server will send a message to the cellularphone saying the given task has been completed successfully.

The cellular phone will be connected to the server in the network, thustaking the control over all the computers in the network and handing it over

to the user to his convenience. In other words the cellular phone will betransformed into mini mobile computer, so now the user can control anycomputer in the network from anywhere.

The Market Need:

In the post-PC era, the market for network-connected devices continuesto grow at an enormous rate. While new classes of devices like smart cellulartelephones, pagers, and PDAs proliferate, traditional consumer electronicsincluding televisions, VCRs, CD players, and game machines are also

becoming smarter and gaining new capabilities. Whether these devices arenew or just more powerful versions of existing products, all are becomingincreasingly interconnected across a network.

Today there is a strong need for solutions which can make finest use ofconsumer electronic devices like cellular phones and pack the power ofcomputer in it. May it be a large enterprise or a huge network, user today


6/35

wants the power to manage then through his cellular phone or PDA. Goneare the days where the physical presence of the user was required to controlor manage any device or computer. Now there is a need for an applicationthat will allow the user to access and control his computer or other devicesfrom any part of the world through his cellular phone when he is on the

move.

Scope of future Application:

This application can be further extended to make mobile to control

every electronic device. The future applications that can be added in this

project are STEGANOGRAPHY, VIDEO CONFERENCING Etc.

Applications:

This application can be used by system administrators to managethe system through their cell phone even when they are not physicallypresent. The system administrator through his cell phone can find outnumber of machines working, applications running on them and he can alsoopen any application on the machine or transfer files from one machine to

another through his cell phone and he can also shutdown the machine.

S oftware Module:

Conceptual Components of controlling computer throughmobile using blue tooth :


7/35

Advantages of controlling computer through mobile:

The advantages of controlling computer through mobile are as follows:

1) The application is built using java therefore it is platform independent

i.e. it will work with all the operating systems.

2) The application is very compact thus utilization very less space andmemory

3) Easy to use. The application is user-friendly and easy to use.4) A person can control his personal computer or entire computer

network sitting any where in the 100 mtrs range of the computers.5) A person can copy the files ,folders from one system to the other

system in local network using mobile.

Disadvantages ofcontrolling computer through mobile usingblue tooth :

The disadvantages of mobile payment system are as follows:


8/35

1) Limited Display: since the cell phone screen is smaller therefore not

much information can be displayed.

2) People who do not have cell phone can make use of this service.

3) Cell phone has limited Power Supply & Connectivity

The said project is developed using:

1) J2ME

2) Servlets &

3) (Remote Method Invocation)RMI

What is J2ME

Sun Microsystems has defined three Java platforms, each of which

addresses the needs of different computing environments:

Java 2 Standard Edition (J2SE)

Java 2 Micro Edition (J2ME)

The inception of the J2ME platform arose from the need to define acomputing platform that could accommodate consumer electronics and


9/35

embedded devices. These devices are sometimes referred to collectively aspervasive devices.Wireless Java 2 ME Platform Programming. The creators of the J2ME platform

delineated pervasive devices into two distinct categories:

Personal, mobile information devices

that are capable of intermittent networked communicationsmobilephones, two-way pagers, personal digital assistants (PDAs), and organizers

Shared-connection information devices

connected by fixed, uninterrupted network connectionset-top boxes,

Internet TVs, Internet-enabled screen phones, high-end communicators, and

car entertainment/navigation systems

The first category describes devices that have a special purposeor are limited in function; they are not general-purpose computing machines.The second category describes devices that generally have greater capabilityfor user interface (UI) facilities. Of course, devices with superior UI facilitiestypically have more computing power. Practically speaking, computing poweris the primary attribute that distinguishes these twocategories of devices.Nevertheless, this delineation is somewhat fuzzy, because technologycontinues to enable more and more power to be placed in smaller and

smaller devices.

Like computing power, connectivitythe availability of media such

as wireless networksalso affects the kinds of functionality and services

that pervasive devices can support. The challengeand the primary goal

for J2ME is to specify a platform that can support a reasonable set of services

for a broad spectrum of devices that have a wide range of different

capabilities.

The creators of J2ME identify modular design as the key

mechanism that enables support for multiple types of devices. The J2ME

designers use configurations and profiles to make J2ME modular.


10/35

Defining a Java Platform for Pervasive Devices

Configurations and profiles are the main elements that comprise

J2MEs modular design. These two elements enable support for the plethora

of devices that J2ME supports.

A J2ME

Configuration defines a minimum Java platform for a family of

devices.

Members of a given family all have similar requirements for memory andprocessing power. A configuration is really a specification that identifies thesystem level facilities available, such as a set of Java language features, the

characteristics and features of the virtual machine present, and theminimum Java libraries that are supported. Software developers can expect acertain level of system support to be available for a family of devices thatuses a particular configuration.Introduction to the Java 2 Micro Edition (J2ME) Platform

A configuration also specifies a minimum set of features for a category of

devices.

Device manufacturers implement profiles to provide a real platform for a

family of devices that have the capabilities that a given configuration

specifies.

The other J2ME building block, the profile specifies the application-level

interface for a particular class of devices. A profile implementation consists

of a set of Java class libraries that provide this application-level interface.

Thus, a profile theoretically could specify all kinds of functionality and

services.

This is not the intention of its creators, however. The creators of J2ME

intend that a profile should address the needs of a specific device category

or vertical market pertaining to that device category


11/35

.

The idea is not to place a plethora of unrelated application level

features in a profile. Rather, the main goal is to guarantee interoperability

which doesnt necessarily imply compatibility between different

manufacturers Implementations between all devices of the same category

or vertical market family to define a standard platform for Java application

development.

For example, a profile might support a network communication

facility for the popular Short Message Service (SMS) standard widely used by

mobile phones.

Because the SMS standard is a ubiquitous feature of mobile telephony, it

makes sense to define this service in a profile that targets mobile phones,

rather than to build it into a configuration.

A profile is implemented on top of a configuration, one step closer to

the implementation of real-world applications. Typically, a profile includes

libraries that are more specific to the characteristics of the category of

devices they represent than are the libraries that comprise configurations.Applications are then built on top of the configuration and profile; they can

use only the class libraries provided by these two lower-level specifications.

Profiles can be built on top of one another.

A J2ME platform implementation, however, can contain onlyone configuration. So far, these notions of configurations, profiles,

and platform definitions is somewhat abstract. The next section gives

you a more concrete description of the characteristics of actual

environments.


12/35

Configurations and Profiles

A configuration specifies three basic elements:

a set of Java programming language features

a set of Java virtual machine features

a set of supported Java libraries and application programming

interfaces (APIs)

Figure shows the conceptual layers that comprise the J2ME platform.

The creators of J2ME have defined only two configurations to avoida fragmented landscape of incompatible platforms. The two configurationsthat exist currently represent the two categories of pervasive devices yousaw earlier in this chapter, namely:

Personal, intermittently connected mobile devices

supported by the Connected Limited Device Configuration (CLDC)

Constantly connected network devicessupported by the Connected Device Configuration (CDC)

Theoretically, a configuration could specify the very same support asthe J2SE platform libraries. This is unlikely in the real world because, as younow know, J2ME is targeted at devices that are far less powerful thandesktop computers. Configuration specifications require that all Java classes


13/35

adapted from J2SE be the same as or a proper subset of the original J2SEclass. That is, a class cannot add methods not found in the J2SE version.Configurations can include additional classes in their specifications, however;configurations themselves are not necessarily proper subsets of J2SE. Bothconfigurations that have been defined to date add classes not present in

J2SE in order to address device attributes and constraints.

The J2ME platform consists of a set of layers that support a basicruntime environment with core Java libraries and a Virtual Machine (VM), aset of system-level application programming interfaces (APIs) in aconfiguration, and a set of application-level APIs in a profile.

Connected, Limited Device Configuration (CLDC)

The second of the two J2ME configurations, the Connected, Limited

Device Configuration (CLDC), supports personal, mobile devices, which

constitute a significantly less powerful class of devices than the one that the

CDC supports.

The CLDC specification identifies devices in this category as having

the following characteristics:

160 to 512 KB total memory available for the Java platform 16-bit or 32-bit processor

Low power consumption, often battery powered

Intermittent network connectivity (often wireless) with potentially limitedbandwidth

The goal of the CLDC is to define a standard Java platform for these

devices. Because of the wide variety of system software on various personal

devices, the CLDC makes minimum assumptions about the environment in

which it exists. For example, one OS might support multiple concurrent

processes, another might or might not support a file system, and so forth.


14/35

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. Figure 1.2 shows the relationship

between the two configurations and the J2SE platform.

Like the CDC, the CLDC specifies the level of support of the Javaprogramming language required, the required functional support of acompliant Java VM, and the set of class libraries required.

Java Language Support. The CLDC specification omits support for the

following features of the Java language:

floating point calculations

object finalization

the java.lang.Error class hierarchy in its entirety Of course, these features

involve the VM as well


15/35

The lack of floating point support is the main language-level difference

between a

Java virtual machine that supports CLDC and a standard J2SE VM that is

visible to programmers. This means that programs intended to run on the

CLDC cannot use floating point literals, types, or values. You cant use the

float built-in type, and the java.lang.Float class has been removed from CLDC

libraries. This feature is not present because of the lack of floating-point

hardware or software on most mobile devices.

Object finalization is also absent. This means that the Object.finalize()

method has been removed from the CLDC libraries.

The java.lang.Error exception hierarchy has also been removed from the

CLDC libraries and is therefore not available to applications. The primary

reason that error handling is absent is memory constraints on mobile

devices. This typically doesnt create any disadvantages for applications

development; after all, applications are not supposed to recover from error

conditions. And the resource cost of implementing error handling is

expensive, beyond the capabilities of todays mobile devices. Moreover, errorrecovery is device-specific on embedded devices like mobile phones. In

consequence, it doesnt make sense to stipulate the recovery mechanism

that devices should use. This mechanism may well be outside the scope of

an embedded VM.

Java Virtual Machine and Library Support. The CLDC specifies

requirements for a Java virtual machine. It defines a VM that is highly

portable and designed for resource-constrained small devices. Support for

several features that exist in a standard J2SE VM have been omitted from the

CLDC specification.

What is Servlets


16/35

Servlets are modules that extend request/response-oriented servers,

such as Java-enabled web servers. For example, a servlet might be

responsible for taking data in an HTML order-entry form and applying the

business logic used to update a company's order database.

Servlets are to servers what applets are to browsers. Unlike applets,

however, servlets have no graphical user interface.

Servlets can be embedded in many different servers because the

servlet API, which you use to write servlets, assumes nothing about the

server's environment or protocol. Servlets have become most widely used

within HTTP servers; many web servers support the Servlet API.

Use Servlets instead of CGI Scripts!

Servlets are an effective replacement for CGI scripts. They provide away to generate dynamic documents that is both easier to write and faster torun. Servlets also address the problem of doing server-side programmingwith platform-specific APIs: they are developed with the Java Servlet API, astandard Java extension.

So use servlets to handle HTTP client requests. For example, haveservlets process data POSTed over HTTPS using an HTML form, includingpurchase order or credit card data. A servlet like this could be part of anorder-entry and processing system, working with product and inventorydatabases, and perhaps an on-line payment system.

Other Uses for Servlets

Here are a few more of the many applications for servlets:

Allowing collaboration between people. A servlet can handle multiple

requests concurrently, and can synchronize requests. This allows

servlets to support systems such as on-line conferencing.

Forwarding requests. Servlets can forward requests to other servers

and servlets. Thus servlets can be used to balance load among several
http://java.sun.com/products/servlet/industry.htmlhttp://java.sun.com/products/servlet/industry.html


17/35

servers that mirror the same content, and to partition a single logical

service over several servers, according to task type or organizational

boundaries.

Interacting with Clients

An HTTP Servlet handles client requests through its service method.

The service method supports standard HTTP client requests by dispatching

each request to a method designed to handle that request. For example, the

service method calls the doGet method shown earlier in the simple example

servlet.

Requests and Responses

This section discusses using the objects that represent the client's

request (an HttpServletRequest object) and the servlet's response (an

HttpServletResponse object). These objects are provided to the service

method and to the methods that service calls to handle HTTP requests.

Handling GET and POST Requests

The methods to which the service method delegates HTTP requests

include,

doGet, for handling GET, conditional GET, and HEAD requests

doPost, for handling POST requests

doPut, for handling PUT requests

doDelete, for handling DELETE requests

By default, these methods return a BAD_REQUEST (400) error. Your

servlet should override the method or methods designed to handle the HTTP

interactions that it supports. This section shows you how to implement

methods that handle the most common HTTP requests: GET and POST.
http://d/Remote_Admin/soft/j2me2/selected12/servlets/overview/simple.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/overview/simple.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/client-interaction/req-res.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/client-interaction/http-methods.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/overview/simple.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/overview/simple.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/client-interaction/req-res.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/client-interaction/http-methods.html


18/35

The HttpServlet's service method also calls the doOptions method

when the servlet receives an OPTIONS request, and doTrace when the servlet

receives a TRACE request. The default implementation of doOptions

automatically determines what HTTP options are supported and returns that

information. The default implementation of doTrace causes a response with a

message containing all of the headers sent in the trace request. These

methods are not typically overridden.

The Servlet Life Cycle

Each servlet has the same life cycle:

A server loads and initializes the servlet

The servlet handles zero or more client requests

The server removes the servlet(some servers do this step only when they shut down)

Initializing a Servlet

When a server loads a servlet, the server runs the servlet's init

method. Initialization completes before client requests are handled and

before the servlet is destroyed.

Even though most servlets are run in multi-threaded servers, servlets

have no concurrency issues during servlet initialization. The server calls the

init method once, when the server loads the servlet, and will not call the init

method again unless the server is reloading the servlet. The server can not

reload a servlet until after the server has destroyed the servlet by running

the destroy method.

Interacting with Clients

After initialization, the servlet is able to handle client requests. This

part of the servlet life cycle was handled in the previous lesson.
http://d/Remote_Admin/soft/j2me2/selected12/servlets/lifecycle/init.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/client-interaction/index.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/lifecycle/init.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/client-interaction/index.html


19/35

Destroying a Servlet

Servlets run until the server destroys them, for example, at the

request of a system administrator. When a server destroys a servlet, the

server runs the servlet's destroy method. The method is run once; the serverwill not run the destroy method again until after the server reloads and

reinitializes the servlet.

When the server calls the destroy method, another thread might be

running a service request. The Handling Service Threads at Servlet

Termination lesson shows you how to provide a clean shutdown when there

could be long-running threads still running service requests.

Architecture of the Servlet Package

The javax.servlet package provides interfaces and classes for

writing servlets. The architecture of the package is described below.

The Servlet Interface

The central abstraction in the Servlet API is the Servlet interface. All

servlets implement this interface, either directly or, more commonly, by

extending a class that implements it such as HttpServlet

The Servlet interface declares, but does not implement, methods that

manage the servlet and its communications with clients. Servlet writers

provide some or all of these methods when developing a servlet.

Client Interaction

When a servlet accepts a call from a client, it receives two objects:

A ServletRequest , which encapsulates the communication from theclient to the server.

A ServletResponse , which encapsulates the communication from theservlet back to the client.
http://d/Remote_Admin/soft/j2me2/selected12/servlets/lifecycle/destroy.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/lifecycle/service-threads.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/lifecycle/service-threads.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.Servlet.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.http.HttpServlet.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.ServletRequest.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.ServletResponse.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.ServletResponse.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.ServletRequest.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.http.HttpServlet.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.Servlet.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/lifecycle/destroy.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/lifecycle/service-threads.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/lifecycle/service-threads.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.Servlet.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.http.HttpServlet.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.ServletRequest.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.ServletResponse.html


20/35

ServletRequest and ServletResponse are interfaces defined by thejavax.servlet package.

The ServletRequest Interface

The ServletRequest interface allows the servlet access to:

Information such as the names of the parameters passed in by the

client, the protocol (scheme) being used by the client, and the names

of the remote host that made the request and the server that received

it

The input stream, ServletInputStream . Servlets use the input stream

to get data from clients that use application protocols such as the HTTP

POST and PUT methods.

Interfaces that extend ServletRequest interface allow the servlet to

retrieve more protocol-specific data. For example, the HttpServletRequest

interface contains methods for accessing HTTP-specific header information.

The ServletResponse Interface

The ServletResponse interface gives the servlet methods for replying to the

client. It:

Allows the servlet to set the content length and MIME type of the reply.

Provides an output stream, ServletOutputStream , and a Writer

through which the servlet can send the reply data.
http://java.sun.com/products/servlet/2.1/api/javax.servlet.ServletInputStream.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.http.HttpServletRequest.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.ServletOutputStream.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.ServletOutputStream.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.http.HttpServletRequest.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.ServletInputStream.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.ServletInputStream.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.http.HttpServletRequest.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.ServletOutputStream.html


21/35

Interfaces that extend the ServletResponse interface give the servlet

more protocol-specific capabilities. For example, the HttpServletResponse

interface contains methods that allow the servlet to manipulate HTTP-specific

header information.

Additional Capabilities of HTTP Servlets

The classes and interfaces described above make up a basic Servlet.

HTTP servlets have some additional objects that provide session-tracking

capabilities. The servlet writer can use these APIs to maintain state between

the servlet and the client that persists across multiple connections during

some time period. HTTP servlets also have objects that provide cookies. The

servlet writer uses the cookie API to save data with the client and to retrieve

this data.

Calling Servlets From an HTML Page

To invoke a browser from within an HTML page just use the servlet

URL in the appropriate HTML tag. (This section assumes knowledge ofHTML

.) Tags that take URLs include those that begin anchors and forms, and a

meta tags.

This section uses the Duke's Bookstore ShowCart, Cashier, and

Receipt servlets. Luckily this is the order that the servlets are displayed

when you look at your cart and buy your books.

For the most direct access to the ShowCart servlet, click the

Show Cart link from the Duke's Bookstore main page. If you have

servletrunner or a web server set up to run the example, go to the main

page of the bookstore as shown in the previous section. Just for fun, you

might want to add a book to your cart before accessing the ShowCart servlet.
http://java.sun.com/products/servlet/2.1/api/javax.servlet.http.HttpServletResponse.htmlhttp://www.w3c.org/TR/REC-html32.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/call-servlets/browser.htmlhttp://www.w3c.org/TR/REC-html32.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.http.HttpServletResponse.htmlhttp://java.sun.com/products/servlet/2.1/api/javax.servlet.http.HttpServletResponse.htmlhttp://www.w3c.org/TR/REC-html32.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/call-servlets/browser.html


22/35

Example Servlet URLs in HTML Tags

The page returned by the ShowCartServlet has a number of anchors,

each of which has a servlet as a destination. The following shows the code

for one of those anchors:

public class ShowCartServlet extends HttpServlet {

public void doGet (HttpServletRequest request,HttpServletResponse response)

throws ServletException, IOException{

...out.println(... +

"Check Out " +

...);...

}...

}This code results in an HTML page that has the following anchor:


23/35

...out.println(... +

"" +

..."" +..."" +..."" +...);

out.close();}

...}

This code results in an HTML page that has the following tag to begin theform:

If the cashier servlet's page is displayed in your browser, you can see

the tag that begins the form if you view the source of the page. Then submit

the form. The receipt servlet will return the page that contains the nextexample. The receipt servlet's page resets itself though, so if you want to

view the page's HTML source, do it fast!.

The page returned by the receipt servlet has a meta tag that uses a

servlet URL as part of the value of the http-equiv attribute. Specifically, the

tag directs the page to reset to the main page ofDuke's Bookstore after

thanking the user for the order. The following shows the code for this tag:

public class ReceiptServlet extends HttpServlet {


24/35

public void doPost(HttpServletRequest request,HttpServletResponse response)

throws ServletException, IOException{

...out.println("" +" Receipt " +

"" +

"" +...

}...

}

This code results in an HTML page that has the following tag:

Destroying a Servlet

The destroy method provided by the HttpServlet class destroys the

servlet and logs the destruction. To destroy any resources specific to yourservlet, override the destroy method. The destroy method should undo any

initialization work and synchronize persistent state with the current in-

memory state.

The following example shows the destroy method that accompanies

the pseudo-code init method in the previous lesson:

public class DBServlet ... {

Connection connection = null;

... // the init method


25/35

public void destroy() {

// Close the connection and allow it to be garbage collected

connection.close();

connection = null;

}

}

A server calls the destroy method after all service calls have been

completed, or a server-specific number of seconds have passed, whichever

comes first. If your servlet handles any long-running operations, service

methods might still be running when the server calls the destroy method.You are responsible for making sure those threads complete.The next lesson

shows you how.

The destroy method shown above expects all client interactions to be

completed when the destroy method is called, because the servlet has no

long-running operations.

What is RMI:

Remote Method Invocation(RMI) allows an object running inside a Java

Virtual Machine to invoke a method on an object running on a remote

machine and have the results returned to the Client.

Thus, RMIimplies a Client and a Server.

The Server application creates a remote object and akes it accessible.
http://d/Remote_Admin/soft/j2me2/selected12/servlets/lifecycle/service-threads.htmlhttp://d/Remote_Admin/soft/j2me2/selected12/servlets/lifecycle/service-threads.html


26/35

A Client application gets a remote reference to one of the objects in the

Server and then invokes methods on it.

. This model is referred to as a distributed object application.

Remote Method Invocation (RMI) is the action of invoking a method of a

remote interface on a remote object. Most importantly, a method invocation

on a remote object has the same syntax as a method invocation on a local

object.

The Server registers the objects that are available to clients. One of the

ways this can be accomplished is through a naming facility provided as part

of the JDK, which is called rmiregistry.

The Server uses the registry to bind an arbitrary name to a remote

object. The Client looks up the name in the registry, and obtains a reference

to the remote object.

RMI Architecture

The stub/skeleton layer provides the interface that Client and Serverobjects use to interact with each other.

The remote reference layer handles the creation of and management of remote object

references.

The transport layer is the protocol that sends remote object requests across thenetwork.


27/35

The Remote Interface

The Server's job is to accept requests from the Client, perform some

service, and then send the results back to the Client.

The Server must specify an interface that defines the methods

available to clients. This remote interface defines the client view of the

remote object.

The remote interface is always written to extend the java.rmi.Remote

interface. Remote is a "marker" interface that identifies interfaces whose

methods may be invoked from a non-local virtual machine.

Implementing the Remote Interface

Now we need a class that implements the CalendarTask interface.

The Server will then create an object of this class, the remote object,and register it.

Writing the Server


28/35


29/35

javac CalendarImpl.javajavac CalendarServer.javajavac CalendarClient.java

Next, generate the client stubs and server skeletons.

The stub is a client-side proxy for the remote object. The stub:. Maintains an internal reference to the remote object it represents. Forwards the method invocation request to the remote object by"marshalling" the method arguments into serialized form

on the server side, the skeleton:. Converts the remote request into the appropriate method call on theactual server object, which includes "unmarshalling" the method arguments.

Stubs and skeletons are generated from remote object

classes using the rmic compiler.rmic CalendarImpl

We now have the following two files:CalendarImpl_skel.classCalendarImpl_stub.class

Compiling and Running the CodeIf you run rmic with the keep option, you will also have the following files:CalendarImpl_skel.java

CalendarImpl_stub.java

. Examining this source code will help you understand exactlywhat goes on in these classes.

Note that skeleton classes are optional in Java 2. TheRMI runtime in Java 2 contains generic code thatperforms the function of skeletons. The v1.2 option onrmic suppresses the generation of the skeletons.

Next, start the RMI registry service.

start rmiregistry

Alternately, the server code could call the following method tocreate the registry:LocateRegistry.createRegistry()You will see this in our next example.

Then start the server.


30/35

java CalendarServer

Finally, run the client.java CalendarClient

Remote Method Arguments and Return Values

The arguments to a remote method must be serializablei.e., they must be primitive types or objects of classes that implement theSerializable interface. The same restriction applies to return values.

The RMI stub/skeleton layer decides how to send arguments andreturn values over the network.

. If the object is Serializable but not Remote, the object is serialized andstreamed in byte format. The receiver deserializes the bytes into a copy of

the original object.

. If the object is a Remote object, a remote reference for the object ismarshaled and sent to the remote process. This reference is received andconverted into a stub for the original object.

. If the argument or return value is not serializable, ajava.rmi.MarshalException is thrown.

The key difference between remote and non-remote objects is thatremote objects are sent by reference, while non-remote objects (and

primitive types) are sent by copy.

Dynamic Loading of Stub Classes

If the client stub class is not available in the localCLASSPATH, itmust be loaded dynamically over thenetwork. This is a typical scenario whenthe Client andServer are not running on the same machine. We willillustratedownloading of stub classes via a web server.

When the RMI run-time system marshals a remote objectstub, itencodes a URL in the byte stream to tell theprocess on the other end of thestream where to look forthe class file for the marshaled object. This URL isobtained from a system property called java.rmi.server.codebase. We will setthis property on the command line to point to a directory within the webservers document base.

Note that in order for a Java runtime system to be able to load classes


31/35

remotely, it has to have a security manager installed that will allow it. Thereis one provided by the java.rmi.RMISecurityManager class.

The final issue is that the default Java security policy doesnt allowall the networking operations required to load a class from a remote host. A

RMI client that needs to load classes remotely must have a policy filegranting the necessary permissions. The name of the policy file can bespecified on the command line by setting the java.security.policy property

Software&

Hardware


32/35

Requireme

nts

Software and Hardware Requirements

Software Requirements

Java Development Kit 1.3.1 (JDK1.3.1)

Java Mobile Tool Kit 2.2

Connected Limited Device Configuration (CLDC 1.0)

Mobile Information Device Profile (MIDP 2.0)

Tomcat Server

Minimum Hardware Requirements

Intel Pentium 3 Processor


33/35

128 MB RAM

Java Enabled Cell phone

Languages Java 2 Micro Edition (J2ME) Java 2 Standard Edition (J2SE)

o Remote Method Invocation (RMI)o Java Servlets

TESTING CASE

The tests I have conducted for the project are as follows

Black-box testing

White-box testing

Black-box TestingThis test enables the software engineers to derive sets of inputs

conditions that will fully exercise all functional requirements for a program.This test will find the errors in the following categories.

1. Interface error2. Incorrect or missing function.3. Error in data structures or external data base access.4. Behavior or performance errors.5. Initialization and termination errors.

The project is Mobile based hence I have also conducted the following test.

The content model for the Mobile is reviewed to uncover errors.

The design model for the Mobile is reviewed to uncover navigationerror.

Selected processing components and Mobile are tested.

The architecture is constructed and integration tests are conducted.


34/35

The assembled Mobile is tested for overall functionality and contentdelivery.

The Mobile is implements in a verity of different environmentalconfigurations and is tested for compatibility with each configuration.

The Mobile is tested by a control and monitored population of end-

user.

Bibliography

WEBSITES:

http://www.java.sun.com/wireless

http://www.java.sun.com/j2me

http://www.jguru.com/faq/j2me

http://www.sun.com/developers


35/35

BOOKS:

1. Wireless Java Programming with J2ME

by: Yu Feng and Dr. Jun Zha.

2. Wireless Java: Developing with J2ME

by: JONATHAN KNUDSEN

3. Developing Java Servlets

by: James Goodwill

4. CodeNotes for J2EE

by: Rob McGovern

5. Advanced Programming for the Java 2 Platform

by: Calvin Austin & Monica Pawlan

mobile control o

Documents