Avoid Mobile Enterprise Dev Hazards - I

Devs facing the task of mobilizing their existing applications need to adjust their current enterprise integration approach, according to a growing number of enterprise wireless experts, IDN gets top advice for senior mobile dev execs from Intel, IBM and others in this 2-part series.

Tags: Wireless, Developers, Enterprise Wireless, Vick, Devs, Server, Wireless Apps,

Let's get started with an overview, and the first 3 mobile apps traps to avoid.

When conducting a wireless integration project for the enterprise user, special attention must be placed on three key factors, experts advise.
1. The nature of the "occasional connectedness" of a device (and whether that device will need to operate independent of a wireless connection to a host);
2. The value of documents being accessed and/or passed; and
3. The special demands of constrained mobile device resources.

ESB-CON Due Diligence Day - March 2, 2006 - Free Online Conference

Join leading ESB vendors BEA Systems, IBM, Sonic Software and Sun Microsystems as they address "The Tough ESB Questions" at ESB-CON -- a live, free online event. Attendees get a full-day of ESB straight-talk about Architectures, Use Cases, Most Popular Features, Designing Pilots, Product Details, and Roadmaps for SOA. Click here for details and no-cost registration.

Gotcha Tips for Enterprise Wireless Devs
  • 1. Reliability C.V. Vick, a senior software architect for Intel Corp., describes the differences devs should watch for: In previous distributed systems, he explained, "most applications have been written for dial-up or Ethernet [connections], which are extremely reliable." In contrast, wireless nets are inherently unreliable. "Someone opening up a microwave oven can blow your whole wireless network out," Vick said. Many of the failures of first-generation web-oriented wireless networks arose, he said, because designs and developers assumed the "reliability" of such technologies.

  • 2. Synchronization Vick also pointed out that while synchronization with LANs is pretty straightforward, that's far from the case in the wireless domain. Developers should take care when formulating what Vick calls "granularity of the synch" -- in other words, requiring too large a start-of-day download, or even too many step-downloads, in some wireless settings, can spell disaster. So, keep it simple and in small steps, especially at start-up, Vick advised.

  • 3. Resource Limitations IBM's senior software architect David Reich said that Big Blue is in the process of fine-tuning its app dev tools to enable better deployment of wireless apps to small clients. Two key features are: (a) support for on-board databases; and (b) new J2ME components (that have migrated to Java wireless from the J2EE server-side domain.).

    "We have a set of wizards based on the J2SE and J2EE programming model, and these will generate code," Reich said. "For mobile developers, we have a set of tools that let you further optimize the code and assist you in overriding everything that gets generated for you." Thus, elements of J2SE and J2EE styles can be brought down to the less familiar J2ME space, and, in turn, off-load servers and reduce trips between device and server.

    Tools should help developers partition the new wireless app, he said, helping them decide how much is going to be done offline locally, where transactions can be queued up for future sends, and which functions should be isolated and invoked only when the user is hooked up to the server.
    In Reich's view, one key step to optimizing development for enterprise wireless is to override those handy code generators. "When it comes to development tools, let's face it, we all write really fat code these days. We assume tons of disk space. These devices don't have it," he said.

    In Part II, IDN looks at issues of context-sensitive development, leveraging existing documentation and code, and adding a wireless extension cord to current apps.