Internet applications employ a three-tier architecture, with one or more data sources, a client browser, and a Web server. Wireless Internet applications are no different, except that the Web server is often replaced with or enhanced by a wireless application server. These servers extend the capabilities offered by standard application servers by adding support for wireless application development and deployment, usually based on J2EE technology. In many cases, the technology provided by a wireless application server vendor is installed onto existing application servers, such as those provided by BEA Systems, IBM, or Sybase.
Comparing J2EE application servers is beyond the scope of this book, but it is safe to say that performance, security, scalability, business logic management, component support, and enterprise data connectivity are among the features that you should consider when selecting an application server.
Every wireless application server vendor has its own list of features that the company markets as critical for a successful solution. That said, these features do not always coincide with the features required by the typical wireless application developer. This section provides a summary of the core features that you can expect to find in any complete wireless application server implementation.
Note |
Do not confuse these offerings with WAP gateways. A WAP gateway is typically deployed at the wireless carrier site and does not have to be implemented by individual enterprises. It is responsible for the communication from a wireless device to the gateway using WAP, and then from the gateway to the enterprise server, using HTTP. That said, many of the features described here may also be supported by WAP gateways. |
In most cases, the wireless application server has to be able to work in harmony with the enterprise Web server. Corporations already have Web sites, and these should not be adversely affected when a wireless solution is implemented. To prevent this, request-handling proxies, or redirectors, can be installed on your existing Web server. These proxies enable desktop Web requests to be handled by the existing Web server infrastructure and to forward requests from wireless devices to the wireless application server. These capabilities provide the following benefits:
You can maintain the same URL for all Internet clients, wireless or otherwise.
You can maintain the same Web server and firewall configurations.
It can provide load-balancing capabilities for your wireless clients, improving scalability and performance.
Content that looks great on a Pocket PC device may not be at all suitable for a WAP phone, and vice versa. With so many microbrowsers and devices on the market, it is important that content can be delivered in a customized format. Ideally, this can be accomplished without having to write a new version of the application for every browser/device combination you require. The concept behind content transformation (often called transcoding) is to be able to reuse existing content, such as that from an HTML Web site, for wireless clients. There are many ways to accomplish this, with varying degrees of effort and overall effectiveness. If you are going to be deploying to many wireless browsers, you will want to evaluate the content-transformation techniques that are provided by the vendor you select. Keep in mind that if it looks too good to be true, it probably is.
In order to provide customized content for specific microbrowsers, you need a way to identify them. The most common way is by viewing the UserAgent that is part of the HTTP request header. The UserAgent will typically identify the microbrowser in use, along with its version number. Once you know this information, you can obtain the properties of that specific browser and format your content accordingly. Some products also keep a repository of microbrowser information, so you do not have to do this research yourself.
In addition to the UserAgent, the HTTP header can also provide you with much more information about the device itself, including the preferred language (for example, English or Japanese), whether cookies are supported, the maximum packet size for the device, and supported MIME types.
Another way to determine a device's capabilities is by using Composite Capabilities/Preferences Profile (CC/PP). CC/PP is a collection of the capabilities and preferences of any client that accesses the World Wide Web. It contains information about the hardware platform, system software, and any applications used by the user. In addition, it can also contain information about individual user preferences, allowing for very customized content delivery. (For more information on CC/PP, visit the W3C site at www.w3.org/Mobile/CCPP.)
To be effective, wireless Internet applications require dynamic content. This may include real-time weather information, stock quotes, or business-related data such as price lists and inventory levels. Wireless application servers will typically support Java servlets, JSPs, ASPs, or XML and XSL to provide this capability. The best wireless Internet applications provide dynamic data personalized for the current user and customized for the microbrowser and device they are using. (Chapter 13 covers the leading content-generation techniques, using code examples.)
Most wireless microbrowsers on the market do not provide client-side session management capabilities. To understand the impact for Internet applications, turn off cookie support in your Netscape or Internet Explorer browser and visit your favorite Web sites. You will quickly see just how important this capability is. You will lose the ability to store valuable information on the client for user authentication and personalization. As well, information gathered on one page will not be available on another.
To overcome this limitation, wireless application servers maintain session information on the server. This is usually accomplished in one of two ways: URL rewriting or persistent cookies. URL rewriting works by appending a unique session ID to the end of the URL to identify users as they move from page to page. This approach should only be used where there is no client support for cookies. Persistent cookies allow for the server to maintain session information, such as username, preferences, and application variables in a global object on the server. This information is available until the user logs off or until the session times out. This provides a convenient way to maintain a session even when the user device is temporarily disconnected from the network. When users reconnect, they can reestablish their session and continue where they left off.
Note |
Many wireless clients, such as WAP phones, do not store cookies on the device, but still allow for sessions to be managed using cookies. This is possible because the WAP gateway stores cookies on behalf of the client and adds the cookies to any HTTP request made for that client. |
The ability to access enterprise data is crucial for any m-business application. Wireless application server products should provide at least standard database access using JDBC, ODBC, or native database drivers. In addition, a way to interact with packaged enterprise resource planning (ERP), customer resource management (CRM), and supply chain applications is also very useful. Very often, this level of integration is provided using a prebuilt custom adapter that is created in the component model supported by the server.
Another level of enterprise integration that is growing in importance is the ability to integrate with Web services and to create your own Web services. All of the leading software vendors, including Microsoft, Oracle, Sybase, Sun Microsystems, and BEA Systems, are big backers of Web services. With this level of corporate support, Web services will soon be inherent to all forms of enterprise applications. (An overview of Web services is provided in Chapter 18, "Other Useful Technologies.")
Messaging capabilities are also of growing importance for wireless applications development. Technologies such as WAP Push, HDML notifications, Short Message Service (SMS), and instant messaging (IM) can help to improve the effectiveness of wireless Internet applications. Selecting a server that allows you to incorporate these protocols into your application will prove to be beneficial. (Complete information on mobile and wireless messaging systems is provided in Chapter 5.)
Wireless devices typically connect to the enterprise using public carrier networks. This means that sensitive enterprise data could be traveling over inherently insecure lines. For this reason, it is important to have a complete suite of security capabilities that will prevent the data from being observed or altered by unauthorized users.
To make sure you know who is accessing the server applications, user authentication capabilities have to be included in the solution. This can range from a simple username and password combination to a more complex (and more secure) solution using digital signatures. Once a user is authenticated, authorization can be implemented using access control lists (ACLs). ACLs provide a way to control to which data and logic a user has access.
To prevent unauthorized access to your data, public key cryptography solutions such as SSL/TLS or WTLS are required. It is essential that the wireless application server you select have support for these technologies. Finally, the overall solution should be able to work within the firewall environment you have in place, ideally without having to add a new entry point into the system. (Complete information on mobile and wireless security is provided in Chapter 6, "Mobile and Wireless Security.")
As more applications are deployed, and as more users start to take advantage of those applications, the scalability of the platform becomes increasingly important. To meet these growing needs, select a product that has strong performance and that can scale without having to adapt a new architecture. This often can be accomplished using clustering technology, wherein many servers work together as a single unit. When a request comes in to the cluster, it is allocated to a particular server. This capability is referred to as load balancing. Load balancing provides a way to evenly distribute the number of users across the number of servers in a cluster to maximize performance. Many possible algorithms can be used to distribute the load, ranging from round robin to weighted distributions that are based on each server's processing power.
This category is self-explanatory. There are many server-side operating systems currently in use. Most vendors usually classify them into two broad categories: Windows and UNIX. On the Windows side, support for Windows NT, 2000, and XP is required. On the UNIX side, the most common OS supported is Solaris, although Linux support is spreading. In some cases, vendors will also provide support for HP-UX, AIX, among others. (The issue of client-side operating system support was covered earlier in this chapter in the section on microbrowsers.)
A development tool is not a core requirement for a wireless application server, but it will definitely improve productivity. This is especially true if the developer is new to the technologies being used. A number of features are useful to have in a development tool, including support for drag-and-drop client-side development, support for multiple markup languages, built-in device emulators, and application server integration. Not all of these features are required for every application, but they are useful to have if the need arises. The topic of development tools is covered in more depth later in this chapter.
The list of vendors that offer wireless application servers is in a constant state of change. During the height of the wireless explosion in 2000, there were easily 50 vendors that could be listed in this category. Two years later, the list is considerably shorter, with approximately 10 leading vendors and a handful of challengers. It is expected that this list will continue to change as the industry matures and consolidation continues.
One of the most interesting things about this vendor list is the similarity—or perceived similarity—of the offerings. Commentary is ongoing regarding the similarities between the product data sheets and whitepapers produced by these vendors. When you go beyond the marketing, you will discover that each vendor has many unique features and unique opinions on how wireless Internet applications should be developed. To do these products justice, each one would require its own chapter in this book. Since that is not feasible, each product is listed in Table 14.1, with a URL where you can go to find more information. With the rapid change being experienced in the wireless industry, vendor Web sites are often the best source for up-to-date information.
VENDOR |
PRODUCT NAME |
PRODUCT URL |
---|---|---|
Aether |
Aether Fusion |
www.aethersystems.com |
Air2Web |
Mobile Internet Platform |
www.air2web.com |
AvantGo |
AvantGo M-Business Server |
http://avantgo.com/products/mbus_server_app.html |
Broadbeam |
Broadbeam Mobile Solutions System |
www.broadbeam.com/products/mobile_platform.asp |
Covigo |
Covigo Platform |
www.covigo.com/products |
Everypath |
Everypath Server |
www.everypath.com/products/server.shtml |
Extended Systems |
Mobile Solutions Platform |
www.extendedsystems.com |
iAnywhere Solutions |
iAnywhere M-Business Studio Server and Message Anywhere Studio |
www.sybase.com/products/mobilewireless |
IBM |
Websphere Transcoding Publisher |
http://www-3.ibm.com/software/pervasive/products/ |
iConverse |
Mobility Platform |
www.iconverse.com/products/platform.asp |
Microsoft |
Mobile Information Server |
www.microsoft.com/miserver/default.asp |
Oracle |
Oracle 9i Application Server |
www.oracle.com/ip/deploy/ias/mobile/index.html |
724 Solutions |
724 Solutions |
www.724solutions.com/products/platform.asp |
For vendors that have mobile platform offerings, the wireless application server is only one component of the overall solution. When making a decision as to which vendor is best for your needs, it is recommended that you look at the entire platform, since many components of the platform will provide value to your mobile solution.
There is no clear leader in this market, so the companies are listed in alphabetic order.