ECM und SOA – Wie passt das zusammen?
Das Herzstück der SOA-unterstützenden IT-Infrastruktur ist der Enterprise Service Bus (ESB), der die gesamte Kommunikation und Interaktion zwischen den Services vermittelt und zusammenfügt. Genau wie man den Autotank über die Benzinleitung an den Motor des Autos anschließt, sorgt der Enterprise Service Bus (ESB) heute für die Anbindung vorhandener Technologien und bildet dabei das Backbone-System für die Vernetzung, Kommunikation, Vermittlung von Services und das Management von Service-Containern, das für die Unterstützung einer SOA erforderlich ist. Der ESB hat sich mittlerweile zum De-facto-Standard für die Integration serviceorientierter Applikationen entwickelt.Angesichts des Stellenwerts, den der ESB in einer SOA-Implementierung hat, und seiner Auswirkungen auf Kosten, Entwicklungs- und Deployment-Prozesse ist es unerlässlich, die Funktionen und die Struktur des ESB im Detail zu verstehen. Ebenso wichtig ist die Kenntnis darüber, wie sein Design schnelle Änderungen, einfache Konnektivität und deutliche Visibilität sowie Kontrolle der Services und Prozesse in einer SOA-basierten Anwendung ermöglicht. Analysten von Gartner übernahmen den Begriff von der Firma Sonic. ESB steht danach für jede Integrationstechnik, die sich gegenüber Applikationsservern neutral verhält und aus einer Integrationsbroker-Suite sowie einem Bussystem besteht, das Unternehmensapplikationen miteinander verbinden kann. Laut Gartner können ESB-Produkte, die weitgehend auf Standards basieren, eine attraktive Alternative zu eingeführten Suiten sein, wie z.B. 'Websphere MQ Integrator' von IBM, 'Biztalk' von Microsoft, 'E*Gate' von Seebeyond, 'Active Enterprise' von Tibco, 'Businessware' von Vitria oder 'Integration Plattform' von Webmethods. Im Vergleich zu anderen Infrastruktur-Integrationslayern wie Web-Services, Application-Plattform-Suites oder traditionellen EAI-Produkten bietet ein ESB umfassendere Funktionen für Reliability-, Security- und Prozess-Management, einfachere Integration heterogener Systeme, breitere Unterstützung von Standards und eine agilere lnfrastruktur. Die Architektur eines ESB, basiert, wie es der Name sagt, auf einer Bus-Struktur. Diese bietet - basierend auf Standards wie SOAP, HTTP und Java-Messaging-Service (JMS) - Message-Delivery-Services und ist auf hohen Durchsatz sowie eine garantierte Nachrichtenübertragung für eine große Vielzahl an Services und Konsumenten ausgelegt. Die meisten ESB unterstützen XML als nativen Datentyp und darüber hinaus Alternativen für den Umgang mit anderen Datentypen. Im Bereich Routing und Transformation bildet ein hoch performanter Message-Broker die Kernkomponente des ESB. Er ermöglicht Content-basiertes Routing von Messages und Datentransformation unter Nutzung von Standards wie XQuery und XSLT. Adaptoren, die normalerweise gemäß der Java-Connector-Architecture-Spezifikation (JCA) aufgebaut werden, ermöglichen die Integration einer breiten Vielzahl an Unternehmensapplikationen. Eine verteilte Abfrage-Engine, die in der Regel auf XQuery oder SQL basiert, erlaubt die Gestaltung von Datenservices. Dies ermöglicht es, die Komplexität der darunter liegenden Datenquellen zu abstrahieren.Kundenanwendungen, basierend auf Standards wie J2EE und .net, die mit dem ESB verbunden werden können, liefern eine Anwenderschnittstelle zu den Unternehmensservices. Eine Service-Orchestierung- oder BPM-Engine steuert die Ausführung von Services, hält diese für lang laufende Prozesse in Stand. Diese Engine basiert in der Regel auf Standards wie Process-Definition für Java (PD4J) und Process-Execution-Language (BPEL). Die Service-Orchestierung erlaubt eine effiziente und standardkonforme Definition von Workflows entlang einzelner Services, damit aus einzelnen Services größere Anwendungen entstehen können. Dabei können Workflows nicht nur BPEL-konform modelliert, sondern auch mit anderen Werkzeugen ausgetauscht werden. Die Vorteile von SOA erschließen sich erst richtig dann, wenn alle Komponenten und Anwendungen auf ein Dienstekonzept umgestellt sind. Nur dann funktioniert auch die "Orchestrierung von Services". Grundidee ist dabei, dass es für jede Funktion nur einen gekapselten Service gibt. |