kontakt

+49 421 20696 - 0
info@team-neusta.de

Ein Portal, ein Tor zum personalisierten Content – Teil 7

EAI – Enterprise Application Integration

Mit Einführung der elektronischen Datenverarbeitung in den frühen 1960’er
Jahren wurde der Ruf in Unternehmen, eine einheitliche, aggregierte Sicht
auf den gesamten Datenbestand zu ermöglichen, zunehmend lauter. In den
vergangenen Jahren stieg der Anteil von Anwendungen, die ihren eigenen
Datenbestand managen, massiv an.

Der Wunsch nach einheitlicher Integration dieser Daten, unter Ermöglichung
eines offenen Datenaustauschs, untereinander wuchs unaufhaltsam. Die
Einführung von Personal Computern in den 1980’er und 1990’er Jahren ließ
den Druck weiter ansteigen, endlich von einer integrierten und konsistenten
Datenbasis mit flexiblen Austauschmöglichkeiten über alle angebundenen
Anwendungen hinweg zu profitieren. Viele verschiedene Ideen wurden aus
diesem Konzept entwickelt, um dieser Problemstellung beizukommen.

Die Aufteilung in sparten ähnlichen Anwendungen ist heute ein weit verbreiteter Lösungsansatz im Umfeld der Unternehmens-IT-Architektur. Ziel ist das Gruppieren von ähnlichen Funktionalitäten und ähnlich gelagerten Daten bei gleichzeitiger Reduktion der Komplexität und der Einführung einheitlicher Benutzeroberflächen. Diese so genannte Enterprise Application Integration (EAI) wird bereits seit Mitte der 1990’er Jahre insbesondere von Großunternehmen verfolgt. Zusammengefasst ist der Hauptgedanke hinter EAI die Einführung einer zusätzlichen Middleware-Komponente, die sich aller Kommunikation in Richtung der angeschlossenen Anwendungen annimmt und so die Gesamtzahl der proprietären Interfaces des Anwendungsportfolios deutlich verringern hilft.

Eine unternehmensinterne EAI-Initiative kann im Wesentlichen in vier
verschiedene Lösungsansätze eingeteilt werden:

  • EAI auf Datenbankebene – Durch Integration von verschiedenen Datenbanken.
  • EAI auf Applikationsebene – Durch Integration unter Ausnutzung der API.
  • EAI auf methodischer Ebene – Durch Verteilung von Geschäftslogik und/oder –Methoden.
  • EAI auf Benutzerebene – Durch Integration verschiedener Applikationen auf der Ebene der verschiedenen Benutzerinterfaces.

Man kann erkennen, dass sich der Abstraktionslevel zwischen den vier
verschiedenen EAI-Integrationsansätzen stark unterscheidet. Die überwiegende
Mehrheit der verschiedenen EAI-Initiativen beschränkt sich in der
Regel allerdings eher auf den technischen Teil der Integration. Der
Lösungsansatz der Einführung einer Middleware, die alle wichtigen
Informationsquellen vereinheitlicht und sowohl Datenaustausch als auch
Kommunikation über Anwendungsgrenzen hinweg ermöglicht, wird von
vielen Kritikern in Bezug auf das Thema EAI vielfach bereits als überholt
angesehen.

Verschiedene EAI-­Ansätze
Je nach den Problemstellungen und den während der Analysephase herausgearbeiteten
Herangehensweisen zu Applikationsintegration, müssen auf
jeden Fall sowohl architektonische als auch technische Probleme identifiziert
und gelöst werden, damit die EAI erfolgreich umgesetzt werden kann.
Die beiden nächsten Absätze behandeln diese beiden Bereiche im Detail. Die
nach der Identifizierungs- und Analysephase vorgeschlagene Architektur
stellt eine möglichst allumfassende Plattform für alle Arten von Protokollen
zur Verfügung, um einen benutzerorientierten Lösungsansatz sicher zu
stellen. Dieser soll möglichst alle Aspekte sowohl der Anwendungs-
Customisierung als auch einfache Team-Collaboration-Features abdecken
können.

Aufgrund der unüberschaubaren Masse an Applikationen und der Vielzahl
von Protokollen sollte die vorgeschlagene Architektur mindestens die
wichtigsten Unternehmenslösungen unterstützen, ohne dabei in extensive
Anpassungen zu verfallen. Denn Individuallösungen bedeuten bei der EAI
stets mögliche Fehlerquellen, Performance-Engpässe und Gefahren.

Globale Portal-­Architektur
Weil die Ausrichtung eines Portals stets eng mit dem Anspruch der
Schaffung einer hochintegrierten, kollaborativen Umgebung innerhalb eines
Unternehmens verknüpft ist, sollte viel Beachtung auf die Integration
bereits vorhandener, aktiv genutzter Komponenten und Lösungen zur
Prozess-, Benutzer- und Rechteverwaltung gelegt werden.

User-­Interface Architektur
Da verschiedene Anwendungen naturgemäß auch verschiedene Protokolle
nutzen, besitzt ein Portal in der Regel einen so genannten Display Manager,
der eine flexible Basis für die Einbindung verschiedenster Protokoll-Handler
ermöglicht. Die verschiedenen identifizierten Protokolle werden normalerweise
während der Designphase in requestorientiert (HTTP, SOAP, WSRP, …)
auf der einen, und kommunikationsorientiert (RDP, SSH, XML, …) auf der
anderen Seite unterschieden. Das Design der entsprechenden Architektur
sollte stets einem dienstorientierten Ansatz folgen. Einzelne Dienste sind
darin im Normalfall „stateless“ und gemäß ihrer Funktionalität gruppiert.
Allen involvierten Protokoll-Handlern gemein ist dabei der Ansatz des
Proxy-Mechanismus, der es den Protokoll-Handlern (Konnektoren) ermöglicht,
als Zwischenschicht zwischen der Ziel-Anwendung und dem Endbenutzer
zu fungieren.

Ferner kann ein Portal in seiner Gesamtheit als Proxy – also als eine Art
Zwischenschicht – für eine gesamte User-Session fungieren. Dies impliziert
allerdings, dass jegliche Kommunikation zwischen dem Service-Provider
(Anwendung) und dem Consumer (Endbenutzer) über das Portal geleitet
wird. Diese Art der Umsetzung bietet in heutigen gemischten LAN/WAN-Kommunikationsnetzwerken entscheidende Vorteile: Zum einen auf der
Sicherheitsseite, denn es bedarf lediglich der Erstellung eines einzigen
Rulesets auf einer Firewall, da alle Anfragen zu den verschiedenen angeschlossenen Anwendungen lediglich von einer einzigen IP initiiert sind.
Zum anderen erlaubt dies auf einfachere Weise Transformationen in der
Präsentation der Inhalte (zum Beispiel auf CSS/JavaScript-Ebene bei HTMLInhalten),
damit auf diese Weise ein einheitliches CLAF (common look and
feel, corporate design, …) umgesetzt werden kann.

Der größte Nachteil dieses Portal-Proxy-Ansatzes ist allerdings, dass bei
dieser Art der Umsetzung das Sicherheitsniveau signifikant sinken kann, da
die technischen Voraussatzung für sogenannte „Man-in-the-middle-
Attacken“ durch zentrales Routing aller Anwendungen durch die
Portalengine geschaffen sind und mit den Sicherheitselementen der
Portalengine lediglich ein einziger „point of failure“ existiert. Auch das
Problem der globalen Portal-Performance sollte bei dieser Art der
Integration Beachtung finden. Ein komplettes Routing/Proxying aller
Anwendungsdaten durch ein zentralisiertes Portal bedeutet in der Regel
auch einen signifikanten Anstieg des Workloads der internen IT des
Unternehmens. Damit verbundene, zum Teil nicht unerhebliche Mehrbelastungen
von Budgets, Mensch und Material für den ausfallsicheren Betrieb
der Portalplattform (Failover/Mirroring) sollten nicht unbeachtet bleiben.

In den meisten Fällen hat sich deshalb aus diesen Gründen beim
Portaldesign ein asynchroner Ansatz bestens bewährt: Dieser besteht darin,
möglichst „einfache“ Services zu gruppieren und durch das Portal als Proxy
zu leiten, während andere komplexere Anwendungen, die meistens über
eigene hochverfügbare Backend-Systeme verfügen, extern über die
Konnektoren Inhalte zum Portal in die Portlets liefern.

 Blog Proxy Server

 

 

 

 

 

 

 

Fortsetzung in Teil 8:

Im nächsten Teil geht es um Request Orientierte Protokolle an Hand eines Beispiels und Vorbehalte gegenüber Open Source Lösungen.

Lesen Sie hier ab dem 09.10 den Teil 8

Share