Die Rückkehr der Einfachheit 62

Transkript

1 7.09 Plus CD! Stellenmarkt S. 58 Das war die JAX 2009 S. 15 Deutschland 7,50 Österreich 8,60 Schweiz sfr 15,80 Java Magazin Java Architekturen SOA Agile CD-Inhalt JavaRebel 2.0 Squish WebCastellum QF-Test Groovy Scala Apache Trinidad specs Keynote von der JAX 2009 Mobile JavaFX Mobile Neal Ford: Ancient Philosophers & Blowhard Jamborees Alle CD-Infos 3 Plattformübergreifend entwickeln 92 Web Web Application Security Gib Hackern keine Chance 48 Architektur Lose gekoppelte Systeme ActiveMQ und Camel 83 Java Core Einführung in Scala, Teil 4 Pattern Matching & Co 24 Die Rückkehr der Einfachheit 62 Google App Engine 38 D Cloud Computing mit Java Cloud Computing erobert die IT-Welt. Zu verlockend ist die Möglichkeit, Hardwareressourcen nach Bedarf hinzuzufügen und so immense Fixkosten einzusparen. Anfang April wurde die GAE für Java als Early Look veröffentlicht. Wie zeigen, wie die Google App Engine funktioniert.

2 SOA Center SOA aus dem wahren Leben Teil 9 SOA Design Pattern: Compensation In den letzten acht Artikeln dieser Serie haben wir uns mit den Bausteinen beschäftigt, aus denen eine SOA zusammengesetzt ist. Im Folgenden werden wir einige der wichtigsten SOA Design Pattern beschreiben, die wir in Projekten erfolgreich angewandt haben. Dazu gehören das Compensation Pattern, das UI Mediator Pattern, das Common Data Format Pattern und das Data Access Pattern. Alle diese Muster haben Einzug gefunden in Tomas Erls Buch SOA Design Pattern [1] und werden hier, mit unseren praktischen Erfahrungen angereichert, im Detail vorgestellt. Wir starten unsere SOA-Pattern-Best-of-Sammlung mit dem Compensation Pattern. von Berthold Maier, Hajo Normann, Bernd Trops, Clemens Utschig-Utschig und Torsten Winterberg n unserer virtuellen Autovermietung RYLC wurden BPEL- Prozesse entworfen, die Services orchestrieren. Diese Services waren sauber beschrieben, was ihre Funktionalität und ihre nichtfunktionalen Anforderungen, etwa in Bezug auf Antwortzeiten, angeht. Ein Thema jedoch verursachte ein mulmiges Gefühl unter den Beteiligten: Was ist, wenn entlang einer Kette von Serviceaufrufen, die zusammen eine logische (Geschäfts-) Transaktion bilden, etwas schiefgeht? Manche Services liefen über Transaktionsmonitore (z. B. auf einem Mainframe), sodass deren Entwickler dafür warben, alle Services über derartige Mechanismen anzubieten, um so gemeinsam das Problem zu bewältigen. Dieses Vorgehen war jedoch nicht umsetzbar, ohne das Designprinzip der losen Kopplung [2] zu verletzen. Unser Chefarchitekt kam über einen, teilweise schmerzhaften, Erkenntnisprozess zu dem Ergebnis: Der einzige Weg, eine Art der Transaktionalität in einer heterogenen SOA-Landschaft umzusetzen, besteht darin, für jede verändernde Serviceoperation eine Undo-Serviceoperation zu implementieren, die von der steuernden Orchestrierung (BPEL-Prozesse im beschriebenen Projekt) im Kompensationsmodus aufgerufen werden, wenn in einer Serviceaufrufkette etwas schiefgeht. In diesem Artikel werden wir diese Lösung als alternatives Transaktionsmuster beschreiben, mit allen Implikationen und Hinweisen, wann dieses Mus ter sinnvoll anwendbar ist und wann nicht. Motivation Compensation wird in einer SOA bei Fehlersituationen notwendig, da mehrere atomare Serviceoperationen in der Regel nicht mit klassischen Transaktionen verbunden werden können das würde, wie wir noch sehen werden, das Prinzip der losen Kopplung verletzen. Auftreten wird eine solche Fehlersituation vor allem, wenn Serviceoperationen bei der Orchestrierung oder durch Anwenden des Composit Patterns zu Prozessen oder neuen Services zusammengesetzt werden und die Transaktionsklammer dadurch erweitert werden muss. Wir benötigen Mechanismen, um die Auswirkungen von einzelnen Services (Statusveränderungen im Gesamtsystem) rückgängig zu machen und das System zu jedem Zeitpunkt in einen 78 javamagazin

3 SOA aus dem wahren Leben Teil 9 SOA Center konsistenten Zustand zu überführen es geht also um das Wahren der Integrität. Für das Compensation Pattern möchten wir folgende Fragen behandeln: Warum ist es wichtig bei SOA, über Compensation zu sprechen? Wie ist das Thema Compensation mit dem Thema Transaktionen verbunden? Wo liegen die Herausforderungen, wenn man Compensation betrachtet? Abb. 1: Services müssten geänderte Ressourcen für ein späteres Rollback locken [1] Das konkrete Problem Services sind per Definition atomare Einheiten, die eine klar definierte Geschäftsfunktion anbieten. Wenn bei der Nutzung eines Service fachliche oder technische Fehler auftreten, liegt es in der Verantwortung des Service, mit diesen Fehlern umzugehen, entsprechende Meldungen an den Aufrufer des Service zu senden und dafür zu sorgen, dass die Integrität des Gesamtsystems nicht verletzt wird. Es wird Situationen geben, in denen der Service alleine die Integrität nicht sicherstellen kann. Das ist z. B. der Fall, wenn mehrere Services mit einer Orchestrierungs-Engine zu einem Prozess oder zu einem Komposit Service zusammengeschaltet sind, aufgerufen werden und bei einem Fehler in einem der Services auch die Änderungen der vorgehenden Services zurückgenommen werden müssen. Im Prinzip müsste die Serviceoperation oder der angeschlossene Transaktionskoordinator dann mit allen beteiligten Serviceoperationen der Orchestrierung kommunizieren und die Verarbeitungsschritte rückgängig machen. Das gleiche gilt für den Fall, wenn die Runtime-Plattform auf Fehler während des Ablaufs einer Orchestrierung stößt. Auch in diesem Fall muss dafür gesorgt werden, dass Veränderungen von bereits aufgerufenen Services wieder rückgängig gemacht werden. Der klassische Ansatz, dieses Problem anzugehen, wäre die Nutzung eines Transaktionskoordinators nach dem ACID-Prinzip (Atomicy, Consistency, Isolation, Durability). Die Nutzung von Transaktionen würde bedeuten, dass alle beteiligten Services in die Lage versetzt werden, via Rollback, ihre Änderungen zurückzunehmen. Um das zu ermöglichen, müssen in der Regel die genutzten Backend-Ressourcen, wie Datenbank- Records oder andere Datenquellen, für den gesamten Zeitraum der Verarbeitung gesperrt werden, was oft zu einem Blockieren bei parallelem Zugriff führt. Insbesondere, da Ressourcen aufgrund sehr langlaufender Prozesse unter Umständen für mehrere Wochen geblockt wären. Wir befinden uns jedoch in einer SOA, wo Services lose gekoppelt sind [3]. Eine Transaktion stellt eine logische Klammer um eine Reihe von Services dar und bringt diese so in eine Abhängigkeit, die per se in einer SOA nicht gewünscht ist. Aus diesem Grund benötigen wir einen alternativen Lösungsansatz, der im Folgenden beschrieben wird. Das Compensation Pattern: Lösungsansatz Lösung Eine Compensation lässt sich als logisches Undo auffassen. Für verändernde Funktionalität muss entsprechende Undo-Logik bereitgestellt werden. Das bedeutet konkret, dass jede Serviceoperation, z. B. erstelleauftrag, die zu einer Zustandsänderung im System führt, eine entsprechende Undo-Serviceoperation benötigt, die den Zustand wieder in den vorherigen Stand zurücksetzen kann. Diese Undo-Serviceoperation ist in der Regel keine einfache inverse Serviceoperation, wie z. B. deleteauftrag, bei der ein Eintrag wieder aus einer Datenbanktabelle entfernt wird. Meistens muss eine komplexere Auswirkung einer Serviceoperation, und zwar dokumentierbar, rückgängig gemacht werden. Das entspricht einem gängigen Verfahren, das in der Geschäftswelt schon lange praktiziert wird: Fehlerhafte Buchungen werden nicht ausradiert, sondern mit einer Stornobuchung dokumentiert zurückgefahren. Dieses Konzept der Compensation wird bei Serviceorchestrierungen und -kompositionen benötigt. Hier kann es zu der Situation kommen, dass in einem Prozessablauf verschiedene Serviceoperationen erfolgreich durchgeführt wurden. Eine später aufgerufene Serviceoperation wirft nun einen Fehler, der dazu führt, dass die vorhergehenden Serviceoperationen zurückgefahren werden müssen, die den Zustand des Systems geändert haben und zu dem gleichen Service- Wenn in Prozessen fachliche oder technische Fehler beim Aufruf von Services auftreten, ermöglichen die Mechanismen des Compensation Pattern, das Gesamtsystem wieder in einen konsistenten Zustand zu versetzen. javamagazin

4 SOA Center SOA aus dem wahren Leben Teil 9 Abb. 2: Compensation erfordert kein Sperren der zugrunde liegenden Ressourcen [1] Das BPEL-Sprachkonstrukt zur Abwicklung einer Compensation ist intuitiv anzuwenden: In einem Exception Handler wird der auftretende Fehler gefangen und bei Bedarf mittels der compensate-aktivität der entsprechende Compensation Handler angestoßen, der sich um das logische Rollback kümmert. Da ohne Transaktionsmonitor keine Locks auf die entsprechenden Datenquellen gesetzt werden, arbeiten die Fachprozesse oft mit Attributen, wie beispielsweise Auftragsstatus=FREIGEGEBEN. Diese Attribute müssen entsprechend auch in Fehlerfällen manipuliert werden. kontext gehören. Anstelle der Nutzung einer technischen Transaktion zur Sicherstellung der Integrität des Systems, wird die Serviceorchestrierung um die Funktion eines Compensation Handlers erweitert. Mithilfe des Compensation Handlers kann definiert werden, welche Undo-Serviceoperationen im Fehlerfall aufgerufen werden müssen. Das Zurückpropagieren eines Fehlers in einer Aufrufkette wird dadurch erreicht, dass Anwendungsgebiete jeder Service oder Prozess eine Fault-Operation bereitstellen muss. Das stellt für synchrone Services kein Problem dar hier wird im Fehlerfall ein entsprechender Fault zurückgegeben. Für alle asynchronen Serviceaufrufe muss eine alternative Lösung gefunden werden. Hier bietet sich innerhalb der Serviceorchestrierung die Implementierung des asynchronen Request-Response-Pattern an: Der aufrufende Prozess wartet in diesem Fall so lange, bis eine Rückmeldung erfolgt. Im Fehlerfall versendet der aufgerufene Service anstatt der normalen Rückmeldung eine Fehlernachricht an den Aufrufer, woraufhin der entsprechende Compensation Handler aktiviert wird, der sich um das logische Rollback der nötigen Schritte kümmern kann. In BPEL würde hierzu statt einer Receive- Aktivität die Pick-Aktivität verwendet werden, um entweder auf die Antwort oder den Fehler zu reagieren. Kompensationslogik liegt in der Hand der Servicedesigner und muss berücksichtigt werden. Compensation wird bei Servicekompositionen eingesetzt, wenn mehrere Serviceoperationen aufgerufen werden, die unabhängig voneinander den Zustand des Gesamtsystems verändern. Compensation kann nicht zum Einsatz kommen, wenn Services Daten implizit verändern, z. B. durch Auslösen von Datenbank-Triggern. Beim Kapseln von Altsystemen durch Web Services und der Bereitstellung ihrer Funktionen als Serviceoperationen liegt der Einsatz des Compensation Pattern nah, da hier die Nutzung eines Transaktionsmanagers selten in Frage kommt. Oft hat man nur die Option, eine Serviceoperation im Fehlerfall via Compensation zurückzusetzen, weil das Altsystem gar nicht die Möglichkeit bietet, via Rollback den ursprünglichen Status wiederherzustellen. Auswirkungen Folgende Auswirkungen sind beim Einsatz von Compensation zu beachten: Der Aufbau von Undo-Serviceoperationen bedingt Berücksichtigung in der Fachlichkeit und im Code von existierenden Services. Compensation zwingt die Entwickler umzudenken und das klassische Transaktionsmodell zu verlassen. Kompensationslogik existiert nicht einfach und kann automatisch verwendet werden, wie von einem Datenbank-Rollback bekannt, sondern liegt vollständig in der Hand der Servicedesigner und muss entsprechend beim Design Berücksichtigung finden. Da es um nicht weniger als die Integrität des Gesamtsystems geht, kommt dieser Aufgabe besondere Bedeutung zu und wirkt sich letztlich auf die Qualität der Services direkt aus. Werden z. B. Undo-Serviceoperationen so gebaut, dass sie unreflektiert alles zurücksetzen, ohne auf die Geschäftslogik zu achten, kann es dazu führen, dass man davon ausgeht, dass die Kompensation sauber ausgeführt wurde, das Gesamtsystem sich aber nicht mehr in einem konsistenten Zustand befindet. Das kann gerade dann passieren, wenn der Designer der Komposition keine detaillierte Beschreibung der Logik des aufgerufenen Service und dessen Undo-Serviceoperationen besitzt. In der Compensation-Phase werden alle Serviceaufrufe in inverser Ordnung durch entsprechende Undo-Serviceoperationen rückgängig gemacht. Dieses Design stößt in einigen Fällen an seine Grenzen: Was geschieht in der Compensation-Phase, wenn im Prozessablauf Serviceaufrufe durch Konditionallogik verwehrt wurden ein 80 javamagazin

5 SOA aus dem wahren Leben Teil 9 SOA Center Regelservice bestimmt beispielsweise zum Zeitpunkt des Aufrufs, ob die Operation fachlich überhaupt durchgeführt werden darf. Ein Compensation Handler weiß dann zur Designzeit nicht, welche Undo-Operationen er aufrufen soll. Um auch diesen Fall abzudecken, sind zwei Anwendungsmuster denkbar: Idealerweise sind Services und vor allem Undo-Serviceoperationen idempotent implementiert. Ein Aufruf aller Undo-Serviceoperationen im Prozess würde dann ohne Folgen bleiben von der Systemlast abgesehen. Alternativ dazu muss auf die Protokollierung aller Aufrufe in einer separaten Variablen zurückgegriffen werden. Bei Verwendung einer BPEL-Prozess-Engine werden die Variablen persistiert und stehen auch bei einem späteren Aktivieren bzw. Zurückrollen noch zur Verfügung. Ohne Prozess-Engine oder wenn Prozesse lediglich das Message Exchange Pattern Fire and Forget implementieren, ist die Protokollierung aller Aufrufe in einem separaten Header-Bereich der Message ein beliebter, aber unschöner Lösungsweg, um die getätigten Aufrufe durch einen separaten Compensation-Prozess rückgängig machen zu lassen. Es gibt aber auch Situationen und Anwendungsfälle, in denen es unbedingt notwendig ist, Transaktionen durchzuführen. Das klassische Beispiel hierfür ist die Banküberweisung, bei der es aus Geschäftsprozesssicht heraus kritisch ist, sich auf Kompensation zu stützen. In diesem Fall steht das SOA-Prinzip der losen Kopplung [2] gegen das Integritätskonzept. Für diese Fälle kann man Alternativlösungen anstreben, die im Folgenden beschrieben sind. Abb. 3: Ein Transaktionskoordinator verwaltet die Transaktionsgrenzen [1] Abb. 4: Ein Error- Handler fängt in BPEL alle Fehler ab und stößt per compensate den passenden Compensation Handler an 1. Transaktionskapsel: Wenn es triftige Gründe dafür gibt, nicht auf das Compensation Pattern zurückzugreifen, kann man den Prozess in einen Compound Service [1] umwandeln. Man erweitert dazu den Funktionsumfang des Service (transfermoneyfromaccounttoaccount( )) und behandelt die Transaktion innerhalb dieses Service. Eine Alternative ist die Nutzung der proprietär zur Verfügung gestellten Mechanismen einiger SOA Suiten, die für ESB- und BPEL-Integrationsprozesse die Möglichkeit bieten, einen Transaktionskontext zwischen Serviceaufrufen zu verwalten. Damit erhält man die Möglichkeit, bei Fehlersituationen eine zusammengesetzte Transaktion via Rollback sauber zurückzurollen, ohne entsprechende Undo-Operationen bereitstellen zu müssen. Noch einmal: Durch diese Verwendung einer klassischen Transaktionsklammer schafft man eine Abhängigkeit zwischen den Serviceoperationen (Abbuchen und Zubuchen) und erweitert somit den technischen Schnittstellenvertrag künstlich um die Details der Transaktionsklammer. Das unterläuft SOA-Prinzipien, z. B. Wiederverwendung oder lose Kopplung. 2. Abstützen auf bestehende Transaktionsprotokolle (WS-TX, XA): Statt der Verlagerung der Transaktionsverantwortung in die Serviceoperation erwägt Thomas Erl die Verwendung eines Transaktionskoordinators (Transaction Coordinator [4]). Das bedeutet für Services, dass sie sich beim Transaktionskoordinator registrieren, sobald eine Operation ausgeführt wird und somit ihre Transaktionsmanagementverantwortung delegieren. Da Ressourcen nicht über einen längeren Zeitraum gesperrt werden dürfen, ist diese Implementierung nur im Fall von kurzlebigen Transaktionen zu empfehlen und findet sich daher oft in hochperformanten Integrationsprozessen wieder. Use Case In unserem RYLC-Unternehmen [5] ist der Chefarchitekt bei der SOA-fizierung der Anwendungen auf folgendes Problem gestoßen: Nachdem Services und Prozesse definiert waren, hat er sie teilweise mithilfe von SessionBeans, teilweise mit Spring POJOs, umsetzen lassen. In einem weiteren Schritt wollte er nun auf diesen Service Web-Service- Schnittstellen aufsetzen. Das hat sich im ersten Anlauf auch sehr gut umsetzen javamagazin

6 SOA Center SOA aus dem wahren Leben Teil 9 lassen gerade solange die Gut -Fälle betrachtet wurden. Sobald aber Ausnahmen und Fehlerfälle hinzu kamen, wurde die Sachlage komplexer: Nach der fehlerhaften Ausführung von Web Services konnte das System nicht mehr mithilfe von Rollbacks zurückgefahren werden, da nach Erweiterung auf SOAP Web Services das Konzept der Transaktionen so nicht mehr zur Verfügung stand und die entsprechenden Undo-Serviceoperationen in den SpringBeans und EJBs (noch) nicht implementiert waren. Wenn wir uns den Einsatz des Compensation Pattern an einem konkreten Beispiel, in unserem RYLC-Unternehmen beim Teilprozess schreiberechnung anschauen, so werden innerhalb dieses Prozesses zwei Serviceoperationen aufgerufen, die unabhängig voneinander das Gesamtsystem verändern. Schlägt eine dieser beiden Serviceoperationen fehl, befindet sich das Gesamtsystem in Listing 1: Implementierung eines Compensation Handlers in einem BPEL-Prozess [3] <!-- Update crm 2 infos --> <scope name= Scope_CRM2_UpdateInfos > <!-- Definition des Compensation Handlers --> <compensationhandler> <! Aufruf der undo funktion --> <invoke name= Invoke_SetCRMRecordToInvalid partnerlink= CRM2 porttype= client:rylc_compensation operation= somethingelse inputvariable= Invoke_SetCRMRecordToInvalid_initiate_ InputVariable /> </compensationhandler> <invoke name= Invoke_SchreibeCRMInfos partnerlink= CRM2 porttype= client:rylc_compensation operation= initiate inputvariable= Invoke_SchreibeCRMRechnung_initiate_ InputVariable /> </scope> <scope name= Scope_SchreibeRechnung > <faulthandlers> <!-- fault handler, alle Fehler --> <catchall> <!-- expliziter call zu compensation --> <compensate name= Compensate_CRMInfoRecord /> </catchall> </faulthandlers> <invoke name= Invoke_SchreibeRechnung partnerlink= InvoiceService porttype= client:rylc_compensation operation= initiate inputvariable= Invoke_SchreibeRechnung_initiate_ InputVariable /> </scope> einem inkonsistenten Zustand. Genau für diesen Fall benötigen wir: 1. Die in diesem Artikel bereits beschriebenen Undo-Serviceoperationen 2. Einen Compensation Handler, z. B. den Compensation Handler einer BPEL Engine, der die Undo-Serviceoperationen der im Scope der Transaktion befindlichen Services aufruft,und somit das Gesamtsystem wieder in einen konsistenten Zustand bringt In diesem Beispiel nutzen wir zwei Serviceoperationen, die letztendlich ihre Informationen in Datenbanktabellen ablegen und gegebenenfalls an Datenbanktransaktionen teilnehmen könnten. Ob nun der Standardtransaktionsmechanismus der Datenbank oder der Compensation-Mechanismus zum Einsatz kommen, ist im Einzelfall abzuwägen: Compensation ist immer die richtige Wahl im Sinne einer reinen SOA, Standardtransaktionen sind aber oft einfacher umgesetzt. Ist ein weiterer Schritt innerhalb des Beispielprozesses das Versenden einer an den Kunden so kann dieser Schritt nicht mit einem Undo oder Rollback zurückgefahren werden. Hier würde die Undo-Serviceoperation eine weitere generieren, die den Kunden darüber informiert, dass die vorhergehende ungültig ist, also eine Stornierungsfunktionalität zum Einsatz kommt. Fazit Wenn man über SOA spricht oder an eine erste Umsetzung geht, wird das Thema Fehlerbehandlung häufig zurückgestellt man konzentriert sich zunächst auf die Gut -Fälle. Letztendlich kommt man aber nicht um die Beschäftigung mit den entsprechenden Konzepten herum, da teilweise Anpassungen in der Architektur nötig werden. Jeder Architekt muss sich daher mit den Implikationen von Transaktionen und Compensation innerhalb einer SOA auseinandersetzen, um die Auswirkungen einschätzen zu können. Wie beschrieben gibt es auch Alternativen das Verlagern der Transaktion in die Serviceimplementierung oder die Nutzung von verteilten Transaktionen diese Alternativen widersprechen jedoch grundlegenden SOA-Prinzipien, besonders dem Prinzip der losen Kopplung und sollten vermieden werden. Bereits beim Design von Services muss man sich Gedanken über Compensation machen. Service- und Prozessdesigner müssen definieren, welchen Scope Undo-Serviceoperationen haben. Diese Aufgabe gilt sowohl für Services, die Altanwendungen kapseln, als auch für Services, die neu entwickelt werden. Compensation Handler werden von allen auf dem Markt befindlichen BPEL-Prozess-Engines standardkonform angeboten und ermöglichen das robuste Aufsetzen von Systemen, gerade auch im Umfeld komplexer Enterprise- Systeme gründeten die Autoren die Masons-of-SOA mit der Vision, SOA über internationale Unternehmensgrenzen hinaus zu propagieren, kritische Projekte gemeinsam zu unterstützen und Erfahrung aus zusammen 20 SOA-Projektjahren weiterzugeben. Die Publikation dreier Entwurfsmuster (Compensating Service Transaction, UI Mediator sowie Canonical Schema Bus) in Thomas Erls SOA-Design-Patterns- Buch und die vorliegende Artikelserie sind Beispiele für diese Arbeit. Links & Literatur [1] Erl, Tomas: SOA Design Patterns : [2] Maier, Berthold; Normann, Hajo; Trops, Bernd; Utschig-Utschig, Clemens; Winterberg, Torsten: Lose Kopplung, in Java Magazin [3] wsbpel/2.0/os/wsbpel-v2.0-os. html#_toc [4] Cross Service Transaction: soapatterns.org/cross_service_ transaction.asp [5] Maier, Berthold; Normann, Hajo; Trops, Bernd; Utschig-Utschig, Clemens; Winterberg, Torsten: Rent your Car Service-oriented, in Java Magazin [6] Maier, Berthold; Normann, Hajo; Trops, Bernd; Utschig-Utschig, Clemens; Winterberg, Torsten: Servicekategorien, in Java Magazin [7] Business Transaction Protocol: coordination.html#btp 82 javamagazin