The Realities of Deploying Wireless J2ME Solutions Over Unreliable Networks
Pages: 1, 2
On the server side we could have used JSP or Perl, but for convenience and consistency with languages, a servlet is used. Looking at this example from a higher level, the MIDlet makes a connection to the servlet and sends a request, which in turn is processed by the servlet and then returned to the MIDlet. This works "out of the box" and runs very well within the desktop/Internet environment (it's definitely not rocket science), but for the reasons mentioned earlier, this will not work well within a wireless environment. HTTP has inherently high overheads that cause the inefficient transfer of data; most importantly, network coverage failures cannot be handled at all.
In addition to inefficient protocols, the operator's network resources (speed and capacity) have limitations; this is something that cannot be programmed around. No matter how fat the pipe is, it will be filled.
The following are some things we should think about when designing a J2ME mobile solution.
- What happens when the network is not contactable?
- How many times will the application retry sending the data?
- What happens to the data when you cannot connect after retries?
- What happens to the data when you actually reconnect?
- When the network is not contactable, how can the application still be functional?
- When a crucial transaction is sent over the wire, can we guarantee that it will be processed?
- Where will you store and access the data?
In addition to these
concerns, you will also have to write into your code a lot more exception
handling to make your solution ready for "general release."
clearly not an optimal user experience.
Sun has put together a great resource called the Wireless Blue Print that enables a developer to quickly connect a MIDlet to a back-end service using Enterprise Java Beans. A standards-based approach using a J2EE application server is a step in the right direction, but this still does not solve any of the main issues of running a solution within a wireless environment. SOAP MIDlet examples have also been produced, again over HTTP, using XML to communicate to many devices, using a variety of operating systems. XML, like HTML and cHTML, is a very verbose way to get a simple piece of text from the client to the server. The markup language adds significantly to the minimum requirement of the actual payload; this additional overhead is much too excessive for real-world wireless solutions.
Size Does Matter
Size matters in two respects when making a MIDlet for the wireless environment: in the size of the packaged byte code, and in the size of the packets you are pumping over the network. Due to the increased lines of code for exception handling, persistent storage of messages, and resend code, your MIDlet is starting to really look bloated, since the space to download onto in the mobile device is still extremely tight. It is quite likely you will not be able to fit all of these requirements on the device. In most cases, it is up to you to be smarter with the architecture of the MIDlet code, and to compromise on the quality of service you are able to deliver.
Message size across a network is something mobile data operators watch very closely. Text-based markup languages, in most situations, really chew up bandwidth fast, whereas binary and string data types produce more efficient results.
Wireless Requirements and the HTTP Communication Model Do Not Match
The classic client/server architecture is one that even a beginner can come to terms with relatively quickly. Systems that use this model have a very tightly coupled linear communication protocol (request/response). Errors can occur within such systems when one of components' semantics change without the other party's knowledge. When logic changes, the related protocol is changed in turn; the result is corrupted communications -- things just stop working (see Figure 3).
Processes in systems that are complex and tightly coupled to each other result in a high likelihood that an error will occur (Figure 3, Quadrant 2). The Three Mile Island nuclear accident and the Challenger disaster have been associated with complex tightly-coupled system design. Design of any type of system that has tightly coupled, complex interactions are by nature prone to accidents, as the acclaimed sociologist Charles Perrow shows in his seminal work Normal Accidents.
CORBA is another example of a system that is inherently error-prone. Experience has shown CORBA to be a complex system to set up and maintain with a tightly-coupled communication model. When a WAN CORBA system is used over fixed lines with poor quality of service (such as those in some areas of Asia), the system becomes extremely brittle and unstable, regularly breaking down and re-establishing connections, each of which takes up to two to three minutes. CORBA, as with HTTP, just does not work under unreliable network conditions, because of the inherent nature of their communication models.
What is needed is a system that achieves the basic requirements for communication within the wireless environment at the infrastructure level. Those requirements are:
- Uses lightweight, efficient and de-coupled communication (both synchronous and asynchronous modes).
- Guarantees the sending and receiving of data under unreliable conditions.
- Reduces the complexity for large-scale installations.
- Includes session management to hold state.
- Bearer- and device-agnostic communication.
- Based on fully documented extendable APIs.
- Standards-based (future-proofing back-end services).
- Future-proofing back-end services should remain the same as devices and networks change.
The major players have not provided leadership in this area, nor have they understood the basic requirements for the new mobile data industry. Consequently, existing infrastructure companies have developed poorly-analyzed proprietary platforms that are not suitable for large-scale bearer/device-agnostic deployments in a disconnected environment.
An appropriate communication model needs to be applied to this unreliable wireless environment!
Sun's Wireless Blue Print
Charles Perrow's Normal Accidents
Mike Wilson is the Director of Product Management at Softwired AG. He has worked within the Telecommunications Industry as a Field Technician and in IT as a Developer/Manager in Australasia, Asia and Europe for over 10 years.
Return to ONJava.com.