Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

12.05.2006

SOA braucht den Enterprise Bus

Als Integrationsschicht in einer Service-orientierten Architektur ermöglicht der Enterprise Service Bus das Zusammenspiel von Softwareservices in heterogenen IT-Umgebungen.
Herzstück des Enterprise Service Bus sind leistungsstarke Messaging-Funktionen.
Herzstück des Enterprise Service Bus sind leistungsstarke Messaging-Funktionen.

Um eine SOA-Strategie zu realisieren, ersetzen Unternehmen nicht einfach ihre bestehende Infrastruktur. Aus Kostengründen und mit Blick auf die Komplexität der Applikationen werden bestehende Programme als Services zur Verfügung gestellt. Damit lassen sie sich auch für andere Geschäftsprozesse und Anwendungen verwenden. Deswegen ist das Herz jeder SOA ein Integrations-Layer, der dynamische Interaktionen zwischen Services in einer heterogenen Umgebung unterstützt.

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 obenstehende Grafik 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).

Hier lesen Sie …

Dieser Layer muss Veränderungen in der IT bewältigen, die beispielsweise erforderlich sind, wenn das Geschäft wächst und neue Kunden und Partner angesprochen werden sollen. Dazu unterstützt er die Weiterentwicklung bestehender und die schnelle Ergänzung neuer Services. Gleichzeitig ist es erforderlich, die Servicenutzer von Änderungen an den Serviceendpunkten abzuschirmen. Der Integrations-Layer ist deshalb so ausgelegt, dass Interaktionen zwischen den Services nicht mehr von den Endpunkten selbst aus verwaltet werden müssen. Ein solcher Layer wird Enterprise Service Bus (ESB) genannt.

Kernfunktionen

ESBs bieten folgende Schüsselfunktionen: eine Registry für Publishing, Versionsverwaltung von Services und Message Brokering, ferner dynamisches Routing und Transformation zwischen Services. Darüber hinaus unterstützen ESBs die Message- und Transportsicherheit. Als verteilte Übermittler ermöglichen sie die Umsetzung der Policies, die mit Routing-Regeln, Transformationen, Sicherheit und Zugang verbunden sind.

Wie lässt sich ein ESB mit anderen Infrastruktur-Integrations-Layern vergleichen? Web-Services fügen einer IT-Architektur einen Abstraktions-Layer hinzu. Um einen einfachen und verständlichen Zugang zu den Applikationen zu ermöglichen, verwenden sie offene Standards. Trotzdem sind Web-Services allein für allgemeine Integrationsprojekte nicht ausreichend. Ihren Standards fehlt es an Spezifikationen für das Reliability- und Security-Management. Sie bieten auch nicht die umfassende Koordination und das Prozess-Management, die erforderlich sind, um zwischen den Anfragen der Servicenutzer und den Ressourcen der Servicehersteller zu vermitteln.

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.

Agile IT-Infrastruktur

Obwohl heute viele Infrastrukturlösungen als ESBs beschrieben werden, erfüllen nicht alle die Anforderungen für die Serviceintegration in heterogenen IT-Umgebungen. ESBs müssen Interaktionen zwischen Services ermöglichen, die auf unterschiedlichsten Applikationsplattformen wie beispielsweise Legacy-Stacks, .NET oder J2EE laufen. In einer SOA sind die Services wie Konsumenten angelegt, die auf die Werte anderer Services zugreifen und diese nutzen. Der ESB muss die Servicekonsumenten und -Provider von der Komplexität, die sich aus den Unterschieden der implementierten Transportprotokolle und Message-Formate ergibt, abschirmen. Er ist darauf ausgelegt, die Schwierigkeiten zwischen der "Sprache" des einen Service und der eines anderen zu beseitigen. Ein ESB ermöglicht dynamische Transformationen zwischen verschiedenen Service-Endpunkten unter Verwendung interoperabler Standards wie XQuery.

Verwaltbarkeit ist Bedingung

Wenn Services mit einem intelligenten Vermittler verbunden sind und Routing und Transformation für die Unterstützung von heterogenen Serviceinteraktionen eingesetzt werden, muss die IT die Verfügbarkeit dieser Interaktionen kontrollieren können. Nur so lässt sich die Zuverlässigkeit gewährleisten, die bei heutigen Geschäftstransaktionen erwartet wird. Eine intelligente, verwaltbare Infrastruktur als Teil eines einzigen zusammengefassten Layers erlaubt es, alle registrierten Services zu verwalten. Messages werden erfasst, die Performance wird überwacht. Zudem können Service- Level-Agreements (SLAs) getroffen werden, um die Qualität der Dienste zu gewährleisten.

Alles verbinden

Langfristig werden solche Serviceinfrastruktur-Lösungen erfolgreich sein, deren Funktionen sowohl aus der Sicht der Entwickler als auch der des Managements integriert sind. Gleichzeitig müssen sie offen und mit Hilfe von etablierten Standards, Protokollen und Schnittstellen erweiterbar sein. Den Kern dieser Implementierungen wird ein vereinheitlichtes Metadata Repository bilden, das alle Fähigkeiten der Infrastruktur untermauert. (wh)