=Paper=
{{Paper
|id=Vol-93/paper-2
|storemode=property
|title=Funktionsgetriebene Integration von Legacy-Systemen mit Web-Services
|pdfUrl=https://ceur-ws.org/Vol-93/paper2.pdf
|volume=Vol-93
|dblpUrl=https://dblp.org/rec/conf/eai/TeschkeJKLHR04
}}
==Funktionsgetriebene Integration von Legacy-Systemen mit Web-Services==
https://ceur-ws.org/Vol-93/paper2.pdf
Funktionsgetriebene Integration von
Legacy-Systemen mit Web Services
T. Teschke1 , H. Jaekel1 ,
S. Krieghoff2 , M. Langnickel2 ,
W. Hasselbring3 und R. Reussner3
1
OFFIS, Bereich „Betriebliches Informations- und Wissensmanagement“
{teschke|jaekel}@offis.de
2
Kommunale Datenverarbeitung Oldenburg (KDO)
{krieghoff|langnickel}@kdo.de
3
Universität Oldenburg, Department für Informatik,
Abteilung Software Engineering
{hasselbring|reussner}@informatik.uni-oldenburg.de
Zusammenfassung Dieser Beitrag beschreibt die Nutzung von Web
Services bei der Migration eines Legacy-Systems. Es wird eine Archi-
tektur vorgestellt, auf deren Grundlage die Kommunale Datenverarbei-
tung Oldenburg (KDO) ihre umfangreichen Legacy-Anwendungssysteme
in eine moderne Softwarearchitektur integriert. Grundlage dieser Archi-
tektur ist das Dublo-Architekturmuster, das die sanfte Integration und
Migration von Legacy-Anwendungssystemen unterstützt. Das betrachte-
te kommunale Anwendungssystem wird über Web Services in eine J2EE-
Architektur integriert, wobei die zustandsabhängige Verfügbarkeit ein-
zelner Funktionen anhand von Protokollautomaten kontrolliert wird.
1 Einleitung
Die Kommunale Datenverarbeitung Oldenburg (KDO) ist ein Softwarehaus und
IT-Dienstleister für die kommunale Verwaltung. Angesichts des enormen Kosten-
drucks im kommunalen Bereich und wachsender bzw. sich änderndender Auf-
gaben der Verwaltungen müssen die von der KDO entwickelten kommunalen
Informationssysteme flexibel und kostengünstig an neue, kundenspezifische An-
forderungen anpassbar und somit langfristig nutzbar sein.
Bislang sind die Client/Server-Informationssysteme der KDO auf der Grund-
lage von Informix-Datenbanksystemen und der 4Js-Implementierung [Fou03] der
Informix 4GL [IBM03] entwickelt worden, wobei Präsentations- und Anwen-
dungscode in den 4GL-Programmen eng verzahnt sind. 4GL ist eine so genannte
„fourth generation language“ [WW90]. Maßnahmen zur Sicherung der Konsistenz
der in den Datenbankrelationen abgelegten Daten sind nicht auf Datenbankebe-
ne, sondern durch die Fachverfahren realisiert. Dies ist durch die Notwendigkeit
begründet, den Betrieb auch mit alten Datenbankversionen sicherzustellen, da
Kommunen aus Kostengründen nicht regelmäßig in neue Datenbanktechnologie
investieren bzw. Vollwartung abschließen können.
Die KDO hat sich dazu entschlossen, diese (monolithische) 2-Schichten-Ar-
chitektur mittelfristig durch eine flexiblere Mehrschichtenarchitektur zur erset-
zen, die auf aktuellen Standards aufsetzt und moderne Techniken des Software
Engineering berücksichtigt. Da die aktuelle Implementierung der Fachverfahren
umfangreiches Domänenwissen beinhaltet und daher nicht einfach ersetzt werden
kann, sollen diese Altverfahren zunächst über Web Services in die neue Archi-
tektur eingebunden und später schrittweise abgelöst werden. Das Oldenburger
Forschungs- und Entwicklungsinstitut für Informatik-Werkzeuge und -Systeme
(OFFIS), ein An-Institut der Carl von Ossietzky Universität Oldenburg, beglei-
tet die KDO bei dieser Umstellung ihrer Softwarearchitektur. Die in diesem Bei-
trag vorgestellte Arbeit ist das Ergebnis einer Kooperation des OFFIS-Bereichs
„Betriebliches Informations- und Wissensmanagement“, der Abteilung „Software
Engineering“ des Departments für Informatik und der KDO.
Dieser Beitrag ist wie folgt aufgebaut: Ausgehend von einer kurzen Vorstel-
lung des Dublo-Architekturmusters in Abschnitt 2 skizzieren wir in Abschnitt 3
drei grundsätzliche Alternativen zur Identifikation von Web Services in Legacy-
Systemen. In Abschnitt 4 beschreiben wir den bei der KDO verfolgten Ansatz
zur Identifikation von Web Services in den Altverfahren und deren Integration
in die neue Architektur, bevor wir den Beitrag in Abschnitt 5 mit einer Zusam-
menfassung und einem Ausblick beschließen.
2 Sanfte Legacy-Integration und -Migration
nach dem Dublo-Muster
Legacy-Anwendungssysteme unterscheiden sich von modernen Softwarearchitek-
turen oft darin, dass sie monolithisch aufgebaut sind und nicht zwischen un-
terschiedlichen Schichten für Präsentation, Anwendungslogik und Datenhaltung
unterscheiden. Stand der Softwaretechnik sind heute jedoch mehrschichtige Ar-
chitekturen mit klarer Trennung von Präsentation, Anwendungslogik und Da-
tenhaltung, mit denen u. a. vereinfachte Austauschbarkeit und Anpassbarkeit
von Komponenten, verbesserte Nachvollziehbarkeit fachlicher Anforderungen in
der Schicht der Geschäftslogik oder erhöhte Transparenz von Datenbankaspekten
angestrebt werden.
Eine sanfte Migration von monolithischen Legacy-Systemen zu modernen,
mehrschichtigen Softwarearchitekturen gestattet das Dublo-Muster [HRJ+ 04].
Dublo steht für „Dual Business Logic“ und basiert im Kern auf dem Gedanken,
Geschäftslogik an zwei Stellen zu halten: im Legacy-System sowie in neu ein-
geführten Mittelschichten. Dabei wird (neue) Geschäftslogik in einer neuen Ge-
schäftslogikschicht implementiert und mittels eines Legacy-Adapters [GHJV96]
mit der alten Geschäftslogik verbunden. Neben dem Zugriff auf alte Geschäfts-
logik wird dieser Adapter insbesondere auch für den Datenbankzugriff genutzt,
d. h. Zugriffe der neu implementierten Geschäftslogik auf die Datenbank erfol-
gen ausschließlich über den existierenden Legacy-Code. Dieser Zugriff auf die
Datenbank durch bestehenden Legacy-Code führt zwar zu einer Verteilung von
Geschäftslogik auf zwei Schichten, hat aber den Vorteil, dass alte Geschäftslogik
zunächst weiter verwendet werden kann (um schließlich schrittweise ersetzt zu
werden). Insbesondere kann so aufwändige Geschäftslogik des Legacy-Systems,
die (wie bei 4GL Systemen häufig) intrinsisch mit dem Datenbenkzugriff ver-
woben ist, weiter genutzt werden und mehr oder weniger unverändert durch die
mittleren Schichten zu einer neuen Präsentationsschicht weitergereicht werden.
Im Laufe der Migration wird dann immer mehr Geschäftslogik portiert, bis der
Legacy-Adapter schließlich vollständig durch einen Datenbank-Adapter ersetzt
werden kann. Abbildung 1 zeigt die Struktur des Dublo-Architekturmusters.
Client Server
Client User
Interface Legacy Client Communication
Frontend
Client Server: Business Tier Legacy
System
Local
Communication
Novel Protocol
GUIs Remote Business Logic
and Communication
Portals Protocol
Database
Application Server
Abbildung 1. Strukturelle Sicht auf das Dublo-Architekturmuster
Im Kontext der KDO wird das Dublo-Architekturmuster eingesetzt, um
einen J2EE-Server [Sha01] an das bestehende Informix-4GL-System anzubin-
den. Dabei werden die Legacy-Adapter über Web Services realisiert. Von der
Nutzung einer standardisierten, plattformunabhängigen Technologie wie Web
Services verspricht man sich insbesondere Flexibilität bei Technologiewechseln
in der Datenbank- und Geschäftslogikschicht [PG03]. Alternativen zur Identifi-
kation geeigneter Web Services werden im folgenden Abschnitt diskutiert. Die
KDO wird die durch das Dublo-Muster eingeführte neue Präsentationsschicht
ergänzend zum Zugriff auf neue Geschäftslogik auch für den Zugriff auf alte
Geschäftslogik entwickeln, um die alte Präsentationsschicht abzulösen.
Die Verbindung zwischen Präsentationsschicht und Geschäftslogikschicht
muss aus Gründen der Datensicherheit gesondert gesichert werden. Dazu kann in
einer Java-Umgebung beispielsweise RMI und SSL eingesetzt werden. Im Kon-
text der KDO wurde diese Verbindung mittels OSCI (Online Services Computer
Interface) [OSC] gemäß gesetzlichen Vorgaben gesichert. Durch Sicherung der
Verbindung zwischen Präsentations- und Geschäftslogikschicht laufen Server,
die diese Schichten realisieren, in einer gesicherten Umgebung, d. h. insbeson-
dere kann die Verbindung zwischen Geschäftslogik- und Datenbankschicht als
gesichert angesehen werden.
3 Alternativen zur Identifikation von Web Services
Bei der Identifikation von Web Services (oder allgemeiner: Klassen) in Legacy-
Systemen lassen sich nach [WBF97] drei alternative Ansätze unterscheiden:
1. Datengetrieben: Identifikation von Web Services zur Repräsentation des Ob-
jektmodells auf der Grundlage der im Legacy-System implementierten Da-
tenstrukturen.
2. Funktionsgetrieben: Identifikation von Web Services zur Bündelung der für
die Durchführung zentraler Anwendungsfälle relevanten Dienste auf der
Grundlage der im Legacy-System realisierten Funktionalität.
3. Objektgetrieben: Erstellung eines Objektmodells der Anwendungsdomäne
und Analyse des Legacy-Systems, um Code-Elemente zu identifizieren, die
die Datenstrukturen und Funktionalität entsprechender Klassen implemen-
tieren.
Im Kontext der KDO erschien die objektgetriebene Identifikation von Web
Services, die z. B. auf einem durch Entity Beans definierten Ziel-Objektmodell
aufsetzen könnte, grundsätzlich nicht gangbar. Da die den Altverfahren zugrun-
de liegenden Relationen im Allgemeinen nicht normalisiert sind und sich daraus
erhöhte Differenzen zwischen Ist- und (normalisiertem) Ziel-Objektmodell ab-
leiten ließen, waren bei diesem Ansatz Schwierigkeiten bei der Zuordnung von
Funktionen der Fachverfahren zu den Entity Beans des Ziel-Objektmodells zu
erwarten.
Ähnlich wie der objektgetriebene Ansatz zielt auch die datengetriebene Iden-
tifikation von Web Services auf die Implementierung eines Objektmodells durch
Legacy-Funktionen ab. Der wesentliche Unterschied zwischen beiden Ansätzen
ist darin zu sehen, dass der objektgetriebene Ansatz von einem Ziel-Objektmo-
dell ausgeht, während der datengetriebene Ansatz auf dem aktuell implemen-
tierten Objektmodell aufbaut. Beim datengetriebenen Ansatz werden geeignete
Web Services im Sinne abstrakter Datentypen (ADTs) ausgehend von den im
Legacy-System implementierten Datenstrukturen identifiziert. Dies können zum
einen (komplexe) Datentypen, die im Quellcode der Anwendung genutzt werden,
und zum anderen (relationale) Datenbankschemata sein. In der Forschung sind
verschiedenartige Ansätze auf Basis von Techniken wie Clustering und Konzept-
analyse (vgl. z. B. [vDK99]) oder Datenfluss-, Kontrollfluss- und Syntaxanalyse
(vgl. z. B. [KP99]) untersucht worden.
Der funktionsgetriebene Ansatz zielt im Kern auf die „Entdeckung“ von An-
wendungsfällen in Legacy-Systemen ab, für die durch geeignet zusammengestell-
te Web Services eine Schnittstelle definiert werden soll. Dabei kann sich diese
Ermittlung von Anwendungsfällen an den einzelnen Legacy-Programmen, die
die betriebliche Funktionalität des Legacy-Systems implementieren, oder an den
Bildschirmmasken des Systems orientieren. Erstgenannter Ansatz wird z. B. von
Erlikh [Erl02] verfolgt, der zunächst Web Services durch iterative Verfeinerung
von Mengen funktional zusammengehöriger Programme identifiziert. Die APIs
dieser Web Services werden anschließend durch Einsatz verschiedener Techni-
ken des Knowledge Mining ermittelt. Bei dem maskenorientierten Ansatz, den
Stroulia et al. in [SERS02] vorgestellen, werden durch die Analyse der Be-
nutzerinteraktionen mit dem Legacy-System Anwendungsfälle extrahiert, für die
eine neue Schnittstelle (in unserem Fall in Form von Web Services) anzubieten
ist. Durch die Bestimmung der für die Durchführung dieser Anwendungsfälle ge-
nutzten Funktionen lassen sich die APIs entsprechender Web Services definieren.
4 Identifikation und Nutzung von Web Services
bei der KDO
Da sich die Struktur der Implementierung der einzelnen kommunalen Fachver-
fahren und ihrer Funktionen primär an den unterstützten Anwendungsfällen und
Geschäftsprozessen und weniger an den zugrunde liegenden Datenbankstruktu-
ren orientiert, hat sich die KDO für einen funktionsgetriebenen Ansatz zur Iden-
tifikation und Nutzung von Web Services entschieden. Dabei erschien das von
Erlikh [Erl02] vorgeschlagene Verfahren aufgrund des Einsatzes von Techniken
des Knowledge Mining zu komplex. Wesentliche Gedanken des von Stroulia et
al. [SERS02] untersuchten Ansatzes ließen sich dagegen auf die KDO übertra-
gen, da in den Fachverfahren eine enge Kopplung zwischen den Bildschirmmas-
ken und den Funktionen besteht. Sein Einsatz setzt allerdings voraus, dass die
Struktur der aktuellen Masken in der J2EE-Implementierung im Wesentlichen
beibehalten bleibt.
Die Identifikation der Web Services, die zur Nutzung der Altverfahren zu
exportieren sind, orientiert sich an den bestehenden Fachverfahren und deren
Bildschirmmasken und wird manuell durchgeführt. Für jede Maske werden da-
bei die Benutzerinteraktionen ermittelt, mit denen datenverarbeitende Vorgän-
ge ausgelöst werden, die jeweils auszuführenden Funktionen analysiert und (für
jede dieser Interaktionen) entsprechende Operationen eines Web Services de-
finiert. Ein Web Service kann dabei die Operationen einer Maske oder einer
funktional zusammenhängenden Sequenz von Masken umfassen. Die Parameter
der Operationen eines Web Service werden aus den Feldern der jeweiligen Ein-
gabemaske abgeleitet. Die für einen Web Service zulässigen Interaktionsfolgen
(Sequenzen von Operationsaufrufen) werden durch Analyse der Abhängigkeiten
zwischen Bildschirmmasken bestimmt und in Form eines endlichen (Protokoll-)
Automaten spezifiziert, um die korrekte Nutzung der Dienste der Altverfahren
sicherzustellen. Sind Bildschirmmasken nicht vorhanden, oder sind ihre Abhän-
gigkeiten nicht (implizit oder explizit) spezifiziert, so können auch Verfahren
zur Analyse von Geschäftsprozessen („Process Mining“) genutzt werden, um die
Menge zulässiger Interaktionsfolgen zu bestimmen [Sch02]. Die explizite Angabe
von zulässigen Sequenzen ermöglicht die Erkennung von unzulässigen Aufrufse-
quenzen zur Laufzeit. Der Vorteil dieser Erkennung liegt in der exakten Identi-
fikation des ersten unzulässigen Aufrufs. Würde man diese Überprüfung unzu-
lässiger Aufrufreihenfolgen nicht durchführen, würde das Fehlverhalten, welches
durch eine unzulässige Aufrufreihenfolge verursacht wird, entweder gar nicht
oder aber möglicherweise so spät entdeckt, dass eine Identifikation des unzuläs-
sigen Aufrufs nur schwer oder gar nicht möglich ist. Beschreibt man nicht nur die
zulässigen Aufrufsequenzen des Adapters, sondern zusätzlich auch die von der
Geschäftslogikschicht benötigten Dienste, ist eine statische Interoperabilitsprü-
fung der Aufrufsequenzen (Protokolle) möglich. Wird diese Prüfung schon zur
Entwicklungszeit durchgeführt, können Überprüfungen der Aufrufsequenzen zur
Laufzeit wegfallen, da eine statische Prüfung alle inkompatiblen Interaktionsfol-
gen ausschließt. Da der Aufwand einer Modellierung der von der Geschäftslogik
benötigten Aufrufsequenzen als zu hoch eingeschätzt wurde, verzichtete man im
beschriebenen Projekt auf statische Überprüfungen.
Ein Ansatz, der mit unserer Automatennutzung vergleichbar ist, wird bei
verschiedenen Beschreibungssprachen für Web Services verfolgt. So lässt sich im
Web Service Choreography Interface (WSCI) [W3C02] das beobachtbare Verhal-
ten eines Dienstes als temporale und logische Abhängigkeiten zwischen den aus-
getauschten Nachrichten beschreiben. Die Business Process Execution Language
for Web Services (BPEL4WS) [BEA03] definiert eine Notation, die die tempo-
ralen und logischen Bedingungen bei der Zusammensetzung von Geschäftspro-
zessen aus mehreren Web Services beschreibt. Formal lassen sich Sequenzen von
Web Services mit den gängigen Notationen zur Protokollspezifikation, also z.B.
endlichen Automaten oder Petri-Netzen, beschreiben [BRSM03, MPP02]. Da
noch nicht absehbar ist, welcher der konkurrierenden Standards WSCI oder
BPEL4WS sich zukünftig durchsetzen wird, werden bei der KDO endliche Au-
tomaten zur Beschreibung der zulässigen Interaktionsfolgen eingesetzt.
Eine Voraussetzung für den Zugang zur implementierten Funktionalität über
Web Services ist die Trennung der GUI-Aspekte von dem eigentlichen Anwen-
dungscode durch Auslagerung des jeweiligen Codes in eigenständige 4GL-Funk-
tionen. Dabei werden Interaktionen, die bislang aufgrund der Verzahnung von
GUI- und Anwendungsaspekten innerhalb einer Funktion abgefragt und verar-
beitet wurden, durch die Aufspaltung der 4GL-Funktionen an den Interaktions-
punkten berücksichtigt. Die Web-Service-Schnittstelle kann dann auf technischer
Ebene als Adapter für die resultierenden 4GL-Anwendungsfunktionen bereitge-
stellt werden.
Der Zugriff auf die Altverfahren der KDO über Web Services kann gemäß
dem in Abbildung 2 dargestellten Sequenzdiagramm erfolgen. Dabei werden die
folgenden Schritte ausgeführt:
① Aufruf eines Dienstes durch einen (Präsentations-)Client: Ein Client ruft
eine Methode einer zustandsbehafteten Session Bean [DYK01] auf, die durch
einen J2EE-Server bereitgestellt wird.
② Initialisierung der Session Bean: Sofern die Session Bean noch nicht initiali-
siert wurde, meldet diese sich zunächst bei einem „Fassaden-Server“ mit einer
Kundenkennung sowie dem gewünschten Verfahren und der auszuführenden
Verfahrensserver
Client J2EE-Server Fassade (J2EE-Server) Manager-WS
service()
connect(KdNr,
Verfahren, Fallart)
mapCustomer2Server
(KdNr, Verfahren)
initWebService(Fallart, DBName)
new Fallart-WS
(DBName)
Fallart-WS
return portNumber
call(ws-operation)
checkValidity(ws-operation)
[ is valid ] ws-operation()
Abbildung 2. Integration von Altverfahren über Web Services
Fallart an (der Fassaden-Server bietet in Anlehnung an das gleichnamige
Entwurfsmuster [GHJV96] eine abstrakte Schnittstelle zu den Altverfahren
an). Ist die Session Bean bereits initialisiert, wird dieser Schritt übersprun-
gen und direkt mit Schritt 6 fortgefahren.
③ Auswahl des Verfahrensservers: Der Fassaden-Server, dessen Dienste eben-
falls über (zustandsbehaftete) Session Beans implementiert sein können,
wählt anhand der Kundenkennung und des Verfahrens einen zuständigen
Verfahrensserver aus. Dabei erfolgt auch die Bestimmung der durch das Ver-
fahren zu benutzenden Datenbank.
④ Beantragung einer Web-Service-Instanz: Der Fassaden-Server beantragt bei
einem „Manager-Web-Service“, der auf dem zuvor ermittelten Verfahrensser-
ver läuft und die Erzeugung von Web Services kontrolliert, eine Instanz des
für die gewünschte Fallart zuständigen Web Services und übergibt dabei den
Namen der zu benutzenden Datenbank.
⑤ Erzeugung der Web-Service-Instanz: Der Manager-Web-Service legt eine In-
stanz des gewünschten Web Services als neuen Prozess an (da die 4Js-Pro-
gramme der Altverfahren globale Variablen nutzen, erfolgt hier eine Tren-
nung zwischen unterschiedlichen Clients durch die Erzeugung unabhängiger
Prozesse). Er gibt die Nummer des Ports zurück, über den der Prozess identi-
fiziert und angesprochen werden kann. Mit der anschließenden Speicherung
dieser Port-Nummer auf dem Fassaden-Server wird die Initialisierung der
Session Bean (Schritt ②) abgeschlossen.
⑥ Anforderung des Dienstes: Die zustandsbehaftete Session Bean fordert die
dem clientseitig angeforderten Dienst entsprechende Operation des Web Ser-
vices beim Fassaden-Server an.
⑦ Prüfung der Gültigkeit des Aufrufs: Der Fassaden-Server prüft die Zuläs-
sigkeit des angeforderten Aufrufs anhand eines Protokollautomaten, der die
zulässigen Interaktionsfolgen einer Web-Service-Session beschreibt.
⑧ Ausführung der Operation: Ist der angeforderte Aufruf zulässig, wird die
Operation des Web Services ausgeführt und Rückgabewerte an den Client
zurückgegeben, anderenfalls wird ein Fehler signalisiert.
Aus Platzgründen verzichten wir hier auf eine detaillierte Betrachtung des
Abbaus von Verbindungen zwischen J2EE-Server und Web-Service-Instanz. In-
wieweit die zusätzliche Serverlast, die durch die Erzeugung einer möglicherweise
hohen Anzahl von Web-Service-Prozessen entsteht, kritisch ist, muss sich im
praktischem Einsatz noch zeigen.
5 Zusammenfassung und Ausblick
In diesem Beitrag wurde ein Ansatz zur funktionsgetriebenen Integration von
Legacy-Systemen mit Web Services im Kontext kommunaler Informationssyste-
me vorgestellt, den wir als Weiterentwicklung bestehender Diskussionen auf dem
Gebiet der Anwendungsintegration einordnen.
Im Anschluss an eine kurze Einleitung, in der die Ausgangssituation der
KDO skizziert wurde, folgte eine knappe Einführung in die sanfte Integration
und Migration von Legacy-Anwendungssystemen nach dem Dublo-Architektur-
muster. Eine Analyse grundsätzlicher Alternativen zur Identifikation von Web
Services in Legacy-Systemen bildete die Grundlage für den nachfolgend vorge-
stellten Ansatz zur Identifikation und Nutzung von Web Services, über den die
umfangreichen kommunalen Fachverfahren in die moderne Mehrschichtenarchi-
tektur der KDO eingebunden werden. Um die Zulässigkeit der Reihenfolge von
Web-Service-Aufrufen sicherzustellen, kommen in der vorgestellten Architektur
Spezifikationen endlicher Automaten zum Einsatz, auf deren Grundlage zulässige
Interaktionsfolgen mit dem Legacy-System beschrieben werden.
Da die Verwendung des Dublo-Musters aufgrund der auf zwei Schichten ver-
teilten, z. T. duplizierten Geschäftslogik einen gewissen Mehraufwand für die
Pflege des Anwendungssystems impliziert, beschränkt sich die Anwendbarkeit
dieses Musters auf „stabile“ Legacy-Systeme, die keine großen funktionalen oder
strukturellen Änderungen mehr erfahren. Als Schwachpunkt des in diesem Bei-
trag vorgestellten Ansatzes muss die Beibehaltung des alten, oftmals im Laufe
der Jahre degenerierten Datenbankschemas in neuen Fachanwendungen betrach-
tet werden. Künftige Arbeiten betreffen daher die Konzipierung eines Migrati-
onspfades zur vollständigen Ablösung von Legacy-Systemen und die dabei durch-
zuführende Evolution des Datenbankschemas. Während des parallelen Betriebs
alter und neuer Geschäftlogik ist zu erwarten, dass die semantische Heteroge-
nität zwischen alter und neuer Geschäftslogik noch weitere Herausforderungen
birgt.
Literatur
[BEA03] BEA, IBM, Microsoft, SAP AG und Siebel Systems,
http://www.ibm.com/developerworks/library/ws-bpel/: Business Process
Execution Language for Web Services Version 1.1, 2003. Besucht am
18.12.2003.
[BRSM03] Berardi, D., F. De Rosa, L. De Santis und M. Mecella: Finite
State Automata as Conceptual Model for E-Services. In: Integrated Design
& and Process Technology. Society for Process & Design Sciences, 2003.
[DYK01] DeMichiel, L. G., L. Ü. Yalçinalp und S. Krishnan: Enterprise Java-
Beans Specification, Version 2.0. Sun Microsystems, 2001.
[Erl02] Erlikh, L.: Integrating Legacy Systems Using Web Services. eAI Journal,
2002.
[Fou03] Four J’s, http://www.4js.com: Four J’s Development Tools, 2003. Be-
sucht am 25.08.2003.
[GHJV96] Gamma, E., R. Helm, R. Johnson und J. Vlissides: Entwurfsmuster:
Elemente wiederverwendbarer objektorientierter Software. Addison-Wesley,
1. Auflage, 1996.
[HRJ+ 04] Hasselbring, W., R. Reussner, H. Jaekel, J. Schlegelmilch,
T. Teschke und S. Krieghoff: The Dublo Architecture Pattern for
Smooth Migration of Business Information Systems. In: 26th International
Conference on Software Engineering (ICSE) 2004, Edinburgh, Schottland,
Großbritannien, Mai 2004.
[IBM03] IBM, http://www-3.ibm.com/software/data/informix/tools/4gl/: Infor-
mix 4GL product family, 2003. Besucht am 25.08.2003.
[KP99] Kontogiannis, K. und P. Patil: Evidence Driven Object Identificati-
on in Procedural Code. In: Proceedings of IEEE Conference on Software
Technology and Engineering Practice (STEP ’99), Seiten 12–21, Pittsbur-
gh, Pennsylvania, USA, August 1999.
[MPP02] Mecella, Massimo, Francesco Parisi Presicce und Barbara Per-
nici: Modeling E-service Orchestration through Petri Nets. Lecture Notes
in Computer Science, 2444:38ff., 2002.
[OSC] OSCI, http://www.osci.de: Online Services Computer Interface. Besucht
am 18.12.2003.
[PG03] Papzoglou, M.P. und D. Georgakopoulo: Special Section on Servuce
Oriented Computing. Communications of the ACM, 46(10):24–61, Oktober
2003.
[Sch02] Schimm, Guido: Process Miner — A Tool for Mining Process Schemes
from Event-Based Data. Lecture Notes in Computer Science, 2424:525ff.,
2002.
[SERS02] Stroulia, E., M. El-Ramly und P. Sorenson: From Legacy to Web
through Interaction Modeling. In: Proceedings of the International Con-
ference on Software Maintenance (ICSM ’02), Seiten 320–329, Montreal,
Kanada, Oktober 2002. IEEE Press.
[Sha01] Shannon, B.: Java 2 Platform Enterprise Edition Specification, v1.3. Sun
Microsystems, 2001.
[vDK99] Deursen, A. van und T. Kuipers: Identifying Objects Using Cluster and
Concept Analysis. In: Proceedings of the 1999 International Conference on
Software Engineering (ICSE ’99), Seiten 246–255, Los Angeles, USA, Mai
1999. ACM.
[W3C02] W3C, http://www.w3.org/TR/wsci/: Web Service Choreography Interface
(WSCI) 1.0, 2002. Besucht am 18.12.2003.
[WBF97] Wiggerts, T., H. Bosma und E. Fielt: Scenarios for the Identificati-
on of Objects in Legacy Systems. In: Baxter, I. D., A. Quilici und
C. Verhoef (Herausgeber): Proceedings of the 4th Working Conference
on Reverse Engineering (WCRE ’97), Seiten 24–32, Amsterdam, Nieder-
lande, Oktober 1997. IEEE Computer Society Press.
[WW90] Wojtkowski, W.G. und W. Wojtkowski: Applications Software Pro-
gramming With Fourth-Generation Languages. Wadsworth Publishing,
1990.