Fachhochschule Köln

Enterprise Application Integration im Neckermann Produktions-System

Diplomarbeit

eingereicht von

Andre Schlieper

2004

Die Diplomarbeit baut auf einem System auf, welches die Produktion von Versandkatalogen unterstützt. Das System wurde für die Neckermann Versand AG produziert und heißt Neckermann Produktions-System kurz NPS. Ich konnte das NPS in seiner Entwicklung mitgestalten und darauf aufbauend die folgende Diplomarbeit entwickeln.

Das NPS unterstützt die Katalogproduktion durch Integration diverser Anwendungssysteme und Datenbestände, um entsprechende Geschäftsprozesse in der Katalogproduktion zu ermöglichen. Beispielhafte Aufgaben und Datenbestände des NPS sind das Workflowmangement, Groupwareanwendungen, Gestaltung von Katalogseitenentwürfen, Verwaltung von Datenbeständen wie Produktbilder, Fotographien und Texten. Das NPS dient hiermit als Kernsystem bei der Produktion von Versandkatalogen für die Neckermann Versand AG.

Das Thema der Diplomarbeit, ist die Erweiterung des NPS um die Möglichkeiten und Techniken der Enterprise Application Integration EAI, mit dem Ziel der Erstellung einer umfassenden strukturellen Basis für eine zukunftsorientierte Integrationsplattform. Da das NPS mit der Zeit stark gewachsen ist und auf verschiedenen Systemen und Datenbeständen aufbaut, steigt mit der Zeit auch die Komplexität des Gesamtsystems, sowie die Komplexität z.B. bei der Kommunikation der Systeme untereinander (Schnittstellenproblematik) und damit auch der Bedarf an geeigneten Integrationstechniken und Integrationslösungen.
Um die Problematik komplexer werdender Systeme mit heterogener Systemlandschaft bewältigen zu können, existieren heute diverse Techniken, welche unter dem Begriff Enterprise Application Integration subsummiert werden können.

Die Diplomarbeit analysiert für die Integrationslösung im NPS die heute möglichen Techniken aus den entsprechenden Bereichen der EAI. Zum einen die Grundlagen betrieblicher Anwendungssysteme (EA aus EAI) aus betriebswirtschaftlicher und aus technischer Sicht. Zum anderen die Grundlagen der Integration von Anwendungssystemen (I aus EAI). Desweiteren wird die Rolle der modernen Middleware (Middleware nach dem Prinzip des Remote Procedure Call und Middleware nach dem Prinzip des Message Passing) in heutigen Anwendungssystemen analysiert und ihre wichtige Rolle und Funktion bei der Integration von Anwendungssystemen aufgezeigt. Der Grundlagenteil der Diplomarbeit führt dann die bekannten und die etablierten Middleware-Techniken zusammen mit den modernsten Techniken, wie Schichtenmodelle, Application-Server, Service Orientierte Architekturen SOA, WebServices, Enterprise Service Bus ESB und analysiert die sich ergebenden Möglichkeiten.

Nach einer Analyse des NPS in Bezug auf die Integrationsfähigkeiten, werden die im Grundlagenteil gewonnenen Erkenntnisse in einem Lösungsansatz zusammengebracht und eine Integrationslösung für das NPS entworfen. Diese Integrationslösung arbeitet nach dem Prinzip des Enterprise Service Bus und soll als zukunftsorientierte Integrationslösung für kommende Entwicklungen im NPS dienen.
Hierfür setzt der implementierte ESB auf modernste Techniken wie die Programmiersprache Java, die Message Oriented Middleware MOM implementiert durch den Java Message Service, eine Service Orientierte Architektur SOA mit dem Simple Object Access Protocol bzw. dem Service Oriented Architecture Protocol SOAP und einen Application-Server auf.

Zum Abschluß wird ein lauffähiger Prototyp des Enterprise Service Bus implementiert und auf der bestehenden Infrastruktur des Neckermann Produktions-Systems aufgesetzt.

Inhaltsverzeichnis

Vorwort

I. Einleitung

II. Grundlagen
II.1. Betriebliche Anwendungssysteme
II.1.1. betriebswirtschaftliche Betrachtung
II.1.2. technische Betrachtung
II.2. Grundlagen der Integration
II.2.1. Integrationsmerkmale
II.2.1.1. Integrationsrichtung
II.2.1.1.1. Integrationsrichtung horizontal
II.2.1.1.2. Integrationsrichtung vertikal
II.2.1.2. Integrationsreichweite
II.2.1.2.1. Integrationsreichweite intern
II.2.1.2.2. Integrationsreichweite extern
II.2.1.3. Integrationsgegenstand
II.2.1.3.1. Integrationsgegenstand Daten
II.2.1.3.2. Integrationsgegenstand Programme
II.2.1.3.3. Integrationsgegenstand Benutzerschnittstelle
II.2.1.3.4. Integrationsgegenstand Prozesse
II.2.2. Integrationsansätze
II.2.2.1. Integrationsansatz Punkt-zu-Punkt
II.2.2.2. Integrationsansatz ERP
II.2.2.3. Integrationsansatz Middleware
II.2.3. Middleware
II.2.3.1. Datenbank-Middleware
II.2.3.2. Programmorientierte Middleware
II.2.3.2.1. Verbindung versus Synchronisation
II.2.3.2.1.1. Kopplung
II.2.3.2.2. Aufruf-Schnittstellen (RPC)
II.2.3.2.3. Nachrichten-Schnittstellen (Message-Passing)
II.2.3.2.4. Aufruf- versus Nachrichten-Schnittstellen
II.2.3.3. Middleware-Dienste
II.2.4. Application-Server
II.2.4.1. Mehrschichtige Architekturen
II.2.4.1.1. Zwei-Schichten-Architektur
II.2.4.1.2. Drei-Schichten-Architektur
II.2.4.1.3. Zwei-Einhalb-Schichten-Architektur
II.2.4.1.4. Vier-Schichten-Architektur
II.2.4.2. Application-Server als Mehrschichtige-Architektur
II.2.4.3. Middleware im Application-Server
II.2.4.3.1. RPC-Middleware im Application-Server
II.2.4.3.2. MOM-Middleware im Application-Server
II.2.4.3.3. Vergleich RPC und MOM im Application-Server
II.2.5. Service-orientierte-Architektur
II.2.5.1. Kopplung einer SOA
II.2.5.2. Services einer SOA
II.2.5.3. Prinzipien einer SOA
II.2.6. WebServices
II.2.6.1. Nutzung offener Standards
II.2.6.2. Techniken der WebServices
II.2.6.3. Kopplung von WebServices
II.2.6.4. WebServices versus RPC/MOM
II.2.6.5. SOAP
II.2.6.6. Integrationslösung mit Hilfe von WebServices
II.2.7. Enterprise Service Bus

III. Ist-Analyse
III.1. Kernaufgaben des NPS
III.2. Anforderungen an das neue NPS
III.2.1. Gründe für die Neuimplementierung
III.2.2. Funktionale Anforderungen an das neue NPS laut Lastenheft
III.3. Gegenwärtiger Entwicklungsstand
III.3.1. Anwendungen und deren Aufgaben
III.3.2. Systemstruktur
III.3.2.1. Hardware-Topologie
III.3.2.2. Drei-Ebenen-Modell
III.3.2.2.1. Benutzerschnittstellen-Ebene
III.3.2.2.2. Programm-Ebene
III.3.2.2.3. Daten-Ebene
III.3.2.2.3.1. Helios
III.3.2.2.3.2. Cumulus
III.3.2.2.3.3. mysql
III.3.2.3. Schichten-Architektur
III.4. Analyse der Integrationsfähigkeit
III.4.1. Integrationsgegenstand Benutzerschnittstelle
III.4.2. Integrationsgegenstand Programme
III.4.3. Integrationsgegenstand Daten
III.5. Ergebnis der Analyse

IV. Soll-Konzept
IV.1. Erweiterung des NPS um einen ESB
IV.2. Anschluss des NPS an einen ESB
IV.2.1. erste Stufe - NPS als Gesamtsystem an den ESB anschließen
IV.2.2. zweite Stufe - Anschluss der Teilsysteme des NPS an den ESB
IV.3. Aufbau des ESB und Integration mit dem NPS
IV.3.1. Aufbau des ESB
IV.3.2. Aufbau der um den ESB erweiterten Infrastruktur
IV.4. Ergebnis des Konzeptes

V. Implementierung
V.1. Aufbau des Anwendungsszenarios
V.1.1. Receiver
V.1.2. Sender
V.1.3. ESB
V.2. Aufbau des ESB im Anwendungsszenario
V.2.1. SOAP-Implementierung AXIS
V.2.2. Implementierung von Bus und Router

VI. Zusammenfassung und Ausblick

Literaturverzeichnis

Glossar und Abkürzungsverzeichnis

Stichwortverzeichnis

Programmcode des Anwendungsszenarios für einen ESB

Kapitel I. Einleitung
Die Basis der vorliegenden Diplomarbeit bildet das zu entwickelnde System NPS - das Neckermann Produktions-System. Wie schon dessen Vorgängermodell auch, sollte das zu entwerfende Produkt die Speicherung und Verwaltung aller relevanten Daten der Katalogproduktion ermöglichen. Dies sind hauptsächlich die operativen Daten der Katalogseiten, wie z.B. Bildmaterial und Produkttexte. Zusätzlich zu der schon vorhandenen Funktionalität, also der Speicherung und Verwaltung, versprach man sich mit dem neuen System eine darüber hinausgehende durchgängige Unterstützung ganzer Katalogerstellungsprozesse, basierend auf den erfassten Datenbeständen.

In einem Katalogerstellungsprozess lassen sich Arbeitsschritte zusammenfassen, die in einem logischen Zusammenhang stehen bei der zielgerichteten Bearbeitung eines Geschäftsfalles. Der Geschäftsfall stammt hierbei aus dem Umfeld der Katalogproduktion.

Die reine Datenspeicherung von Produktphotographien, Texten etc. ist gemessen am Gesamterstellungsprozess ein relativ kleiner Teil und für sich genommen kein ganzer Prozess in der Katalogerstellung. Für eine ganzheitliche Betrachtung als Katalogerstellungsprozess fehlt eine zielgerichtete Bearbeitung der Daten im Sinne eines Geschäftsfalles. Auf den gespeicherten Daten operieren jedoch eine Menge verschiedener Anwendungen um ein bestimmtes Ziel, nämlich die Bearbeitung eines Geschäftsfalles, zu erreichen. Erst die über diese Anwendungen verrichteten Tätigkeiten auf den Daten kann man in einem Zusammenhang als Katalogerstellungsprozess ansehen. Die Prozesse werden in Anlehnung an den meist betriebswirtschaftlichen Charakter auch als Geschäftsprozesse bezeichnet.

Die Anwendungen die den Geschäftsprozessen zu Grunde liegen, sind häufig schon vorhanden und sollen in Zukunft auch weiter benutzt werden. Da die bestehenden Anwendungen meist nicht dafür ausgelegt und entwickelt wurden mit anderen Systemen Daten auszutauschen, ist eine direkte Kommunikation nicht möglich. Um eine Kooperation unterschiedlicher Anwendungen untereinander zu gewährleisten, ist es notwendig sie zusammenzuführen bzw. sie zu integrieren. Erreicht wird diese Integration der beteiligten Anwendungen durch die Bereitstellung von Kommunikationskanälen über Schnittstellen. D.h. daß die an einem Prozess beteiligten Anwendungen über Schnittstellen untereinander in Verbindung treten können.

Das zu entwickelnde System soll zur Bereitstellung von Diensten ebenfalls diverse bestehende Systeme und Datenbestände integrieren. Diese Systeme sind spezialisiert auf bestimmten Gebieten wie z.B. der Massendatenverarbeitung oder der Bildverarbeitung. Außerdem beinhalten einige die eigentliche Geschäftslogik des Gesamtsystems. Entstanden ist diese Art der verteilten Logik durch eine ’best-of-bread’-Strategie, bei der durch Kombination verschiedener Systeme versucht wird, die Anforderungen an das Gesamtsystem optimal abzudecken.

Hierdurch entstehen zunehmend komplexe heterogene Systemlandschaften und damit einhergehend eine komplexer werdende Schnittstellenlandschaft, welche die Kommunikation der Systeme untereinander erschwert.

Bei der Bereitstellung von Schnittstellen, ist es nicht wünschenswert, daß jedes System mit jedem anderen seine eigenen Kommunikationsverbindungen aufbaut. Dies führt zu einem Schnittstellen-Chaos, da für die Verbindungen von jedem System zu jedem anderen System jeweils eigene Schnittstellen bereitgestellt werden müssten. Potenziell führt dies zu einer Ordnung von O(n2) Verbindungen (vgl. [001] Seite 23), was in der Folge zu sehr hohen Kosten bei der Entwicklung und Wartung führt (vgl. [003] Seite 2). Schnittstellenwartung verschlingt vielfach bis zu 60% des gesamten IT-Budgets (vgl. [100] Seite 98). Um jedoch trotzdem die Kommunikation der verschiedenen Dienste zu erreichen und Synergien beim Zusammenwachsen verschiedener Systeme zu nutzen, gilt es die Systeme über eine Art ’Kommunikationsdrehscheibe’ (vgl. [004] Seite 21) miteinander zu verbinden. Eine Drehscheibe für den gemeinsamen Datenaustausch, welche gewährleistet, daß alle Systeme mit allen anderen kommunizieren können. Jedes System soll hierbei nur eine einzige Schnittstelle, nämlich die zur Drehscheibe benötigen und über diese mit allen anderen Systemen Kommunikationsverbindungen aufbauen können.

[...]