| SOA braucht den Enterprise Bus | |
| Seite 2 | |
| Agile IT-Infrastruktur |
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.
welche Aufgaben ein Enterprise Service Bus innerhalb einer SOA übernimmt;
wie sich ein ESB von anderen Integrations-Layern unterscheidet;
aus welchen Komponenten moderne ESB-Produkte bestehen.
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.
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.
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.
