|[an error occurred while processing this directive]|
|Tapping into the AS/400...|
|This article is taken from the
February 2000 edition of NEWS/400.uk.
"We can expect to see the first desktop AS/400s towards the end of this year, with laptop, palmtop and wristtop models to follow." Phil's Home Page, April 1999. How close are we really? Phil Edwards finds out.
It's difficult to satirise IT. OS/400 on a palm-top may be some way off, but IBM has already risen to the challenge of producing a 'wristtop' computing device. The Watchpad, currently in prototype, is an 'always-on instant information device'; as the name implies, it's the size and shape of a watch. The Watchpad's simple touch-screen interface gives access to diary and telephone directory functions, as well as 'wireless information services'. When you're tired of browsing the airwaves, it'll also tell the time. Prototypes feature a green-on-black display, which may be a sign of resource limitations or a subtle piece of retro styling on IBM's part - either that or they have got OS/400 in there after all.
If the Watchpad sounds futuristic, impractical or - not to put too fine a point on it - daft, how about the Wearable PC? A unit the size of a Walkman contains a 233 MHz processor, 64 MB of RAM and a 340 MB disc; the ensemble is completed by a handheld controller - something like a laptop's mouse button, but on its own unit and a headset with microphone. The 'Eye Trek' headset includes an 800x600 pixel SVGA display, a little less than two inches square: mounted a few inches from one eye, this offers an experience similar to using a ten-inch laptop screen. It'll never catch on? Don't bet on it - that's what they said about mobile phones. Admittedly, at present it's hard to imagine what anyone would actually do with a Wearable PC, or what 'wireless information services' a Watchpad user could use. However, several recent developments suggest that the computing landscape is changing and the AS/400 could soon be at the centre of a new kind of network.
To take away
The buzzphrase which is driving the new vision of networking is 'pervasive computing'. The ultimate aim is for computing power to become omnipresent - to go with you wherever you go. To make this possible, a new kind of architecture becomes necessary, bringing together several existing technologies: robust, transaction-driven central servers; the much-ridiculed thin client; and the humble mobile phone. IBM's vision of this architecture is laid out in the white paper Application Framework for e-business - Architecture Overview at http://www-4.ibm.com/software/ebusiness/arch_overview.html ; notes on the specific role played by pervasive computing devices are at http://www-4.ibm.com/software/developer/library/pvc/index.html
The client is assumed to be a thin, relatively 'dumb' device; it's nice to have the processing power of a PC at the front end, but it can't be relied on. The only tasks which can be delegated to the client with any certainty are receiving data, presenting a display, accepting input and sending data back: effectively the 'presentation' layer of the traditional client-server model. The browser is the standard reference point: a device for presenting HTML pages, with some (optional) logic in the form of scripts or Java applets.
The network is assumed to be built on industry-standard protocols - broadly speaking, the Internet. As a result, the network is dumb: like the client, it does not add value to transactions by carrying out any processing of its own. Moreover, the network is open: proprietary standards have no place in this model, and all resources which are deployed building the physical network infrastructure can and will be shared. Finally, the network is resilient: contributions to the network infrastructure come from so many different quarters that multiple redundancy is built into the network, benefiting all users. The intelligence of the system is concentrated at the server level. There are two distinct types of server involved. The Web-based application server handles input and output across the network, and controls data read and write operations. The back-end transaction server, designed for resilience and processing power, runs the applications and databases on which the entire system rests; for maximum flexibility these will be written in server-side Java or 'wrappered' as Enterprise JavaBeans (EJBs).
This architecture is designed to maximise openness and flexibility. This is facilitated by adherence to a few basic industry standards. Java is used at the client and application server levels, and optionally on the transaction server; HTML and XML are used for sending messages to client level and between different servers; and server-side components are handled according to the CORBA framework.
Back to basics
To understand the potential of this model, we need to go back to basics - which means back to IP. Internet Protocol, to give it its full name, is one half of the TCP/IP standard which underpins the Internet and all derived systems such as intranets. Where TCP (Transmission Control Protocol) handles the delivery of data via an end-to-end connection between the source and destination computer, IP is responsible for actually moving data across the network. As the lingua franca of the Internet, IP is developing into a near-universal networking standard - one major exception will be addressed later.
Thanks to the Internet, an IP network can be considered as a basic piece of information plumbing. This makes it possible to achieve major economies by implementing IP in place of a proprietary networking standard. The processing power and intelligence can be stripped out of the network, which becomes a neutral transport medium: processing power migrates back towards the centre, paralleling the move towards thin clients. One project along these lines, recently undertaken by Three X, involved an organisation running 20-30 remote sites from a single AS/400. The AS/400 was connected to controllers at the remote sites via a private IBM network; this guaranteed continuous network availability, but imposed substantial financial costs. A larger drawback was the inflexibility of this arrangement: setting up a new location, in particular, imposed a heavy cost in both money and time.
The solution was to replace the managed network infrastructure with a simple leased line, with an ISDN line in place as a backup measure. AS/400 controller traffic could then be run over IP: in effect, an AS/400-only network was replaced by a standard IP network with AS/400 capabilities. This also had the effect of opening up the network to other kinds of traffic. Wyse thin client devices were installed, replacing the original 5250 terminals. This made it possible for the end users to run Windows-based office applications - served from a central NT machine, enhanced with Citrix MetaFrame to enable it to serve thin clients - alongside standard terminal sessions.
The keynote is centralisation: this configuration created a single point of management for all network traffic, whether from a terminal session or a Windows application. All user sessions can now be 'shadowed' from a central console. As this implies, centralisation of processing power requires a corresponding centralisation of human as well as machine intelligence. As Glynn Robinson of Three X comments: "Moving away from an externally-managed network has a downside. Technology enables you to manage the network centrally, but somebody does need to be there to do the managing."
The management task can be simplified - and the dumbing-down of the network taken still further - by eliminating the 5250 element of the equation. This is the route taken by Three X with another client, Yamaha Motor Europe. Yamaha's parts database runs on a central AS/400. Previously, the company's Europe-wide network of dealers had obtained parts information by a variety of means, ranging from viewdata to fax. The solution now in use centres on an NT-based web server which holds a copy of the central parts database. The NT machine is updated daily from the AS/400; information can also be retrieved in real time if necessary, using Three X's Jorvik middleware. To access the database, dealers simply connect to the Internet, access the relevant web page and supply an ID and password. The Yamaha solution illustrates the potential of an IP-based approach. The AS/400's native networking and screen handling protocols have disappeared from the picture: the network is as unlimited and as resilient as the Internet, and the client device can be anything that supports a browser. The processing power of the entire system is where it needs to be: at the centre. But can the picture be simplified still further, addressing worries about system management by eliminating the NT element and exposing the AS/400 database to the Internet directly (and securely)? And can the choice of clients be broadened still further, to include something as commonplace as a mobile phone?
Take a message
The AS/400-telephony interface is already being mapped out by vendors and solution providers. At the lowest level, voice-based applications can be developed using technology such as RMTi's RVSvoice software or Omtool's hardware-based IMPS solution. More sophisticated options are possible using the Short Message Service (SMS) system operated by most GSM network providers. (GSM - Global System for Mobile Communications - is the dominant European cellphone standard.) SMS, in effect a paging system, transmits text messages up to 160 characters long. Thenon's SEE/GSM Text system exploits this facility, enabling users to send commands to an AS/400 or NT system and receive notification messages in return. The solution involves both hardware and software: a communications device is connected to a V24 comms port on the AS/400, and a SEE/GSM Text subsystem is set up on the AS/400. The subsystem contains three main jobs: one monitors for events on the AS/400 that have been configured to trigger an outgoing SMS message; one monitors the V24 communication port, manages incoming calls, translates them and matches them up to either outgoing messages or instructions to run programs or commands; and the third manages outgoing traffic.
SEE/GSM Text can send a message when a batch job halts with MSGW status, or if a message arrives in a message queue. System messages - multiple attempts to sign on with incorrect password, application program errors, communications problems, etc - can thus be automatically forwarded to the operator in charge. If a message requires operator input, a reply message can be sent from the GSM telephone back to the AS/400; the message will then be used to reply to the message in the message queue.
A variety of different system conditions can be controlled; for instance, SEE/GSM Text can check the AS/400 to make sure that subsystems and jobs are active when they should be. Alternatively, the system can also be used to interact with application software on the AS/400, issuing inquiries to the database and receiving replies. A mobile phone can thus be used as a simple data entry device. Using more sophisticated devices, such as the Nokia Communicator and 3Com Palm Pilot, scripts can be written which allow field personnel to file a detailed time report in the form of an SMS message.
Ring the changes
The mobile phone interface has two main advantages, Thenon's Nigel Wright believes. "Firstly, it helps to keep the AS/400 in the mainstream. Mobile phones are everywhere these days - probably the only thing more people take to work is a briefcase. Mobile phone access is another weapon in the AS/400's armoury. More importantly, it makes a break with the old pattern where people had to make an effort to find out what was going on - has that job completed? Have I got any email? This way, you don't have to be tied to the desk. The system can tell you what it's doing and you can react, wherever you are."
For those whose mobile phone of choice is a Nokia Communicator, on the other hand, another option is open. The Dutch company JCS International produces AGUARD, a multiple-platform operations monitoring system. The standard implementation of AGUARD notifies operators automatically of any error condition, by pager or SMS message; the operator can then dial in and set up a remote terminal session from a laptop PC. Attach a PC directly to the central AS/400, with a modem to receive incoming calls, and a more direct solution is possible: a terminal session can be initiated remotely on the PC and mirrored directly to the screen of the Communicator. In effect the operator has a full-screen AS/400 display to work with, if a rather diminutive full screen: no remote terminal of any kind is required. Once again, the intelligence and processing power is concentrated at the centre, with commands transmitted and responses received over an open, 'dumb' and resilient network.
Neither this nor the SMS option uses the potential of wireless client devices to the full, however. The AGUARD solution is tied to a specific device; SEE/GSM Text is platform-agnostic, but limited by the 160-character constraint of SMS. To enable a wireless device to function as a browser-based client, one of two developments is required. One is to bring the device up to the browser's level, implementing a straight IP and HTML-based implementation; this approach requires extensive processing power and consequently limits the range of applicable devices. This approach is currently favoured by Palm, Microsoft and the Psion-led Symbian consortium. The alternative is to bring the browser down to the device's level, implementing cut-down versions of the major Internet standards for the wireless medium; this is the one major exception from the IP standard referred to earlier.
The latest and greatest
The exception is WAP: the Wireless Application Protocol, a set of standards for wireless application development promoted by the WAP Forum. A rallying point rather than a standards group, the WAP Forum brings together a wide range of vendors with an interest in wireless applications: Motorola, Ericsson, Nokia; AT&T, Deutsche Telecom, One 2 One; Symbian, Microsoft, Geoworks and IBM. IBM's commitment is particularly significant, as the company has considerably less invested in alternatives to WAP than many of its fellow board members.
The existence of a separate protocol for wireless clients highlights the major potential weak spot in the new server-centred architecture: incompatibilities between the back-end server, running heavy-duty transactional processing, and dumb clients. IBM's architecture shows traces of a 'Java everywhere' approach - EJBs on the transaction server are paralleled by servlets on the application server and applets on the client - but this is clearly not always going to be possible.
Translation is an overhead, however - particularly between languages as distinct as HTML and WML ("a custom transcoder to select the right subset of the application content is also needed for effective HTML-to-WML transcoding", IBM cautions). A different approach has been taken by ADVANCED BusinessLink (ABL), whose Strategi e-business middleware is now WML-enabled.
"It's all about templates - templates and messages," explains ABL's Chris Lategan gnomically. "If you look at a standard application server like WebSphere, you've got CGI traffic being generated: that means every page hit there's a new process being launched on the server, which fetches the data, formats it and sends it back out. The AS/400 isn't designed for that: put a high-volume e-commerce site on there and it's liable to start going slow. But it's not the volumes doing that, it's the type of load." The alternative is to initiate a single process which passes out the data requested in the form of messages; these can then be formatted, applying the required templates before sending them back out to the browser. Moreover, Lategan's definition of 'template' covers a lot of ground: "WML's just another template," he comments. "You don't need to translate existing traffic: just design a new front end for your wireless devices. The Web server at the back end can keep firing out the same messages."
The Strategi approach to WML demonstrates the power and flexibility of the new e-business architecture. On the periphery, there are clients which can be as dumb as a mobile phone; in the middle, there is a network with no intelligence of its own, which is available wherever a mobile phone can get a signal; at the centre, the transaction server can be exposed to the Internet without any intermediary in the form of a separate machine. All the processing power and intelligence required by either application serving or traditional transaction processing are concentrated in one place, taking advantage of the AS/400's multi-processing strengths as well as its fabled robustness and manageability. The new 'pervasive' landscape turns out to require some very familiar capabilities on the server side. When you pick up your mail on your Watchpad, it could well be dialling in to an AS/400.
Phil Edwards is a senior contributor to NEWS/400.uk