For some time, in fact, the mantra of mobility was any data over any network on any device. And only a few years ago, there were more than 200 companies selling mobile middleware products. I tried a good number of these products; many of the toolsets were complex to the point of pain, but some were quite simple and elegant. For example, one package I used involved almost three hours of work just to get a stock quote on a cell phone screen -- with another, less than five minutes was involved.
But there is a fundamental flaw in the mantra that drove the mobile middleware industry. It's just not realistic to think of being able to move any data over any network, because the amount of data -- not to mention any inherent requirements for time-bounded service -- might be too great for the selected network. The network might also be overloaded or otherwise unavailable. And though the concept of delayed binding -- allowing a network to be selected at runtime rather than in advance -- was quite common
Requires Free Membership to View
SearchMobileComputing.com members gain immediate and unlimited access to expert guides for mobile deployment, management and security, industry trends, and more-- all at no cost. Join me on SearchMobileComputing.com today!
Kate Gerwig, Editorial Director
and a core feature of many mobile middleware products, it was usually impractical for a given user or enterprise to have multiple accounts on lots of different networks.
Then there is the problem of matching the data to the device. Big screens usually do not map well onto very small screens, which means that reformatting, often an elaborate process, is required. Screen scraping doesn't work well either. And, of course, we're faced with an amazing array of platforms and application programming interfaces (APIs) for mobile devices. One of the reasons, then, that the notebook computer remains so popular is that it is a self-contained engine that runs applications, and hosting data on it is indeed trivial. But the notebook is big and expensive and has serious associated support costs. It's thus a bit more than desirable that we get applications onto highly mobile devices, at least smartphones (those with a PDA form factor) and ideally most -- if not all -- cell phones of any form. But, of course, these platforms lack the processing power and storage of the PC.
A few more traditional packages survive, but today's approaches to mobilizing applications are substantially different. There is not much need to adapt to a wide variety of networks. IP is the only protocol that matters, although care must still be taken to match the expected network throughput to the requirements of a given application. This remains especially difficult because it's very hard to guarantee the performance of a wireless network.
So the two big questions are:
- How can we deal with enterprise data on a mobile device -- in terms of access, security, management, synchronization and basically matching the data to what is possible on a mobile device?
- Should the mobile platform be capable of local program execution or be more Web-oriented, like the iPhone?
As I've noted before, these questions are not likely to be answered in the very near future. We have a long tradition of building robust platforms with equally robust -- OK, some might say bloated -- operating systems, so that's the obvious direction. But mobile devices need to be compact and cheap and to have good battery life, which argues in many cases for the opposite approach. One thing is certain: Between the APIs inherent in a robust OS and the services inherent in modern desktop-class browsers, mobile middleware is no longer critical to the future of mobile applications.
 |
|
|
|
|
|
This was first published in August 2007