- Limited Device Hardware
- Slow, Unreliable Networks
- Pervasive Devices
- Ubiquitous Integration
- The Impatient User
- Summary
- Resources
This chapter is from the book
This chapter is from the book
This chapter is from the book
7.2 Slow, Unreliable Networks
Unlike always-on broadband networks for desktop and server computers, wireless networks have proven to be very slow, unreliable, and insecure. Developers from the PC world, especially those who used to develop server-based with thin client solutions, tend to make excessive use of the network. In this section, we discuss ways to make the best use of network resources.
The Shortest Migration Path from Thin Clients to Smart Clients
In the mircobrowser-based thin client scenario, the client delegates all application logic to the portal server. The portal aggregates a variety of content sources (e.g., database, XML, RSS, SMTP) and automatically generates a view format that fits the device characteristics. For example, the portal can generate HTML for a PDA, WML for a cell phone, and even VoiceXML for a voice caller with the help of voice recognition and synthesis engines.
The shortest migration path from the thin client paradigm to smart client paradigm is through adding J2ME-specific interfaces to existing thin client portals. For starters, we can add new view adaptors to the portal. For example, the portal can generate XUL (XML UI Language) UIs for J2ME devices with XUL rendering libraries (e.g., Thinlet). This way, we can support new smart devices through the existing infrastructure while phasing out old thin client devices. The voice portal server can also be utilized to support multimodal mobile applications for even richer user experiences.
7.2.1 Support the Offline Mode
As we discussed in Chapter 3, one of the most important advantages of the smart client paradigm is the ability to support offline operations when the network connection is temporarily unavailable. The key enabling technology is on-device persistence storage (cache). Other advantages of the on-device cache include reduced network round trips and improved performance.
Offline operations require careful design of the data model. On-device cache can be used explicitly by the application developer or can be built into the framework and become transparently available to applications. Examples of both approaches are illustrated in the iFeedBack (Chapter 3) and Smart Ticket (Chapter 5 sample applications. For simple caches, the application-managed MIDP RMS stores, plain files, or XML documents are adequate. For more sophisticated data management solutions, we can use on-device relational data stores. For backend powered applications, we also need to keep the cache synchronized with backend data sources. Simple synchronization logic can be programmed into the application itself. Commercial mobile databases often come with advanced synchronization solutions.
For more discussions on the "occasionally connected" architecture and related tools, please refer to Part IV, "Mobile Databases and Synchronization Engines," of this book (Chapters 11, 12 and 13).
7.2.2 Use Remote Facades
As described in Chapter 5, Section 5.3.3, remote facade is an effective pattern to have the best of two worlds: fine-grained object model at the server side and coarse-grained access interface for improved network efficiency. Another excellent example of remote facade is the Axis-based MapPoint facade gateway described in Chapter 18, Section 18.2.3.
7.2.3 Place Portals Locally
Mobile portals are essential components in enterprise mobile architectures. However, fixed portals residing in remote data centers are often not accessible from the national mobile networks due to limited coverage and unreliable connections.
Compared with wide area networks, local wireless networks often have better coverage, lower bandwidth cost, higher speed and better security. Mobile portals that reside on the local wireless networks boost the performance and availability of the client devices. Examples of such mobile portals include OSGi service gateways (Chapter 4, Section 4.5), and IBM WebSphere MQe (Chapter 10, Section 10.4). In practice, we can build a mobile application architecture that contains a hierarchical structure of hubs and portals. Each portal handles part of the logic and delegates the rest to the next layer. That allows us to build an enterprise mobile architecture that continues to function with limited capabilities in different levels of network failures. Figure 7.1 illustrates the mobile portal network architecture discussed in this chapter.
)
Figure 7.1. Mobile portal networks for small clients.
7.2.4 Buffered I/O
Reading network data byte by byte is very slow. We should always read and write data in chunks. In Personal Profile applications, we can use the JDK's standard BufferedReader and BufferedWriter. In MIDP applications, we need to buffer the I/O ourselves (Listing 7.1).
Listing 7.1. The buffered input in MIDP
HttpConnection conn = (HttpConnection) Connector.open(url);
conn.setRequestMethod(HttpConnection.GET);
DataInputStream din = conn.openDataInputStream();
ByteArrayOutputStream bos = new ByteArrayOutputStream();
byte[] buf = new byte[256];
while (true) {
int rd = din.read(buf, 0, 256);
if (rd == -1) break;
bos.write(buf, 0, rd);
}
bos.flush();
buf = bos.toByteArray();
// byte array buf now contains the downloaded data
7.2.5 Encrypt Your Data
Wireless networks broadcast data traffic into the air. Anyone can drop in and intercept the traffic. Built-in security for most wireless networks is not adequate for enterprise applications. The use of HTTPS (see Chapter 6, Section 6.6) for confidential communication is strongly recommended. In Chapters 19 and 20, we discuss how to implement your own security solutions. Having said that, we must also understand that cryptography tasks are often CPU-intensive. Security comes at the cost of performance. For small devices, we must carefully evaluate the security requirements and come up with balanced solutions.
7.2.6 Obtain Server Status Efficiently
Many enterprise mobile applications, such as an Instant Messaging client or a database monitoring client, need to be updated with real-time server status at all times. Since the HTTP protocol is ubiquitously supported in all J2ME devices, inexperienced developers sometimes program the device to initiate periodic HTTP connections to poll the server for its status. The polling frequency must be much faster than the expected server status-change frequency to keep the device updated. The constant polling results in a lot of redundant data. It is a waste of bandwidth, server resources, and time. There are several ways to deal with this problem:
-
Use HTTP conditional GET: The HTTP conditional GET operation allows the server to return data only when the data source has been updated since the last query. An excellent description of the HTTP conditional GET and its usage can be found in a blog entry from Charles Miller (see the "Resources" section). This method reduces the amount of network data but does not reduce the frequency of the polling operation. In a long latency network, it could still be a performance bottleneck.
-
Use PUSH-based protocols: To completely fix the "excessive poll" problem, let the server notify the client when the server status is updated. We cannot use the HTTP protocol for this purpose, since HTTP is designed to be a stateless request/response protocol. HTTP connections cannot be kept alive over an extended period of time. That requires us to explore other PUSH-based communication protocols on devices.
-
- SMS messages can be pushed to devices and handled by the J2ME Wireless Messaging API library (see Chapter 9) or the MIDP v2 PUSH Registry.
-
- SIP is a protocol specially designed for signaling in a PUSH-based network. The SIP API for J2ME has already been finalized (see Chapter 9, Section 9.6).
-