- Email: [email protected]
Gateway connections in external computers
Gateway connections in external computers The development of software for a third-party database system is described by J M Holme
The software for the Prestel Gateway to third-party databases was originally developed for the Bildschirmtext market trial carried out by the FRG Post Office. Based on experience gained in the specification of this software, and in the coordination of the introduction of Bildschirmtext, it is possible to describe the software development required in a third-party database to achieve a Gateway connection, and to give an indication of the costs. Keywords: viewdata, software, database, gateway
BILDSCHIRMTEXT AND GATEWAY In 1976, the Deutsche Bundespost (DBP) started private trials of Prestel software from the British Post Office (BPO), with the aim of providing a viewdata service (Bildschirmtext) in the FRG. The DBP, however, realised the advantages of connecting the private databases of information providers (IPs) directly into Bildschirmtext, and so commissionedthe development of the Gateway software. The BPO, noted the success of Gateway and bought the software from the DBP. Since June 1980, the DBP have operated a Bildschirmtext (BTX) market trial based on two central computers in Berlin and Dusseldorf. There are now over 30 third-party databases, or external computers (ECs) as they are correctly known, registered with the DBP. The normal connection between an EC and a BTX central computer (BTZ) is over the public packetswitching network (Datex-P) using an X.25 interface. During the market trial, however, ECs that do not have X.25 software can communicate with a BTZ through a front-end processor using a BSC protocol.
EXTERNAL C O M P U T E R G A T E W A Y SO FTWA R E The computer manager considering a connection to Gateway is faced with several initial problems: Danet, Geschaftsbereich ffir Beratung und Softwareenwicklung der Datel GmbH, Ostend 29, 6103 Griesheim bei Darmstadt, FRG
vol 5 no 2 april 1982
• vagueness about the system interfaces of his own host computer, • lack of understanding of the Gateway protocol and its potential, • lack of store and preparation software for BTX information, • uncertainty of development costs. The first three of these problems each require the development or purchase of software. The costs will be discussed below. Figure 1 illustrates the main components of a Gateway connection. These are: • X.25 software • Gateway protocol handler • application controller The development of such a system usually proceeds in the following steps: • implementation of PAD, protocol handler and offline simulator, • test of simple application with the simulator, • integration of the system and online testing, • extensions to applications and viewdata system (e.g. Editor, statistics, database).
X.25 interface The CCITT recommendation X.25 represents the three lowest layers of the ISO seven-layer reference mode. X.25 is now offered as a standard packet by most manufacturers, although not all include a packet assembly/ disassembly (PAD) function. It should also be noted that the CCITT has issued several updates of its recommendation, which can lead to inconsistencies between different implementations of X.25.
Gateway protocol handler The Gateway protocol has proved to be easily understood. It is the rough equivalent of ISO layers 4, 5 and 6 and describes the messages which provide communi-
0 1 4 0 - 3 6 6 4 / 8 2 / 0 2 0 0 5 9 - 0 3 5 0 3 . 0 0 © 1 9 8 2 B u t t e r w o r t h & C o ( P u b l i s h e r s ) Ltd.
59
System manager I
BTZ X 25
J
Gateway protocol handler
Of-fline test I simu afar
/
Applical-ion
'
'ppliat'°i °
~pplication ~ " :ontrol ~
AppliTvatior1
Page editor
Figure 1. Gateway software In external computer cation between the BTZ and the EC. It is imperative that an EC handles the protocol correctly, since some error situations can bring down the BTZ. The messages are in the form of blocks, of which there are two groups: control blocks and data blocks. Control blocks are used to: • request the establishment of a connection, • positively or negatively acknowledge a connection request, • request a disconnection, • acknowledge received data, • transmit error messages. Data blocks contain viewdata pages, together with their control information and user input requests. The time that a viewdata user is in communication with an EC is known as a session. There will, of course, be several simultaneous sessions, the number being limited by the number of virtual circuits supported by X.25. A session consists of three phases: connection, data exchange and disconnection. This is illustrated in Figure 2. Blocks are exchanged in strict dialogue mode between EC and BTZ, except in an abnormal situation, when either partner can request an asynchronous disconnection. The connection sequence is initiated when a user who is in communication with the BTZ requests the gateway page number of an EC. This page instructs the user to enter '#' to build a connection. This causes the BTZ to send the EC a connection request, which the EC either refuses or acknowledges. If the request is refused or not answered, no connection occurs and the user is notified with a line 24 message from the BTZ. If, however, the request is acknowledged, the BTZ requests a'welcome page' from the EC. The EC returns this page, which is contained in a page data block, and it is displayed to the user. The session is now established. Data blocks are of two types; page data blocks and control data blocks. User requests are passed to the EC in control data blocks which request either specific page numbers or previous page. An EC is, of course, completely free to interpret such requests as it wants. It need not return the requested page numberand how it maintains the previous page stack is its own affair. Page data blocks are subdivided into information retrieval (IR), data collection (DC) and collected data. IR pages contain information only. DC pages additionally offer the user the possibility to enter data into fields defined in the text. User-entered data is
60
transferred back to the EC in collected data blocks. IR pages offer the standard choice facility. The DC page displayed to the user is, in fact, built up of several page data blocks which are chained together and individually requested from the EC by the BTZ. Only when all blocks in a DC chain have been transmitted between the EC and the BTZ is the text displayed to the user. The displayable text is contained in the first block of the chain. The second block defines the fields within the text where the user can enter data, and the remaining pages contain prompt messages for each field. These appear on line 23. The EC has the option of acknowledging a collected data block from the BTZ with a short 'acknowledgement block', which causes the BTZ to redisplay the previous DC page to the user. This saves transmission costs if the same DC page is to be used repeatedly. A session is ended when the user requests a 'goodbye page', either by choice or direct selection. This is a special IR page which, when sent from the EC to the BTZ, causes the BTZ to reply with a disconnection request which the EC should acknowledge. The protocol handler in the EC must ensure that for each session, the protocol is in the correct state for the current block being sent or received. It must also check the formats of all blocks and control each exchange with a timer. Any errors cause a session to be broken off with the optional transmission of a diagnostic line 24 message code.
Application controller The third main software component in an EC is the application controller. This is situated between the protocol handler and the viewdata applications. Its design is completely in the hands of the EC. Its main functions, however, are to check and store user passwords to ensure that only authorized members of closed user groups have access to privileged data. It User
BTZ
EC Connection request Conrlec'l'ioN acknowledge Welcome page request
.,i
Welcome page
NNNN#
i=
Welcome page
Specific page request DC text page Specific page request
g
E O
DC ~ield page Specific page request
g
DC text page
DC prompt page
User data
Collected data
Repeat DC text page
g E
~9#
Goodbye page request
i Goodbye page
E3
Acknowledgement
Goodbye page Disconnection request Disconnection ocknowledqe
Figure 2.
Protocol exchange during session
computer communications
also distributes page requests to the relevant applications, maintains the previous page stack and initiates statistics gathering as required.
Additional software In addition to the three main components already mentioned, there are several extra components essential for any EC. First, a page editor is required to create and store pages. Some editors have been designed which use a normal monochrome VDU, but even when combined with a colour television they are not very satisfactory. The best and most expensive solution is a system designed around an intelligent colour/graphics terminal. Second, for development work, a BTZ simulator is indispensible, enabling applications to be tested offline, since the possibility of testing with the Post Offices own 'test' BTZ is severely limited. Lastly, the whole viewdata system in an EC should be controlled by a system manager, who can dynamically alter the workload (e.g. number of simultaneous sessions), kill sessions, maintain membership of closed user groups and set statistics gathering criteria.
COSTS
years of effort seems to be about average. This can be reduced to 2 or 3 man years, if existing packets and designs are bought from outside. In the FRG, several manufacturers and one software house offer a range of Gateway support. This can be a complete system, or any individual part (editor, protocol handler, application controller). It has also proved fairly straightforward to adapt suitable existing applications to viewdata, for example, private viewdata systems and text editor systems such as Stairs. One interesting development in the FRG is the replacement of viewdata terminals (colour TV and decoder) with intelligent computer terminals and software to emulate the decoder. This provides real computer-to-computer communications, using the gateway protocol in an open network.
REFERENCES 1
Bildschirmtext, Beschriebung und Anwendungsmoglichkeiten Bundesminister fur das Post- und Fernmeldwesen, FRG (1980) Boring, I 'Rechnerverbund im BildschirmtextFeldversuch Bildschirmtext Actuell No 4/5 (July 1980) Doring, I 'Der Externe Rechner im Bildschirmtext Rechnerverbund, Erfahrung beim Anschluss externer Datenbanken' presented at Online 81,
2
3
Costs are difficult to estimate, since they depend on the complexity of the applications, but to achieve a basic system as described here, between 4 and 8 man
UK (1981)
OlSPLR, u Technology & Applications the international journal covering developments in both the technology and applications of displays
Coverage includes: • Digital and alphanumeric displays • Graphic and pictorial displays • Picture processing • Systems design • Commercial evaluation of display technologies • Novel and developing applications • Ergonomic considerations in display design and use i
vol 5 no 2 april 1982
For further details complete and return the coupon nm ann n
w
aml unl
m
m
a n m amm a i m a m
am
alnl n
aim im
|
am
n
|
|
|
To: Christine Mullins Butterworth Scientific
II | | |
Limited - - Journals Division PO Box 63 Westbury House Bury Street Guildford Surrey GU2 5BH England Telephone: 0483 31261 Telex: 859556
an
an
I | I| | |
I
Please send me further details on DISPLAYS I would like a sample copy [] Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organisation and address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I
,11
61
The software for the Prestel Gateway to third-party databases was originally developed for the Bildschirmtext market trial carried out by the FRG Post Office. Based on experience gained in the specification of this software, and in the coordination of the introduction of Bildschirmtext, it is possible to describe the software development required in a third-party database to achieve a Gateway connection, and to give an indication of the costs. Keywords: viewdata, software, database, gateway
BILDSCHIRMTEXT AND GATEWAY In 1976, the Deutsche Bundespost (DBP) started private trials of Prestel software from the British Post Office (BPO), with the aim of providing a viewdata service (Bildschirmtext) in the FRG. The DBP, however, realised the advantages of connecting the private databases of information providers (IPs) directly into Bildschirmtext, and so commissionedthe development of the Gateway software. The BPO, noted the success of Gateway and bought the software from the DBP. Since June 1980, the DBP have operated a Bildschirmtext (BTX) market trial based on two central computers in Berlin and Dusseldorf. There are now over 30 third-party databases, or external computers (ECs) as they are correctly known, registered with the DBP. The normal connection between an EC and a BTX central computer (BTZ) is over the public packetswitching network (Datex-P) using an X.25 interface. During the market trial, however, ECs that do not have X.25 software can communicate with a BTZ through a front-end processor using a BSC protocol.
EXTERNAL C O M P U T E R G A T E W A Y SO FTWA R E The computer manager considering a connection to Gateway is faced with several initial problems: Danet, Geschaftsbereich ffir Beratung und Softwareenwicklung der Datel GmbH, Ostend 29, 6103 Griesheim bei Darmstadt, FRG
vol 5 no 2 april 1982
• vagueness about the system interfaces of his own host computer, • lack of understanding of the Gateway protocol and its potential, • lack of store and preparation software for BTX information, • uncertainty of development costs. The first three of these problems each require the development or purchase of software. The costs will be discussed below. Figure 1 illustrates the main components of a Gateway connection. These are: • X.25 software • Gateway protocol handler • application controller The development of such a system usually proceeds in the following steps: • implementation of PAD, protocol handler and offline simulator, • test of simple application with the simulator, • integration of the system and online testing, • extensions to applications and viewdata system (e.g. Editor, statistics, database).
X.25 interface The CCITT recommendation X.25 represents the three lowest layers of the ISO seven-layer reference mode. X.25 is now offered as a standard packet by most manufacturers, although not all include a packet assembly/ disassembly (PAD) function. It should also be noted that the CCITT has issued several updates of its recommendation, which can lead to inconsistencies between different implementations of X.25.
Gateway protocol handler The Gateway protocol has proved to be easily understood. It is the rough equivalent of ISO layers 4, 5 and 6 and describes the messages which provide communi-
0 1 4 0 - 3 6 6 4 / 8 2 / 0 2 0 0 5 9 - 0 3 5 0 3 . 0 0 © 1 9 8 2 B u t t e r w o r t h & C o ( P u b l i s h e r s ) Ltd.
59
System manager I
BTZ X 25
J
Gateway protocol handler
Of-fline test I simu afar
/
Applical-ion
'
'ppliat'°i °
~pplication ~ " :ontrol ~
AppliTvatior1
Page editor
Figure 1. Gateway software In external computer cation between the BTZ and the EC. It is imperative that an EC handles the protocol correctly, since some error situations can bring down the BTZ. The messages are in the form of blocks, of which there are two groups: control blocks and data blocks. Control blocks are used to: • request the establishment of a connection, • positively or negatively acknowledge a connection request, • request a disconnection, • acknowledge received data, • transmit error messages. Data blocks contain viewdata pages, together with their control information and user input requests. The time that a viewdata user is in communication with an EC is known as a session. There will, of course, be several simultaneous sessions, the number being limited by the number of virtual circuits supported by X.25. A session consists of three phases: connection, data exchange and disconnection. This is illustrated in Figure 2. Blocks are exchanged in strict dialogue mode between EC and BTZ, except in an abnormal situation, when either partner can request an asynchronous disconnection. The connection sequence is initiated when a user who is in communication with the BTZ requests the gateway page number of an EC. This page instructs the user to enter '#' to build a connection. This causes the BTZ to send the EC a connection request, which the EC either refuses or acknowledges. If the request is refused or not answered, no connection occurs and the user is notified with a line 24 message from the BTZ. If, however, the request is acknowledged, the BTZ requests a'welcome page' from the EC. The EC returns this page, which is contained in a page data block, and it is displayed to the user. The session is now established. Data blocks are of two types; page data blocks and control data blocks. User requests are passed to the EC in control data blocks which request either specific page numbers or previous page. An EC is, of course, completely free to interpret such requests as it wants. It need not return the requested page numberand how it maintains the previous page stack is its own affair. Page data blocks are subdivided into information retrieval (IR), data collection (DC) and collected data. IR pages contain information only. DC pages additionally offer the user the possibility to enter data into fields defined in the text. User-entered data is
60
transferred back to the EC in collected data blocks. IR pages offer the standard choice facility. The DC page displayed to the user is, in fact, built up of several page data blocks which are chained together and individually requested from the EC by the BTZ. Only when all blocks in a DC chain have been transmitted between the EC and the BTZ is the text displayed to the user. The displayable text is contained in the first block of the chain. The second block defines the fields within the text where the user can enter data, and the remaining pages contain prompt messages for each field. These appear on line 23. The EC has the option of acknowledging a collected data block from the BTZ with a short 'acknowledgement block', which causes the BTZ to redisplay the previous DC page to the user. This saves transmission costs if the same DC page is to be used repeatedly. A session is ended when the user requests a 'goodbye page', either by choice or direct selection. This is a special IR page which, when sent from the EC to the BTZ, causes the BTZ to reply with a disconnection request which the EC should acknowledge. The protocol handler in the EC must ensure that for each session, the protocol is in the correct state for the current block being sent or received. It must also check the formats of all blocks and control each exchange with a timer. Any errors cause a session to be broken off with the optional transmission of a diagnostic line 24 message code.
Application controller The third main software component in an EC is the application controller. This is situated between the protocol handler and the viewdata applications. Its design is completely in the hands of the EC. Its main functions, however, are to check and store user passwords to ensure that only authorized members of closed user groups have access to privileged data. It User
BTZ
EC Connection request Conrlec'l'ioN acknowledge Welcome page request
.,i
Welcome page
NNNN#
i=
Welcome page
Specific page request DC text page Specific page request
g
E O
DC ~ield page Specific page request
g
DC text page
DC prompt page
User data
Collected data
Repeat DC text page
g E
~9#
Goodbye page request
i Goodbye page
E3
Acknowledgement
Goodbye page Disconnection request Disconnection ocknowledqe
Figure 2.
Protocol exchange during session
computer communications
also distributes page requests to the relevant applications, maintains the previous page stack and initiates statistics gathering as required.
Additional software In addition to the three main components already mentioned, there are several extra components essential for any EC. First, a page editor is required to create and store pages. Some editors have been designed which use a normal monochrome VDU, but even when combined with a colour television they are not very satisfactory. The best and most expensive solution is a system designed around an intelligent colour/graphics terminal. Second, for development work, a BTZ simulator is indispensible, enabling applications to be tested offline, since the possibility of testing with the Post Offices own 'test' BTZ is severely limited. Lastly, the whole viewdata system in an EC should be controlled by a system manager, who can dynamically alter the workload (e.g. number of simultaneous sessions), kill sessions, maintain membership of closed user groups and set statistics gathering criteria.
COSTS
years of effort seems to be about average. This can be reduced to 2 or 3 man years, if existing packets and designs are bought from outside. In the FRG, several manufacturers and one software house offer a range of Gateway support. This can be a complete system, or any individual part (editor, protocol handler, application controller). It has also proved fairly straightforward to adapt suitable existing applications to viewdata, for example, private viewdata systems and text editor systems such as Stairs. One interesting development in the FRG is the replacement of viewdata terminals (colour TV and decoder) with intelligent computer terminals and software to emulate the decoder. This provides real computer-to-computer communications, using the gateway protocol in an open network.
REFERENCES 1
Bildschirmtext, Beschriebung und Anwendungsmoglichkeiten Bundesminister fur das Post- und Fernmeldwesen, FRG (1980) Boring, I 'Rechnerverbund im BildschirmtextFeldversuch Bildschirmtext Actuell No 4/5 (July 1980) Doring, I 'Der Externe Rechner im Bildschirmtext Rechnerverbund, Erfahrung beim Anschluss externer Datenbanken' presented at Online 81,
2
3
Costs are difficult to estimate, since they depend on the complexity of the applications, but to achieve a basic system as described here, between 4 and 8 man
UK (1981)
OlSPLR, u Technology & Applications the international journal covering developments in both the technology and applications of displays
Coverage includes: • Digital and alphanumeric displays • Graphic and pictorial displays • Picture processing • Systems design • Commercial evaluation of display technologies • Novel and developing applications • Ergonomic considerations in display design and use i
vol 5 no 2 april 1982
For further details complete and return the coupon nm ann n
w
aml unl
m
m
a n m amm a i m a m
am
alnl n
aim im
|
am
n
|
|
|
To: Christine Mullins Butterworth Scientific
II | | |
Limited - - Journals Division PO Box 63 Westbury House Bury Street Guildford Surrey GU2 5BH England Telephone: 0483 31261 Telex: 859556
an
an
I | I| | |
I
Please send me further details on DISPLAYS I would like a sample copy [] Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organisation and address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I
,11
61