基于java构建wap程序

WAP builds Java applications Take advantage of your existing EJBs to power a mobile workforce

Document options Print this page E-mail this page Sample code New site feature Kick-start your Java apps Rate this page Help us improve this content Level: Introductory Aashish Patil (ash01@vsnl.net), M.S. candidate, Computer Science department, University of Southern California 01 Jul 2001 If your company already relies on multitiered enterprise Java applications, then you may be closer to a wireless future than you think. By outlining a sample application, Aashish Patil shows you how to connect your existing enterprise Java infrastructure to a wireless netowrk with minimal investment in equipment and labor. Using existing EJBs, modified servlets, and new WML and WMLScript pages makes the process a snap. The Wireless Application Protocol (WAP) can add value to the existing Web architecture of an enterprise. If you are already using enterprise Java applications, you can easily integrate them with WAP services to bring useful data and functionality to a mobile workforce. In this article, I will cover the basics of using J2EE with WAP and then build a sample WAP/enterprise Java application that demonstrates how you can connect your own EJBs to a wireless network. Background: J2EE and WAP You should have a basic understanding of the Java 2 Platform, Enterprise Edition (J2EE) architecture before reading this article. You can find links to more information on J2EE in the Resources section below. As a refresher, here's a diagram of a typical J2EE application designed with a desktop client in mind: Figure 1. J2EE application structure In Figure 1, the layer containing the JavaServer Pages (JSPs) and servlets is responsible for the generation of dynamic HTML pages. In WAP applications, this layer would generate dynamic Wireless Markup Language (WML) pages instead. Thus, in order to alter a standard J2EE app for use with mobile devices, you will have to write new JSPs and, in some cases, new servlets. The Enterprise JavaBeans (EJBs) will be left untouched, since they are not concerned with presentation of data. What is WML? Just as Web browsers display data encoded in HTML, WAP-enabled devices display data encoded in Wireless Markup Language (WML); and, just as Web developers can use JavaScript to embed scripting functionality into Web pages, device developers can use WMLScript to embed the same kind of functionality into WML pages. WML is a subset of XML and will look familiar to anyone versed in HTML or other markup languages. One unique feature of WML to keep in mind is that of a deck of cards; while a single HTML document displays as a single Web document, a single WML document can contain multiple cards. The WAP device screen will only display a single card at a time. Some WML and WMLScript links are available in the Resources section below. Some would argue that the servlets do not need to be changed, either: a simple redirection of their output to JSPs generating dynamic WML pages should be sufficient. However, a servlet cannot differentiate between requests coming from desktop computers and requests coming from WAP devices; since WAP applications may not implement all the functionality of a Web-based architecture, it is important that there be no confusion in this regard. Hence, developers usually design new servlets for WAP applications. However, these servlets will, in most cases, be very similar to servlets that provide similar functionality over a Web-based architecture. Another component that does not appear in Figure 1 but is crucial to WAP applications is a WAP gateway. This component is responsible for conversions from the WAP stack to the Internet stack and vice versa. Figure 2 is a revised version of Figure 1, showing the structure for a J2EE application with a WAP device as a client: Figure 2. WAP/J2EE application structure As noted, all requests to the Web server from a WAP client must be routed through a WAP gateway. Although a WAP gateway can also act as a WAP server by hosting WML/WMLScript pages, it is more convenient to host these on the Web server. There are many deployment scenarios for the WAP gateway. For most WAP applications, the gateway is either deployed by the ISP or by the company hosting the application. The latter scenario is the more secure choice, as we'll see later; however, if users want general-purpose network access on their WAP devices, an internal WAP gateway can be an inconvenience. Most non-ISPs would not want their gateways to be used to access sites other than their own; hence, to visit other sites, users will have to use an ISP's gateway. But for every gateway used by the WAP client, the user has to define a different connection, just as one does in Windows 98's Dialup Networking -- and the number of such connections available on each device is usually limited. This adds inconvenience for the user and it also blocks a connection in a WAP device for access to a single site. Back to top WAP application design considerations A developer used to building J2EE apps for desktop clients will run into some new challenges when working with WAP. The following are some questions you might find yourself asking while building a WAP application. How many lines can I display on a screen? Actually, there is no specific limitation on the number of lines that can be displayed as long as the maximum deck size limit (which varies from device to device) is not exceeded. However, in order to avoid too much scrolling, five to seven lines per screen (i.e., card) is a good limit. What security issues should I consider? Some phones do not support the POST method of sending form data. Hence, a username and password must be sent by the GET method. At the WAP gateway, if the logging function is activated and if the request is logged, the administrator will be able to see the username and password. This would be particularly problematic if the gateway were hosted by an ISP or other third party. Even a secure connection does not completely eliminate insecurity. The data sent to the WAP gateway is encrypted using WTLS (Wireless Transport Layer Security), which uses the same algorithm as standard TLS. However, the data sent to the WAP gateway is binary encoded (for WAP), so the encrypted data must be decrypted and re-encrypted using TLS for the Internet. For some time, the sensitive data is in clear text on the WAP gateway. A hacker could perform a memory dump at the right time and then gain access to this sensitive data. As noted, one way to get around this problem is to have the WAP gateway at your own company's end instead of at the ISP's. In that case, a trusted person could handle the gateway and the logging function could be turned off. You could also use a custom encryption algorithm to encrypt the username and the password at the client end using WMLScript. This is possible only if you use simple algorithms; WMLScript is not powerful enough to support algorithms of the DES category. How can I maintain a session? WAP clients do not support cookies. Thus, in order to maintain information about the client on the server side as he navigates through the various pages of your site, a session ID must be passed as a parameter along with every request sent to the server. The parameter name for this session ID is different for different servlet engines. Sometimes, the default session ID length increases the length of each request considerably. As a result, the client or the WAP gateway may reject the request as a malformed URL. It is necessary to reduce the length of the session ID. See the documentation of the servlet engine that you are using for the parameter name of the session ID. If you are experiencing malformed URL errors, this documentation should also offer guidance on reducing the length of the session ID value. Back to top Building the sample application XYZ Ltd. manufactures PDAs, wearable computers, and other pervasive computing devices. The company's sales staff visits clients to offer live demonstrations of XYZ's products; for some of these demonstrations, salespeople must travel great distances to reach client sites. How will they receive client lists and other vital data while on the road? Using e-mail for this purpose would require bulky, expensive laptops or never-ending searches for Internet cafés; using fax machines at client sites would be even more impractical. Instead, XYZ's sales crew will receive their data via WAP-enabled devices, such as mobile phones or PDAs. Using a mobile device, the salesperson can provide immediate feedback to the company on the status of the client visit. The company could then arrange immediate delivery of goods to the client and maintain current sales statistics. Our application has two main goals. First, our mobile sales staff should be able to use it to view their client lists on their WAP devices. Second, if a client wishes to buy goods, then a salesperson should be able to place an order using the device. Furthermore, one of the important goals of any WAP application should be to reduce the number of keypresses that a user must make. Due to the limited nature of a handheld device's user interface, the amount of data that a user is asked to enter should be kept to a minimum. Here's a flow diagram showing the structure of our system: Figure 3. Application flow diagram Users first must log in to access the system; they can then view the client list and details about each client. If they wish to place an order for a particular client, then they are presented with an item list from which they can select a particular item for that client. For most of the remainder of this article, we will discuss the servlet and JSP code that drives this application. We'll examine the ways in which JSPs and servlets work together. The discussion of each JavaServer Page is accompanied by a graphic showing that JSP's output on a device screen. Listing 1, Login.jsp accepts a username and password and uses them as parameters to call the LoginServlet. For this and all other JSPs, MIME types should be set to be of type text/vnd.wap.wml. Login.jsp above also passes a parameter called SessionID with the request. This must be passed with every request sent to the server. The parameter name SessionID is a placeholder; refer to your application server documentation to find the correct parameter name for your particular app server. The Java method HttpServletResponse.encodeURL(String URL) automatically appends the session ID; this has been used within the servlets in our application extensively. Figure 4. PDA displaying login Validating blank input fields presents a problem. There is an attribute in the input tag which allows you to make an input field nonblank: <input name="name" type="text" emptyok="false"/> A mobile phone user must go to a separate input dialog screen to enter data. Our problem arises because the user may choose to go directly to the next deck or card rather than go to the input dialog screen and enter data in the field. A user confronted with the screen in Figure 4 may omit the password and tap Next. A developer could prevent this from happening by validating using WMLScript, using the onclick event. However, the variable representing the input field value that you pass to the WMLScript function is not initialized until you enter a value in the input box. Hence, with no password entered, the function is passed an uninitialized variable and a script error results. The solution to this problem is to validate all input fields on the server side. Listing 2, LoginServlet is the solution to our problem: it authenticates the salesperson and logs him into the system. It also creates a session for the salesperson on the server side. Comments in the code block above indicate the points at which these actions are performed. Upon a successful login, the device displays the main menu shown in Listing 3 (MainMenu.jsp). This file displays two links on the device screen, as shown in Figure 5. The second link ends the current session; the first leads to the current client list. In the current version of the program flow, the salesperson must select a client from the list before beginning any sales transaction; the list of sales items can only be reached from subsequent screens (the details are to follow). Other program flows are possible: for example, a link could be added to the main menu that sends the user directly to the item list. However, you should not to provide too many links on any one menu, as the small screens of WAP-enabled devices can easily become cluttered. Figure 5. PDA displaying main menu Tapping on View Clients on the menu screen in Figure 5 calls the ClientViewServlet in Listing 4, which extracts the list of clients that the salesperson is to visit. Comments in the code demonstrate how the servlet finds this information on the client side. The servlet then places this list in the session object and calls ClientList.jsp. (The session object referred to here and in the next section refers to the HttpSession class provided as part of the Java servlet package.) Listing 5, ClientList.jsp extracts the list of clients placed in the session by the ClientViewServlet; it displays the names of the clients, but not the complete details (see Figure 6). Upon selecting one of the clients, the salesperson is directed to ClientDetails.jsp. Figure 6. PDA displaying client list Note that the task of displaying of the client list into three separate components -- ClientViewServlet, ClientList.jsp, and ClientDetails.jsp. What are the reasons for this design? Most authorities on J2EE architecture recommend that JSPs should not directly access EJBs; intermediate components like servlets should interact with the EJBs instead. The ClientViewServlet accesses the EJB and obtains the list of clients. The application could have been designed so that all client details would be contained in a single WML document. In this architecture, the client list would be contained in one card of a WML deck and the details for individual clients would be contained in separate cards in the same deck. But this single WML document might contain too much data for a low-bandwidth WAP device to download at once. If the number of clients is high, the amount of data generated could easily exceed the maximum deck size permitted for a WML deck. (The maximum deck size varies from device to device; for the Nokia 7110 the maximum compiled deck size is 1.3 KB). Hence we used two JSPs: ClientList.jsp, for displaying the list of clients, and ClientDetails.jsp, for displaying the details of individual clients. Listing 6, ClientDetails.jsp accepts as a parameter an index into the array of clients, which is present in the session. It then extracts the details of the selected client and displays them. If the salesperson wishes to place an order for this client, he taps on the Items button. This invokes Listing 7, ItemListServlet and displays the items available for order. Figure 7. PDA displaying client detail Listing 7, ItemListServlet extracts the list of items that the salesperson can sell and places that list in the session. It then calls Listing 8, ItemList.jsp. Listing 8, ItemList.jsp extracts the list of items from the session and displays the item names. The salesperson can select an item to order and tap the Order button to invoke PlaceOrder.jsp. The index of the selected item in the array is sent as a parameter to Listing 9, PlaceOrder.jsp. Figure 8. PDA displaying item list PlaceOrderServlet obtains the salesperson, customer, and item IDs from the session. A new order is then placed by the creation of a new Order Entity EJB. The successful placement of an order displays an order ID and the time the order was placed. In this version of the application, the salesperson's only option after completing the transaction is to return to the main menu (see Figure 9). You could alter the code to send the user back to the client or item lists as well. Figure 9. PDA displaying transaction complete message If you've been paying attention, you noticed that the salesperson only enters data twice: when logging on and when entering the number of items to buy for the customer. Back to top About the code The attached files include all the JSP and servlet code included in this article as well as the necessary EJB code. The jar file of the EJBs is also included, along with the deployment descriptors. The screen shots are from Nokia's WAP Simulator 2.0. Back to top Conclusion As mentioned previously, a WAP application provides a very nice value-added service. A standalone WAP application is not a feasible idea. However, such an application can be easily incorporated into any existing Web application architecture without much monetary or labor investment. The only new hardware you'll need is a machine and software for the WAP gateway; if you are using your ISP's gateway, even this cost is eliminated. Existing HTML pages will need to be converted into WML. However, WML pages are not as complex as HTML since they do not support as many features as HTML pages. Hence, this is not a very time-consuming task. WAP also supports images in the Wireless BitMap (WBMP) format. However, a user using WAP services is paying considerably for connection time and is usually more interested in to-the-point and targeted information rather than beauty. Unless the images themselves convey information, it is much better to provide quick information than hog bandwidth and time transmitting graphics to the user. A final note: although a simulator provides a nice environment for testing WAP applications, a WAP application can be said to be completely tested only when it has been run on all possible target WAP devices along with the WAP gateway deployed. All dynamically generated pages are compiled at the gateway. Hence, it is necessary to find out which version of WAP the gateway supports. It is no use writing pages in WML 1.2 if the gateway compiler only works with WML 1.1. Back to top Download Description Name Size Download method Source code wi-entwapsource.zip 25 KB FTP Information about download methods Get Adobe® Reader® Back to top Resources Get an introduction to J2EE at Sun's Java developer connection (free registration required). "WAP Site Authoring" is a good introduction to WML and WMLScript. (developerWorks, May 2001) Find out more about WAP, WML, and WMLScript from the WAP Forum, the open, independent organization that maintains the WAP standard. IBM's Websphere Application Server can be used to run the application outlined in this article. Salmon and IBM bring enterprise Java technology to your wireless network. Return to the Wireless technology zone or the Java technology zone here on developerWorks for more Wireless and Java technology resources. Back to top About the author Aashish Patil recently received a bachelor's degree in computer engineering from Thadomal Shahani Engineering College in Mumbai, India. He completed a project on WAP-enabled stock trading as a trainee at Tata Consultancy Services; this article is a direct offshoot of this project. This fall, he will begin work on a master's degree in computer science at the University of Southern California. Contact Aashish at ash01@vsnl.net.