Application Platform Suites (APS) haben ähnliche Nachteile. Sie sind in einem verteilten Netz mit verschiedenen Servern schwierig zu implementieren oder zu rekonfigurieren. Eine APS bietet Sichtbarkeit und Management für Geschäftsprozesse, die auf einem einzigen Server oder einem Cluster von Servern laufen. Sie können aber keinen umfassenden Überblick verschaffen oder Prozesse verwalten, die auf Systemen in einer heterogenen Umgebung laufen. Deswegen sind Architekturen wie Microsofts .NET oder EJB Container (EJB = Enterprise Javabeans) kaum dafür geeignet, eine größere Zahl von dynamisch konfigurierten Services in einer SOA zu verwalten.
Im Gegensatz zu APS ermöglichen ESB-Service-Container den selektiven Einsatz von Vermittlungsservices genau zu dem Zeitpunkt und an dem Ort, an dem sie gebraucht werden. Dagegen müssen Unternehmen überall dort einen kompletten Applikations-Server-Stack installieren, wo individuelle Integrationsfunktionen erforderlich sind. Das führt zu unnötigen Mehrkosten für die Lizenzierung, die Installation und den Betrieb während der gesamten Laufzeit.
Traditionelle EAI-Produkte wurden speziell für die Anwendungsintegration entwickelt. Sie leisten ein Mapping von Applikation zu Applikation in einem Hub-and-Spoke-Modell. Das konzentriert sehr viel Komplexität auf einem einzigen Integrationspunkt. In der Entwicklung ist es teuer und unpraktikabel, ein Projekt mit IT-Experten zu besetzen, die sowohl fundierte Kenntnisse des EAI-Produkts als auch der semantischen Details aller zu integrierenden Applikationen besitzen. Die Skalierung, sprich Erweiterung der zentralisierten Hub-and-Spoke-Architektur eines EAI-Produkts, erfordert erheblich mehr Rechenressourcen.
Was zur ESB-Architektur gehört
Die Architektur eines ESB gruppiert sich um einen Bus. Dieser bietet - basierend auf Standards wie Soap, HTTP und Java Message Service (JMS) - Message Delivery Services.
Der Bus ist auf hohen Durchsatz und eine garantierte Nachrichtenübertragung für eine große Zahl an Services und Konsumenten ausgelegt. Die meisten ESBs unterstützen XML als nativen Datentyp und darüber hinaus Alternativen für den Umgang mit anderen Datentypen.
Die Grafik auf der ersten Seite veranschaulicht einige Komponentenarten, die mit einem ESB verbunden werden können:
-
Routing und Transformation:
Ein leistungsstarker Message Broker ist die Kernkomponente eines ESB. Er ermöglicht Content-basierendes Routing von Messages und Datentransformation unter Nutzung von Standards wie XQuery und XSLT.
-
Adapter, die normalerweise gemäß der Spezifikation Java Connector Architecture (JCA) gebaut sind, ermöglichen die Integration vieler unterschiedlicher Unternehmensanwendungen.
-
Eine verteilte Abfrage-Engine, die in der Regel auf XQuery oder SQL basiert, erlaubt die Gestaltung von Datenservices, um von der Komplexität der darunter liegenden Datenquellen zu abstrahieren.
-
Kundenanwendungen, basierend auf Standards wie J2EE und Struts, die mit dem ESB verbunden werden können, um eine Anwenderschnittstelle zu den Unternehmensservices zu liefern.
-
Eine Serviceorchestrierung oder BPM-Engine, die die Ausführung von Services steuert und für lang laufende Prozesse instand hält. Sie basiert auf Standards wie Process Definition für Java (PD4J) und der Business Process Execution Language (BPEL).