3G or not 3G?

The telcos' much-promised 3G infrastructures will bring with them a host of challenges, not least of which is back-end...

The telcos' much-promised 3G infrastructures will bring with them a host of challenges, not least of which is back-end application integration. Fortunately it looks as if users will have plenty of time to prepare.

3G mobile networks may promise us lightning fast speeds in the next few years, but service providers have been slow off the starting blocks so far.

Nevertheless, companies wanting to exploit the potential of 3G services should already be thinking about how they will fit into their existing software and networking infrastructure.

Think big - but not too big
In spite of the hype, from an applications perspective 3G is unlikely to be as big a departure from more traditional 2G GSM networks as you might think. Mobile multimedia may be possible, but the bandwidth through which you can reach each customer is unlikely to be as huge as telecoms companies originally predicted.

Vodafone last year admitted that its per-customer bandwidth would fall well short of the 2Mbit/sec that evangelists were predicting a year or two ago.

One thing that is different about 3G and some 2G variants is that they're packet-based, as opposed to circuit-switched, like GSM. This represents opportunities for companies to integrate their IP-based applications with the service providers' networks more effectively.

On the other hand, it could make things less reliable, according to Paul Bruce, product manager for mobile software development components company RadioScape. GSM networks have a single control channel and several individual voice channels that could also be used for data, he explains; once you've got a channel, it's less likely that you'll be thrown off the system.

A 3G base-station, on the other hand, is more open. It may contain a high data-rate carrier that various mobile users are contending for, says Bruce, or various lower-bandwidth channels with different numbers of users at different data rates.

"You could think of a system where you had a base carrier, and there are a huge number of people doing transfer on that channel, and you can't design for the worst case possible all the time," he warns.

Tying up loose ends
The other problem for companies is integrating multiple back-end applications into an acceptable service for wireless users. Nad Nadean, global marketing director at Peramon, a wireless middleware company, argues that end-users in the field want to be able to do things in a task-based fashion, rather than accessing individual applications.

What he's really selling here is a wireless version of the enterprise portal - it's nothing new, but he has a point; on a tiny screen, it makes even more sense to be able to access services in this way.

Peramon (with its Application Generator product) is just one company offering middleware to hook together back-end applications to wireless front-ends. Other companies offering such products include Softwired, which offers iBus, a product to integrate the BEA Weblogic application server with wireless devices using the Java Message Service (JMS).

This sends devices from the application server (which itself integrates with back-end legacy applications) through to client applications held on wireless devices, which can then act on them. The client can then store its own messages in the event of a network outage, sending them back to the main server when it detects a signal, and this goes some way towards resolving Bruce's reliability problem.

Net benefits
The other alternative, of course, is to cut through the whole tangled mess and cleave to Microsoft's latest world domination strategy, .net. This has the advantage of hooking together back-end servers and any .net compatible front-end client (including wireless ones) by virtue of an XML-based remote procedure call system using the Simple Object Access Protocol (Soap). This will get your wireless client talking the same language as your server.

The problem with .net is that you may run into problems if your wireless client isn't a .net-compatible device using Microsoft's PocketPC operating system. In fact, you'll find disparities even among supposedly compatible device formats (say, different WAP phones), and certainly between, say, WAP phones and non-WAP PDAS.

One way around this is to use XML in your middle-tier application logic as a means of transforming back-end data into different formats, depending on the client that is accessing it. In specific terms, the eXtensible Stylesheet Transformation Language (XSLT) can be used to change XML-based data at the back end into different formats such as the Wireless Markup Language that underlies the WAP mobile application protocol.

This still leaves you to convert your back-end data into XML, which is no mean feat and may require automated conversion, perhaps using the same middleware product that you use to speak to your wireless devices. Hopefully over time, the need to feed data through to WAP 1.0 handsets will decrease thanks to the introduction of WAP 2.0 late last year, which includes support for elements of the standard TCP/IP stack.

Secure your strategy
There are many other issues to consider when producing wireless applications for the Web, including the management of security. Current WAP implementations use built-in browser-based encryption, but they also require a gateway between the WAP network and the standard network.

Encrypted messages must be decrypted for part of the journey so that they can be routed across the gateway. This creates significant problems for companies wanting to conduct transactions over WAP links, because they will expect total end-to-end encryption, although it's not clear how this will change with the evolution of WAP 2.0 running over IP-based 3G networks.

According to José López, lead research analyst at Frost & Sullivan, one way around this from a 2G perspective is to simply host your own WAP gateway, therefore bringing it under your own control.

While the service providers continue to agonise over their 3G implementations, companies could do a lot worse than tailor their back-end infrastructures into multi-channel systems so that they will be ready for it. Understandably, many firms will wait until after the downturn before they begin to tinker with their application delivery mechanisms in earnest.

That shouldn't worry you - the likes of Ovum predict that 3G will have a very slow growth curve until the middle of the decade. There's plenty of time yet.

Read more on Wireless networking