Enterprise Application Integration - Enterprise application integration

Enterprise Application Integration ( EAI ) ist die Verwendung der Architekturprinzipien von Software und Computersystemen, um eine Reihe von Unternehmenscomputeranwendungen zu integrieren .

Überblick

Unternehmensanwendungsintegration ist ein Integrationsframework, das aus einer Sammlung von Technologien und Diensten besteht, die eine Middleware oder ein "Middleware-Framework" bilden, um die Integration von Systemen und Anwendungen in einem Unternehmen zu ermöglichen.

Viele Arten von Unternehmenssoftware wie Supply-Chain-Management- Anwendungen, ERP- Systeme, CRM- Anwendungen zur Verwaltung von Kunden, Business-Intelligence- Anwendungen, Gehaltsabrechnungs- und Personalsysteme können normalerweise nicht miteinander kommunizieren, um Daten oder Geschäftsregeln auszutauschen. Aus diesem Grund werden solche Anwendungen manchmal auch als Automatisierungsinseln oder Informationssilos bezeichnet . Diese fehlende Kommunikation führt zu Ineffizienzen, indem identische Daten an mehreren Orten gespeichert werden oder einfache Prozesse nicht automatisiert werden können.

Enterprise Application Integration ist der Prozess, solche Anwendungen innerhalb einer Organisation miteinander zu verknüpfen, um Geschäftsprozesse weitestgehend zu vereinfachen und zu automatisieren, ohne dabei tiefgreifende Änderungen an den bestehenden Anwendungen oder Datenstrukturen vornehmen zu müssen. Anwendungen können entweder am Backend über APIs oder (selten) am Frontend ( GUI ) angebunden werden .

In den Worten des Forschungsunternehmens Gartner : "[EAI ist] die uneingeschränkte gemeinsame Nutzung von Daten und Geschäftsprozessen zwischen allen verbundenen Anwendungen oder Datenquellen im Unternehmen."

Die verschiedenen Systeme, die miteinander verbunden werden müssen, können sich auf unterschiedlichen Betriebssystemen befinden , unterschiedliche Datenbanklösungen oder Computersprachen verwenden oder unterschiedliche Datums- und Uhrzeitformate oder können Altsysteme sein , die von dem Hersteller, der sie ursprünglich erstellt hat, nicht mehr unterstützt werden. In einigen Fällen werden solche Systeme auch als " Ofenpipe-Systeme " bezeichnet, weil sie aus Komponenten bestehen, die so zusammengeklemmt sind, dass sie sehr schwer modifiziert werden können.

Verbesserung der Konnektivität

Wenn Integration angewendet wird, ohne einem strukturierten EAI-Ansatz zu folgen, wachsen Punkt-zu-Punkt-Verbindungen im gesamten Unternehmen. Abhängigkeiten werden spontan hinzugefügt, was zu einer komplexen Struktur führt, die schwer zu pflegen ist. Dies wird allgemein als Spaghetti bezeichnet, eine Anspielung auf das Programmieräquivalent von Spaghetti-Code . Beispielsweise:

Die Anzahl der Verbindungen, die erforderlich sind, um vollständig vermaschte Punkt-zu-Punkt-Verbindungen mit $n$ Punkten zu haben, ist gegeben durch (siehe Binomialkoeffizient ). Damit zehn Anwendungen vollständig Punkt-zu-Punkt integriert werden können, werden Punkt-zu-Punkt-Verbindungen benötigt. ${\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}$ ${\tfrac {10\times 9}{2}}=45$

Allerdings wächst die Zahl der Verbindungen innerhalb von Organisationen nicht mit dem Quadrat der Zahlenpunkte. Im Allgemeinen ist die Anzahl der Verbindungen zu einem beliebigen Punkt unabhängig von der Anzahl anderer Punkte in einer Organisation ( Gedankenexperiment : Wenn Ihrer Organisation ein zusätzlicher Punkt hinzugefügt wird, ist Ihnen dies bewusst? Punkte haben?). Es gibt eine kleine Anzahl von "Sammel"-Punkten, für die dies nicht gilt, die jedoch keine EAI-Muster zur Verwaltung erfordern.

EAI kann auch die Kopplung zwischen Systemen erhöhen und somit den Verwaltungsaufwand und die Kosten erhöhen.

Bei EAI geht es nicht nur um die gemeinsame Nutzung von Daten zwischen Anwendungen, sondern auch um die gemeinsame Nutzung von Geschäftsdaten und Geschäftsprozessen. Ein Middleware-Analyst, der sich mit EAI befasst, wird sich oft das System der Systeme ansehen .

Zwecke

EAI kann für verschiedene Zwecke verwendet werden:

Datenintegration : Stellt sicher, dass Informationen in mehreren Systemen konsistent gehalten werden. Dies wird auch als Enterprise Information Integration (EII) bezeichnet.
Herstellerunabhängigkeit: Extrahiert Geschäftsrichtlinien oder Regeln aus Anwendungen und implementiert sie im EAI-System, sodass selbst beim Ersetzen einer der Geschäftsanwendungen durch eine Anwendung eines anderen Herstellers die Geschäftsregeln nicht erneut implementiert werden müssen.
Gemeinsame Fassade: Ein EAI-System kann einem Cluster von Anwendungen als Front-End dienen, eine einzige konsistente Zugriffsschnittstelle auf diese Anwendungen bereitstellen und Benutzer davor schützen, den Umgang mit verschiedenen Softwarepaketen erlernen zu müssen.

Muster

In diesem Abschnitt werden allgemeine Entwurfsmuster für die Implementierung von EAI beschrieben, einschließlich Integrations-, Zugriffs- und Lebensdauermuster. Dies sind abstrakte Muster und können auf viele verschiedene Arten implementiert werden. Es gibt viele andere Muster, die üblicherweise in der Branche verwendet werden, von abstrakten Entwurfsmustern auf hoher Ebene bis hin zu hochspezifischen Implementierungsmustern.

Integrationsmuster

EAI-Systeme implementieren zwei Muster:

Mediation (interne Kommunikation): Dabei fungiert das EAI-System als Vermittler oder Vermittler zwischen mehreren Anwendungen. Immer wenn ein interessantes Ereignis in einer Anwendung auftritt (z. B. werden neue Informationen erstellt oder eine neue Transaktion abgeschlossen), wird ein Integrationsmodul im EAI-System benachrichtigt. Das Modul gibt die Änderungen dann an andere relevante Anwendungen weiter.
Föderation (Interkommunikation): In diesem Fall fungiert das EAI-System als übergreifende Fassade über mehrere Anwendungen hinweg. Alle Ereignisaufrufe von der 'Außenwelt' an eine der Anwendungen werden vom EAI-System als Front-End ausgeführt. Das EAI-System ist so konfiguriert, dass es der Außenwelt nur die relevanten Informationen und Schnittstellen der zugrunde liegenden Anwendungen zugänglich macht, und führt alle Interaktionen mit den zugrunde liegenden Anwendungen im Auftrag des Anforderers durch.

Beide Muster werden oft gleichzeitig verwendet. Dasselbe EAI-System könnte mehrere Anwendungen synchron halten (Vermittlung), während Anfragen von externen Benutzern für diese Anwendungen bearbeitet werden (Föderation).

Zugriffsmuster

EAI unterstützt sowohl asynchrone (Fire and Forget) als auch synchrone Zugriffsmuster, wobei erstere typisch für den Vermittlungsfall und letztere für den Verbundfall sind.

Lebenszeitmuster

Ein Integrationsvorgang kann von kurzer Dauer sein (z. B. könnte die Synchronisierung von Daten zwischen zwei Anwendungen innerhalb einer Sekunde abgeschlossen werden) oder von langer Dauer sein (z. B. könnte einer der Schritte darin bestehen, dass das EAI-System mit einer menschlichen Workflow- Anwendung zur Genehmigung interagiert eines Darlehens, das Stunden oder Tage in Anspruch nimmt).

Topologien

Es gibt zwei Haupttopologien: Hub-and-Spoke und Bus . Jeder hat seine eigenen Vor- und Nachteile. Im Hub-and-Spoke-Modell steht das EAI-System im Zentrum (dem Hub) und interagiert über die Spokes mit den Anwendungen. Im Busmodell ist das EAI-System der Bus (oder wird als residentes Modul in einen bereits bestehenden Nachrichtenbus oder eine nachrichtenorientierte Middleware implementiert ).

Die meisten großen Unternehmen verwenden Zonennetzwerke, um mehrschichtigen Schutz gegen netzwerkorientierte Bedrohungen zu schaffen. Beispielsweise verfügt ein Unternehmen in der Regel über eine Kreditkartenverarbeitungszone (PCI-konform), eine Nicht-PCI-Zone, eine Datenzone, eine DMZ-Zone für den Proxy-Zugriff externer Benutzer und eine IWZ-Zone für den Proxy-internen Benutzerzugriff. Anwendungen müssen über mehrere Zonen hinweg integriert werden. Das Hub-and-Spoke- Modell würde in diesem Fall besser funktionieren.

Technologien

Bei der Implementierung jeder der Komponenten des EAI-Systems werden mehrere Technologien verwendet:

Bus/Hub: Dies wird normalerweise durch die Erweiterung von Standard-Middleware-Produkten ( Anwendungsserver , Nachrichtenbus) oder als eigenständiges Programm (d. h. verwendet keine Middleware) implementiert, das als eigene Middleware fungiert.
Anwendungskonnektivität: Der Bus/Hub wird über eine Reihe von Adaptern (auch als Konnektoren bezeichnet ) mit Anwendungen verbunden . Dies sind Programme, die wissen, wie sie mit einer zugrunde liegenden Geschäftsanwendung interagieren. Der Adapter führt eine unidirektionale Kommunikation durch, führt Anforderungen vom Hub an die Anwendung durch und benachrichtigt den Hub, wenn ein Ereignis von Interesse in der Anwendung auftritt (ein neuer Datensatz eingefügt, eine Transaktion abgeschlossen usw.). Adapter können anwendungsspezifisch sein (z. B. basierend auf den Clientbibliotheken des Anwendungsherstellers) oder spezifisch für eine Anwendungsklasse (z. B. können mit jeder Anwendung über ein Standardkommunikationsprotokoll wie SOAP , SMTP oder Action Message Format (AMF) interagieren )). Der Adapter könnte sich im gleichen Prozessraum wie der Bus/Hub befinden oder an einem entfernten Standort ausgeführt werden und mit dem Hub/Bus über Industriestandardprotokolle wie Nachrichtenwarteschlangen, Webdienste oder sogar ein proprietäres Protokoll interagieren. In der Java-Welt ermöglichen Standards wie JCA die herstellerneutrale Erstellung von Adaptern.
Datenformat und Transformation: Um zu vermeiden, dass jeder Adapter Daten in/von allen anderen Anwendungsformaten konvertieren muss, schreiben EAI-Systeme normalerweise ein anwendungsunabhängiges (oder gemeinsames) Datenformat vor. Das EAI-System bietet normalerweise auch einen Datentransformationsdienst, um die Konvertierung zwischen anwendungsspezifischen und gängigen Formaten zu unterstützen. Dies geschieht in zwei Schritten: Der Adapter konvertiert Informationen aus dem Format der Anwendung in das gemeinsame Format des Busses. Darauf werden dann semantische Transformationen angewendet (Konvertieren von Postleitzahlen in Städtenamen, Aufteilen/Zusammenführen von Objekten aus einer Anwendung in Objekte in den anderen Anwendungen usw.).
Integrationsmodule: Ein EAI-System könnte zu einem bestimmten Zeitpunkt an mehreren gleichzeitigen Integrationsvorgängen teilnehmen, wobei jeder Integrationstyp von einem anderen Integrationsmodul verarbeitet wird. Integrationsmodule abonnieren Ereignisse bestimmter Typen und verarbeiten Benachrichtigungen, die sie erhalten, wenn diese Ereignisse auftreten. Diese Module können auf unterschiedliche Weise implementiert werden: Auf Java- basierten EAI-Systemen können dies Webanwendungen oder EJBs oder sogar POJOs sein , die den Spezifikationen des EAI-Systems entsprechen.
Unterstützung für Transaktionen: Wenn es für die Prozessintegration verwendet wird, bietet das EAI-System auch anwendungsübergreifende Transaktionskonsistenz, indem alle Integrationsvorgänge über alle Anwendungen hinweg in einer einzigen übergreifenden verteilten Transaktion ausgeführt werden (unter Verwendung von zweiphasigen Festschreibungsprotokollen oder kompensierenden Transaktionen ).

Kommunikationsarchitekturen

Derzeit gibt es viele Variationen über die beste Infrastruktur, das beste Komponentenmodell und die beste Standardstruktur für die Integration von Unternehmensanwendungen. Es scheint Einigkeit darüber zu bestehen, dass vier Komponenten für eine moderne Architektur zur Integration von Unternehmensanwendungen unerlässlich sind:

Ein zentralisierter Broker, der Sicherheit, Zugriff und Kommunikation verwaltet. Dies kann durch Integrationsserver (wie die School Interoperability Framework (SIF) Zone Integration Servers) oder durch ähnliche Software wie das Enterprise Service Bus (ESB)-Modell erreicht werden, das als Dienstmanager fungiert.
Ein unabhängiges Datenmodell basierend auf einer Standarddatenstruktur, auch als kanonisches Datenmodell bekannt . Es scheint, dass XML und die Verwendung von XML-Stylesheets zum de-facto und in einigen Fällen de jure Standard für diese einheitliche Geschäftssprache geworden sind.
Ein Konnektor- oder Agentenmodell, bei dem jeder Anbieter, jede Anwendung oder Schnittstelle eine einzelne Komponente erstellen kann, die nativ mit dieser Anwendung kommunizieren und mit dem zentralisierten Broker kommunizieren kann.
Ein Systemmodell, das die APIs, den Datenfluss und die Regeln für die Einbindung in das System definiert, sodass Komponenten gebaut werden können, um eine standardisierte Schnittstelle zu ihm herzustellen.

Obwohl andere Ansätze wie die Verbindung auf Datenbank- oder Benutzeroberflächenebene untersucht wurden, wurde festgestellt, dass sie nicht skaliert oder angepasst werden können. Einzelne Anwendungen können Nachrichten an den zentralisierten Broker veröffentlichen und den Empfang bestimmter Nachrichten von diesem Broker abonnieren. Jede Anwendung benötigt nur eine Verbindung zum Broker. Dieser zentrale Steuerungsansatz kann extrem skalierbar und hochgradig entwicklungsfähig sein .

Enterprise Application Integration bezieht sich auf Middleware-Technologien wie Message-Oriented Middleware ( MOM ) und Datendarstellungstechnologien wie XML oder JSON . Andere EAI-Technologien beinhalten die Verwendung von Webservices als Teil einer serviceorientierten Architektur als Mittel zur Integration. Die Integration von Unternehmensanwendungen ist in der Regel datenzentriert. In naher Zukunft wird es um Content-Integration und Geschäftsprozesse gehen .

Fallstricke bei der Umsetzung

2003 wurde berichtet, dass 70 % aller EAI-Projekte scheitern. Die meisten dieser Fehler sind nicht auf die Software selbst oder technische Schwierigkeiten zurückzuführen, sondern auf Verwaltungsprobleme. Der europäische Vorsitzende des Integration Consortium, Steve Craggs, hat die sieben wichtigsten Fallstricke skizziert, die Unternehmen, die EAI-Systeme verwenden, angehen, und erläutert Lösungen für diese Probleme.

Ständiger Wandel: Die Natur von EAI ist dynamisch und erfordert dynamische Projektmanager, die ihre Implementierung managen.
Mangel an EAI-Experten : EAI erfordert Kenntnisse in vielen Fragen und technischen Aspekten.
Konkurrierende Standards: Innerhalb des EAI-Bereichs ist das Paradox, dass EAI-Standards selbst nicht universell sind.
EAI ist ein Werkzeugparadigma: EAI ist kein Werkzeug, sondern ein System und sollte als solches implementiert werden.
Schnittstellen zu bauen ist eine Kunst: Das Engineering der Lösung reicht nicht aus. Lösungen müssen mit den Fachabteilungen ausgehandelt werden, um einen gemeinsamen Konsens über das Endergebnis zu erzielen. Ein fehlender Konsens über Schnittstellendesigns führt zu einem übermäßigen Aufwand, um zwischen verschiedenen Systemdatenanforderungen abzubilden.
Detailverlust: Informationen, die zu einem früheren Zeitpunkt unwichtig erschienen, können später entscheidend werden.
Verantwortlichkeit: Da so viele Abteilungen viele widersprüchliche Anforderungen haben, sollte es eine klare Verantwortlichkeit für die endgültige Struktur des Systems geben.

In diesen Bereichen können weitere potenzielle Probleme auftreten:

Fehlende zentrale Koordinierung der EAI-Arbeit.
Neue Anforderungen: EAI-Implementierungen sollten erweiterbar und modular sein, um zukünftige Änderungen zu ermöglichen.
Protektionismus: Die Anwendungen, deren Daten integriert werden, gehören oft verschiedenen Abteilungen an, die aus technischen, kulturellen und politischen Gründen ihre Daten nicht mit anderen Abteilungen teilen wollen

Siehe auch

Initiativen und Organisationen

Verweise

Languages

In other projects