PMRC-Dec 2010

1-a Ans. 1-b Ans. Explain the life cycle of midlet. [10 Marks] See Jun 2010 paper solution Q1-b. Write a note on MVC architecture. [10 Marks]

Figure: MVC architecture MVC (Model-View-Controller) architecture separates the core business model functionality of the web application from the presentation and control logic of the interface-specific application. With this arrangement, it is possible to have multiple use of the same data model of the Web application. Under MVC architecture, data (Model) and user interface (View) are separated from each other so that any change in the user interfaces does not affect the data in the database, and vice versa. Figure shows that View uses the query methods of the Model to retrieve content. In addition, whenever a user sends a request, it passes through the Controller. Then, the controller intercepts the request from the View and passes it to the Model for appropriate action. Controller, which is a Servlet, stores all the business logic. A View, normally a JSP page, contains all the code for representation. A model is implemented by using a pure Java or bean class. The different components in the application, such as Controller, Model, and View, are reusable and make applications highly scalable. Describing the Model Component The model component displays the data on which an application is based. In a web application, JavaBeans hold the data needed by a web application to process user queries. Events sent to Web Controller serves the basis for all modifications to the data. The Model component represents the data and the business logic of the application and has no concern with the presentation logic of the application. An application may have many states that need to be stored somewhere. These states are encapsulated by the Model component of the application. All the functionalities and features of the application are provided by the Model component. The application behaves according to the business logic of the application, implemented by the Model component. Any change in the state of the model component state is notified immediately and this change is reflected in all Views.

Describing the View Component A View provides the Graphical User Interface (GUI) for Model. A user interacts with the application through View, which represents the information based on Model, and allows the user to alter data. A Model can have multiple Views. Model manages the database, the content of which can be changed and updated frequently. Any change in the database must be reflected to the user as soon as possible. Therefore, a view communicates with a Model to get information if any change takes place in the database. Users who want to modify the content of a Model do not communicate with it directly. Instead, they communicate with the Model through a View, which communicates with the Controller regarding the user input. The Controller then makes the required changes in the Model and also notifies the other associated Views. Describing the Controller Component The Controller component controls all the Views associated with a Model. When a user interacts with the View component and tries to update the Model, the Controller component invokes various methods to update the Model. The Controller of an application also controls the data flow and transfers the requests between Model and View. Figure shows the interaction among the various MVC components: The behavior of a Web application is determined by the behavior of its various MVC components. The interaction among the various components is managed by the Controller, which, by controlling the flow among these components, determines the way the application performs the intended tasks. Let's understand how the Controller performs its role when a user needs to change the data stored in a Model. If the user wishes to change this data, the user sends a request to the Controller, which consults the Model to update all the Views. The following steps are followed to change the data: 1. The user sends a request through an interface provided by the View, which passes the request to the Controller. 2. The Controller receives the input request. 3. The Controller processes the request according to the Controller logic, and if access to the Model is not required, the process moves to step 5. 4. The Model is accessed and modified, if required. It then needs to notify all the associated Views regarding the modification. 5. The View presents a user interface according to the modified or original Model, as the case may be. 6. The View remains idle after the ail-rent interaction and waits for the next interaction to begin. This process is repeated again for every new request. 2-a Ans. Design a canvas based MIDP application which generates concentric circles from smallest to largest circle on click of command button. [10 Marks] Canvas ConcentricCirclesCanvas.java code: import javax.microedition.lcdui.*; public class ConcentricCirclesCanvas extends Canvas { protected void paint(Graphics g) { int w , h; int INIT_RADIUS = 5; w = getWidth(); h = getHeight(); g.setColor(255, 255, 255); //white g.fillRect(0, 0, w, h); // white background g.setColor(0, 0, 0); //black

int rmax; if (w > h){ rmax = h/2; } else{ rmax = w/2; } for(int r = INIT_RADIUS; r<=rmax; r+=10){ g.drawArc(w/2-r, h/2-r, 2*r, 2*r, 0, 360); } } } Midlet ConcentricCirclesMidlet.java code: import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class ConcentricCirclesMidlet extends MIDlet implements CommandListener { Command showCommand, exitCommand; // The exit command Display display; // The display for this MIDlet TextBox t; // Textbox to show message ConcentricCirclesCanvas cc; // canvas with concentric circles public ConcentricCirclesMidlet() { t = new TextBox("Concentric Circles", "Select Show command", 255, 0); cc = new ConcentricCirclesCanvas(); showCommand = new Command("Show", Command.EXIT, 0); exitCommand = new Command("Exit", Command.EXIT, 1); t.addCommand(showCommand); t.addCommand(exitCommand); t.setCommandListener(this); cc.addCommand(exitCommand); cc.setCommandListener(this); } public void startApp() { display = Display.getDisplay(this); display.setCurrent(t); } public void commandAction(Command c, Displayable s) { if (c == exitCommand) { destroyApp(false); notifyDestroyed(); } if (c == showCommand) { display.setCurrent(cc); } } public void pauseApp() { } public void destroyApp(boolean unconditional) { } }

2-b Ans. 3-a Ans.

What is event handling? Elaborate its types in J2ME. [10 Marks] See Jun 2010 paper solution Q4-a. What are JDBC drivers, state its types and elaborate each of them. [10 Marks] The different types of drivers available in JDBC are listed in below: JDBC Drive Types Description Type-1 Driver This type of driver is Bridge Driver (JDBC-ODBC bridge) Type-2 Driver This driver is a Partly Java and Partly Native code driver Type-3 Driver This is a Pure Java driver that uses a middleware driver to connect to a database Type-4 Driver This is a Pure Java driver and is directly connected to a database Describing Type-1 Driver The Type-1 driver acts as a bridge between JDBC and other database connectivity mechanisms, such as ODBC. An example of this type of driver is the Sun JDBC-ODBC bridge driver implementation. The JDBC-ODBC Bridge provides the access to the database by using the ODBC drivers. This driver helps the Java programmers to use JDBC and programs Java applications to communicate with existing data stores. This driver is included in the Java2 SDK within the sun. jdbc.odbc package. This driver converts JDBC calls into ODBC calls and redirects the request to the ODBC driver. The architecture of the Type-1 driver is shown in Figure 2-2:

Figure 2-2: The architecture of the Type-1 driver Figure 2-2 shows the architecture of the system that uses JDBC-ODBC bridge driver to communicate with the respective database. As shown in the figure Java Application is programmed to JDBC API and will make a request to JDBC-ODBC bridge driver i.e. JDBC call, where JDBC-ODBC bridge driver is responsible to resolve the JDBC call and make an equivalent ODBC calls to the ODBC driver. To do this JDBC-ODBC bridge driver uses ODBC API. Later ODBC driver comes into action and completes the request, and sends response to the JDBC-ODBC bridge driver. Now, JDBC-ODBC bridge driver converts the response and presents it to the requesting Java Application in JDBC standards. This type of driver is generally used in the development and testing phases of Java applications. Advantages of Type-1 Driver

Single Driver implementation can be used to interact with different data stores. This driver allows us to communicate with all the databases supported by the ODBC driver. This is a vendor independent driver. Disadvantages of Type-1 Driver Due to a large number of translations, the execution speed is decreased. This driver depends on the ODBC driver, and therefore, Java applications also become indirectly dependent on ODBC drivers. ODBC binary code (or ODBC client library) must be installed on every client. This driver uses JNI to make ODBC calls. Because of the preceding listed disadvantages, this driver is not recommended to be used in production environment. In case a database does not have any other JDBC driver implementations, then only we should use this driver in the production environment. Describing Type-2 Driver (Java to Native API) Type-2 driver converts JDBC call into DB vendor specific native call in a client machine. In other words, this type of driver makes JNI calls on database specific native client API. These database specific native client API are usually written in C, C++. The Type-2 driver follows a 2-tier architecture model, as shown in Figure 2-3:

Figure 2-3: The architecture of the Type-2 driver As shown in Figure 2-3, the Java application that wants to communicate with the database is programmed using JDBC API. These JDBC calls (programs written by using JDBC API) are converted into database specific native calls in the client machine and the request is then dispatched to the database specific native libraries. These native libraries present in the client are intelligent to send the request to the database server by using native protocol. This type of driver is implemented specific to a database and is usually delivered by a DBMS vendor. However, it is not mandatory that Type-2 drivers have to be implemented by DBMS vendors only. An example of Type-2 driver is the Weblogic driver implemented by BEA Weblogic. Type-2 drivers are suitable to use with server-side applications. It is not recommended to use Type-2 drivers with client-side applications, since the database specific native libraries for the client platform should be installed on the client machines. Advantages of Type-2 Driver This driver helps in accessing the data faster as compared to other type of drivers We can use the additional features provided by the specific database vendor, which are even supported by the JDBC specification.

Disadvantages of Type-2 Driver Native libraries must be installed on client machines since the conversion from JDBC calls to database specific native calls is done on the client machine. Database specific native functions are executed on the client JMV process and any bug in this driver can crash the JVM. It may increase the cost of the application if the application needs to run on different platforms (since we may require buying the native libraries for all of the platforms). Examples of Type-2 Driver OCI (Oracle Call Interface) DriverOracle Corporation has implemented this driver to communicate with the Oracle database server. This driver converts JDBC calls into OCI (Oracle native libraries) calls. Weblogic OCI Driver for Oracle This driver is also similar to the oracle OCI driver, but the Weblogic OCI JDBC driver makes JNI calls to weblogic library functions. Type-2 Driver for Sybase This driver converts JDBC calls into Sybase dblib or ctlib calls, which are native libraries to connect to Sybase. Describing the Type-3 Driver (Java to Network Protocol/All Java Driver) The Type-3 driver translates JDBC calls into database server independent and middleware server specific net protocol calls (network calls), which are then translated into database server specific calls by the middleware server. Type-3 drivers follow 3-tier architecture model, as shown in Figure 2-4:

Figure 2-4: The architecture of the Type-3 driver As shown in Figure 2-4, JDBC Type-3 driver listens for JDBC calls from the Java application and translates them into middleware server specific calls. Then, the driver communicates with the middleware server over a socket. The middleware server converts these calls into database specific calls. This type of drivers are named as net-protocol fully Java technologyenabled driver, or simply net-protocol driver. The middleware server can be added with some additional functionalities, such as pool management, to improve the performance and availability of connection, which can make this architecture more useful in enterprise applications. Type-3 driver is recommended to be used with applets since this type of driver is auto downloadable. Advantages of Type-3 Drivers Type-3 drivers are pure Java drivers and are auto downloadable. No native libraries are required on the client machine. A single driver provides accessibility to multiple databases, implying that this driver is database independent.

Database details, such as username, password, and database server location, are not required to be given to the client; instead, they are configured in the middleware server. We can switch over from one database to other without changing the client-side driver classes, by just changing the configurations of the middleware server. Disadvantages of Type-3 Driver Compared to Type-2 drivers, Type-3 drivers are slow due to the increased number of network calls. Type-3 drivers are costlier compared to the other drivers. Examples of Type-3 Drivers IDS Driver This driver listens for JDBC calls and converts them into IDS Server specific understandable network calls. A Type-3 driver communicates over a socket to IDS Server, which acts as a middleware server (as described in the architecture). Weblogic EMI Driver This driver listens for JDBC calls and sends the request from the client to the middleware server by using the RMI protocol. The middleware server uses a suitable JDBC driver to communicate with a database. Describing the Type-4 Driver (Java to Database protocol) The Type-4 driver is a pure Java driver, which implements the database protocol to interact directly with a database. This type of drivers does not require any native database libraries to retrieve the records from the database. This type of drivers translates JDBC calls into Database specific network calls. Type-4 drivers follow the 2-tier architecture model, as shown in Figure 2-5:

Figure 2-5: The architecture of the Type-4 driver As shown in Figure 2-5, the Type-4 driver prepares a DBMS specific network message and then communicates with database server over a socket. This type of driver is lightweight and is generally known as thin driver. The Type-4 driver uses data base specific proprietary protocols for communication. Generally, this type of drivers are implemented by DBMS vendors, since the protocol used here are proprietary. You can use Type-4 drivers when you want an auto downloadable option for the client-side applications. It is also recommended to be used with server-side applications. Advantages of Type-4 Driver This type of drivers are pure Java drivers and hence auto downloadable. No native libraries are required to be installed in the client machine. Secure to use since it uses database server specific protocol. This type of driver does not require a middleware server. Disadvantage of Type-4 Driver The main disadvantage of Type-4 Driver is that it uses database specific proprietary protocol

and is DBMS vendor dependent. Examples of Type-4 Driver Thin Driver for Oracle from Oracle Corporation Weblogic, Msssqlserver4 for MS SQL Server from BEA Systems 3-b Ans. 4-a Ans. 4-b Ans. 4-c Ans. Explain the life cycle of servlet. [10 Marks] See Jun 2010 paper solution Q2-a. Obfuscator [5 Marks] See Jun 2010 paper solution Q5-a. Bluetooth Architecture [5 Marks] See Jun 2010 paper solution Q5-d. Configurations and Profiles [5 Marks] A configuration specifies a JVM and some set of core APIs for a specific family of devices. Currently there are two: 1. The Connected Device Configuration (CDC) and 2. The Connected, Limited Device Configuration (CLDC). The configurations and profiles of J2ME are generally described in terms of their memory capacity. Usually a minimum amount of ROM and RAM is specified. 1. Connected Device Configuration (CDC) The Connected Device Configuration (CDC) is a Java ME configuration. This configuration is intended to be used by devices requiring a complete implementation of the Java virtual machine, and an API set that may, via the addition of profiles, include the entire Java Platform, Standard Edition API. Requirement: Minimum-ROM = 2.5 MB. Minimum-RAM = 2 MB. Some kind of network connection. Full JVM must be supported. 2. Connected, Limited Device Configuration (CLDC) The name CLDC appropriately describes these devices, having limited display, limited memory, limited CPU power, limited display size, limited input, limited battery life, and limited network connection. CLDC is aimed at smaller devices than those targeted by the CDC. Requirement: Min-ROM = 160 KB Min-RAM = 32 KB available for the Java platform Total memory = 160KB to 512KB of, including a minimum ROM and RAM A 16-bit or 32-bit processor The Connected simply refers to a network connection that t ends to be intermittent and probably not very fast. The reference implementation of the CLDC is based around a small JVM called the KVM. Its name comes from the fact that it is a JVM whose size is measured in kilobytes rather than megabytes. Profiles A profile is layered on top of a configuration, specifies the APIs and specifications necessary to develop applications for a specific family of devices.

Personal Profile Personal Basis Profile Foundation Profile

Provides full AWT support, applet support, and limited bean support. Includes all of the Personal Basis Profile APIs Provides a limited GUI without full AWT compatibility. Includes all of the Foundation Profile APIs. Provides basic application-support classes such as network support & I/O support. It does not include any support for graphics or GUI services. Profiles based on CDC

Profiles based on CLDC a) Personal Digital Assistant Profile (PDAP) The PDA Profile (PDAP), which is built on CLDC, is designed for application development environment for PDAs. Characteristics: Minimum of 512KB combined ROM and RAM (and a maximum of 16MB). It includes an application model based on MIDlets but uses a subset of the J2SE Abstract Windowing Toolkit (AWT) for graphic user interface. b) Mobile Information Device Profile (MIDP) The Mobile Information Device Profile (MIDP) is a key element of the J2ME. When combined with the CLDC, MIDP provides a standard Java runtime environment for mobile devices. Characteristics: A minimum of 256KB of ROM for the MIDP implementation (this is in addition to the requirements of the CLDC) A minimum of 128KB of RAM for the Java runtime heap A minimum of 8KB of nonvolatile writable memory for persistent data A screen of at least 9654 pixels Some capacity for input, either by keypad, keyboard, or touch screen Two-way network connection, possibly intermittent 4-d Ans. Alerts in MIDP applications. [5 Marks] Alert An alert is an informative message shown to the user. There are two flavors of alert: 1. A timed alert is shown for a certain amount of time, typically just a few seconds. It displays an informative message that does not need to be acknowledged. 2. A modal alert stays up until the user dismisses it. Modal alerts are useful when you need to offer the user a choice of actions. Creating Alerts (Constructors) Alerts are represented by instances of the javax.microedition.lcdui.Alert class, which offers the following constructors: 1. public Alert(String title) 2. public Alert(String title, String alertText, Image alertImage, AlertType alertType) Any or all of the parameters in the second constructor may be null. Alert Types Alert types serve as hints to the underlying MIDP implementation. The implementation may use the alert type to decide what kind of sound to play when the alert is shown. The AlertType class provides five types, accessed as static member variables: ALARM, CONFIRMATION, ERROR, INFO, and WARNING. Methods:

public void setTimeout(int time) Set the time for which the Alert is to be shown. This must either be a positive time value in milliseconds creates timed alert or the special value Alert.FOREVER creates a modal alert. 5 Ans. Design a calculator using high level components to perform basic operations of addition, subtraction, multiplication and division. [20 Marks] CalculatorMidlet.java code: import javax.microedition.lcdui.*; import javax.microedition.midlet.*; public class CalculatorMidlet extends MIDlet implements CommandListener{ private Display display; private Form form; private Command exitCommand, calculateCommand, clearCommand; private TextField textfield1, textfield2, textResult; private ChoiceGroup choicegroup; public CalculatorMidlet() { form = new Form("Calculator"); calculateCommand = new Command("Calculate", Command.SCREEN, 0); clearCommand = new Command("Clear", Command.SCREEN, 0); exitCommand = new Command("Exit", Command.SCREEN, 0); textfield1 = new TextField(null, null, 10, TextField.DECIMAL); textfield2 = new TextField(null, null, 10, TextField.DECIMAL); textResult = new TextField("Result", null, 100, TextField.ANY | TextField.UNEDITABLE); choicegroup = new ChoiceGroup(null, Choice.POPUP); choicegroup.append("+", null); choicegroup.append("-", null); choicegroup.append("*", null); choicegroup.append("/", null); form.append(textfield1); form.append(choicegroup); form.append(textfield2); form.append(textResult); form.addCommand(calculateCommand); form.addCommand(clearCommand); form.addCommand(exitCommand); form.setCommandListener(this); } public void startApp() { display = Display.getDisplay(this); display.setCurrent(form); } public void commandAction(Command c, Displayable d) { if (c == exitCommand) { destroyApp(false); notifyDestroyed(); } if (c == clearCommand) { textfield1.setString(""); textfield2.setString(""); } if (c == calculateCommand) { double t1=0.0, t2=0.0; if(!textfield1.getString().equals("")) t1 = Double.parseDouble(textfield1.getString());

if(!textfield2.getString().equals("")) t2 = Double.parseDouble(textfield2.getString()); switch(choicegroup.getSelectedIndex()){ case 0: textResult.setString(Double.toString(t1+t2)); break; case 1: textResult.setString(Double.toString(t1-t2)); break; case 2: textResult.setString(Double.toString(t1*t2)); break; case 3: if(t2 != 0.0){ textResult.setString(Double.toString(t1/t2)); } break; } } } public void pauseApp() { } public void destroyApp(boolean unconditional) { } } 6-a Ans. Deployment Descriptor [5 Marks] Deployment Descriptor is an important part of Java EE 5 Web applications. They help in managing the deployment configuration of Web applications. For Web containers, the deployment is an XML file called web.xml, which is stored in the /WEB-INF directory of the Web application. The Java Servlets specification specifies a Document Type Definition (DTD) for the Deployment Descriptor. It has several purposes: Initializing parameters for Servlets and Web applications This allows us to minimize the amount of hard coding of initialization values within the Web applications. For example, if a Servlet requires access to a database, the best place to specify the login and password to access the database, is the Deployment Descriptor. This allows us to configure our applications without having to recompile the Servlets. Servlet/JSP Definitions Each Servlet/precompiled JSP used in a Web application should be defined in the Deployment Descriptor. This entry includes the name of the Servlet or JSP, class of the Servlet or JSP, and an optional description. Servlet/JSP MappingsWeb containers use this information to map incoming requests to Servlets and JSPs. Specifying MIME Types Since each Web application can contain several content types, you can specify the MIME types for each of these in the Deployment Descriptor. SecurityYou can manage access control for an application by using the Deployment Descriptor. For example, you can specify the pages of the Web application that require a login, the appearance of the login page, and the role the user should have. Web Container Web containers refer to the platform that holds the Web components and provides the platform specific functionality to these components. Prior to the execution of a Web component associated with an application, you need to assemble it in the Web module and

6-b Ans.

deploy it in the Web container. Alternatively, a Web container serves as a runtime environment for a Web application. The Web applications run within a Web container of a Web server. In addition, a Web container is used to provide Web components associated with the Web application. Few Web servers may also be used to provide additional services, such as security, concurrency, transaction, and secondary storage. The EJB container is used to provide these additional services. A Web server does not need to be located on the same machine as the EJB server. The Java EE application components use the protocol and methods available in the container to access the functionality provided by the server. Types of Web Containers The Java EE application server supports the following types of Web Containers: Web containers in a Java EE 5 Application server Refers to in-built Web containers in the Java EE 5 supported application servers, such BEAs WebLogic Server, Borlands Inprise application server, Netscapes iPlanet application sever, and IBMs WebSphere application servers. Web containers built into Web servers Refers to the Wbe container that is integrated with the web server. Few examples are Java WebServer from Sun Microsystems and Jakarta Tomcat from Apache project. Web containers in a separate runtime Refers to Web server and Web containers that are configured separately. The examples include Apache and Microsoft IIS, which require a separate Java runtime to actually run the Servlets and Web server plug-in to integrate the Java runtime with the Web server. The communication between the Web server and Web container is managed by the plug-in. 6-c Ans. Components of web application A Web application consists of Web components, such as Java Servlet and JavaServer Pages (JSPs). Earlier Web-based appllations used to face maintenance problems, which were solved by using the Model/View/Controller MVC paradigm for building user interfaces. JSPs are generally used for a creating dymmic response or View. Servlets, containing the logic for managing requests, act as the Contoller; while the existing business rules are the Model.

Figure: Components of web application Java Serviets A Java Servlet is used to extend the capabilities of the servers in a client-server programming model, and is considered the building block for developing Web applications. Java Servlets extend the functionality of a Web server. Although they can respond to any type of requests, they are commonly used in the Web applications hosted by Web servers. Servlets function similar to applets that run on the server. These are portable platform and Web server independent means to deliver dynamic content. An application that is browserbased and calls Servlets need not support Java. This is because of the fact that the output of a Servlet can be HTML, XML, or any other content type. Java Server Pages JSP pages are text-based documents that are executed as Servlets, but allow a more natural approach to creating static content JSP pages are also designed to provide dynamic content. JSP is designed to provide a declarative, presentation-centric method to develop Servlets.

JSP technology offers the ability to rapidly develop Web pages where content and display logic are separated, and reuse the code through a component-based architecture. JSP technology provides an option to develop the Servlet-based dynamic content. JSP pages have the additional benefit of separating content and display logic. Developers can independently update the content and application logic with specific expertise in each area. JSTL and JSF JSP requires two more components to be the complete Web application development technology JSTL (JSP Tag Library) and JSF. JSTL is a set or library used by JSP for implementing JSTL tags whereas the JSF technology is a framework to build user interfaces for Web applications. JSF, with well-defined programming model, enable developers to quickly and easily build Web applications by using reusable Ul components in a page. JSF helps in connecting the Ul components to an application data source, and wiring clientgenerated events to Server-side event handlers. JSFs give the power to Web applications to manage all the complexities of creating a Ul on the server and allowing you to focus on application code. 6-d EJB centric web application. [5 Marks] See Jun 2010 paper solution Q6-b. Describe any two frameworks supported by JEE 5. [10 Marks] See Jun 2010 paper solution Q6-a. State the steps for packaging and deployment of midlet. [10 Marks] MIDlets are deployed in MIDlet suites. A MIDlet suite is a collection of MIDlets with some extra information. There are two files involved. 1. One is an application descriptor, which is a simple text file. 2. The other is a JAR (java archive) file that contains the class files and resource files (images and other files) that make up your MIDlet suite. Like any JAR file, a MIDlet suites JAR file has a manifest file.

7-a

7-b Ans.

Figure 6.2 Structure of a MIDlet suite Packaging a MIDlet suite consists of three steps: 1. The class files and resource files that make up the MIDlets are packaged into a JAR file. Usually, youll use the jar command-line tool to accomplish this. 2. Additional information thats needed at runtime is placed in the JARs manifest file. All JARs include a manifest; a MIDlet suite JAR contains some extra information needed

by AMS. 3. An application descriptor file should also be generated. This is a file with a .jad extension that describes the MIDlet suite JAR. It can be used by the AMS to decide whether a MIDlet suite JAR should be downloaded to the device. MIDlet Manifest Information The information stored in a MIDlets manifest file consists of name and value pairs, like a properties file. The following attributes must be included: 1. MIDlet-Name: This attribute actually refers to the name of the entire MIDlet suite, not just one MIDlet. 2. MIDlet-Version: This describes the version of the MIDlet suite. Its a number you pick yourself in the form major.minor.micro 3. MIDlet-Vendor: This is your name or the name of your company. 4. MIDlet-n: For each MIDlet in the MIDlet suite, the displayable name, icon file name, and class name are listed. The MIDlets must be numbered starting from 1 and counting up 5. MicroEdition-Configuration: This attribute describes the J2ME configurations upon which this MIDlet suite can run. Multiple configuration names should be separated by spaces. 6. MicroEdition-Profile: This describes the set of profiles upon which this MIDlet suite can run. For MIDP 2.0 applications, this is MIDP-2.0. For applications that can also run on the older MIDP 1.0 profile, use MIDP-2.0 MIDP-1.0. Application Descriptor The attributes in a MIDlet suite JAR are used by the AMS to run MIDlets within a suite. The application descriptor, by contrast, contains information that helps a device and/or the user decides whether or not to load a MIDlet suite. Because an application descriptor is a file separate from the MIDlet suite JAR, it is easy for a device to load and examine the file before downloading the MIDlet suite. As it happens, a lot of the information in the application descriptor has to be the same as the information thats in the MIDlet suite JAR. For example, the application descriptor must contain the MIDlet-Name, MIDlet-Version, and MIDlet-Vendor attributes. In addition, it must include the following: MIDlet-Jar-URL: This is the URL where the MIDlet suite JAR can be found. MIDlet-Jar-Size: This is the size, in bytes, of the MIDlet suite JAR. The application descriptor is useful in over the air (OTA) deployment. A device (and the user) can download and inspect the descriptor, a relatively short file, before deciding whether the entire MIDlet suite JAR should be downloaded and installed. Deployment of midlet There are two possibilities: either youll transfer MIDlet suites to the phone from your computer via an external connection (can be serial cable, USB cable, IRDA, Bluetooth, etc. depending on the device manufacturer) , or youll transfer MIDlet suites over the wireless network. This second possibility is called over the air (OTA) provisioning.