There are some fascinating predictions at the moment about the growth of telephone based devices connected to the internet, over 200 million by 2004. There are still a lot of questions to be answered as to what these devices will be, and who will make them. But there is a fair chance that there will be a growing dominance of European products over American ones, which will be most welcome.
The key to all this is the convergence of mobile telecom devices and the internet. This is particularly based on the developments of wireless technology. There is already a preliminary use of GSM phones to handle simple data e.g. small message service (SMS) for paging applications, but the technology is only capable of low data rates, about 9600bps, which while useful, is far too low for any interactive applications. However, communications technology is developing very rapidly, both for wire based and wireless. The big hurdle to clear at the moment is the investment required for building the huge, international networks needed.
An investment in the best current technology would soon be obsolete, which is an obvious deterrent, which slows down the implementation of faster network services, but doesn't stop the development. It looks for instance likely that many homes will be getting 1 Mbps data rates, with xDSL, on wired services during this year. The same developments are progressing with wireless technology, though obviously at later dates than with wired-services, but 350-plus Kbps will be followed, so it is claimed, by 1 Mbps wireless capability.
In view of the predicted enhancements, now is the time to develop new protocols to cover the new applications. Key to this is the Wireless Application Protocol (Wap), an open global specification, again with a strong European presence in the Wap Forum. Wap is the current defacto standard by which devices connect to information services. The protocol allows a device to negotiate with the service in order to provide a sensible interchange of data.
The current situation with HTTP and HTML assumes that the client device has all the functions of a Web browser. This may also include a Java Virtual Machine (JVM). As a result the much simpler 'advanced telephones' cannot be used with current Web servers. With Wap the client will negotiate and establish what services it can accept. Thus a laptop can accept all the server functions, but a telephone can only handle simple messages. There is of course the need to redevelop the Web server pages to match the demands of the Wap protocol.
While redeveloping normal Web information servers is an obvious need, there are some equally interesting opportunities for e-commerce applications. Already there is a lot of activity developing interactive applications accessing legacy and other transaction systems with a browser, via an 'application server'. This can be used with Wap because all the emphasis is on replacing the Web front end code with Wap functionality; the 'back-end' can be the same. While it is a good investment to develop new applications in Java, there is another, older technique which can take advantage of Wap. Screen-scraping was one of the earliest techniques for adding GUI interfaces to existing applications.
The PC GUI, and now a Web browser GUI, is used to manipulate the input data into a protocol for the common character based terminals, which means 3270 for IBM mainframes, 5250 for AS/400 and various ASCII terminals for Unix. These interfaces could be enhanced to include multiple 'screens' integrated into the one GUI. Early examples were thick client models, very difficult to manage, but now the protocol converter runs on the server side, with only a conventional browser on the client side, dramatically easing development and maintenance. This is a classic example of a 'browser-enabled' system.
It now follows that if a full browser can be supported by a protocol converter server, that server can be enhanced to support Wap as well as HTTP/HTML. The obvious problem with this style of interface is that it is limited, compared to a full Application Server. But this is surely of little consequence to the new generation of telephone-like client devices, because they are essentially simpler than a PC, and thus don't need any particularly sophisticated applications.
It seems to me that the Wap enabled terminal emulator products, such as Seagull's Wireless-to-host (which also has other capabilities such as Java support), are strong candidates for supporting the new development.