Leverage EJB to make mobile work groups strong

If your organization already relies on multi-tier enterprise Java applications, you may be closer to the future of wireless technology than you might think. By describing a sample application, Aashish Patil shows you how to connect your existing enterprise Java infrastructure components to a wireless network with minimal human resources. Using existing EJBS, modified Servlet, and new WML and WMLScript pages can make a leap in this process.

The Wireless Application protocol (Wireless application Protocol,wap) can improve the gold content of an enterprise's existing WEB architecture. If you have already used enterprise Java applications, you can easily integrate them with WAP services, which can bring useful data and functionality to mobile work groups. In this article, I'll cover the basics of using the WAP-related Java EE, and then create a wap/Enterprise Java-based sample application to show you how to connect your EJB to a wireless network.

Background: Java EE and WAP

Before reading this article, you should have a basic understanding of the Java 2 platform, the Enterprise Edition (EE) architecture. You can find links to more information about Java EE in the resources section below. As a review, here is a schematic diagram of a typical Java EE application designed for desktop clients.

Figure 1-J2EE Application Structure

In Figure 1, the layer that contains the JavaServer page (JSP) and the Servlet is responsible for generating dynamic HTML pages. In WAP applications, this layer generates a dynamic Wireless Markup Language (Wireless Markup Language, referred to as WML) page. Therefore, in order to convert a standard Java EE application to be used by mobile devices, you will have to write a new JSP and, in some cases, write a new Servlet. Enterprise JavaBean (EJBS) remain unchanged because they are independent of data performance.

Some people think that the servlet doesn't need to change, or that it's enough to simply redirect the servlet's output to the JSP that generates the dynamic WML page. However, the Servlet does not differentiate between the requests from the desktop and from the WAP device, and since the WAP application may not be able to implement all of the functionality of the web-based architecture, it is important that there is no confusion in this regard. Also because of this, developers typically design a new Servlet for WAP applications. In most cases, however, the servlet is very similar to a servlet that provides similar functionality on a web-based architecture.

Another component that does not appear in Figure 1 but that is important for WAP applications is the WAP gateway. This component is responsible for the mutual conversion between the WAP stack and the Internet stack.

Figure 2 is an improved version of Figure 1 that shows the structure of using WAP devices as Java EE applications for clients:

Figure 2-WAP/J2EE Structure of application

As shown, all requests from the WAP client to the WEB server must be sent through a WAP gateway. Although WAP gateways can also be used as WAP servers for placing Wml/wmlscript pages, it is more convenient to use WEB servers to place these pages.

There are many ways to deploy WAP gateways. For most WAP applications, gateways are deployed by ISPs or by companies that provide this application. The latter are more secure and we will explain later, however, an internal WAP gateway is inconvenient if users require multipurpose network access on their WAP devices. Most non-ISPs do not want their gateways to be used to access sites other than their own, so users will have to use an ISP gateway in order to access other sites. However, for each gateway used by WAP clients, users must define a different connection, as in Windows 98 dial-up networking-and on each device, the number of connections is usually limited. This increases the inconvenience of the user and causes the connection to be blocked in the WAP device when accessing a site.