Contribution to the Workshop "Offering the same information via multiple services" of the First International Conference on the World-Wide Web, Geneva, May 1994.

Multiple Service Integration Confronted with Legacy Systems

Louis Perrochon

Institut fuer Informationssysteme

ETH Zuerich

8092 Zuerich, Switzerland

e-mail: perrochon@acm.org

phone: ++41-1-632 72 82

fax: ++41-1-632 11 72

Abstract

Like the data migration research community, the field of multiple service integration is confronted with legacy systems. Despite of the new interfaces providing uniform access to variety of information (e.g. WWW, Gopher), plenty of information is still accessed using interactive services with textual interfaces. The lucky case are interfaces based on DEC's VT100 or IBM's 3270 standards. To allow access to interactive services, the straight forward solution was the introduction of special URI-Schemes (telnet, rlogin and tn3270). Nevertheless is the user forced to fight a new interface almost every time he hits an interactive session. We introduce a translation server to allow easier access to interactive sessions.

Keywords: Multiple service integration, legacy systems, World Wide Web (WWW), interactive session, textual interface, translation server.

Open Questions: More examples of legacy systems with textual interfaces? How much can be covered using translation servers? How to define a schema? Are there suitable languages (ASM.1?) available?

1. Introduction

Normally researchers prefer to start their work from scratch and develop new ideas. But the necessity of re-engineering is more and more widely acknowledged. Thus re-engineering of existing software (cf. proceedings of the software engineering conferences) and data (only recently, e.g. [AP93]) is a growing field of research. Up to now, most of the work is done in fields, where existing solutions are already very old, e.g. in the database field.

Like the database migration research community, the field of multiple service integration is confronted with legacy systems. Although the new client-server based interfaces (like WWW or Gopher) provide uniform access to a variety of information, plenty of it is still accessed using an interactive services. Interactive services normally provide some kind of specially designed service interface. Service interfaces based on DEC's VT100 or IBM's 3270 standards are nice, because sometimes only a teletype based interface is offered.

To include information offered by interactive services in WWW, special Universal Resource Identifiers (URI) Schemes (telnet, rlogin and tn3270) have been defined. This allows some kind of transparent access to interactive services. Nevertheless is the user forced to fight a new service interface almost every time he hits an interactive session.

The goal of this paper is to show and discuss some solutions, how to integrate certain types of interactive services into the universal set of objects as defined in the WWW-context.

2. Some Examples of Interactive Sessions

Below some examples of interactive services are listed. They share two important properties. First, the service providers are, for any reason, not (yet) offering their service via another access-protocol. Second the services are of a simple request-respond type, similar to search-fields.

2.1 SVI-Kurs

SVI-Kurs has been build by the Development and Application Research Group of the ETH-Zurich as a service to the Swiss Computer Science Associations (SVI). SVI-Kurs is an information system offering information on non-commercial computer science related conferences and seminars. SVI-Kurs has been written for exactly this purpose and then been integrated in our campus information system (ezInfo, telnet://guest@ezinfo.ethz.ch/) (Fig. 6).

The data provided in SVI-Kurs is our main information to be offered via multiple services. We spend some time right now to offer the same information using the Swiss Telecom's Videotex system. And soon the embedding campus information system ezInfo will migrate to a new platform (probably WWW). If we can't offer the same information using other services until then, we'll have to migrate our home-grown software too.

2.2 Information Retrieval on INFBIB

The Information Retrieval Research Group of the ETH Zurich offers a retrieval system based on the catalogue of our department library ([Sch93], telnet://infbib@orion.inf.ethz.ch/). It accepts queries from users and produces a list of books, sorted by relevance to the query (Fig. 5.).

2.3 ETV

ETV (Elektronisches Teilnehmerverzeichnis) is an electronic white/yellow pages directory of all the phone numbers in Switzerland (sorry, no URL, as it can't be accessed by everybody) (Fig. 7). This user interface is quite comfortable, especially to casual users. Notwithstanding users which use it only infrequently have problems. By the way, the provided interface is quite new, it used to be worse not long ago.

2.4 Interactive Games

It is our opinion, that games are a perfect study area for complex problems, as they take place in a well specified mini-world. We are looking for a slightly interactive multi user game, i.e. one that does not rely on immediate response from the user. Interactive games offered on the internet are normally built in people's spare time. Thus available programming capacities for an additional WWW-Interface are sometimes not available.

3. Definitions

We will now define some terms as they are used in this paper: A client is either a WWW-client or a product with similar functionality (i.e. a Gopher-client).

Using an interactive service, the user has to provide the request for information in a dialogue with the machine. Request-respond services accept the user's request in one block. The latter is also called client-server computing, where the client issues one request and gets one response from the server. Please note, that also clients (defined as above) offer an interactive service, as the user has to go through a dialogue with the client to access useful information. In contrast, servers (WWW, Gopher or similar) offer request-respond services.

Textual service denotes an existing interactive service with some kind of textual interface (no GUI), that can for any reason (e.g. cost, computing power) not be migrated to a new interface. Examples are services like most libraries and many home grown services (as described above). Note that the word textual should not imply bad. In fact many of these textual interfaces have been carefully defined and have been in use for years without complaints.

In the WWW context, interactive services are called interactive sessions. There exists special URIs for some of them (telnet, rlogin, tn3270). These three examples refer to textual services. Normally the client doesn't handle such interactive sessions itself but delegates this task to external programs. Other interactive services, especially those with graphical interfaces, currently have to find other ways. Some WWW-servers understand specialised URIs and provide the user with a direct service interface popped up on the users screen directly (based on the X-Windows system).

The term client interface refers to the graphical interface the client is providing. The interface of a textual service is referred to as textual interface (Fig. 1).

A complete description of the protocol (or a subpart of it) that is used while accessing a textual service, is called a schema. It must be written in a standardised language.

4. Translation Servers

In this chapter we will finally show our approach to the problem:

We plan to set up translation servers, that can access textual services and provide a uniform access to the user. The textual services would be classified depending on the kind of dialogue they require, and each textual service would have to describe its own textual interface protocol (i.e. its schema) in a protocol description language. The translation server will then access the textual services and via a client, provide a common client interface to the user (Fig. 3). Using different translation servers and clients, any desired client interface could be served. Thus different user can access the same textual service in different ways.

              +--------------+  --- client interface
              ŚModern Service|
              +--------------+
                     Ś
            +------------------+
            |Translation ServerŚ
            +------------------+
                     Ś
              +---------------+ --- textual interface
              |Textual Service|
              +---------------+

Fig. 1. Translation Servers

Such an indirect upgrading of a textual interface to a graphical client interface using a translation server is much cheaper, as one translation server per requested client interface is enough for a range of textual systems. The textual system's protocol must just be described once.

4.1 Protocol Definition

As a first step we look at different textual interfaces and define possible classes of textual interfaces. For each class a protocol template is specified. The individual services interface will then be described in a schema using this template. Figures 2 and 3 give an idea, of how such a schema could look like. In this context, it seems reasonable to encode special characters using the WWW-Style (although such characters have been ignored in the examples for better readability).

SERVICE_URL=telnet://orion.ethz.ch
SERVICE_NAME="Finger Service"
QUERY_TEXT="Please enter name:"
ON {anysign}.ch. SEND $answer1
START_TRANSLATE                    -- Send everything to user, just as we get it

Fig. 2. Description of a simple interactive service.

SERVICE_URL=telnet://guest@ezinfo.ethz.ch
SERVICE_NAME="SVI-Kurs by subject"
QUERY_TEXT=SVI_Kurs.html           -- This must return an integer $checkbox
SEQUENCE
  ON Username: SEND $username END
  ON "ezinfo>" SEND "EXTORG SVIKURS" WAIT 1 SEND 2 END
  ON ">" SEND $checkbox            -- This will select the appropriate submenu
  TRANSLATE USING FILTER VT100     -- Send the result, but filter out VT100 codes
END SEQUENCE
END "E" WAIT 1 "LOG"

Fig. 3. Description of a subpart of SVI-Kurs: Select events according to subject.

Ideally any schema can be written interactively. A generator tool can monitor a typical session, i.e. one of the kind that will be offered via the translation server. Each action of this sessions user must then be caught by the tool and documented by the user so the tool can compile a description.

4.2 Translation Server

The Translation Server should be able to parse such a schema and compose WWW-Objects to get the necessary information from the user. The result, returned with the TRANSLATE statement, should be translated on-the-fly and returned as a WWW-Object too, most presumably a html-page.

There is no restriction to a single request-respond iteration. Consecutive processes could be implemented on specialised translation servers. This might require more than a simple protocol description language.

4.3 Client

For the client, everything is transparent. Any WWW-Client should be able to access a translation server. The object-type of the query would most probably be a page with some forms in it, the result a simple html-page.

5. Implementation Aspects

With the Common Gateway Interface (CGI) an interface for running external programs under an information server is available. It is supported at least by the NCSA's httpd. A WWW-server supporting CGI can start an external program and support it with information from the user. The server then relays the results of the external program to the client. It seems reasonable to implement a translation server accordingly to the CGI Specifications. Fig.1 would then look like Fig. 4. A translation server for the Gopher client can similarly be implemented, as also many gopher servers support the execution of external programs. Some parts of the translation server are thus already available But he translation server is not superfluous. Without translation server an external program must be written for each textual service And the translation of the result to html (or any other document type) is neither supported via CGI nor Gopher.

              +--------------+ --- client interface
              ŚModern Service|
              +--------------+
                     Ś
          +----------------------+
          |CGI capable WWW-ServerŚ
          +----------------------+ --- CGI interface
          |  Translation Server  Ś
          +----------------------+
                     Ś
              +---------------+ --- textual interface
              |Textual Service|
              +---------------+

Fig. 4. Translation Servers implemented via the CGI

6. Discussion

6.1 Benefits

Providers of legacy systems don't have to take big cost to offer their service via new user interfaces. All they have to do, is deliver a description of their existing textual interface to a translation server. The translation servers will then translate the interface to the user's preferred view.

The same holds for providers of new services. They can build a simple textual interface and broadcast the description.

All the aspects of different character sets and communication differences between heterogeneous computers are shielded from the provider of a service. He has to offer one simple textual interface to server a multitude of users with different character sets, languages and understandings of how a GUI should look like.

6.2 Disadvantages

Commercial Services will not easily be able to bill the client, as the requests are relayed by a translation server. The same problems holds also for "Proxy"-Servers and is discussed in other contexts. Additions to the WWW-protocol should be able to solve such conflicts.

Due to the different functionality of all the services, some of the functions are expected to be lost. It is not clear, where the border between full support and simplicity can be drawn.

The main disadvantage is the vulnerability to changes in the textual interface. Every such change has to be accompanied by a redesign of the respective schema.

7. Future

The problem of accessing information hidden behind textual services remains.

As soon legacy database systems can be accessed using SQL and until SQL-access using systems like WWW is easily available, some problems will be solved. We guess, that even then, the basic problem remains. We believe, that only the definition of a legacy system will shift. Providers of a working service suddenly must provide another interface.

References

[AP93] Aebi, D. and Perrochon, L. Towards Improving Data Quality. CISMOD 93, New Delhi, October 1993. [Sch93] Schaeuble, P. A Multiuser Information Retrieval System for Semistructured and Dynamic Data. Proceedings of the 16th International ACM SIGIR Conference, Pittsburgh, June 1993


INFBIB                                                 SPIDER V1.3

+----------------------------------------------------------------+
|           I N F O R M A T I K    B I B L I O T H E K           |
+----------------------------------------------------------------+


INFBIB basiert auf dem SPIDER Information Retrieval System und er-
moeglicht ein effizientes Recherchieren im Katalog der Informatik-
bibliothek.

ANLEITUNG: Tippen Sie einfach Suchwoerter ein und starten Sie die
Suche mit <return>. Weitere Details finden Sie im Hilfetext ('help'
und <return> eingeben).

AUSKUNFT: Bei Fragen, Problemen, Anregungen, usw.... senden Sie
bitte eine mail an infbib@inf.ethz.ch


(h)elp (r)etrieve (s)how (n)ext (p)rev (m)ail (q)uit
: r
  Enter your query or <return> to escape.
  query> information retrieval
  Enter the max. number of books to be retrieved
  or <return> for the default number (20).
  number> 5

Rank   Score  Title
-----------------------------------------------------------------
  1.   4.074  Information Retrieval
  2.   3.663  Information Retrieval Based on Information Structur
  3.   3.663  Information Retrieval Based on Information Structur
  4.   3.663  Vocabulary Control for Information Retrieval
  5.   3.644  Research and Development in Information Retrieval

(h)elp (r)etrieve (s)how (n)ext (p)rev (m)ail (q)uit: Interactive Sessions
: s 3

Book on rank 3
--------------
Title       : ---------------------------------------------------
Information Retrieval Based on Information Structures
-----------------------------------------------------------------
Authors     : Schaeuble, P.
Publisher   : Verlag der Fachvereine
Signature   : RD.89.15
Year        : 1989

(h)elp (r)etrieve (s)how (n)ext (p)rev (m)ail (q)uit
: q

Fig. 5. INFBIB

 CALENDAR OF EVENTS  SVI/FSI 
                                                                              
       Display all events                                                     

 (1)   02.05.94  Informatik '94 - Stand und Trends                            
                                                                              
 (2)   03.05.94  Informatik-Sicherheit: Ein Muss zur Risikoabwendung im       
                                                                              
 (3)   10.05.94  Virtual Reality: Anwendung und Entwicklungsrichtungen        
                                                                              
 (4)   11.05.94  Le Language Clipper                                          
                                                                              
 (5)   24.05.94  Fourth Intern. Conference on Principles of Knowledge         
                                                                              
 (6)   24.05.94  ACM SIGMOD / PODS 94                                         
                                                                              
 more..
 (M)enu          (N)ext page                 (H)elp                           
 (B)ack                                      (E)xit                           

 >

Fig. 6. SVI-Kurs (probably with a typical demonstration of character-set mismatches)

 ETV V1.2-1 - Telephone Directory                 entry #:   1      total:   1

 last name:      Perrochon                                                   
 first name:     Louis                                                       
 maiden name:                                                                
 street:         Schoentalstr. 19                               
 ZIP/city:       8004 / Zuerich                                  canton: ZH 

 tel. number:    01  / 241 02 08                                             

 rubric:                                                                     
 generic term:                                                               
 profession:                                                                 
                                                                             

 add. info:      (Wuenscht keine Werbung) -                                  

 entries:       private              search range:  city                     
                                     spelling:      phonetic                 


 DOWN forward        UP back       RETURN,ENTER overview       Ctrl/N new query
 Ctrl/E edit input            Ctrl/V original output page           Ctrl/Z quit

Fig. 7. ETV (another demonstration of character-set mismatches)