enterprise - PARAGON Systemhaus GmbH

paragonsystemhaus

enterprise - PARAGON Systemhaus GmbH

Anzeige

05.04

Internet & Enterprise Technology

mit CD!

Deutschland € 5,50

Open Source-Tools: Welche IDE für wen?

Einführung in JUnit

Grundlagen für automatisiertes Testen

Struts und Together

Webentwicklung mit UML

J2EE-Architektur

Grundlagen und Prinzipien

Groovy

Alternative mit Java-Integration

UDDI 3.0

Verzeichnisdienst wird erwachsen

Naked Objects

Objekte pur

10.–14. Mai 2004 Alle Infos im Heft! (S. 57)

D 45 86 7

Österreich € 6,50

Schweiz SFr 10,70

Eclipse vs. Netbeans

www.javamagazin.de


enterprise

Host-Integration

Schrittweise Integration altgedienter Host-Anwendungen in die

neue Java-Welt

von Martin Welß

Richtung Zukunft

In vielen Unternehmen mit Großrechner-EDV sind teilweise recht umfangreiche 3270-Anwendungen zu

finden, die sich seit vielen Jahren bewährt haben. Allerdings wird in vielen Unternehmen die Weiter- und

Neuentwicklung von Software auf Basis von alternativen Technologien betrieben. Aus diesem Grund

stellt sich häufig die Frage, wie ein gangbarer Weg zu einer neuen, zukunftsweisenden Architektur gefunden

werden kann. Der vorliegende Beitrag beschreibt anhand eines konkreten Projekts einen Weg

der weichen Übergänge, der skalierbar ist, harte Einschnitte vermeidet und schrittweise alte durch

neue Module ersetzt. Auf Basis der J2EE, einer Java 3270 Emulation und des Frameworks Paraklet sind

alte und neue Welt integrierbar.

Motivation

In der Regel sind die Anwendungen, die

die Kerngeschäftsprozesse von Unternehmen

unterstützen, seit langem im Einsatz.

Hierbei handelt es sich oft um Applikationen

in COBOL, PL/I oder sogar Assembler

mit einer 3270-Benutzer-Schnittstelle.

Häufig auftretende Probleme sind:

• Die Programme sind historisch gewachsen,

werden von der zweiten oder dritten

Entwicklergeneration betreut und sind

mittlerweile nur noch schwer zu warten.

• Häufig gibt es viele isolierte Datenmodelle,

die redundante Daten in unterschiedlichen

Strukturen vorhalten.

• Zusätzlich besteht das Problem, dass die

Daten mittels unterschiedlicher Paradigmen

(hierarchische DB, relationale DB

etc.) und Technologien verwaltet werden.

• Die flexible und integrative Unterstützung

von Arbeitsabläufen im o.g. Umfeld

gestaltet sich schwierig.

• Die Benutzerschnittstelle auf 3270-Basis

ist zwar schnell, bietet aber bei weitem

nicht die Möglichkeiten einer grafischen

Anwendung (Grafiken, Diagramme etc.).

• Die Integration (auf Anwenderseite) von

Software (z.B. CTI, Textverarbeitung,

72

5.2004

Tabellenverwaltung etc.) mit der 3270

Emulation ist äußerst aufwändig.

• Es fällt zunehmend schwer, gute CO-

BOL- oder PL/I-Entwickler zu finden.

Der vorliegende Beitrag zeigt, wie einige bekannte

Probleme in dem hier dargestellten

Projekt gelöst worden sind. Das Projekt hat

insbesondere darauf geachtet, dass die neue

Software weiche Übergänge auf der Anwenderseite

gewährleistet und das die Inbetriebnahme

nicht in Form eines Big Bang

durchgeführt werden musste.

Zielsetzung

Das Ziel des hier beschriebenen Projekts

PartnerDB war die Realisierung einer neuen

zentralen Adressen-Datenbank (ZAD)

bei der Neuen Rechtsschutz Versicherung

(NRV) in Mannheim. Die PartnerDB soll

den kompletten Umfang der alten Host-

ZAD beinhalten sowie folgende Erweiterungen:

• erweitertes Daten-/Objektmodell

• Integration mit dem Dokumenten-Management-System

• Integration mit der Telefonanlage (CTI)

• zukunftssichere Architektur, die auch für

die Portierung weiterer Anwendungsmo-

dule geeignet ist und sich an gängigen

Standards orientiert

• einmalige Migration der Adressendaten

und Parallelbetrieb mit der „alten“ Host-

ZAD

• möglichst einfaches Betriebskonzept

Architektur

Die Architektur ist eine Standard-3-Tier-

Architektur auf Basis der Java 2 Enterprise

Edition (J2EE), einer relationalen DB2-Datenbank,

JBoss als Middle-Tier mit der eigentlichen

Geschäftslogik und einem Java

Rich-Client als Benutzerschnittstelle. Natürlich

wurde auch die Anbindung von

Web-Clients vorgesehen. Zusätzlich werden

durch die Verwendung des Paragon-eigenen

Frameworks Paraklet die Entwicklung

beschleunigt und die Wiederverwendbarkeit

erhöht. Diese Architektur hat, zusammen

mit der strikten Einhaltung der

Standards EJB/J2EE und SQL, in Bezug auf

Zukunftssicherheit und Investitionsschutz

die nachfolgend aufgeführten Vorteile.

Plattformunabhängigkeit

Durch die Wahl von Java als Programmiersprache

und die Realisierung als 3-

Tier-Architektur können die drei Teile beliebig

auf unterschiedliche Plattformen


verteilt werden. Hier ein paar interessante

Kombinationen:

• Datenbank und EJB-Server auf dem

Host, Clients unter Windows

• Datenbank auf dem Host, EJB-Server

unter Unix (z.B. AIX, Solaris, Linux),

Clients unter Windows

• Datenbank und EJB-Server unter Unix,

Clients unter Windows oder Linux

• Datenbank und EJB-Server unter Windows,

Clients unter Windows

In diesem Projekt laufen in der Produktionsumgebung

Datenbank und EJB-Server

unter AIX sowie die Clients unter Windows.

In der Entwicklungsumgebung liefen

alle drei Teile auf einem PC wahlweise

unter Windows oder Linux.

Skalierbarkeit

Wichtig im Hinblick auf Zukunftsfähigkeit

ist die Möglichkeit der Architektur, mit den

Anforderungen wachsen zu können. Das

betrifft sowohl die Datenmengen als auch

die Antwortzeiten. So konnte zu Beginn eine

preiswerte Kombination aus EJB-Server

und Datenbank eingesetzt werden, die später

je nach Bedarf durch High-End-Produkte

mit ausgefeilten Clustering-Fähigkeiten

ersetzt werden könnte.

3270 Emulation

Die klassische Großrechnerarchitektur besteht

aus dem zentralen Großrechner und daran angeschlossen

jeder Menge „dummer“ Terminals,

die nichts anderes können, als Text in Form

von Bildschirmmasken anzuzeigen und Tastatureingaben

des Anwenders entgegenzunehmen.

Die Regeln für diese Kommunikation zwischen

Großrechner und Terminal sind spezifiziert

im so genannten TN3270-Protokoll. Die

Anwendung stellt sich für den Benutzer als eine

Abfolge von Masken dar, zwischen denen er

mehr oder weniger komfortabel mit Funktionstasten

(12, 24 oder auch 36 Stück) und Datenfreigabe

navigieren kann. Nicht von der Hand

zu weisen, sind die Vorzüge dieser Architektur

bzgl. Skalierbarkeit und Wartung. Der auch in

diesem Artikel erwähnte Zero Administration

Client ist also im Grunde nichts Neues.

Der Maskenaufbau wird vom Anwendungsprogramm

auf dem Großrechner erledigt, das

in einer typischen Großrechner-Programmiersprache

wir COBOL oder PL/I geschrieben ist.

Abb. 1: Architektur

Die Skalierbarkeit sollte aber nicht

nur in Bezug auf eine Vergrößerung betrachtet

werden, sondern auch in Bezug

auf eine Verkleinerung. Durch die Wahl

eines sehr „schlanken“ EJB-Produkts ist

es z.B. möglich, mit der Anwendung und

einem DB-Ausschnitt auf einem Laptop

zu arbeiten. Nicht zuletzt auch für den jeweiligen

Entwicklerarbeitsplatz ist die

Plattformunabhängigkeit ein wichtiges

Merkmal, denn unabhängig von der Plattform

des Produktionssystems ist der Standard-PC

kostentechnisch kaum zu unterbieten.

Wahl des besten Produktes

Durch die strikte Orientierung an Standards

besteht die Möglichkeit, die geeignetsten

Produkte auszuwählen und vor allem

die Abhängigkeit von einem Hersteller

zu vermeiden. Die Erfahrung zeigt zwar,

dass so ein Umstieg in der Praxis normalerweise

nicht on the fly möglich ist, aber

die Anpassungen lokal begrenzt und überschaubar

sind (z.B. Deployment oder Datenbank-Mapping;

hier sind die Standards

offen bzw. ungenau).

Wartbarkeit

Eine gute Architektur sollte zukünftige

Änderungen mit überschaubarem Aufwand

verkraften können. Dafür sind zwei

Aspekte von entscheidender Wichtigkeit:

enterprise

Host-Integration

• Kapselung von fachlichen Modulen und

Subsystemen. Dies bezieht sich sowohl

auf die Server- als auch auf die Client-

Seite.

• Gute Testbarkeit wird häufig vernachlässigt.

Eine gute Testbarkeit erreicht

man nur durch eine strikte Berücksichtigung

im Rahmen des Designs und des

Entwicklungsprozesses.

Objektmodell

Das Objektmodell für die PartnerDB orientiert

sich am Partner der Versicherungs-

Anwendungs-Architektur VAA [1] und an

Fowler [2]. Wie in Abbildung 2 zu sehen,

findet grundsätzlich eine Trennung der

reinen Partnerdaten von den eigentlichen

Adressendaten statt. Das bedeutet, ein

Partner hat beliebig viele postalische und

elektronische Adressen, die mit Rollen

qualifiziert werden. So können bei postalischen

Adressen etwa Erstwohnsitz und

Geschäftsadresse unterschieden werden,

bei den elektronischen Adressen beispielsweise

Telefon, Handy und eMail.

Besonders interessant sind die ebenfalls

durch Rollen qualifizierten Beziehungen

zwischen Partnern: Damit können Familienbeziehungen

und Geschäftsbeziehungen

der Partner untereinander modelliert werden.

Gerade Praxisgemeinschaften oder

Kanzleien sind auf diese Weise einfach darzustellen.

Sogar Hierarchien und Organi-

5.2004

73


enterprise

Host-Integration

Abb. 2: Das Objektmodell

sationsstrukturen lassen sich auf diese

Weise abbilden.

Design der Serverseite

Die zusätzliche Komplexität in Bezug auf

Konfiguration und Deployment durch einen

EJB-Server lohnt sich nur dann, wenn

tatsächlich die Stärken des Servers genutzt

werden. Es war deshalb ein Ziel beim Entwurf

der Serverseite, die spezifikationskonformen

Fähigkeiten eines EJB-Servers auszunutzen:

• Container Managed Persistence nach

dem Standard EJB 2.0 mit der Unterstützung

von Container Managed Relations.

Das bedeutet konkret, dass der EJB-Con-

Das Framework Paraklet

tainer für die objektrelationale Abbildung

der Objekte auf die Datenbank inklusive

der Beziehungen zuständig ist,

außerdem für das Caching der Objekte

und die Ausführung von in EJB QL formulierten

Abfragen.

• Container Managed Transactions machen

dem Anwendungsentwickler das

Leben deutlich leichter, ihre Verwendung

muss aber von Anfang an im Design

berücksichtigt werden (s.u.).

• Nebenläufigkeit ist ein zentrales Leistungsmerkmal,

um kurze Antwortzeiten

in einem Umfeld mit vielen gleichzeitigen

Benutzern zu erreichen. Die EJB-

Spezifikation ist von Beginn an dafür

ausgelegt und fordert vom Bean-Ent-

Das Framework hat die Zielsetzung, die Kosten, Fehler und Entwicklungszeiten deutlich zu reduzieren

und gleichzeitig die Wartbarkeit, Stabilität und Skalierbarkeit zu erhöhen. Bei der Entwicklung

wurde großen Wert auf die Einhaltung von Standards (CORBA, JavaBeans, XML etc.)

gelegt. Dadurch ist das Framework produkt-, hersteller- und plattformunabhängig. Durch den modularen

Aufbau können auch einzelne Komponenten des Frameworks unabhängig eingesetzt werden.

Besondere Schwerpunkte des Frameworks:

• Die Tool-gestützte Anbindung von Oberflächen an die Fachlogik reduziert deutlich die Entwicklungszeit

und den Ausbildungsaufwand.

• Eine große Menge einheitlich gestalteter Oberflächenkomponenten auf Basis von JavaBeans

inkl. zugehöriger Property-Editoren fördert die Wiederverwendbarkeit und ein homogenes

Look & Feel

• die Kapselung der verteilten Kommunikation (CORBA, RMI)

• ein logisches, an Schichten orientiertes Gerüst für jede Art von Anwendung

74

5.2004

wickler den Verzicht auf jegliche Thread-

Befehle und entlastet ihn damit vollständig

von dieser Problematik.

Das Ergebnis ist eine stärkere Konzentration

der Anwendungsentwickler auf die

Geschäftslogik und damit von höherer Effizienz,

weil sie von Fragen der Systemprogrammierung

weitgehend entlastet werden.

Der Server hat in diesem Projekt konkret

die folgenden Aufgaben:

• Anbindung an die Datenbank und Verwaltung

der persistenten Objekte

• Sicherstellung der Datenintegrität durch

geeignete Steuerung der Transaktionen

• Synchronisation mit der „alten“ Datenbank

auf dem Host

Um die beiden ersten Punkte zu erreichen,

werden u.a. die J2EE Patterns Session Facade

und Value Object eingesetzt [3]. Die

Session-Fassade koordiniert das Zusammenspiel

von Geschäftsobjekten und stellt

der Präsentationsschicht eine einheitliche

Schnittstelle zur Verfügung. Die Komplexität

der Persistenzschicht wird gekapselt

und macht die aufrufende Schicht unabhängig

von Änderungen der Implementierung.

Darüber hinaus kann durch die

Einführung einer Fassade die Transaktionssteuerung

auf simple Art und Weise

und für den Client transparent erfolgen.

Das vereinfacht die Fehlersuche und er-

Abb. 3: Die 3270 Emulation im Java-Hauptfenster


leichtert die Wartung. Die Session-Fassade

wird als Session Bean realisiert und durch

geeignete Definition der Methoden kann in

der Regel der EJB-Mechanismus elegant

ausgenutzt werden, um die Transaktionsgrenzen

zu legen: Die vom EJB-Server zur

Verfügung gestellte Container-Managed

Transaction-Logik gemeinsam mit der konsequenten

Konfiguration aller „internen“,

also nach außen nicht sichtbaren Beans

(Entity und Session) mit dem Transaktionsattribut

„required“ sorgt automatisch für

den korrekten Ablauf.

Der Datenaustausch zwischen EJBund

Präsentationsschicht wird erleichtert

durch so genannte Value Objects. Das sind

Objekte, die die Daten in geeigneten Portionen

halten und die Anzahl der entfernten

Methodenaufrufe reduzieren. Es wird

unterschieden in Read-only Value Objects

und Updateable Value Objects, die von

der Präsentationsschicht verändert an die

EJB-Schicht zurückgegeben werden können.

In diesem Projekt kommen die Updateable

Value Objects zum Einsatz, weil

sie so gut mit der Transaktionssteuerung

an der Session-Fassade harmonieren.

Design der Clientseite

Die besondere Herausforderung auf der

Präsentationsseite war die Integration der

neuen Java-Oberfläche mit den bestehenden

Anwendungen auf Basis der 3270

Emulation. Damit für den Anwender der

Medienbruch möglichst wenig störend

wirkt und weiche Übergänge zwischen den

Welten möglich sind, ist eine Zusammenar-

beit der beiden Oberflächen zwingend erforderlich.

Eine zentrale Forderung des

Kunden war die schrittweise Einführung

neuer Softwarekomponenten in den Produktionsbetrieb.

Dies sollte ohne größere

Änderungen bei der Hostfunktionalität erledigt

werden, um den Programmieraufwand

und die resultierenden Risiken auf

der Hostseite zu minimieren.

Es bietet sich daher an, die Steuerung

der Integration in die neue Client-Software

einzubauen. Zu diesem Zweck muss

die neue Software die vollständige Kontrolle

über die Daten und den Kontrollfluss

der 3270 Emulation haben.

Die Lösung liegt in der Verwendung einer

3270 Emulation in Java, die im selben

Prozessraum läuft wie die neue Oberfläche.

Die Vorteile liegen auf der Hand:

• Die Sichtbarkeit der Hostemulation kann

gezielt gesteuert werden: So können ein-

COM und DDE mit Java

enterprise

Host-Integration

zelne Masken oder Module deaktiviert

werden. In diesem Projekt sind das die

Masken der „alten“ ZAD. Der Anwender

kann nicht „aus Versehen“ noch mit

der alten Anwendung arbeiten, Fehler

werden so vermieden.

• Die Tastendrücke in der Hostemulation

können protokolliert und bei Bedarf

verändert oder verworfen werden. So ist

es beispielsweise möglich, bei Querverweisen

von einer Maske zur zentralen

Adressendatei, diesen Tastendruck nicht

an die Hostemulation weiterzuleiten,

sondern stattdessen in die neue Oberfläche

zu verzweigen.

• Der Inhalt von Hostmasken kann ausgelesen

werden. Der Wechsel auf eine neue

Maske kann durch das Verfolgen der

3270-Events festgestellt werden. Man

kann durch diese Form der Integration

alle Aktivitäten in der 3270 Emulation

interpretieren und geeignet reagieren

Wenn Java, das ja grundsätzlich plattformunabhängig ist, auf dem bisher immer noch dominierenden

Windows-Desktop läuft, stellt sich durchaus die Frage nach der Integration mit anderen

Applikationen (z.B. mit MS Office oder, wie in diesem Projekt, mit dem Dokumentenmanagement

und der Telefonanlage). Unter Windows vorherrschend sind die proprietären Schnittstellen DDE

und COM, die sich aus Java heraus nur über das Java Native Interface (JNI), sprich eine DLL,

ansprechen lassen. Das Produkt Coroutine for Java von Neva Object Technologies nimmt einem

hier nicht nur viel Arbeit ab, sondern bietet über DDE und COM hinaus auch eine bessere Anbindung

an das Windows Printing als Java selbst. Für COM-Objekte können mit einem Generator

die notwendigen Java Stub-Klassen erzeugt werden, über die die eigentliche Anbindung erfolgt.

Die Kombination mit Java Web Start ist kein Problem, da Web Start die Möglichkeit bietet,

native Bibliotheken mitzuverwalten, zu laden und dem Java-Prozess zur Laufzeit zur Verfügung

zu stellen.


enterprise

Host-Integration

(z.B. kann man in die neue Anwendung

verzweigen, wenn auf der Maske xyz die

Taste F6 gedrückt wird).

• Es können gezielt Felder der Hostemulation

gefüllt und Tastendrücke simuliert

werden. So ist es möglich, beim Wechsel

von der neuen in die alte Welt zu bestimmten

Masken zu navigieren und so dem Anwender

Tipparbeit zu ersparen und/oder

Daten automatisch zu übernehmen.

Durch die Verwendung einer Java 3270

Emulation, die im selben Prozessraum

läuft, ist diese Kopplung auch aus Entwicklersicht

einfach zu verwenden, weil alle Teile

der Anbindung komplett in Java sind. Eine

Verwendung von C /C++ oder des Java

Native Interface (JNI) ist nicht erforderlich.

Die Desktopintegration geht in diesem Projekt

allerdings noch einen Schritt weiter: Es

war eine Anbindung an die Telefonanlage

und an das Dokumenten-Management-

System (DMS) gefordert.

Bei der Telefonanlage handelt es sich

um ein Voice over IP-System, sodass das Telefon

selbst eine Anwendung auf dem

Rechner des Mitarbeiters ist. Die Anbindung

erfolgt über den Windows COM-Mechanismus

zur Interprozess-Kommunikation.

Dadurch ist es möglich, bei einem

eingehenden Anruf mithilfe der übermittelten

Rufnummer eine Kundensuche zu starten,

sodass der Anwender im Idealfall bereits

beim Abnehmen weiß, mit welchem

Kunden er es zu tun hat, und die entsprechenden

Daten auf dem Bildschirm sind.

Umgekehrt ist auch möglich, aus der ZAD-

Anwendung heraus einen Anruf zu tätigen,

ohne dass der Anwender eine Nummer von

Hand eintippen muss.

Die Anbindung an das Dokumenten-

Management-System erfolgt über Windows

DDE. So kann beispielsweise aus

der ZAD-Anwendung heraus die Suche

nach Dokumenten zu einer bestimmten

Versicherungsscheinnummer gestartet werden.

Synchronisation

Eine zentrale Aufgabe des Projekts bestand

in der Synchronisation zwischen der alten

und der neuen Datenhaltung. Erst durch

diesen Parallelbetrieb wird ein gleichzeitiger

Betrieb von alter und neuer Applikation

und damit ein weicher Übergang möglich.

76

5.2004

Änderungen und Neuanlagen, die von der

neuen Applikation ausgeführt werden, werden

in den alten Datenbestand übernommen

und umgekehrt. Besonderen Wert muss

an dieser Stelle auf die Transaktionssteuerung

gelegt werden, damit die Datenintegrität

gewährleistet ist.

Da die neue Anwendung ein neues, erweitertes

Datenmodell hat, kann sich die

Synchronisation nur auf den Teil beschränken,

der im alten System vorhanden

ist. Durch diese Verfahrensweise können

sowohl Anwendungen (z.B. HOST-

ZAD) als auch zentrale Module schrittweise

abgelöst werden, ohne größere Risiken

für den Produktionsbetrieb einzugehen.

Der Parallelbetrieb von alten und

neuen Anwendungen sowie von alten und

neuen Datenbeständen ermöglicht dann

ein späteres nicht mehr produktionskritisches

Abschalten.

Betriebskonzept

Beim Betriebskonzept wurden von Anfang

die Aspekte Einfachheit und Wartbarkeit

in den Vordergrund gestellt. So ist

beispielsweise zum Betrieb der serverseitigen

Applikation kein projektspezifisches

Know-how erforderlich. Es gibt ein paar

einfache Kommandos zum Starten und

Stoppen sowie zum Installieren von neuen

Versionen. Insbesondere ist kein Wissen

über den verwendeten Applikationsserver

oder komplizierte Deployment-Prozeduren

erforderlich. Es ist damit eine klare

Trennung der Aufgaben in Betrieb und

Entwicklung möglich.

Auf der Client-Seite ist die Administrierbarkeit

ein entscheidender Faktor. Es

musste sichergestellt werden, dass eine

neue Version der Client-Anwendung allen

Benutzern zu Verfügung steht, ohne dafür

auf jeden Rechner zugreifen zu müssen

(Stichwort wartungsfreier Client oder auf

Neudeutsch: Zero Administration Client).

Dieses Problem wurde mit Java Web Start

gelöst: Auf dem Client-Rechner wird einmalig

die Java-Laufzeitumgebung inklusive

Web Start installiert (ab JDK 1.4 ist Web

Start Teil der JRE). Die eigentliche Anwendung

wird auf dem Server installiert. Der

Client lädt dann vom Server nur die Versionsdifferenzen.

Die Startzeit und Netzwerklast

werden auf diese Weise reduziert.

Fazit

Die hier vorgestellte Strategie liefert einen

umfassenden und in der Praxis bewährten

Lösungsweg zur schrittweisen Ablösung

von bestehenden Host/3270-Systemen hin

zu einer modernen Java-Architektur. Die

Strategie ist skalierbar und insbesondere

auch für große Projekte ein gangbarer Weg

mit überschaubarem Risiko. Durch die

Plattformunabhängigkeit von Java einerseits

und die strikte Orientierung an Standards

andererseits sind die Investitionen

optimal geschützt. Dieser Weg der überschaubaren

Schritte und weichen Übergänge

betrifft die folgenden Bereiche:

• Oberfläche: Durch die Integration einer

Java 3270 Emulation in einen Java Rich-

Client können alte und neue Welt für den

Anwender effizient miteinander verbunden

werden.

• Host-Funktionalität: Durch die Synchronisation

in beide Richtungen können

andere Host-Module schrittweise

für den Zugriff auf die neue Datenbank

umgestellt werden.

• Inbetriebnahme/Einführung: Ebenfalls

aufgrund der Synchronisation ist es möglich,

flexibel den Umstieg auf die neuen

Anwendungen zu steuern: Sei es pro Mitarbeiter

oder pro Abteilung. Eine riskante

Komplettumstellung auf einen Schlag

ist nicht erforderlich.

Das hier beschriebene System ist seit Sommer

2002 im produktiven Einsatz (mit ca.

60 gleichzeitigen Benutzern).

Martin Welß arbeitet bei der Paragon

Systemhaus GmbH als Projektleiter und

Architekt mit mehr als 20 Jahren Erfahrung

in der Softwareentwicklung. Seine

Schwerpunkte liegen im Bereich J2EE/

Web Services, in dem Entwurf von skalierbaren

Enterprise-Architekturen und der

Gestaltung des Softwareentwicklungsprozesses

von der Analyse bis zur Inbetriebnahme.

Links & Literatur

[1] Versicherungs Anwendungs Architektur (VAA) des Gesamtverbands

der Deutschen Versicherungswirtschaft

(GDV): www.gdv.de/

[2] Martin Fowler: Analysis Patterns: Reusable Object Models,

Addison-Wesley, 1996

[3] Sun J2EE Blueprints: java.sun.com/

[4] Paragon-Systemhaus: www.paragon-systemhaus.de/

Weitere Magazine dieses Users
Ähnliche Magazine