Using XML to Integrate existing Software Systems

into the Web

Harry M. Sneed
Institut für Wirtschaftsinformatik, Universität Regensburg
CaseConsult GmbH, Wiesbaden, Germany
Email: Harry.Sneed@T-Online.de

Abstract:The eXtensible Markup Language – 70 % of all mainframe applications.[2] A recent

XML – is not only a language for communication study in Germany conducted by the University of

between humans and the web, it is also a language Karlsruhe discovered that more than 60 % of the

for communication between programs. Rather than productive applications in German industry run on

passing parameters, programs can pass documents the mainframe. Especially in the financial sector

from one to another, containing not only pure data, where banks, insurance companies and credit

but control information as well. Even legacy institutes are active, but also in the trade sector and

programs written in ancient languages such as in governmental administration, the host computer

COBOL and PL/I can be adapted by means of remains the workhorse of information technology.

interface reengineering to process and to generate Of the largest 2000 enterprises in the world, over

XML documents. This paper intends to describe the 90% employ an IBM-390 as a central server. [3]

process and the tools required to accomplish that

goal and to present three cases – one for online, one Therefore, it is ignorant to ignore those application

for batch and one for subprograms – to illustrate systems which are running on the host. The fact

how XML may be used to integrate existing that they are still there, despite several attempts in

software systems into the web. the 1990’s to replace them with client/server

Keywords: XML, Software Reengineering, Data systems, underlines the necessity to cope with

Conversion, Integration, Framework, Enterprise them.

Application Integration, e-Commerce

The Case for layered Reuse of existing
Systems
Most large commercial organizations
application systems which date back to the 1970’s
and 1980’s. Recent studies show that 80 % of the
actual IT-production is carried out by legacy
systems.[1] COBOL is still the most widely used
language in the mainframe world, making up for
The strategy advocated by an IBM white paper in
the late 1990’s and adapted here is not to replace
the host but to reemploy it as the hub of an
enterprise intranet.[4] In so doing, it is also
necessary to encapsulate the existing legacy
have software and data within the new intranet
architecture. They actually become the core of the
future web based information systems. The data
remains in a hierarchical or relational database on
the host, e. g. IMS or DB2. The access shell is
separated from the application programs, so that all
requests for data pass through that shell no matter
where they originate from. The host application
programs whether they be online or batch go
through the access shell to obtain and store their
data. The batch programs can be triggered from a
remote client. The online programs can run either in
a traditional mode with 3270 terminals under a
classical teleprocessing monitor such as IMS or
CICS, or in an internet mode with a web server
such as Websphere or DotNet. Furthermore, both
host and batch programs as well as their common
subprograms can be accessed from other programs
in the periphery to service their requests. In that
way additional application layers can be added on
without having to reimplement the functionality
already existing in the core.[5]
Since it is reasonable to assume that the additional
layers being added to the mainframe core will
themselves become legacy systems in the near
future, it is easy to imagine that over the years a
multilayered architecture will emerge in which each
generation of new software is built on top of the
existing software layers reusing their data and
functionality. (See Figure 1.)
This layered reuse strategy is a cost effective
alternative to the much propagated replacement
strategy whereby the legacy systems are totally
replaced by modern newly developed ones. Studies
have demonstrated that layered reuse is less than
35 % as expensive as replacement systems [6], not
to mention the risk of new development. According
to the study of the Standish Group only some 43 %
of new development projects are ever finished.[7]
Therefore, from an economic point of view, reuse
of existing software systems is definitely a better
choice. Both, the costs and the risks are less, as is
documented in several studies.[8]

Web Web Web Corporate

Browser Browser Browser Users

Web Application Server (Websphere, DotNet)

Work Flow Control Software (JBEE)

Newer Distributed Applications (C++, Java)

Older Host Applications

(Assembler, COBOL, PLI)

Database Access Shell

Corporate
Databases

Figure 1: Layered Software Architecture

The Role of XML in connecting parameters. The programs remain functionally
bound.
Software Layers

For the client/server environment with it’ s statically

The eXtensible Markup Language – XML – was
predetermined interactions between clients and
specified by the W3C Consortium as a more
servers, the CORBA model was sufficient to
sophisticated solution than HTML for human
support program to program communication. This
communication in the internet. Since it was derived
does not hold for the internet where interactions are
form SGML it also had the propensity to represent
not predetermined and where any server can be
any type of document.[9] It is an advantage that
invoked by any client and any server can exchange
with the aide of a style sheet, XML documents can
data with any other server. Here a more flexible
be displayed as web pages or printed as printouts.
means of program to program communication is
In this respect they serve the requirements of
required. The programs should be strictly data
human communication. However, the real benefit
bound, meaning that the sender of a message needs
of XML is that it can be used to exchange data
to know nothing about the receiver of a message.
between programs, programs written in different
All of the information required to respond to a
languages and running in different environments.
message should be in the message itself, i. e. the
messages are self describing.[11]
Up until now programs have been connected
mainly via call interfaces. An entry point or
The same requirements apply to communication
function in the target program is called with a list of
between programs in different layers of software.
parameters. The parameters have to be data types
Since programs in different layers are usually
known both to the source and the target program.
written in different languages for different
Besides they must be in the correct order. Any
environments, their data types and prototypes will
change to the interface on the side of the called
seldom be compatible. For instance COBOL and
program must be reflected in the calling program.
C++ have totally different run time environments
and calling conventions. Thus, calling a COBOL
The CORBA architecture specified by the OMG
program from a C++ class is quite a difficult
and implemented in a number of commercial
matter. Even using CORBA-IDL, there are still
products such as Orbix, Visibroker and Component
compatibility problems which apply to JAVA and
Broker went as far as one could go in standardizing
COBOL as well. PL/I is even worse in this respect,
and refining this type of functional interface. The
since it is totally dependent on the physical
IDL – Interface Definition Language – is used to
environment in which it is executing.[12]
specify the interfaces stored in a common interface
definition repository available to both the client and
If, however, legacy programs in languages such as
the server programs.[10] Thus, both use the same
COBOL or PL/I receive their requests via a data
interface description. Still the client must be aware
interface, the compatibility problems vanish. Any
of what functions to invoke and with which
COBOL or PL/I program can be adapted to read
ASCII character strings. They can recognize tags
and interpret the document type definitions –
DTD’ s. Besides that, a tool can be developed which
would extract the data from the XML document
and convert it to the program input structure. The
only input the tool needs is the original data
structure declaration and a cross reference table to
associate tags in the XML document with field
names in the target program. In this way, any
legacy program, even Assembler ones, can be
adopted to process incoming XML documents and
to generate outgoing XML documents, using the
same technique, only inverted. This technique of
XML-enabling and how it applies to legacy
programs will be describe in the following sections.
Enabling the Legacy Programs
Batch programs are driven by transaction files
produced by some other program. In the simple
case it is one file. In more complicated cases, there
are many files. The read or get statements have to
be replaced by stub calls, i. e. calls to an input
subroutine, to provide the next data record. In the
environment described here, it is the XMLIN
function. Besides the data record, the stub also
provides control information such as the end of file
or invalid key signal. For this additional parameters
are required as illustrated in Figure 2.
Batch programs may also produce output files
which go back to the client. These write or put
statements also have to be replaced by stub calls,
i. e. calls to an output subroutine, to pass on the
current output record. In the environment described

Life would be so simple if only all legacy programs here, this is the XMLOUT function which

were subprograms which receive their input data generates an XML document for the output queue.

from a parameter list. In some cases this is true, but

the vast majority of mainframe legacy programs are Both, the input and the output file statements are

either batch main programs or transaction replaced automatically by the SoftWrap

processing programs. Both have to first be altered preprocessor. To make things more convenient to

before they can be used to service requests from a the user, SoftWrap even displays the names of all

remote client.[13] files used by a program in a list box so that the user
may select which files are to be wrapped, i. e.

Enabling Batch Programs replaced by XML message queues.

<!DOCTYPE RECHNUNG [
<!ELEMENT X-CICS-RETCODE? >
<!ATTLIST X-CICS-RETCODE Type = "int">
<!ELEMENT RECHNUNGSPOSTEN
(AUFTRAGNR,
KUNDENNR,
ARTIKELNR,
ARTIKELNAME,
BESTELLMENGE,
ARTIKELPREIS)>
<!ELEMENT AUFTRAGNR (#PCDATA) >
<!ATTLIST AUFTRAGNR Type (char|dec|pack|int|float|ptr|str) "dec">
<!ELEMENT KUNDENNR (#PCDATA) >
<!ATTLIST KUNDENNR Type (char|dec|pack|int|float|ptr|str) "dec">
<!ELEMENT ARTIKELNR (#PCDATA) >
<!ATTLIST ARTIKELNR Type (char|dec|pack|int|float|ptr|str) "dec">
<!ELEMENT ARTIKELNAME (#PCDATA) >
<!ATTLIST ARTIKELNAME Type (char|dec|pack|int|float|ptr|str) "char">
<!ELEMENT BESTELLMENGE (#PCDATA) >
<!ATTLIST BESTELLMENGE Type (char|dec|pack|int|float|ptr|str) "dec">
<!ELEMENT ARTIKELPREIS (#PCDATA) >
<!ATTLIST ARTIKELPREIS Type (char|dec|pack|int|float|ptr|str) "float">
]>
< RECHNUNG >
< X-CICS-RETCODE>03</X-CICS-RETCODE>
< RECHNUNGSPOSTEN >
< AUFTRAGNR >1001</AUFTRAGNR >
< KUNDENNR >10548501</KUNDENNR >
< ARTIKELNR >4711</ARTIKELNR >
< ARTIKELNAME >Straps</ARTIKELNAME >
< BESTELLMENGE >0010</BESTELLMENGE >
< ARTIKELPREIS >018,50</ARTIKELPREIS >
</RECHNUNGSPOSTEN >
</RECHNUNG >

Figure 2: XML Input Document

Enabling Online Programs

Online transaction programs are driven by terminal
input messages. These may come as a data stream
or as a map. Maps are structured according to some
proprietary convention such as CICS-BMS or IMS-
MFS. In addition to the variable data itself maps
also contain constant texts and control information
such as field attribute bytes and field lengths.
Unfortunately, these controls are often used by the
program to decide what to do next, so they cannot
be removed from the program without causing
errors. The maps are received by proprietary
teleprocessing input operations such as the CICS
RECEIVE macro or the IMS GET UNIQUE call.
Maps are sent by TP-output operations such as the
CICS SEND macro or the IMS INSERT call. To
enable an online program to act as an XML-server,
these operations have to be replaced by stub calls as
illustrated by the following COBOL/CICS program
(see Figure 3).
In the environment under discussion the input maps
are provided by the XMLTPIN function which also
supplies the attribute bytes, field lengths and return
codes. The output maps are handled by the
XMLTPOUT function which extracts the raw data
from the map and passes it on as a data stream.
As with the batch programs all teleprocessing
statements are replaced automatically by the
SoftWrap preprocessor. Here the user has no
choice in the matter. The call statements replacing
them have all the parameters necessary to emulate
the original TP-operation. Teleprocessing messages
may not be left in the program since they would
compete with the message queues coming from and
going to the web. The user may not communicate
with the program both by the traditional terminals
and the web site, i. e. CICS maps and XML
documents. There can only be one mode of human
to program communication at one time.[14]
RECEIVE-RECHNUNG.
MOVE LOW-VALUES TO RECHNUNGSPOSTEN
MOVE SPACES TO ARTIKELNAME
WRAP *****************************************************
WRAP * Replace CICS Receive Map with XML INPUT DOCUMENT
WRAP *****************************************************
WRAP * EXEC CICS RECEIVE MAP (’RECHNUNG’)
WRAP * MAPSET (’ABRECHNG’)
WRAP * INTO (RECHNUNGSPOSTEN)
WRAP * END-EXEC.
WRAP MOVE ’RC’ TO X-CICS-FUNCTION
WRAP MOVE ’RECHNUNG’ TO X-CICS-MAP
WRAP CALL ’XMLTOCOB’ USING X-CICS-FUNCTION,
WRAP X-CICS-RETCODE,
WRAP X-CICS-MAP,
WRAP RECHNUNGSPOSTEN
WRAP MOVE X-CICS-RETCODE TO EIBRESP
WRAP EVALUATE TRUE
WRAP WHEN X-MAPFAIL
WRAP PERFORM VV-860
WRAP WHEN X-PF1
WRAP PERFORM VV-710
WRAP WHEN X-PF2
WRAP PERFORM VV-720
WRAP WHEN X-PF3
WRAP PERFORM VV-730
WRAP WHEN OTHER
WRAP CONTINUE
WRAP END-EVALUATE.

Figure 3: CICS-Map Emulation via XMLTOCOB Stub

Generating the Conversion Tables separated from the program source and usually are
in the form of a copy book, an include or an

The key to converting XML data to Assembler, Assembler macro. A static analysis tool in

COBOL or PL/I data is the data conversion table. XMLWrap processes the data structures to extract

This table contains the names, types, positions, the names, types, lengths, etc. and place them in a

lengths, occurrences and redefinitions of the data in table. The positions of the data fields have to be

the host program interfaces whether they be calculated based on the lengths of the preceding

parameter lists, records, or maps. It is via the data fields. For each program module a separate data

conversion table that character data is extracted conversion table is generated in the form of an

from the XML document to feed the host program XML document with a container tag for each data

interface at runtime. It is also via the data field and an elementary tag for each field attribute.

conversion table that XML documents are The level number of the fields is stored as an XML

generated from the host programs. attribute of the field name. It would be possible to
declare all field attributes as XML data attributes,

To create these tables it is necessary to parse the but it is more flexible and easier to process if they

target program data interfaces. These can be are listed as values.

There is only one document type definition – DTD to have an additional name association table. This is
– for all tables since it is generic to all data a relational table containing binary tuples. Each
structures. It lists the table elements and attributes. binary tuple associates an XML tag with a host
Since the tables are automatically generated, this program field. There must be a 1 : 1 relation
DTD serves more a documentary purpose. A between tag names and field names, otherwise the
sample XML conversion table is displayed in data cannot be converted correctly. If a name such
Figure 4. as “Date” occurs in several places, then it must be
qualified, e. g. Birth.Date or Employment.Date.
Should the XML tags differ from the field names of The hononym, synonym problem is not unique to
the programs, i. e. XML tag names follow other XML documents. It is common to all
conventions than Assembler labels, it is necessary languages.[15]
<MapSet Name = "ABRECHNG">
<Field Level = "77">
<name>X-CICS-RETCODE</name>
<type>B </type>
<pos>0000</pos>
<lng>0002</lng>
<occurs>0001</occurs>
</Field>
<Map Name = "RECHNUNG">
<Field Level = "01">
<name>RECHNUNGSPOSTEN</name>
<occurs>0009</occurs>
</Field>
<Field Level = "02">
<name>AUFTRAGNR</name>
<type>D </type>
<pos>0001</pos>
<lng>0008</lng>
<occurs>0001</occurs>
</Field>
<Field Level = "02">
<name>KUNDENNR</name>
<type>D </type>
<pos>0009</pos>
<lng>0008</lng>
<occurs>0001</occurs>
</Field>
<Field Level = "02">
<name>ARTIKELNR</name>
<type>D </type>
<pos>0017</pos>
<lng>0008</lng>
<occurs>0001</occurs>
</Field>
<Field Level = "02">
<name>ARTIKELNAME</name>
<type>A </type>
<pos>0025</pos>
<lng>0020</lng>
<occurs>0001</occurs>
</Field>
<Field Level = "02">
 <name>BESTELLMENGE</name>
<type>D </type>
<pos>0045</pos>
<lng>0004</lng>
<occurs>0001</occurs>
</Field>
<Field Level = "02">
<name>ARTIKELPREIS</name>
<type>F </type>
<pos>0049</pos>
<lng>0006</lng>
<occurs>0001</occurs>
</Field>
</Map>
</Mapset>

Figure 4: XML to COBOL Conversion Table

The XML Stubs place them at the proper position in the program
data structure. Thus, the standard methods are:

The actual tools for processing the XML documents

are the XML stubs which are called instead of the − Parse_DTD (Doc:Name),

file system or the teleprocessing monitor. There are − Select_next_DataItem (Data_Name),

two such stubs for each language and each TP
monitor being wrapped. One is for extracting data
from an incoming XML document and converting it
to the appropriate internal data structure, i. e. CICS
map or COBOL record. This is the stub
XMLTOCIS, XMLTOIMS, XMLTOCOB,
XMLTOPLI, etc. The other is for creating an
outgoing XML document from the internal data
structure of the wrapped program, i. e. from the
CICS map or COBOL record. This is the stub
CISTOXML, IMSTOXML, COBTOXML,
PLITOXML, etc. (See Figure 5.)
− Convert_DataType (Data_Type),
− Store_DataValue (Data_Value).
Of course for the Convert_DataType there are
several sub methods, one for each target data type –
fixed binary, packed decimal, hexadecimal, floating
point etc.
The input stub is called each time a map is to be
received or a record is to be read. It’ s purpose is to
fill the input buffer with the data from the next
XML document in the incoming message queue.

The stub for converting incoming XML documents
processes the conversion table for that particular
interface. It is generated from a standard template
and joined together with the conversion table. In
effect the conversion table is the object and the stub
the methods. The methods are to parse the XML
document, select the data noted in the conversion
table, convert the data to internal data types and to
The stub for generating outgoing XML documents
is also based on the corresponding conversion table.
Only the direction of the conversion is reversed.
The output stub is called with the record or map
containing the output data. Via the table the
variable names are associated with the field
displacements, lengths and types to extract the
values and embed them in a corresponding XML
document. The DTD is created based solely on the
conversion table. The result is a correct and well
formed XML document which is placed in the
outbox.
The greatest conversion difficulties are caused by
multiple occurrences and redefinitions. In the case
of redefinitions the conversion type is determined
by the actual value. In the case of multiple
occurrences, i. e. vectors, the actual number of
elements in the table must be computed. This
becomes complicated when repeated data groups
are involved, but it is a problem which any
compiler must resolve.

CICS Transaction Monitor

Input Output
XML Docus Message Message XML Docus
Queve Queve

CICS / COBOL Program

CICS Input Output CICS

XMLTOCOB BMS Map Map BMS COBTOXML
MAP Buffer Buffer MAP

XML to COBOL COBOL to XML

CONVERSION CONVERSION
DB Access Shell

Database

Figure 5: XML Stubs for Map Emulation

Executing the XML-wrapped Programs In the online environment, the program remains
under control of the TP monitor which opens and

The wrapped programs are executed in their native closes the databases, commits or roll backs the

environment. For this reason it is important that the database transactions, establishes connections to

stubs are in the same language as the program, as other programs, maintains the communication data

they are statically linked to it. In the batch areas and handles errors. The only difference is that

environment, the program now reads its input from there are no connections to the terminals. The map

the XML document stream and writes its output input/output operations have been diverted to the

data into the XML output queue. Otherwise it appropriate stubs which provide the map data from

functions exactly as before, retrieving and storing the XML input queue and write the map data onto

records, segments or relations of the database. the XML output queue. In effect the map
processing is replaced by message processing
complemented by the XML conversion.
The problem involved here is the need to have a
second program version for processing XML
documents which is slightly different than the
original map handling version. If the user intends to
abandon the 3270 terminals and work only on the
web, there is no problem. He maintains only the
reengineered version. If, however, the user wants to
run the web-based version parallel to the original
terminal-based version, then he must maintain two
copies of the same program. That is why it is so
important to be able to generate the wrapped
version out of the original version automatically.
The user makes his changes to the original
terminal-based version and tests it in the standard
environment. Then he invokes the tool to create the
XML version. In this manner, only one version
need be maintained..[16]
Experiences with XML-based System
Integration
The introduction of XML to traditional data
processing enterprises in the old economy has
actually just started, so there have been little
experiences reported as of yet. Even in the U.S.A.,
the world leader in information technology, only a
handfull of companies have actually started using
XML as a means of integrating their enterprise
applications. This is probably due to the fact that
the technical environments to support such an
XML-based system integration, environments such
as Enterprise JavaBeans, BizTalk and WebSphere,
are not yet ripe enough for full scale production.
Don Estes cites in his report on Business to
Business System Integration four pilot projects
going on in the U.S.A. – one for general accounting
reporting at AICPA, one for news dissemination at
Reuters News Agency, one for processing stock
orders and derivatives at J. B. Morgan and another
one for stock trading at Pricewaterhouse
Coopers.[17] Peter Aiken, a prophet of XML for
system integration, reports on a project taking place
at the Deutsche Bank in New York.[18] All of these
projects are still in progress, so it is too early for
statistical results.
In Germany and Austria, where this author works,
only two projects have so far been reported. One
took place at the German Trade Union Bank – DG
Bank – using XML to integrate bank trading
applications. The architecture developed for that
project is called the Trading Room Integration
Architecture. It connects C++ and JAVA
applications with existing COBOL programs. The
frontend components use XSLT to display and
accept the user interfaces and XML to transfer the
contents via a CORBA type communication
network. The first applications are already in
operation.[19]
The other project was at the Deutsche Bauspar AG
and was reported on in a previous paper. The goal
of this project was to connect JAVA applets
running at local savings and loan offices with the
central host computer in Frankfurt. The web page
contents were converted to XML documents which
were sent via IBM’ s MQ-Series to the host where
they were converted to COBOL structures by an
XMLCOBOL tool. The pilot project delivered the
proof of concept. The follow up project is now
underway.[20]
In Vienna, where the author is participating in a
project to develop a standard stock trading package
implemented in C++ to run on several target
computers, XML is used to connect a new web-
based frontend implemented in JAVA with the
existing C++ backend applications. This project has
just been completed and will be reported on soon.
The tools described in this paper are currently being
tested in a project to integrate the existing
production control system at Porsche with recently
installed standard ERP systems running under
MySap from SAP. The author is responsible there
for finding a suitable EAI solution. At the
University of Regensburg, where the author teaches
Software Engineering, the tools have been used to
integrate a JAVA/XML frontend developed by the
students with a series of existing C and COBOL
programs. The JAVA frontend processed order
entries for articles on stock. The modules for
accessing the customer and article databases in MS-
Access were written in C using ODBC to access the
databases. The modules for producing invoices,
dispatch orders and supplier orders are legacy
COBOL programs. All of the inter program
communication is done by means of message
queuing of XML documents produced by the JAVA
and C components. This research project has been
reported on in a previous paper.[21]
Areas for further Research
The basic problem of converting XML to various
target language data structures has been resolved.
What is needed now is to optimize the conversion
to reduce run time costs. The task of message
queuing for web server to host communication is
being addressed by the suppliers of middleware
products.
The greatest remaining application problem is how
to reengineer the existing program interfaces so that
they are compatible with XML document
processes. With batch and subprograms this is less
of a problem than with online transaction
processing programs. The logic of these programs
is based on synchronous event driven map handling
and function keys. Now they must revert to
asynchronous sequential document processing. This
entails restructuring of the program interfaces and
presents a significant challenge to the reengineering
community. The task is to automatically convert
host programs from CICS/BMS or IMS/MFS to
CICS/XML or IMS/XML. There are many
opportunities here for universities and research
institutes to render useful contributions.
Conclusions
This paper has presented a proposal for enterprise
application integration using XML as a common
interface language. The main objectives are to link
existing legacy programs with new web-based
applications within the framework of a multilayered
architecture. XML is used to exchange data
between the software layers independently of their
implementation languages and runtime
environments. For this purpose conversion stubs
have been implemented which use data conversion
tables generated from the existing program
interface structures. These stub can convert XML
documents to COBOL, PLI and Assembler data
structures and generate XML documents from
COBOL, PLI and Assembler. In this way both,
batch input records and online maps can be
replaced by XML interfaces.
The prerequisite to using this technology is to
reengineer the interfaces of the existing programs
so that they process messages rather than map and
records. Either the programs have to be rewritten by
hand or they have to pass through a precompiler
which automatically restructures them. This paper required in optimizing the interface reengineering
has emphasized the latter solution because of the process to ensure that the reengineered versions are
costs involved in rewriting. More research is functionally equivalent to the original ones.
References

[1] Warren, Jan: “The Renaissance of Legacy Distributed System”, Proc. of CSMR-2000, IEEE
Systems”, Springer Verlag, London, 1999, p. 5 Computer Society Press, Zürich, March 2000,
[2] Schricker, D.: “COBOL for the Next Millenium”, p. 183 to 188
IEEE Software, March 2000, p. 48 to 52 [14] Sellnik, A./Sneed, H./Verhoef, C.: “Restructuring
[3] Kebschull, V./Spruth, W.: “Kommerzielle of COBOL/CICS Legacy Systems”, Proc. of
Großrechner als Ausbildungsaufgabe an CSMR-1999, IEEE Computer Society Press,
Universitäten und Fachhochschulen”, Informatik Amsterdam, March 1999, p. 72 to 82
Spektrum, Band 24, Heft 3, June 2001, p. 140 to [15] Westphal, R.: “Strong Tagging – Der Ausweg aus
143 der Interface-Versionshölle”, Object-Spectrum,
[4] IBM: “A Survey of object-oriented Technology Nr. 4, July 2000, p. 24 to 29
on MVS/ESA”, IBM Red Book Doc. No. GG24- [16] Sneed. H.: “Accessing Legacy Mainframe
2505, Pougikeepsie, N.Y., Feb. 1995 Applications via the Internet”, Proc. of
[5] Israel, B.-S./Gish, J./Robinson, W.: “An Reengineering Forum (ed. Chikofsky, E.),
Integrated Network Component Architecture”, Zürich, March 2000, p. 34 to 46
IEEE Software, Sept. 1998, p. 79 to 85 [17] Estes, D.: “Legacy.NET”, Cutter IT Journal,
[6] Harmon, P.: “XML – Solving Business Vol. 14, No. 1, p. 35 to 42
Problems”, Cutter Consortium, Arlington, Mass., [18] Aiken, P./Yates, M.: “Novel Approaches to Large
2001, p. 5 to 25 Scale Systems Reengineering”, Proc. of
[7] Standish Group: “CHAOS – The Cost of IT Reengineering Forum (ed. Chikofsky, E.),
Project Failures”, in PC-Week, Nr. 16, Jan. 1995 Zürich, March 2000, p. 16 to 30
[8] Sneed, H.: “Risks involved in Reengineering [19] Weitzel, T./Harder, T./Buxmann, P.: “Electronic
th
Projects”, Proc. of 6 WCRE, IEEE Computer Business and EDI with XML”, dpunkt Verlag,
Society Press, Atlanta, Oct. 1999, p. 209 to 211 Heidelberg, 2001,p. 181 to 198
[9] Graham, I./Quin, L.: “XML – Specification [20] Haeckel, A./Gößner, J./Wahl, H.: “Integration of
Guide”, John Wiley & Sons, New York, 1999, Legacy Applications in modern object-oriented
p. 1 to 3 Systems via XML” in Object Spectrum, No. 5,
[10] Mowbray, T./Zahavi, R.: “The Essential Sept. 2000, p. 35 to 40
CORBA” OMG-Series, John Wiley & Sons, [21] Sneed, H.: “Wrapping Legacy COBOL Programs
New York, 1995, p. 35 to 45 behind an XML Interface”, Proc of WCRE 2001,
[11] Hasselbring, W.: “Information System IEEE Computer Society Press, Stuttgart, Oct.
Integration”, Comm. of ACM, Vol. 43, No. 6, 2001
June 2001, p. 33 to 36 [22] Lewis,T.: “Mainframes are dead, Long live
[12] Seligmann, L./Rosenthal, A.: “XML’ s Impact on Mainframes”, IEEE Computer, August, 1999, p.
Databases and Datasharing”, IEEE Computer, 102-104l
June 2001, p. 59 to 66
[13] Sneed, H.: “Generation of Stateless Components
from Procedural Programs for Reuse in a