J2EE Application Servers Go Wireless
- Why Use an App Server?
- BEA WebLogic
- IBM WebSphere
- Oracle 9iAS
The most difficult aspect of wireless application development is not the wide variety of technologies involved or the limited bandwidth that most applications must work with. Instead, the real difficulty lies in designing and building an application that can support a large number of device types, content types, connectivity types, and network types without adversely affecting the application's scalability or maintainability. As an example, a large-scale wireless app may present the following requirements:
Device typesPalm OS PDAs, Pocket PC PDAs, WAP clients, SMS messaging clients, IVR (VoiceXML), laptops
Content typesHTML, WML, SMS, VoiceXML, XML
Connectivity types Messaging, connected (HTTP/WTP/etc.), disconnected (mobile sync solution)
Network typesWiFi, LAN (sync), CDMA, GSM, GPRS, CDPD, Mobitex, DataTAC
An application that requires all (or most) of the capabilities listed above would probably be targeted at the general public, not internal corporate users, and may be beyond the scope of anything you are responsible for. For instance, the requirements listed above would be relevant for the following types of apps:
Stock trading and associated financial services
Portal access to email, calendar, contacts, and so on
Subscription-based breaking newsfeed or sports scores
Mapping app with directions
Because of the diverse set of operating requirements, a scalable, component-based architecture is a must-have under these conditions.
Sun Microsystems' Java 2 Enterprise Edition (J2EE) is the leading server platform in use today. Microsoft's .NET is a remote yet rapidly advancing newcomer. Saving the topic of mobile .NET application development for another day, I'll focus on J2EE wireless application development in this article. Sun recently released the "Top Five Reasons to Choose J2EE," so you can visit that document for more info on the J2EE platform.
Why Use an App Server?
To begin, lest anyone think a point-and-click solution is in the future, you should know up front that a great deal of "real work" is involved with any of these products. A number of different approaches are used, but be prepared to exit the "open" world of J2EE portability and enter the world of vendor lock-in. Not that this is a bad thing (depending on the vendor), but any hopes of quickly moving your wireless app between application server products will be lost if you use any of the vendor-specific extensions. At some point, Sun may very well extend the J2EE specification to include support for wireless middleware and mobile content generation, but until then, the best wireless options are offerings from the J2EE market leaders: IBM, Oracle, and BEA.
To phrase it a bit differently, the J2EE platform (and application server product suites based on this platform) provides the infrastructure required of any mobile enterprise application. However, the specification itself does not in any way provide specific implementation details related to wireless applications. This is somewhat ironic, given Sun's focus on J2ME (Java 2 Micro Edition). However, suffice it to say that J2EE application server products provide all the services (component model, messaging, transaction management, clustering, security, and so on) that will be required of any intensive mobile application.
J2EE developers, then, generally have two choices when faced with building a large-scale mobile application:
Write the entire application targeting multiple mobile devices and environments yourself from scratch.
Utilize J2EE-based mobile tools developed by leading companies in the J2EE space.
Developers who choose option 1 usually opt to build a custom "transcoding" solution using Java servlets, XML, and XSL.
WhatIs.com defines transcoding as the following:
"Transcoding is a technology used to adapt computer application displays and Web content so that they can be viewed on any of the increasingly diverse devices on the market. Transcoding servers and services reformat material that would otherwise have to be developed separately for display on different platforms."
Assuming that you opt for choice 2, in this article I'll take a look at mobile offerings from three of the leading J2EE application server vendors (Oracle, IBM, and BEA). I'll also discuss the range of capabilities that each product brings to the market.