We've briefly touched upon the major infrastructure vendors who are selling runtime and presentation layer solutions to the carriers. It is worth mentioning that most of these vendors also want to sell to the enterprise and ASP markets.
Most of the data solutions being pitched at the enterprise at the moment employ a dual server approach, with a carrier-grade server connected to the carrier's presentation layer and communicating securely with a smaller, enterprise-grade server installed in the enterprise datacentre. This solution can give various levels of control to those larger businesses determined to own all eyes trained on their business - and who are willing to invest the time and the personnel to manage the service. All of the companies mentioned in the previous section have their own variations on this model designed for the business market.
They will also all supply versions of their infrastructure products to ASPs and WASPs (Wireless Application Service Providers). Budget constraints may eventually attract SME's to either go direct to the carrier or turn to affiliated ASPs that have wirelessly enabled the applications on their menu, but this market, given the current downturn, has yet to mature.
Many of the vendors on the list offer complete, bespoke end-to-end solutions that can be tailored to very specific business needs. Nevertheless some businesses with specialist needs will still choose specialist mobile technology outfits such as Brience. Brience will work with any infrastructure platform and has an impressive portfolio of mobile solutions, ranging from edge servers to session management products to bandwidth management guarantees. Although both NetMorf, a US mobile specialist, and mBrane, an equivalent UK based company, recently went into receivership, other specialist companies have already demonstrated considerable staying power. Viryanet, for instance, have been delivering completely managed mobile solutions to field engineers since 1988.
At the end of the day the solution chosen will depend on the complexity of the application and the importance of the business process that it serves. Providing email and intranet access to your mobile sales force is going to be a much simpler task than providing a service hub for mobile engineers that can access CRM, ERP applications and process orders.
The Presentation Applications
Technically speaking, a description of the presentation layer should include a detailed description of all the different servers and microbrowsers available to the mobile phone. This guide is specifically written for the business that wants to be able to wirelessly enable as many of its applications and processes for its mobile fleet as possible, and as such will assume the minimum mobile device in use will at least have the processing capability and screen size of a smartphone.
There are four main methods of getting your applications out to your mobile fleet: transcoding, thin client or 'screen-scrape', server-side synchronisation or mobile java applet. Each has its advantages and disadvantages.
Transcoding
Transcoding is the process where content is analysed and tagged so that it can be dynamically reformatted to the unique display characteristics of the device - that is usually running some kind of browser - trying to access it. Modern transcoding servers use a combination of XML tags and SOAP (Simple Object Access Protocol) calls to create a simple template, or UI (User Interface). When the device requests the data it is pulled from the dynamic database and dropped into the template and automatically formatted.
Nearly all of the companies with an interest in mobile computing use transcoding in some form or other. Transcoding is a popular way of displaying reference information by virtue of the fact that it is cost effective and simple. It also keeps much of the processing server-side which has certain security benefits for more valuable data.
The disadvantage of Transcoding is that, in the current circuit-switch dominated environment, it is expensive as it relies on a live connection. The reliance on a live connection will also mean that the user will be unable to access his applications if he happens to hit a coverage blackspot.
Transcoding is set to come into its own with the establishment of packet switched network like GPRS or 3G solutions. Used in conjunction with caching on 'edge' servers on the fringe of the service, data costs can be minimised, with only incremental data changes being charged for over the line - although caching in itself may case security problems for the more confidential data.
Thin client or 'screen-scrape'
The oldest of the mobile solutions, so called 'screen-scrape' technologies work by taking a bit-map snap-shot of the GUI, sending it to the 'thin' client installed on the receiving device and from then on only transmitting the mouse movement protocols and the changes to the bit-map image of the GUI. It is effectively a form of remote control of a system, with the major advantage that the system it can see could either be a humble NT Workstation or a mission critical mainframe.
The pioneering company here is Citrix, whose ISA protocol is the lightest and fullest functioning on the market. Microsoft also has their own version which was co-developed and licensed from Citrix. This version uses the RCA protocol, which has slightly less functionality than the Citrix version, but comes bundled with the Windows 2000 server.
Many businesses have already deployed thin clients in an attempt to wring extra life from aging PCs, which makes the decision to use it as a mobile solution a no-brainer for them, particularly if they're using it for messaging (which is usually the case). ASPs are also particularly fond of the technology, (and were specifically targeted by Citrix who developed the product with Reliability, Availability and Scalability firmly in mind).
It shares its main disadvantage with transcoding - if you're in a coverage blackspot, you won't be able to do your work. Transferring data from the remote system to the device can also be problematic sometimes, and requiring remote mapping to drives might prove difficult in PDAs.
The latest version of the Nokia Communicator has a Citrix client bundled with the OS.
Server Side Synchronisation
PDA's were originally developed as portable extensions to the PC. The idea was that they would carry cut down versions of the applications on the desktop and the users would synchronise data from the desktop to the portable device, enabling the user to continue work on the move.
Palm, Psion and Windows CE devices all had their own proprietary synchronisation software that did the job with varying success for their own product, and not at all for the others. Regardless, PC synchronisation was utterly inconvenient for heavy users - although the mobile user might be able to work away from the desktop he or she was still tied to it with an invisible thread and had to return if they wanted fresh data. The other problem, covered earlier in this spotlight, was security: PDAs could siphon important LAN data onto a highly losable device - which could have very serious consequences in the case of a security breach.
Synchronising to a centrally managed server over a wireless link is a different proposition. PDAs become truly mobile, and the administrator of the server will have a record of what is passing through the system. The new SyncML standard has the backing of all the major PDA vendors and promises to considerably simplify the process, although there have been server-side synchronisation products on the market that have worked their own proprietary way around this problem since 1998.
The main advantage to this type of data solution is that the user can work off-line, so it is very suited to circuit-switched GSM and coverage blackspots. Veteran PDA users who remember the time it took to synchronise with their desktops through a parallel port cable might balk at the idea of the same process happening over a slow wireless link. Although we haven't actually tested a server synchronising product, it is highly doubtful that the server process will be as profligate with the information it sends as the PC based product was, and it will probably be capable of transmitting only the data from client template to a server version. The critical issue of this solution is exactly how it is made to integrate with the business processes at the backend.
For a long time the only UK representative of this type of solution was Advance Systems. IBM were relatively quick to licence the solution, which was recently renamed XTNDConnect Server.
Java
There's no doubt about it - Mobile and Java were made for each other. Whether you are an enterprise that wants to remotely manage a fleet of business devices, or a carrier looking to score a major dollar from a volatile and unpredictable consumer market, Java's promise of re-usable, downloadable applications on demand is compelling. Major developments in embedded silicon are underway and word from inside the industry predicts that carrier grade Java servers may be in operation as early as next year.
The Java that Sun developed for wireless, Java Platform Micro edition J2ME, was released for the application developers in September of last year. The membership list was comprehensive. All the major handset manufacturers support J2ME. Epoc and Symbian support J2ME. DoCoMo supports J2ME. The only major player that didn't sign up was Microsoft.
At the moment to run Java a mobile device needs at least 256kb of memory. The current bottleneck is bandwidth for the downloads: an applet will be about 10-100kb, a sophisticated application between 100-1000kb. In contrast, some estimate the maximum bandwidth of GPRS to be about 40 kbps. Applications look set to be downloaded once and stored in persistent memory until erased to make way for the next applet.
There are two different versions of Java developed applications, as outlined by the white paper on the Sun website. The first high-level APIs have a high degree of abstract content, concentrate on delivering an accurate service from a central site and will be of most use to the mobile business user. Low level APIs, on the other hand, are mapped much more firmly to the hardware of the device, and allow the application to exploit its physical properties, such as the screen. Games are the most typical application of this type.
iMode is already delivering k-Java applications and games to its users. HP has their Chai applications and IBM also deliver their own brand of Java. To complicate matters even further, Microsoft are now developing mobile applications in C# that can take advantage of their various Windows platforms. On the face of it, it looks like yet another bewildering balkanisation of standards, but several commentators have insisted the differences can be overplayed and will be resolved at runtime in the MIDP engine that executes the code.
In terms of business use Java will work in coverage blackspots and has the added flexibility of being able to provide applications exactly when they are wanted. A demonstration of 'elata senses', a wireless application server written entirely in Java, gave a flavour of what could be done with the technology.
Using a Psion 7, elata senses showed strong potential for remote management. Profiles were generated on the server and mapped to applications, and then dragged and dropped to a specific fleet of devices. If a new application, such as a car rental expenses form, was needed, this could be immediately wirelessly downloaded onto the mobile system. All applications could synchronise on connection, and everything was recorded on the server.
The most widely anticipated disadvantage of Java as a mobile solution relates to the rarity of, and subsequent demand for, decent Java programmers.
Sorry, we are no longer accepting comments on this item. We suggest trying to contact the author directly.