Das Paradigma der Service-orientierten Architektur (SOA) stellt neue Anforderungen an die Softwareentwicklung. Dabei zeigt sich, dass die Komplettlösung eines Herstellers nicht immer die erste Wahl ist. ZDNet gibt einen Überblick.
SOA bringt Transparenz in die IT-Landschaft - ermöglicht sozusagen eine Inventur -, bietet Flexibilität und schützt getätigte Investitionen, indem sich bereits vorhandene, stabile laufende Systemteile wieder verwenden lassen. Die Analysten der Aberdeen Group gehen davon aus, dass allein die Top-2000-Unternehmen weltweit in den kommenden fünf Jahren etwa 53 Milliarden Dollar an IT-Ausgaben durch SOA sparen können. Der Grund: Ist eine SOA erst mal implementiert, purzeln die Entwicklungskosten.
Doch bis geerntet werden kann, ist der Acker erst zu bestellen, das sagen die Analysten fairerweise auch. "SOA braucht neben den elementaren Teilen wie Service-fähige Anwendungen und eine neue Denke im Unternehmen vor allem ein stabiles IT-Fundament: einen 'Baukasten', dessen Elemente aufeinander aufbauen und einander ergänzen", gibt Markus Görg, Solution Architect bei der Danet GmbH in Weiterstadt, zu Protokoll. Sowohl in horizontaler als auch in vertikaler Richtung müssen die Komponenten miteinander interagieren: vom User-Front bis zur Datenbank und zwischen einzelnen Applikationen und innerhalb einer Anwendung. Das Denken in Services ist dabei außerordentlich hilfreich.
Unternehmen haben nun grundsätzlich drei Möglichkeiten, eine solche Basisinfrastruktur zu etablieren:
- selber bauen
- eine Development- und Integrations-Suite von einem Hersteller kaufen
- ein Framework aus Open-Source-Bausteinen zusammenstellen.
Für die wenigsten Unternehmen ist es sinnvoll, ein eigenes Framework zu erstellen. Herstellung und Pflege der Bausteine sind aufwändig, wenn man das volle Spektrum der benötigten Aktivitäten und Artefakte berücksichtigt. Insgesamt ist ein Engagement auf dieser Ebene in der Regel nicht profitabel. Softwareentwicklung gehört für das Gros der Industrie-, Handels und Dienstleistungsfirmen nicht zum Kerngeschäft.
Die Antwort der Softwareindustrie ist mittlerweile hinreichend publiziert: "Kaufen Sie eine Suite von der Stange." Doch eine kommerzielle Komplettlösung wie bekannte EAI- oder neuerdings SOA/ESB-Komplettlösungen haben neben dem Kostenaspekt weitere Nachteile: die Abhängigkeit und zum Teil eine völlige Überfrachtung. Software, die auf Basis dieser Frameworks entsteht, ist in der Regel in anderen Umgebungen nicht verwendbar. Denn trotz aller Lippenbekenntnisse und Initiativen in Sachen Interoperabilität verstehen Hersteller SOA als Mittel, vor allem "eigene" Produkte untereinander austauschbarer zu machen. Auch die Integration der einzelnen Bausteine der Komplettlösung untereinander lässt nicht selten zu wünschen übrig.
Bleibt Variante drei: Open-Source-Software bietet ausreichend Kandidaten, um einen SOA-Baukasten zu gestalten. "Die Produkte fußen auf Standards, die heute eine Vielzahl von Referenzen nachweisen können", wie Danet-Mann Görg erklärt. Dass die Qualität und die Zuverlässigkeit von Open-Source-Software hoch sind, hat eine Untersuchung der Standford-Universität zu Beginn dieses Jahres gezeigt: "Das Viele-Augen-Prinzip, beim der Quellcode von zahlreichen Entwicklern begutachtet, geprüft und optimiert wird, ist Grund für eine geringe Fehlerrate", so das Urteil des Forschungsberichts. Doch zum Nulltarif gibt es das SOA-Framework auf Basis von Open Source nicht, wie auch IT-Architekt Görg weiß: "Es ist zunächst darauf zu achten, welche Aufgabenstellung es zu lösen gilt und welche Komponenten dazu benötigt werden. Wie wählt man die aus und integriert sie? Diese Fragen müssen beantwortet werden. Notwendige Elemente einer SOA sind aus Sicht der Softwarehersteller ESB, WebServices, (UDDI) Registry und eine Workflow-Engine. Nach der Meinung von Görg ist keine dieser Bausteine zwingend für eine SOA.
Viele SOA-Initiativen zielen zunächst darauf ab, eine Kommunikationsinfrastruktur (Messaging) zu etablieren. Das passiert vor allem dort, wo die IT das SOA-Thema vorantreibt. Es ist zu beobachten, dass SOA nun als Vehikel benutzt wird, um weitere Gelder dort loszueisen, wo der EAI-Hype nach der Einführung großer Middelware-Boliden zum Teil eher ernüchternde Erfahrungen gebracht hat. Die Festlegung auf ein unternehmensweit einheitliches Messaging - sei es ein Standard wie Java Messaging Service (JMS) oder sogar ein Produkt -, sei laut Görg jedoch nicht entscheidend - mitunter sogar kontraproduktiv. Denn die Anforderungen an die Kommunikation können sehr unterschiedlich sein.
Die Geschäftlogik sollte plattform- und technologieunabhängig modelliert werden (PIM), und konkrete Implementierungen sollten über plattform-spezifische Modelle (PSM) und Transformationen generiert werden. Wer seine Entwicklungsmethodik nicht gleich so radikal umstellen möchte, kann zumindest versuchen, bei Serviceaufrufen die Bindung an die konkrete Kommunikationstechnik zu generieren. Was vielen unbekannt ist: Web-Services-Definitionen nach WSDL sind erst mal nicht an HTTP/SOAP gebunden. Vielmehr trennt WSDL die Definition der Services von der technischen Bindung an ein Protokoll. Interessant wäre jetzt ein Framework, das es erlaubt, einen Service-Aufruf zu formulieren und dabei die Details der Kommunikation generieren zu lassen. Einen solches Framework gibt es im Open-Source-Lager: Apaches WebService Invocation Framework (WSIF). Neben dem ganzen SOA-Hype scheint WSIF kaum beachtet zu werden. Allerdings mehren sich die Hinweise, dass diese Ideen in aktuellen SOA-Standards, hier: JBI (JSR-208), wieder aufgegriffen werden.
Neben dem Aspekt der Kommunikation und des Messaging wird im Kontext von SOA heftig über Geschäftsprozesse diskutiert: Die Fachabteilungen sollen durch SOA in die Lage versetzt werden, selbst und möglichst ohne Zutun der IT Geschäftsprozesse zu implementieren. Selbstredend grafisch, ohne Programmierkenntnisse. So weit die Versprechen der Hersteller. "Mag sein, dass dies in Zukunft Realität werden könnte - zurzeit ist die Vision in der Praxis eher eine Fata Morgana", wie Lösungsarchitekt Görg erklärt. Wichtig ist allerdings, dass man bei der Konzeption einer Anwendung in einer SOA unterscheiden muss: einerseits zwischen möglichst universellen, auf Wiederverwendung in unterschiedlichen Kontexten ausgelegten Services und anderseits der Verkettung dieser Services, also Workflows, als oberster Verdrahtungsebene.
Services sind universell, stabil, wieder verwendbar, Workflows dagegen spezifisch für einen Kunden oder eine Anwendung und müssen flexibel änderbar sein. Daher ist es wichtig, diese Schichten zu trennen, insbesondere dann, wenn projektübergreifende Lösungsbausteine und kunden- oder projektspezifische Anwendungsteile voneinander isoliert werden müssen. Die Praxis zeigt jedoch, dass die Workflows nie geändert werden, ohne dass es eines neuen oder geänderten Services bedarf.
Es gibt jedoch ein gutes Argument dafür, Workflow Engines einzusetzen: Mitunter lassen Prozessketten nicht "am Stück" abarbeiten. Beinhalten die Geschäftsprozesse Haltepunkte, an denen auf äußere Ereignisse gewartet werden muss, ist eine Workflow Engine unverzichtbar. Insbesondere, wenn die Prozesse insgesamt länger laufen (Stunden oder gar Tage). Hier ist es unumgänglich, den Kontext der Instanz dieses Geschäftprozesses persistent zu speichern. Ein Spezialfall von Prozessen mit Haltpunkten sind solche, die manuelle Bearbeitungsschritte, also die Interaktion von Anwendern, enthalten. Im Wesentlichen haben sich zwei relevante Standards für die Entwicklung und Ausführung von Workflow-Engines etabliert: die Business Process Execution Language (BPEL) und die XML Process Definition Language (XPDL). Hierfür eignet sich beispielsweise WfM Open, eine Open-Source-Implementierung für eine XPDL-Engine.
Open-Source-Komponenten lassen sich etwa über Standards zusammensetzen, die quasi den Kleber zwischen den Werkzeugen bilden können. So eignet sich XMI für Modelle, die ein Generator-Framework weiterverarbeiten kann. Dass die Werkzeuge in der Praxis gut zusammenpassen, liegt in der Struktur der Open-Source-Landschaft. Niemand tritt hier mit dem Anspruch an, eine Komplettlösung zu liefern. Man ist also darauf angewiesen, miteinander "zu können". Hier sind es die Quasi- oder Industriestandards, an denen man nicht vorbeikommt, wie Eclipse, das die verschiedenen Tools zusammenschweißt. Eine weitere Quelle für aufeinander abgestimmte und Standards bildende Komponenten ist das Java-Umfeld mit seinem JCP (Java Community Process).
Neben der Auswahl der passenden Technik und Tools ist es entscheidend, das Unternehmen auf SOA und die Verwendung von Open-Source-Tools vorzubereiten. Danet-Mann Görg empfiehlt: "Bis eine IT clever genug ist, solche "Wunderwerke" zu erschaffen, sollte sie sich darauf konzentrieren, SOA in der Planung und Implementierung von IT-Strukturen für komplexe Aufgabenstellungen zu verstehen und zu testen." Dabei liegt der Fokus auf der Designphase. Hier wird eher ein Dokumentations- und Diskussionsforum benötigt, in dem Teams ihre Erfahrungen und Lösungsansätze austauschen, Anforderungen klären und Inhalte (Semantik) von Diensten und Parametern dokumentieren können. Benötigt wird eine Plattform, die alles bietet, was Lösungsarchitekten und -entwickler brauchen, um einen Baustein einsetzen zu können - ein "internes Corporate Wikipedia". Diese Online-Sammlung von Informationen in einem Unternehmen, die sich dadurch auszeichnet, dass jeder unbürokratisch mitarbeiten und Beiträge leisten kann, unterstützt den Change-Prozess weitaus besser ein UDDI.
Tabelle:
|
Die Aufzählung hat keinen Anspruch auf Vollständigkeit. Quelle: Danet