20070910i Information Builders Umsetzung von SOA
|
|
|
»manage
it«
als
|
Umsetzung von SOA zu Integrationszwecken: 5 Hürden Integration ohne HürdenFlexibilität ist nicht mehr nur ein Schlagwort, sondern unverzichtbare Grundlage des Geschäfts. Insbesondere bei Akquisitionen und der unternehmerischen Neuausrichtung spielt die Fähigkeit zur Integration von Systemen und Anwendungen eine entscheidende Rolle. Nur eine effektive Integration ermöglicht dem Unternehmen den notwendigen nächsten Schritt. IT unterstützt somit die Wachstumsstrategie des Unternehmens und macht es fit für die Zukunft. Um dies zu erreichen, müssen CIO und IT sich darauf konzentrieren, mit effizienten Prozessen dem Unternehmen neue Möglichkeiten auf den von starkem Wettbewerb geprägten Märkten zu erschließen.
n diesem Zusammenhang werden immer wieder serviceorientierte Architekturen (SOA) als goldener Lösungsweg diskutiert. Und tatsächlich bieten diese einen guten Ansatz, Integrationsaufgaben in den Griff zu bekommen. Die Umsetzung von SOA zu Integrationszwecken ist jedoch nicht ohne Probleme. Im Folgenden werden fünf Integrationshürden vorgestellt und Strategien erläutert, wie Unternehmen diese überwinden können. Zuvor jedoch gilt es zu unterscheiden, in welcher Form SOA hier betrachtet wird. Sehr häufig wird SOA unter dem Entwicklungsaspekt gesehen. SOA bildet dann die Plattform, auf der neue Anwendungen entwickelt werden. Im Unterschied dazu betrachtet dieser Artikel SOA unter dem Blickwinkel der Integration bereits vorhandener Anwendungen. Es geht also nicht darum, eine einheitliche Anwendungsumgebung zu kreieren, sondern eine Integrationsumgebung zu etablieren, in der die bestehenden Anwendungen sinnvoll miteinander interagieren. Dies bedeutet zum Beispiel, dass Transaktionen unterschiedlich gehandhabt werden müssen. Während in einer SOA als Entwicklungsumgebung alle zu einem Anwendungsfall gehörenden Services in einer Transaktionsumgebung ablaufen können, ist das in einer SOA als Integrationsumgebung unter Umständen anders. Hier befinden sich die Quelle eines Events und das Ziel dieses Events unter Umständen in unterschiedlichen Transaktionsumgebungen. Das hat zur Folge, dass Anwendungen und Anwendungsfälle bei einer SOA als Integrationsplattform nicht nur aus der Perspektive von Services betrachtet werden können. 1. Hürde: Es dreht sich alles um Services Im Zusammenhang mit SOA als Integrationsplattform sind Services nicht genug. Genauso wichtig sind die – häufig unterschätzten – Kanäle. Die Services bilden die Geschäftsfunktion ab, das bedeutet sie müssen nur dann geändert werden, wenn sich die Funktion des Kerngeschäfts ändert. Beispielsweise wird die Anforderung »Bestellung anlegen” weit weniger häufig geändert als die Technologie zur Umsetzung dieser Anforderung. Mit anderen Worten: Die Art und Weise der Verarbeitung von Bestellungen ändert sich häufiger als die Tatsache, dass Bestellungen verarbeitet werden. Daher sind die Services als solche wesentlich konstanter als die Technologie zur Implementierung der Services. Die Kanäle hingegen bestehen aus der technischen Schnittstelle zum Aufruf der Services, der semantischen Darstellung des Service und der Beziehungen der Services untereinander. Kanäle bilden die Unternehmensstruktur als IT-Struktur ab. Gehen wir beispielsweise von einem Kanal aus, der nach folgenden Prinzipien arbeitet: (1) es werden über EDI (Electronic Data Interchange) eingegangene elektronische Bestellungen akzeptiert, (2) die Verwaltung von Rabatten und CRM-Prozessen (Customer Relationship Management) erfolgt über Webservices, (3) über JMS-Messaging (Java Messaging Services) werden Aufträge an andere Abteilungen des Unternehmens übermittelt. Dieser elektronische Prozess ist das direkte Abbild der Unternehmensstruktur, in deren Zentrum die Bestellungen und deren Umsetzung stehen. Während die Services also recht konstant sind, ändern sich die Kanäle deutlich häufiger, da sie in Wechselwirkung zu den Geschäftsbeziehungen stehen. Diese werden in vielen Unternehmen jedoch besonders häufig verändert. Um eine maximale Flexibilität der Services zu erzielen, sollte daher eine Implementierung gewählt werden, die eine problemlose Neukonfiguration anhand von Kanälen zulässt. Damit erzielen Unternehmen über eine serviceorientierte Architektur hinaus eine Architektur, die auf Geschäftsdomänen ausgerichtet ist. 2. Hürde: Enterprise Service Bus – nur ohne »Enterprise« wirklich sinnvoll Die Bezeichnung Enterprise Service Bus (ESB) lässt darauf schließen, dass es eine Lösung zur Integration aller Schnittstellen und Verbindungen im Unternehmen gibt. Kurioserweise kann ein ESB jedoch nur dann erfolgreich eingesetzt werden, wenn die Hürde »Enterprise” entfernt wird – die Software also gerade nicht für das gesamte Unternehmen eingesetzt wird. Vielmehr sollte die Unternehmensstruktur den Integrationsprozess festlegen. Zur Verwaltung der Schnittstellensemantik sollte jede Geschäftsdomäne deshalb über einen logischen Semantik-Hub verfügen. Um die Kommunikation zwischen zwei verschiedenen Semantik-Hubs/Message Brokern zu gewährleisten, muss ein Federation-Protokoll zwischen die beiden Messaging-Systeme geschaltet werden. Solche Protokolle sind jedoch proprietär. Dies stellt kein Problem dar, solange Message Broker eines Typs verwendet werden. Kommen allerdings verschiedene Broker-Typen (zum Beispiel BEA und Sonic) zum Einsatz, kann keine Federation gebildet werden. Dieser Umstand stellt eine Hürde für die Integration dar. Daher muss in jeder komplexen Umgebung eine Brücke zwischen den Messaging-Systemen geschlagen werden, um sozusagen »die Integratoren zu integrieren«. Auch wenn diese Hürde aus dem Weg geräumt werden kann, sollte die Idee eines Enterprise Service Bus verworfen werden. Der Begriff »Enterprise« lässt auf einen Servicebus-Typ für alle Unternehmensabteilungen schließen. Da die Infrastruktur jedoch von den verfügbaren Mitteln abhängt, sind Systemarchitekten und Unternehmen besser beraten, Semantik-Hubs für Domänen zu erstellen. Dann müssen Änderungen nur gegen den Semantik-Hub getestet werden, es ist nicht mehr erforderlich, nacheinander alle Schnittstellen zu testen 3. Hürde: Zu viele Anforderungs- und Antwortprotokolle Alle fünf oder sechs Jahre preisen IT-Experten ein neues RPC-Protokoll (Remote Procedure Call) als Lösung für nahezu jedes Integrationsproblem an. DCE, CORBA und Webservices sind nur einige der jüngeren Beispiele dafür. Aber die Versprechungen stellen sich als nicht haltbar heraus. Solche Protokolle können unter Umständen Interoperabilitätsprobleme lösen, nicht aber Integrationsprobleme. RPC-Protokolle, und darauf basierende Webservices eingeschlossen, lösen in der Regel das Interoperabilitätsproblem durch eine enge Verknüpfung der Endpunkte, aber dieser Ansatz steht in Konflikt zur anstrebenswerten lose gekoppelten Integration. Dies scheint zunächst erstaunlich, denn auf RPC-Protokollen basierende Webservices scheinen weiter verbreitet zu sein als andere Lösungen. Dabei werden die Front-End-Anwendung und die aufgerufenen zustandslosen Services RPC-basiert integriert. Es liegt nahe, dass sich dafür ein RPC-Protokoll anbietet. Aber diese Lösung unterscheidet sich von einer tatsächlichen Anwendungsintegration. Es mag sinnvoll erscheinen, ein Front-End als »Anwendung« zu bezeichnen. Wenn Systemarchitekten jedoch ein Front-End zum Aufruf zustandsloser Services entwickeln, realisieren sie im Grunde genommen ein schichtenorientiertes Design der Anwendungen (Tiering), nicht aber eine Anwendungsintegration. Die Schichtung der Anwendungen erfolgt auf Anwendungs- beziehungsweise Technikebene, wohingegen bei der Anwendungsintegration geschäftsbasierte Services auf der Grundlage von anwendungsbasierten Services generiert werden müssen. Zusammenfassend kann gesagt werden, dass »Services« in einer serviceorientierten Architektur in erster Linie ereignisgesteuert sein sollten. Nur wenn es unumgänglich ist, sollten die Services über RPC-Anforderungen und Antwortprotokolle gesteuert werden. 4. Hürde: BPEL – integriert keine Anwendungen, sondern erstellt sie Einige Argumente für BPEL (Business Process Execution Language) scheinen unschlagbar. Anstatt von Grund auf neue Services zu erstellen, kann der Benutzer bereits vorhandene Services per Drag & Drop in die BPEL-Konsole ziehen, Tests durchführen und die Services bereitstellen. Eine solche Vorgehensweise eignet sich für eindrucksvolle Demos. Leider sind die Dinge jedoch komplexer als sie auf den ersten Blick scheinen. Zunächst sollten BPEL-basierte Prozesse lose mit den Services gekoppelt sein, die sie orchestrieren. Rufen zum Beispiel 20 BPEL-basierte Geschäftsprozesse den Service »getCustomerInfo« auf, sollten nicht alle Prozess-Definitionen angepasst werden müssen, wenn ein Mitarbeiter der Marketingabteilung beschlossen hat, dass sein Service geändert werden muss. Das bedeutet, es ist eine Integration von BPEL und den Services erforderlich, bevor die Orchestrierung der Services erfolgen kann. Diese Vorgehensweise läuft entgegengesetzt dem üblichen Verfahren: BPEL wird nicht für die Integration von Anwendungen eingesetzt, sondern normalerweise werden Anwendungen integriert, damit die Verwendung von BPEL möglich ist. Dabei kann es zu Problemen kommen, wenn die aufgerufenen Services nicht auf dem Anwendungsserver laufen, auf dem BPEL verwendet wird. Dann muss das XML-Format von BPEL in das XML-Format der Services transformiert werden – ein sehr aufwendiger Prozess. Ein weiteres Problem bei der Verwendung von BPEL stellt die Skalierbarkeit dar, die einen Einfluss auf Leistung und Komplexität der verarbeitbaren Services hat. Hier sorgt BPEL für Performance-Probleme bei hohem Nachrichtendurchsatz, als auch bei der Verarbeitung der Transaktionen. 5. Hürde: SOA-Integration ist für Programmierer, nicht Analysten Die SOA-Integration muss von Programmierern implementiert werden, obwohl sie eigentlich eine Aufgabe für Analysten wäre. Dies liegt daran, dass eine klare Darstellung von für die Analysten verwertbaren Metadaten fehlt. Webservice-Metadaten sind physische Daten. Wer einen SAP-basierten Webservice erstellt, erhält Elemente mit unverständlichen Abkürzungen deutscher Definitionen. Datenbank-basierte Webservices enthalten Datenelemente, die den kryptischen Namen entsprechen, die Programmierer zur Benennung von Spalten in Datenbankschemata verwendet haben. Logische Metadaten dagegen sind frei von allen Implementierungsbesonderheiten aus den Metadaten, wie beispielsweise physische Datentypen oder Einschränkungen der Implementierung. Dies ist der Typ von Metadaten, den ein Analyst verwenden kann. Sie werden auch als konzeptuelle Metadaten bezeichnet. Benutzer von Geschäftsvorgängen können leider nur dann Prozessabläufe schreiben – und Services erstellen –, wenn ihnen konzeptuelle Metadaten zur Verfügung stehen. Bedauerlicherweise gibt es unter Verwendung der heutigen Technologie nahezu keine Möglichkeit, Webservices in Form von konzeptuellen Metadaten darzustellen, und es besteht wenig Hoffnung, dass sich dieser Umstand in nächster Zukunft ändern wird. Die Erstellung von BPEL-basierten Prozessen ist also auch weiterhin die Aufgabe des Programmierers. Empfehlungen Nachdem nun die Hürden der Integration aufgezeigt wurden, wird im Folgenden dargestellt wie die SOA-basierte Integration erfolgen sollte, um diese Hürden zu überwinden. 1. Zuerst integrieren, dann orchestrieren Zunächst wird der zustandslose Prozessablauf erstellt, der die Abwicklung eines Geschäftsereignisses beschreibt. Dabei sollte es sich um einen ereignisgesteuerten Prozess, nicht um einen RPC-basierten Prozess handeln. Anschließend wird bestimmt, wie die Ereignisse von Umgebung zu Umgebung übertragen werden. 2. »Drehstuhl«-Integration steigert die Effizienz ‚Einfache’ Integrationsaufgaben findet man dort, wo ein Ereignis in einem System ein Ereignis in genau einem anderen System auslöst. Die »Drehstuhl«-Metapher beschreibt das Bild eines Mitarbeiters, der auf einem Drehstuhl sitzt und ein Ereignis in einem System erstellt (zum Beispiel »purchaseOrderAccepted«) und sich dann auf seinem Drehstuhl einem neuen Bildschirm zuwendet, um die Daten in gleicher oder leicht abgewandelter Form in ein weiteres System einzugeben. Die Drehstuhlintegration führt unmittelbar zur Effizienzsteigerung und liefert, wenn sie mit Blick auf eine mögliche Wiederverwendung durchgeführt wird, Anhaltspunkte zur Identifikation der auslösenden Ereignisse für wichtige Geschäftsprozesse. 3. Dann folgen die Batchprozesse Batchprozesse verarbeiten eine Vielzahl eingehender Daten und Ereignisse, deshalb bieten sie eine einfache Option, um diese wieder in einzelne Ereignisse aufzusplitten. 4. Schließlich erfolgen die Orchestrierungen Ereignisse und Services müssen zunächst im Rahmen einer losen Kopplung erstellt werden, bevor Orchestrierungen implementiert werden können. Deshalb verzögert sich der ROI (Return on Investment) bei Projekten, die eine Orchestrierung im Vorfeld erfordern. Nachdem aber Ereignisse und Services erstellt wurden, die eine Drehstuhl-Integration und Batch-Verarbeitung unterstützen, kann die Orchestrierung unter Verwendung dieser Komponenten auf profitable Weise umgesetzt werden. 5. Immer eine Kompensation in Betracht beziehen Wenn Unternehmen Serviceschnittstellen für die Orchestrierung erstellen, sollte immer das Thema ‚Kompensation’ in Betracht gezogen werden. In einer verteilten Landschaft, in der verschiedene Dienste von unterschiedlichen Systemen implementiert werden, ist es im Allgemeinen nicht möglich, eine den Geschäftsprozess umfassende Transaktionsklammer zu implementieren. Ein Lösungsansatz für diese Problematik ist es, für jede Aktion, die Daten verändert, eine sogenannte Kompensations-Aktion vorzusehen, die es erlaubt die Änderung der Daten wieder ‚rückgängig’ zu machen oder eben entsprechend zu kompensieren. Dies gilt sowohl für die unmittelbare Kompensation als auch für die Kompensation im Anschluss an die Übernachtverarbeitung. Da alle Services wiederverwendbar sein sollten, ist die Kompensation auch dann wichtig, wenn für das ursprüngliche Projekt keine Kompensation erforderlich ist. Resümee Anwendungsintegration mit den Prinzipien einer SOA ist zwar ein technisch anspruchsvoller, aus Business-Sicht aber durchaus lukrativer Ansatz. Insbesondere wenn es gelingt, die technischen Integrationshürden zu meistern, entsteht ein zukunftsfähiges, Business und IT sinnvoll zusammenführendes Konstrukt. Voraussetzung bleibt allerdings der nüchterne und pragmatische Zugang zum Thema, ohne Heilsversprechen abzugeben, die nicht einzulösen sind. Aufgabe der IT bleibt es also, den Business-Entscheidern das Machbare und dessen Nutzenpotenzial vor Augen zu führen. Klaus Hofmann zur Linden ___________________________________________________________________ Klaus Hofmann zur Linden ist Technical Manager bei Information Builders
|
Folgen Sie »manage it« auf Google+
|
