|
|
|
Using Wireless Application Protocol (WAP) with WebLogic Server
Wireless Application Environment (WAE)
Wireless Markup Language (WML)
Application design considerations
Supporting multiple client types
Overview
Wireless Application Protocol (WAP) is a set of protocols that allow for the development of Internet and Web-based services for mobile phones and other mobile devices. The WAP standard was developed by the WAP Forum whose founding members include Ericsson, Motorola, Nokia and Phone.com and addresses the limitations of mobile networks (low bandwidth, high latency, and unpredictable availability and stability) and mobile devices (limited CPU, memory, and battery life, and a simple user interface). The WAP Forum has developed their standards in such a way that they leverage and compliment existing industry standards as much as possible. The WAP standard specifies two essential elements of wireless communication: an end-to-end application protocol and an application environment, the Wireless Application Environment (WAE), based on a browser.
There are a number of products currently available that implement the end-to-end application protocol for WAP. These products, called WAP Gateways, form the connection between clients on the mobile network and applications hosted on application servers on the Internet. The WAP Gateway builds a bridge between the telecommunication and computer networks by routing requests from mobile clients to the application servers. It can be physically located in either network, though it is needed in only one of them.
This document discusses how to provide content that is suitable for WAE and how to configure and use WebLogic Server with a WAP Gateway. For general information on WAP technologies see Additional resources.
Wireless Application Environment (WAE)
WAE defines the framework for network-neutral, wireless applications for narrow-band devices. Two of the main components of WAE are Wireless Markup Language (WML) and WMLScript (WMLS).
Wireless Markup Language (WML)
WML is analogous to HTML for HTTP applications. It is an XML-based language that is specifically designed to interface with the micro-browsers that exist in WAP-enabled devices. The Wireless Markup Language Specification defines the tags and structure of a WML document.
A WML document is a collection of one or more cards. Each card is considered a well defined unit of interaction. The general rule of thumb is that a card carries enough information to fit in one screen of a mobile device. One or more cards can be logically grouped into a deck of cards. See Generating WML for information on ways to serve WML documents to mobile clients. For general information on WML, see Additional resources.
WMLScript (WMLS)
WMLScript provides general scripting capability to the WAP architecture. It is designed to overcome the limitations of narrowband communication and mobile clients. While many of the services that can be used with small mobile clients can be implemented with WML, the human behavioral compatibility of scripting improves the standard browsing and presentation facilities of WML. WMLScript resides in .wmls files that can be made available to mobile clients by placing them into the document root. The document root is the root directory for files that are publicly available on WebLogic Server. For more information, see Setting up a document root. For general information on WMLScript, refer to Additional resources.
Generating WML
Requests from mobile clients are routed through the WAP Gateway to WebLogic Server in the form of HTTP requests. As described in Setting up WebLogic Server as an HTTP server, 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 generated WML dynamically.
The "phonebook" example in the 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 1-1 phone.wml from 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 encourage to generate WML directly since WML is designed to address the display limitations of most WAP devices. See Application design considerations for additional information.
The "date" example in the 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 1-2 Date.jsp from 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 Using XML with WebLogic Server for additional examples of generating XML from within WebLogic Server.
Configuring WebLogic Server
To run a WAP application on WebLogic Server, you must configure the MIME types associated with WAP in the weblogic.properties file as shown below.
weblogic.httpd.mimeType.text/vnd.wap.wml=wml
weblogic.httpd.mimeType.text/vnd.wap.wmlscript=wmls
weblogic.httpd.mimeType.application/vnd.wap.wmlc=wmlc
weblogic.httpd.mimeType.application/vnd.wap.wmlscriptc=wmlsc
weblogic.httpd.mimeType.image/vnd.wap.wbmp=wbmp
The weblogic.properties file has the above MIME types configured by default.
The WAP Gateway
The WAP Gateway acts as the bridge between the mobile network containing mobile clients and the computer network containing application servers as shown below.
Figure 1-1 WAP application architecture
A WAP Gateway typically includes the following functionality:
When a mobile client sends a request to your WAP application running on WebLogic Server, the request is first routed through the WAP Gateway where it is decoded, translated to HTTP, then forwarded to the appropriate URL. The response is then re-routed back through the gateway, translated to WAP, encoded, and forward to the mobile client. This proxy architecture allows application developers to build services that are network and terminal independent.
There is a growing number of vendors that provide WAP Gateways. WebLogic Server should work with any WAP-compliant Gateway. For a current list of WAP-compliant Gateways and other WAP products, refer to the WAP Deployment Fact Sheet compiled by the WAP Forum.
Application design considerations
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.
Simple user interfaces
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.
Limited memory
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 suggested 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 Using XML with WebLogic Server for additional information on XSL.
Session tracking
Session tracking is useful to keep track of a user's progress over multiple servlets or pages. As described in Using 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 hyper-links on the page that your servlet sends back to the browser. The session ID is then retrieved when 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.
A better alternative is to include a WML postfield element containing the session ID along with any WML go element. In WML, the go element indicates navigation to a URL. The go element may contain one or more postfield elements. These elements specify information to be submitted to the origin server during the request. In the example WML code (with scriptlet) below, the session ID is obtained from the session and used to set the value of the WebLogicSession postfield.
<go href="index.jsp" method="post">
<postfield name="WeblogicSession" value="<%= session.getId() %>"/>
</go>
The code above will cause an HTTP POST to the URL index.jsp with a message entity containing WebLogicSession=sessionID where sessionID is the ID obtained from the session.getId() call. From within index.jsp, the session ID can then be obtained by getting the parameter from the HTTP request with the call request.getParameter("WebLogicSession").
Additional resources
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|