|
|
|
|
| |
This section includes the following topics:
Requests from mobile clients are routed through the WAP Gateway to WebLogic Server in the form of HTTP requests. WebLogic server can respond to HTTP request by serving static files or HTTP Servlets written as Java Servlets or JavaServer Pages (JSP). For WAP applications, static files will typically be WML files while servlets and JSPs will be used to generate WML dynamically.
The phonebook example in the samples/examples/wap subdirectory of your WebLogic distribution demonstrates serving up a static WML file by placing the file into the document root and requesting the file's URL from a mobile client. The WML file presents options to the user for looking up phone numbers via the select element as shown below.
Listing 2-1 phone.wml from samples/examples/wap/phoneBook
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<!-- Copyright (c) 2000 by BEA Systems, Inc.
All Rights Reserved. -->
<wml>
<card id="card1" title="Phone Book" newcontext="true">
<p>
Name:
<select name="name" value="" title="Name">
<option value="">All</option>
<option value="John">John</option>
<option value="Paul">Paul</option>
<option value="George">George</option>
<option value="Ringo">Ringo</option>
</select>
</p>
<do type="accept" label="Get number">
<!-- Edit the URL below to point to the appropriate
hostname and listenport of your WebLogic Server -->
<go href="http://localhost:7001/phone?name=$(name:escape)"/>
</do>
</card>
</wml>
Based on the user's input, an HTTP request is made to PhoneServlet and a query parameter (name) is added to the servlet's URL. In this example, PhoneServlet is an existing servlet example that generates an HTML response. The HTML response is then converted to WML by the WAP Gateway before forwarding the response to the mobile client. Using the WAP Gateway to automatically translate HTML to WML is fine for demonstration purposes, however it is strongly encouraged to generate WML directly since WML is designed to address the display limitations of most WAP devices. See the Application Design Considerations section for additional information.
The "date" example in the samples/examples/wap subdirectory of your WebLogic distribution demonstrates generating a WML document from a JSP. When Date.jsp is accessed by the mobile client, the page determines the current date and time and returns the results in a WML document as shown below.
Listing 2-2 Date.jsp from samples/examples/wap/date
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<!-- Copyright (c) 2000 by BEA Systems, Inc.
All Rights Reserved. -->
<!-- set document type to WML -->
<%@ page contentType="text/vnd.wap.wml" %>
<wml>
<template>
<do type="prev" label="back">
<prev/>
</do>
</template>
<card title="WML DATE EXAMPLE" id="frstcard">
<p>
<small>The current date is:
<br/>
<%= new Date() %>
<br/>
Copyright © 1999-2000 by BEA Systems, Inc.
All Rights Reserved.</small>
</p>
</card>
</wml>
As shown in the code above, the line that sets the page's contentType to text/vnd.wap.wml is required whenever you are generating WML directly from a JSP or servlet. This line sets the MIME type of the generated document to the WML MIME type. Without this line, the MIME type will default to the HTML MIME type and the WAP Gateway will attempt to translate the document into WML with unfavorable results.
WML is based on XML. Refer to Programming WebLogic XML for additional examples of generating XML from within WebLogic Server.
To run a WAP application on WebLogic Server, you must specify the MIME types associated with WAP in the web.xml file of the web application. The MIME type is defined by the mime-mapping deployment descriptor element. For information on creating and editing a web.xml file, see the Writing Web Application Deployment Descriptors section. (In earlier versions of WebLogic Server, MIME types were defined on each server, as server properties. The new method of defining MIME types within the web application is consistent with the Java Servlet Specification 2.2 published by Sun Microsystems, Inc.)
Table 2-1 shows the MIME types required for WAP applications
Table 2-1 MIME Type Definitions for WAP Applications
When developing a WAP application, you must consider the limitations of mobile devices and determine the most efficient and flexible way to provide suitable content. This section discusses some of these considerations.
Most mobile devices have extremely simple user interfaces. WML and WMLScript were specifically designed to address these limitations. While some WAP Gateways have the ability to automatically translate HTML to WML, in practice, it is encouraged to generate WML directly and tailor the interface to the specific needs of the wireless user. Developing a corresponding WML front-end leverages the previous engineering effort to develop the business logic and content of your application, while providing significant user interface benefits.
Because of the limited real estate of graphical displays on most WAP-enabled devices, it is often desirable to allow users to customize the application offering to allow them to see only those services that they are interested in. Tools such as Personalization are well suited for providing this sort of flexibility in your application.
Most WAP devices have little memory. When grouping WML cards into WML decks, you should be aware that a deck is the smallest download unit. In other words, information is downloaded to a mobile client in decks, not cards. Because of the memory limitations, it is highly recommended to avoid decks with large amounts of cards.
Supporting Multiple Client Types
Typically, a WAP application is an extension of an existing HTML browser-based application. The back-end functionality should not require modification in offering the same services to mobile clients. Instead, a corresponding WML front-end can be developed to leverage the same back-end functionality.
There are two strategies for handling both HTML and WML client types. There can be separate URLs for HTML and WML entry points, or a single URL can be used which will generate content according to the browser type of the requestor. The browser type can be determined by examining the User-Agent request header of an HTTP request. See the SnoopServlet example included in the examples/servlets subdirectory of your WebLogic distribution for an example of accessing this type of header information.
A similar strategy can be used, if the developer whishes to take advantage of the different features and display sizes of the different WAP-enabled devices available on the market. The display sizes of WAP-enabled devices currently ranges from four lines of text to about eight lines of text (although this is likely to change dramatically in the near future). By examining the browser type of the client, an application can use the extra graphical real estate only when it is available. Obviously, the simplest method is to create content suitable for the lowest common denominator (four lines).
The future direction is the usage of XSL (eXtensible Style Language). An application can have JSPs and servlets generate XML. An XSL style sheet can then transform the content to into HTML or WML depending on the browser. See Programming WebLogic XML for additional information on XSL.
Session tracking is useful to keep track of a user's progress over multiple servlets or pages. As described in Programming WebLogic HTTP Servlets, tracking is accomplished by storing session data in a javax.servlet.http.HttpSession object that can be retrieved given the session ID. The session ID is typically stored in a cookie that is set in the client. However, WAP does not support cookies.
One alternative is to use URL rewriting which causes the session ID to be encoded into hyperlinks on the page that your servlet sends back to the browser. The session ID is then retrieved from the URL parameters when the link is activated. However, the length of the session ID (to ensure secure sessions with a uniformly random distribution, it is necessary for session IDs to contain a certain number of characters) can cause problems for WAP-enabled devices because many devices limit URLs to 128 characters.
There are two ways to limit the length of the session ID:
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|