HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Here's a quiz: consider a physician accessing different patients' histories on a PDA while making rounds at a Manhattan hospital versus a field engineer whose responsibility is to monitor and repair sections of an oil pipeline that stretch across 200 miles in Texas.

Which professional is able to have continuous access to data and applications - the doctor, who is always connected to the wireless LAN network, or the field worker, who experiences only intermittent connectivity?

The answer is both. The doctor and the field engineer can have uninterrupted access to data and applications, without the unrealistic expectation of continuous wireless connectivity, if they're equipped with an "always-available" mobile solution.

Java provides the foundation for always-available mobile applications. For example, a J2ME-enabled mobile device can operate in both wireless and disconnected modes. Unlike browser-based WAP or HTML applications, J2ME applications are persistent; a J2ME application can function on a cellular phone, laptop, or PDA without a wireless connection. When a wireless connection is established, however, the J2ME application can communicate with the corporate network, sending and receiving data changes, additions, and deletions.

Java's ability to work in all modes makes this technology invaluable for all types of environments and mobile applications. In addition, the user interface of a J2ME application can be customized and enriched with graphics, media components, and more intuitive navigation to improve the user experience. The challenge, then, is to tailor a Java-based solution around the business needs, the nature of the work, and the mobile environment.

Always-Available Mobile Applications
The need for mobile applications to operate in any mode is the result of three overriding business concerns:

  1. Limitations in network infrastructure
  2. Low wireless connection bandwidth
  3. Cost of wireless service
First, current limitations in network coverage make disconnected applications a must-have for the mobile professional. Whether a sales representative is traveling on a plane or a field engineer is in the desert fixing a pipeline, they must all be productive with or without the benefit of a wireless connection. Until wireless connections are ubiquitous and 100% reliable around the world, disconnected functionality will remain invaluable to the mobile worker.

Low wireless connection bandwidth is also an issue with most mobile professionals. It will continue to be a bottleneck, even with GPRS and 3G networks. Synchronizing applications only when necessary is therefore of great value. A field engineer, for example, may not want to update daily job information every time he or she enters one line of data; the engineer may simply need to ensure all jobs have been entered, verified, and completed intermittently throughout the day.

Airtime minutes will continue to be a cost factor until carriers and other wireless network providers switch to a true data usage-based model. Synchronization eliminates the needless overhead of "dead" airtime minutes used during a wireless data session in which a user is charged even though no data was exchanged during the wireless connection (such as when reading e-mail). The beauty of synchronization is that it allows the user to connect to the network only if data transmission is necessary, and automatically disconnect when the transmission has been accomplished.

In this environment, choosing the appropriate synchronization model is critical to successfully deploying mobile applications.

Mobility Achieved with a Java Synchronization Solution
There are several synchronization approaches. File sharing is one common option, but it requires the presence of databases on both the client and the server. This becomes cumbersome if all you want to do is synchronize data between enterprise and client applications, neither of which stores data in databases. It also often requires a proprietary file format for transporting the data between devices.

Application-level synchronization is another option, but its shortcomings include the inability to extend the synchronization solution across multiple applications and back-end databases. Since this synchronization solution is specific to the application, multiple solutions may need to be supported when a project requires access to more than one enterprise application.

An optimal synchronization solution would sit between the application and database level, allowing objects or components to freely synchronize with one another. This is possible using Java (see Figure 1). By allowing a server's data access layer to synchronize directly with the client's data-access layer, it doesn't matter which type of databases or applications need to be synchronized, or which client devices need to be supported. Any database, application, or client device can synchronize at the data access-layer level by communicating with industry-standard interfaces, including JDBC, EJB, XML, JCA, JMS, and HTML. You can extend any J2EE services existing on the server to a mobile client device.

Figure 1
Figure 1

Architecting a Java Synchronization Solution
Conflict resolution during synchronization usually depends on complex business rules that are set by the user and require a robust solution to appropriately handle these rules. Such a solution should support the following:

  • Multiple Device Support
    A robust synchronization solution should be functional on multiple client devices that support offline deployment. J2ME is only one type of client technology that needs to be supported. Other platforms such as PersonalJava (pJava), J2SE, and WABA can also be supported by your wireless platform without requiring additional or third-party add-on products.

    Should your synchronization solution connect directly to the client application or require a client database, you'll need to provide for cross-device functionality. The best way to ensure this functionality is to connect your synchronization solution to the data-access layer of the client application. This method allows your synchronization solution to remain flexible in light of the various client devices, platforms, and applications.

  • Real-Time and Asynchronous Access
    Synchronization should not be a standalone product, feature, or function. Your mobile solution should support both real-time (e.g., browser-based) and offline access (e.g., client application and synchronization) to corporate back-end applications and content. Find a vendor who can provide both types of products - otherwise you'll be left with integration and incompatibility issues between your connected and disconnected solutions.

  • Client-Side Data Caching
    Mobile devices should not require a client database for your synchronization solution to work. Many devices don't even have a file system that supports a client database (e.g., Compaq iPaq). If your synchronization solution does depend on a client database, it will require you to add more software products than necessary, raising incompatibility and memory-limitation issues on your client device.

    Using the client's cache is a more practical solution. Given that the device will have local memory capacity, you can achieve persistence using this memory. The memory used for persistence is also less than that used by a client database. Having made the argument for using a caching solution, it's still important that your synchronization solution supports the use of a client database should it be needed due to the nature of the work or the application.

  • Multiple Enterprise Connections
    Your synchronization solution should be able to interface with multiple server-side applications and databases. Avoid using synchronization solutions directly from enterprise application providers; they may work with that particular application, but are not likely to interface well with other back-end content. Find a solution that's open and allows you to interface with multiple back-end solutions; this will save you from significant upgrade and maintenance headaches. You'll need to support connections to JDBC, EJB, XML, JCA, JMS, and HTML data sources, among others.

  • Open APIs
    Find a mobile solution that allows you to develop using API-level access. This development approach enables you to easily integrate with third-party software applications and preserves the flexibility of your current and future mobile strategy.

  • Open Application Development and Java Support
    Ensure that the applications you develop, on both the server- and client-side, use open architectures and industry-standard development methodologies. The most fitting solution for this paradigm is J2EE on the server-side, and J2ME/J2SE on the client-side. If you already have Java in the enterprise, your mobile solution should extend this investment to client devices. Look for a solution that allows you to extend your existing J2EE components or services to mobile devices without the need to rearchitect your existing enterprise IT infrastructure.

  • Flexible Business Logic and Synchronization Rules
    Conflict resolution rules should always take into account the intended functionality of the application. Such synchronization rules can't take a "one size fits all" approach to resolving conflicting data information. In most cases, "last in wins" conflict resolution can have a disastrous effect on the application data accuracy. Synchronization rules should be flexible enough to support the various business logic rules of the application, allowing developers and/or users to decide which priority settings should be used if a data conflict occurs.

  • Logging Tables
    Whatever the outcome of the conflict, log tables are necessary to document the results. They must be reliable and easily accessible from within various administrative environments, displaying results as hierarchical tree views of log data, for example. Log tables ensure that even when a conflict occurs, none of the data is lost and the subsequent rollback of the initial conflict resolution can occur.

  • Security
    Allowing mobile devices access to your corporate networks produces security nightmares among your IT staff. Make sure your mobile strategy incorporates industry-standard security technology to encrypt the connection between the mobile device and your corporate networks.

    Understanding Development and Implementation Issues
    J2ME is only one type of client technology that allows for disconnected applications. Due to the variety of mobile devices, different technologies emerged to take advantage of the differences in functionalities offered by each device. The two prevalent technologies, both of which happen to be Java-related, are J2ME and PersonalJava (or pJava).

    J2ME is mostly used on mobile phones and requires a micro Java Virtual Machine. While the proliferation of J2ME phones is currently very low, future mobile phones are expected to incorporate this technology. Nokia, for example, is currently making a big push into shipping J2ME phones worldwide.

    PJava is generally used on Pocket PCs and takes advantage of the underlying functionality of the operating system. It can deliver a better user experience than a cell phone, due to the additional software and hardware functionality of the mobile device. It appears unlikely that these two technologies will merge anytime in the near future. In fact, it's more likely that new client technologies will emerge, highlighting the need for a robust mobile and synchronization solution that will take these future changes into consideration through open, flexible, and extensible architectures.

    Deciding on a synchronization solution is not much different than deciding on a real-time wireless solution. The solution should be based on open standards, leverage existing investment in technologies, and be flexible enough to accommodate future changes in technologies or business direction.

    There are many add-on synchronization solutions that may work with your existing enterprise and mobile initiatives. Add-on solutions, however, don't provide the most flexible and robust synchronization as compared to integrated solutions. An integrated solution should provide both real-time and offline functionality of your mobile project. Synchronization should be a simple extension of your real-time wireless solution and shouldn't require a separate technology or software/services vendor.

    Whether add-on or integrated, the synchronization solution must be based on open standards and remain flexible for future changes in technologies, not just synchronization technology. An open solution is something that can be managed without the help of the vendor or specialized systems integrator. As with any software solution, you should not be dependent on the company that produced or sold the software to you, but be able to manage the solution with existing in-house resources.

    Conclusion
    When selecting a synchronization solution, many factors play an important role in choosing the solution that's appropriate for the task at hand. Choosing the best-of-breed synchronization solution may not turn out to be the correct choice when you consider other factors. You should make your decision based on a wide variety of influencing issues that are not limited to just your mobile strategy. First, determine the business requirements of your project. Will a wireless solution without offline capability suffice? If not, do you need a mobile solution that can operate in a disconnected mode? Do you need both, allowing certain parts of your organization to use one or the other?

    Second, know your existing enterprise and client technology, including both your software and hardware investments. Do you plan on building a new mobile project from scratch? Do you plan on extending an existing enterprise application? Have you invested in Java technology? Are you looking to integrate the wireless/mobile solution into your existing IT infrastructure? Are you looking to build out a completely separate wireless/mobile island, away from the corporate IT system? What type of devices do you plan on supporting - just one or many? Are you planning on mobile-enabling just one or many enterprise applications? Do you need direct access to database content from mobile devices?

    Third, evaluate the vendors. Choose one that fits your needs. The more openness and flexibility you (or your vendor) preserves, the better. Choose a product vendor, not a services vendor. Look for a vendor who focuses on and has experience with mobile technologies. Consider the total long-term cost of ownership of your mobile solution, not just the products and/or services cost in the first year.

    Synchronization solutions are a must-have for the mobile professional. The current limitations in wireless connectivity require client applications to function even in an offline mode of operation to enhance the productivity of the end user. Synchronization solutions should therefore be an integral part of your mobile strategy.

    Author Bio
    Jeff Capone, PhD, is CTO of Aligo, where he leads the technology development and is principal architect of the M-1 Server. He has spent the past decade researching wireless applications. [email protected]

    All Rights Reserved
    Copyright ©  2004 SYS-CON Media, Inc.
      E-mail: [email protected]

    Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.