14.1 Direct Access to Remote Databases

In the previous three chapters, we discussed the application architecture of the disconnected but synchronized mobile databases. Although that architecture is adequate for most mobile application scenarios, in some cases, direct connections to remote databases are still preferred or even required:

• Some applications depend on real-time backend data to function correctly. In theory, we can synchronize the databases as frequently as we wish to catch up with the real-time changes, but that would soon become too inefficient. For example, a salesperson might only need to look up the current availability of a specific product. There is no need to synchronize the entire product catalog. It is much better and more flexible to allow the application to query the backend database directly.

• Some devices, especially MIDP devices, do not have enough resources to support large on-device data sets.

• Legacy data on mainframe applications is available only remotely.

Fortunately, the wireless network intermittency and latency, which make always-connected applications impossible in consumer markets, are less a problem in the enterprise markets: Many enterprise users reside on company campus and have always-on, low latency connectivity through WiFi or other company-provided networks. Now, let's have a look at remote database access schemes.

14.1.1 Application-Specific Middleware

In many cases, direct database access only happens inside the middleware layer. The database component is invisible from the client side. The mobile client only needs to know how to integrate with the specific middleware application. This is the approach used in the iFeedBack and Smart Ticket examples. Since this approach is application specific, I suggest interested readers consult those examples to study how it is implemented.

14.1.2 Using JDBC

The JDBC API is a generic way to access relational databases over the network. Some J2ME JDBC implementations allow you to obtain a remote database connection object by supplying a remote URL to the connection factory method. IBM DB2 and Oracle JDBC drivers provide such remote access functionalities. Since JDBC is a well-documented technology, we will not discuss it in detail here. For a quick tutorial on JDBC.

14.1.3 Gateway Servlet

Mobile clients, especially MIDP clients that do not support JDBC, can rely on gateway servlets to access backend databases. A gateway servlet takes in a request from the client, queries the remote database, and then sends the data back to the client via HTTP. Commercial products that implement gateway servlets include Oracle9i J2ME SDK and Data Representation Simplicity XML transaction engine. In the rest of this chapter, we discuss how to use those two products to access generic SQL databases and legacy databases.

14.2 The Oracle J2ME SQL SDK

The Oracle J2ME SDK (beta) enables mobile clients to access backend databases through the Oracle9i Mobile Application Server. It works on all J2ME profiles. There are only four classes in the oracle.wireless.me.sql package: DriverManager, Connection, Statement, and ResultSet. Their use is very similar to that of their JDBC counterparts. Those classes contain only very simple and lightweight methods. For example the query results can be retrieved only as string objects.

The SDK connects to a special gateway servlet, J2MEJDBC. The backend database URL and authentication information are stored in the gateway servlet's configuration file. Oracle runs a demo servlet for public testing. A simple example of database query using the SDK is shown in Listing 14.1.

Listing 14.1. Usage of the Oracle J2ME SDK

// The example is adopted from the

// Oracle SDK example



// The Oracle test gateway servlet URL.

// The backend DB is configured in the servlet.

DriverManager.init("http://iasw.oracle.com/ptg/j2mejdbc");



// Obtain a connection

Connection con = DriverManager.getConnection();



String sql = "select table_name from user_tables";

// Create a new Statement object

Statement stmt = con.createStatement();

// Get the ResultSet from the sql query

ResultSet rs = stmt.executeQuery(sql);

// Go to the next record

rs.next();

// Get a field in the record

System.out.println(rs.getString(1));

14.3 Legacy Applications

For companies with a lot of data on legacy mainframe systems, any mobile commerce strategy requires remote access to the mainframes from either the mobile clients or mobile middleware. However, neither SQL nor JDBC works with mainframe systems. Legacy applications use proprietary wire protocols over TCP/IP raw sockets or even serial lines. We need to hire developers who understand the proprietary protocols and ask them to code the protocol library manually in Java. That is an expensive and slow process.

14.3.1 Screen Scraping

A relatively simple way to access legacy systems without messing with the proprietary wire protocols is to use a technique called screen scraping. It works as follows: A recorder (or a screen scraper) is a software agent that records every keystroke and all screen displays from a terminal during a period of time. With the recorder turned on, a mainframe user is asked to perform a certain task during an interactive session. The recorder then generates Java code to replicate the same process.

Now, let's have a look at the process the user goes through to search computer inventory in a legacy system. In the first screen (Figure 14.1), the system prompts the user for authentication credentials. In the second screen (Figure 14.2), the user enters the text string computer and the systems displays search results. You can use predefined keys (Ctrl-N, in this case) to scroll between pages.

 

The recorder records when and how to connect the server, send out the username/password combo, send out the query string, scroll result pages, and parse needed information from the formatted display screen. Then, it generates a Java stub method that returns search results when invoked with a query string and user credentials. In mobile applications, the stub can reside inside a gateway servlet that interacts with mobile clients through standard HTTP remote procedure call . We discuss this scenario in the next section.

14.4 Using Simplicity for Legacy Databases

Screen scraping relies on the recorder tool and code generator. Now, let's take a detour to check out the tool we are going to use: the Simplicity IDE (v1.5) from Data Representations.

The Simplicity IDE is an all-visual Rapid Application Development (RAD) tool. Many IDEs have visual builders for UI components, but Simplicity allows you to build application logic components through the drag-and-drop model as well. Simplicity is written entirely in Java and supports application development for both J2ME and part of J2EE (mostly gateway servlets for mobile clients). We use the Simplicity IDE to demonstrate how to integrate legacy back ends in your mobile enterprise solutions.

14.4.1 Simplicity Mobile

The central part of the Simplicity IDE is its visual composer. Figure 14.3 illustrates a fully assembled MIDP application in the Simplicity for Mobile Devices IDE. Besides nodes representing normal MIDlet life cycle methods, you should pay attention to two nodes Transactions and Display. Modules under those two nodes are dragged and dropped from modules palettes, which are also shown on the figure. One strength of the Simplicity IDE is that it provides a lot of preconfigured modules that we can directly use. There are roughly two kinds of modules.

 

• Modules such as TextBox and Form take care of the view logic. In this composer, Form presents application information to users using MIDP UI components; TextBox maps user input to internal variables. The view modules have functionalities similar to visual UI components found in other IDE RAD tools.

• The Transactions module is part of the business logic. It contains a micro XML parser and can talk with Simplicity Enterprise server via a proprietary XML protocol. It also has a built-in, configurable RMS cache for transactional data. The business logic modules are linked to the view logic modules through internal variables.

Now, we can use the Simplicity Enterprise IDE to build the gateway servlet for a demo legacy mainframe application. The gateway servlet contains a module that is designed to talk with the MIDlet's Transaction module.

14.4.2 Simplicity Enterprise Legacy Rejuvenation

Simplicity Enterprise is a separate IDE from Simplicity for Mobile Devices. Simplicity Enterprise runs its own built-in HTTP server and servlet engine for development. It also bundles a PointBase embedded database for internal use. The application composer in the Simplicity Enterprise IDE looks very similar to the one in Simplicity for Mobile Devices. Legacy Rejuvenation is a palette of enterprise modules that help us write legacy gateways. The legacy palette is shown in Figure 14.4.