t first glance, bringing peer-to-peer capabilities to mobile wireless devices may appear to impose a needless layer of complexity on the already complex task of providing remote access.
This concept extends to any wireless device that can communicate with the corporate network. When plugged into any of a growing number of peer-to-peer platforms, wireless devices are becoming mini-servers, each capable of running tiny, yet powerful, data-dispensing applications. In this architecture, data flows from person to person across the edge of the network as well as back to the server.
What a mobile P2P user can access depends, of course, on permissions he has been granted?an issue which we’ll discuss later?but it’s likely that the user will have access to at least some co-workers’ devices as well as their own desktop PC. Through this mechanism, the borders of the company’s information infrastructure have been expanded meaningfully?without rebuilding the client-server architecture, engaging in legacy integration, or even building an intra/extranet site.
For that reason, we’d suggest it’s worth getting to know what issues you’ll face in building peer-to-peer functionality into your wireless connectivity schemes. Here, we’ll outline the scope of the wireless P2P development problems and describe some proposed solutions.
More Hassle, More Benefit
In recent times, a steadily growing list of wireless-capable devices has been hitting the scene?including the RIM Blackberry, Handspring Visor, Compaq iPaq, and HP Journada?facing developers with a growing list of interfaces and operating systems to consider. With the mobile device market split among these varied camps, IT departments will probably be asked to support virtually all of them.
Connecting these devices to information sources ranges in difficulty, from familiar processes to a protracted process of adapting code for low-powered devices with non-standard operating systems. For example, programmers who want to connect a handheld computer wirelessly can usually work with familiar tools, as these are typically Win32 devices. In other words, with handhelds like the iPaq already running a version of Windows, integration runs along familiar pathways. Even in that case, however, varied versions of Windows CE may complicate the task somewhat.
Developers working with smart phones, for their part, will encounter a few different operating systems, each with their own quirks. Perhaps the most popular browser is the Openwave Mobile Browser, created by mobile software developer Openwave Systems of Redwood City, CA, but competition does exist, and developers need to know their way around this.
Presenting web information via PDA platforms such as the Palm OS, meanwhile, requires that programmers write more elaborate translation routines, given that client-server systems will not be compatible with this PDA platform. Linux-powered mobile devices such as the Yopy PDA from G.Mate Inc. will call for their own approaches as well.
Which Microbrowser to Implant?
For just about every implementation, developers must choose the type of microbrowser they’ll implement, and decide upon a method for translating ordinary HTML or other data to a supported format such as WAP.
These days, corporate information departments have had little choice but to create connections for these disparate devices, despite the hassles. Given the time-consuming nature of the task, it’s easy to see why adding P2P functionality may sound like just one more unwelcome chore. And up to a point, it’s true?peer-to-peer software isn’t eliminating the problems mobile device developers face, and, in some cases, introduces technical issues of its own.
On the other hand, P2P also brings information sharing, collaboration, and real-time synchronization options that aren’t likely to exist in a pure client-server environment. In fact, peer-to-peer technology may actually simplify the process of opening up worker access to key information, permitting users to tap PC data freely, rather than wait for IT departments to connect them one at a time to critical apps such as Outlook. Tradeoffs like these make the bigger picture seem far more balanced.
Wireless P2P Development Options
As the peer-to-peer market has matured, a growing number of companies have rolled out products that lay the groundwork for wireless P2P development, including the following:
Further down the road, open source wireless P2P development tools will also be readily available. Sun Microsystems, for example, is working on Project JXTA, which is aimed at creating a core services layer that they’d like to see adopted by all P2P developers. Sometime in the next few months, Sun plans to release its JXME standard. JXME is a version of the JXTA protocol aimed at the mobile information devices platform contained within the Java 2 Platform Micro Edition.
Problems in Wireless P2P Development
While these platforms are designed to solve some implementation problems, wireless P2P developers still face their own unique set of challenges.
Adapting the client.
Developers may need to find a way to make the richer “peer experience” of a P2P-enabled device work for their particular situation, even though they face significant limitations in memory, storage, and processing power. For some devices, a fat, highly functional P2P client will be needed, while for others, any client that supports P2P connections will do, notes Matt Page, manager of device platforms for Groove Networks. “Developers must consider if there exists the need for a fat client experience based on the target platform,” Page notes. “For example, smart phone users will likely never use that device to edit large Excel models.”
Synchronization issues.
Another problem in wireless P2P development is determining how, when, and under what circumstances developers want to have peer devices synch up with central data stores. Developers will also need to decide how and when users will synch up with each other, which users they will access, and under what circumstances. P2P goups like the ones created by Groove can stay synchronized with each other, even if they’re not connected to the central IT infrastructure. In other cases, it may be better to synch through a central data store. Also, given the variation in wireless networks from place to place, developers may want to give users the option of shutting off P2P synching or even data exchange depending on how good the wireless network coverage is in their location, Page pointed out.
Securing the data.
Still another problem in wireless P2P environments is creating a secure environment for data sharing. This topic is complex enough to call for its own full-length article, but in brief, here are just a few of the more critical issues to be addressed.
In the case of an 802.11b P2P area network, extra security measures are appropriate. Particularly if rich user data is being shared P2P across such a network in addition to corporate info, developers and other IT staff must take care to protect against unauthorized users sniffing information off of the wireless network, noted Greg Bolcer, chief technology officer of Endeavors.
To push information across the airwaves, enterprises will have to use a gateway device that speaks the protocol of the receiving network. That device can be leased from an external vendor or run on premise by a company, but either way, a gateway is needed. As data is transmitted from a corporate IP network across a gateway, however, there’s a moment when all of the data is exposed. Some enterprises are comfortable with this and some aren’t; ultimately, it may be your job to be aware of and address this problem.
Bandwidth/Resource Consumption.
Finally, bandwidth consumption between peer nodes is also a concern. In a peer-to-peer environment, developers need to plan their data distribution architecture not only to squeeze corporate information across wireless connections to devices, but also to permit information to flow from device to device.
Take the experience of Cleveland, Ohio-based wireless solutions developer WISP Inc., which has been testing BadBlue’s zShare with a financial services client. Unaware of any potential problems, one of the end-user testers attempted to open a 35MB Excel spreadsheet that resided on another user’s system. The move, while legal on the BadBlue system, brought computing to a halt for both parties. “The machine [that the spreadsheet] was hosted on went into all sorts of fits doing what it had to do so it could share the information,” says Martin Hasemann, network engineer with WISP.
If developers bear these concerns in mind as they approach P2P, however, they may find that P2P technology is the killer app that makes the effort of connecting mobile devices worthwhile. After all, ultimately, if users have the information they want, the developers have done their job well. The faster and more conveniently they can get it, the better.
