Quo vadis JSF? Grails in Action. OSGi mit Spring dm Viele Köche verderben (nicht) den Brei. Die nächste Generation der Webentwicklung 42

Transkript

1 Plus CD! Stellenmarkt 8.09 Liferay Enterprise Edition gives you all the benefits of open source with the stability, security, and reliability of an enterprise subscription. And with version 5.1, get the latest in SOA, Social Networking, and Collaboration technology, all at a fraction of the cost of Oracle or IBM. Liferay 5.1 Enterprise Edition Maintenance Subscription EUR / server / year Platinum Support (24x7) EUR / server / year Compare Oracle WebCenter Suite: EUR / processor, support EUR / yr, as of 6 / 2008 For more information, us at sales@liferay.com. JSF 2.0 Spring dm Meta Programming System ScalaModules Grails Garbage Collector Now get the best of both worlds. Das Tutorial: Lose Kopplung mit Mule Deutschland 7,50 Java Magazin Java Magazin You spoke. We listened. Introducing Liferay Enterprise Edition. S. 62 Java Architekturen SOA Agile S. 71 Österreich 8,60 Schweiz sfr 15,80 CD-Inhalt ALLE IN FOS ZU AB SEIT Apache Commons Compress E 29 Grails Spring dm 1.2 Project Mojarra Scala Mule Die nächste Generation der Webentwicklung 42 Ed Burns: Secrets of the Rockstar Programmers Session von der JAX 2009 Alle CD-Infos 3 Java Core OSGi on Scala DSLs mit ScalaModules 18 XML vs. Annotations Sind Annotations die erhoffte Rettung? 37 Tools Java-Spracherweiterung mit JetBrains MPS Effizient DSLs erstellen Interview mit Ed Burns Grails in Action Enterprise Garbage Collector Das unbekannte Wesen Quo vadis JSF? 65 Erfahrungsbericht: WerKannWann.de 56 D EUROPEAN HEADQUARTERS - LANGEN, GERMANY LIFERAY GMBH ROBERT - BOSCH - STRASSE 11, LANGEN, GERMANY TEL: (0) Ý FAX: (0) OSGi mit Spring dm Viele Köche verderben (nicht) den Brei 24 R

2 SOA Center SOA aus dem wahren Leben Teil 10 SOA und Benutzeroberflächen Das Zusammenspiel von Benutzeroberflächen mit Diensten einer SOA ist ein oft vernachlässigtes Thema. In diesem Artikel betrachten wir die besonderen Herausforderungen, die bei der Erstellung von Oberflächen zu meistern sind, wenn ganze Prozessketten aufzurufen sind und mit diesen interagiert werden soll. Nach einigen allgemeinen Architekturüberlegungen beschreiben wir eine praktische Anwendung des UI Mediator Pattern von Thomas Erl [1], angereichert mit unseren praktischen Erfahrungen. Einführung: Technisch alles kein Problem Die Antwort auf diese Anforderung liefert im SOA-Umfeld die WS-Humanvon Berthold Maier, Hajo Normann, Bernd Trops, Clemens Utschig-Utschig und Torsten Winterberg ie Interaktion eines Menschen mit einem Geschäftsprozess besteht im einfachsten Fall darin, den Prozess anzustoßen und das Ergebnis abzuwarten. Ein Prozess läuft jedoch in den seltensten Fällen vollautomatisch ab, sodass die Möglichkeit menschlicher Ein- griffe in einen Prozessablauf eine wichtige Anforderung darstellt. Task Spezifikation [2]. Hier wird eine einheitliche API für einen Workflow- Service definiert, über den sich ein Postkorb mit Aufgaben befüllen lässt. Kommt die Prozessautomatisierungssprache BPEL zum Einsatz, so definiert die BPEL4People-Spezifikation, wie Artikelserie: SOA aus dem wahren Leben Teil 01: Rent your Car Service-oriented (Use Case) Teil 02: SOA Blueprint Ein Werkzeugkasten für Architekten Teil 03: SOA-Bausteine im Kontext konkreter Projekte von klein nach groß Teil 04: Servicekategorisierung Teil 05: Lose Kopplung Teil 06: Service Requirements Teil 07: Governance Organizational Change Teil 08: SOA Security Teil 09: SOA Pattern 1 Compensation und Use Case Teil 10: SOA Pattern 2 Benutzeroberflächen und Use Case Teil 11: Das kanonische Datenmodell Teil 12: Dataaccess in einer SOA Teil 13: Change Management Teil 14: Event-driven SOA Teil 15: Schlussbetrachtung 14 Monate RYLC und nun? 88 javamagazin

3 SOA aus dem wahren Leben Teil 10 SOA Center diese Postkorbfunktionalität mittels WS-HumanTask direkt im Prozessablauf Anwendung finden kann. Beispiel: Ist während eines Prozessablaufs eine manuelle Freigabe oder die Eingabe weiterer Daten notwendig, so kann vom Prozess der zuständige Akteur ermittelt und via BPEL4People die Aufgabe in dessen Postkorb eingestellt werden. Dazu stellt der Human- Task-Service unter anderem eine Web Service API bereit. Der Endanwender empfängt die Einträge über seinen Postkorb und arbeitet die anfallenden Aufgaben sequenziell ab, worauf der wartende Prozess seine Arbeit im Hintergrund wieder aufnimmt. Abb. 1: Trivialer Standardansatz alle Daten sammeln, Prozess anstoßen und auf Ergebnis warten, aber was ist mit den Menschen? Dieses Lösungskonzept funktioniert technisch hervorragend, ist für viele Endanwender jedoch ungewohnt in der Handhabung. Bei kurzläufigen Prozessen ohne Rollenwechsel wird der Arbeitsfluss sogar als störend empfunden, da die altbekannten, datengetriebenen Anwendungssysteme sofort eine Antwort liefern konnten (Request-/ Response-artig), ohne den lästigen Umweg über einen Postkorb: Die Prozesssteuerung war sozusagen direkt in die Oberflächensteuerung mit eingebettet. Mithilfe derartiger herkömmlicher Applikationen konnte der Anwender gleichsam sein eigener Prozessherr Anzeige javamagazin

4 SOA Center SOA aus dem wahren Leben Teil 10 Abb. 2: Worklist-Applikation (Postkorb) für langlaufende Prozesse sein, während eine postkorbgestützte Lösung den Anwender in das Korsett eines vorgegebenen Prozesses zwängt. Jeder, der klassische BPEL-Prozesse mit Postkorbinteraktion designt, sollte sich klar machen, dass in der Folge ein Mensch morgens vor einer langen Liste an Aufgaben aus einem Postkorb sitzt, die oft sehr mechanische und sich immer wiederholende Benutzerinteraktionen erzwingen. Diesen Zwang erfassen viele Fachseiten heute intuitiv und stellen sich schützend vor die Anwender, für deren alltägliche Abläufe sie Anforderungen erstellen. Mit Einzug der SOA und loser Kopplung werden Arbeitsabläufe weiter automatisiert und die Prozesssteuerung verlagert sich Zug um Zug in das Backend. Da zudem einmal bestehende Prozesse auf Grund der vielgeforderten Flexibilität häufigen Anpassungen unterliegen können, ist eine zu enge Kopplung von Prozessen und Oberflächen zu vermeiden und die Entkopplung über den Postkorb die allgemeine Lösung. Im Folgenden wollen wir den gut verstandenen Einsatz von postkorbartigen Arbeitslisten vorstellen, ehe wir uns mit einer komfortableren Lösungsvariante beschäftigen, die auch als UI Mediator Pattern im SOA-Umfeld bekannt ist. Mit Einzug der SOA und loser Kopplung werden Arbeitsabläufe weiter automatisiert. Asynchronität ermöglicht stabile Oberflächen In Abbildung 1 wird der trivialste Fall einer Interaktion von Benutzeroberfläche und Prozess dargestellt. Über eine Reihe von (Web-)Seiten werden Daten erfasst, die anschließend einem Prozess als Eingabeparameter übergeben werden. Der Prozessaufruf, der synonym zu einem Serviceaufruf betrachtet werden kann, ist für ein synchrones Antwortverhalten entworfen, um das Ergebnis auszuwerten und direkt in die Folgeseiten zu verzweigen. Dieses Muster sieht man in der Praxis sehr häufig, es kann jedoch in einer SOA nicht das Mittel der Wahl darstellen. Wo liegt das Problem in dieser Architekturvariante? Die Antwort fällt leicht, wenn man wieder einen Schritt zurücktritt und überlegt, warum überhaupt SOA als Architekturprinzip zur Prozessumsetzung hergenommen wurde. SOA verspricht eine hohe Flexibilität und der Prozess eine schnelle Umsetzung bei Änderungswünschen. Was passiert aber, wenn genau diese Flexibilität wirklich eingefordert wird und der Prozess so verändert werden muss, dass das Ergebnis nicht mehr sofort, sondern um eine Zeitspanne X verzögert geliefert werden kann? Als neue Anforderung wird z. B. eine weitere Aktivität ergänzt, die vielleicht langläufig ist, vielleicht sogar eine Benutzerinteraktion über einen Postkorb beinhaltet. Als Folge bricht die Implementierung der Benutzeroberfläche, da hier synchron gearbeitet wurde und die verzögerte Antwort nun zu Blockaden oder bei Webanwendungen zu einem Timeout führt. Die oft gehörte Forderung nach synchroner Interaktion mit Services kollidiert in der Praxis mit der losen Kopplung und muss hinterfragt werden. Ist wirklich Synchronität gefordert oder erfüllt auch eine schnelle Asynchronität die Anforderungen? Aus unserer Erfahrung ist kaum ein Unterschied in den Antwortzeiten von synchronen oder schnellen asynchronen Serviceaufrufen zu messen, da das Netz mit seinen Latenzzeiten ohnehin den Engpass darstellt. Der Postkorbansatz Nachdem wir gesehen haben, dass beim Aufruf von Prozessen ein asynchrones Message Exchange Pattern eine wichtige Rolle spielt, wollen wir uns nun dem umgekehrten Weg zuwenden: Wie kann ein Prozess eine Rückfrage bei einem Benutzer stellen? Da der Prozess auf einem Server läuft, ist keine direkte Kommunikation vom Server zum Rechner des Benutzers möglich. Eine Kommunikation muss immer vom Benutzerrechner ausgehen. Abbildung 2 verdeutlicht die Herangehensweise, die in allen Prozess- und Workflow-Ablauf umgebungen ähnlich implementiert ist. Der Prozess ermittelt den Akteur eine Person oder Rolle und stellt eine Aufgabe in dessen Aufgabenliste ein. Anschließend wartet der Prozess, bis der Akteur die Aufgabe aus seinem Postkorb entnommen und als bearbeitet wieder zurückgelegt hat. Dabei können beliebig komplexe Daten transportiert werden. Manche Umgebungen erlauben die Einbettung kompletter Maskenbereiche zur Datenerfassung, die dann dem Benutzer einfach nur angezeigt werden müssen. Im Fall von BPEL wird über BPEL4People mit einem Workflow-Service kommuniziert, der die Verwaltung und Steuerung der Arbeitslisten übernimmt. 90 javamagazin

5 SOA aus dem wahren Leben Teil 10 SOA Center In vielen Fällen ist allein durch die Einführung dieses einfachen Postkorbansatzes bereits ein deutlicher Gewinn zu erzielen: Individuelles Prozesswissen einzelner Mitarbeiter und hartverdrahtete Anwendungen können in Form von Prozessen explizit gemacht werden. So kann die Bedienung von mehreren komplexen Anwendungen z. B. durch eine übergeordnete Prozesssteuerung stark vereinheitlicht werden. Zudem ergeben sich Monitoring-Möglichkeiten der einzelnen Prozessinstanzen, sodass die Transparenz im Unternehmen deutlich zunehmen kann. Der Postkorbansatz funktioniert hervorragend, lässt in manchen Situationen jedoch etwas Komfort vermissen. Hierzu werfen wir einen Blick auf das UI Mediator Pattern. Use Case Ein Arbeitsablauf in unserer virtuellen Autovermietung RYLC soll das Problem verdeutlichen: Ein RYLC-Agent gibt gewöhnlich während eines Telefonats Bestelldaten auf einer oder mehreren Masken ein. Am Ende der Eingaben wird ein asynchroner Hintergrundprozess gestartet, der den eigentlichen Bestellvorgang abwickelt. In der dahinter liegenden Prozesskette wird die Liste der zur Verfügung stehenden Autos ermittelt und abhängig von diversen Geschäftsregeln ein Wagen reserviert. Angenommen, das Autoreservierungssystem stellt an einem Prozessschritt fest, dass es sich um einen Kunden mit Goldstatus handelt und zum gewünschten Zeitpunkt kein passendes Auto verfügbar ist. Im bisherigen Prozess (bzw. in der Altanwendung) wurde dies sofort gemeldet. Doch seit Kurzem besteht zwischen RYLC und der Firma SOX eine Kooperation, die besagt, dass die Autovermieter bei Engpässen auf die Wagen des Partners zurückgreifen können. Die Anbindung aus RYLC-Sicht erfolgt dabei elegant aus dem eigenen BPEL-Bestellprozess heraus, mittels asynchronen Aufrufs des SOX- Reservierungsservices. Doch leider benötigt der neu eingebundene Service von Abb. 3: Einzelne Use Cases sind auf Grund der Asynchronität durch den Postkorb unterbrochen SOX noch weitere Eingabeparameter, die nur durch Rückfrage an den Kunden ermittelbar sind. Dies macht eine Systemanpassung bei RYLC notwendig. Es gibt nun zwei Lösungswege, die Das Konzept ist bei Workflow- Pattern unter dem Begriff Chained Execution bekannt. zusätzlichen Daten für den Aufruf des SOX-Services zu ermitteln: Die Anfrage wird dem Sachbearbeiter in den Postkorb gelegt. Alle Schnittstellen werden um die geforderten Felder erweitert. Die erste Lösung (Postkorb) führt zu folgendem Verhalten: Hat der Agent schon aufgelegt und bekommt über den Postkorb zeitversetzt die Anfrage, muss er den Kunden zurückrufen, was Mehraufwand bedeutet und oft zu Komplikationen mit erhöhten Stornierungsraten führt. Zudem wird der Arbeitsfluss des Sachbearbeiters unterbrochen, was bei den alten GUI-Anwendungen mit integrierter Businesslogik (der Agent konnte sofort auf die Plausibilitätsprüfung reagieren und Maßnahmen einleiten) nicht der Fall war. Die zweite Variante: Man erweitert alle Schnittstellen und schleust die zusätzlichen Parameter durch den gesamten Prozess. Dies zieht jedoch erhebliche Aufwände nach sich und wird aus Agilitätsbzw. Governance-Gründen langfristig bei einer übergreifenden Enterprise SOA zu massiven Problemen führen. Aus fachlicher Sicht wird eine SOA daher, abgesehen von der gewonnenen Agilität, von der Fachabteilung oft als ein Rückschritt empfunden. Was muss also geändert werden? Aus Sicht des menschlichen Akteurs wäre auch in einer SOA eine Art Synchronisierung der Arbeitsschritte wünschenswert, ohne aber Architekturparadigmen wie das der losen Kopplung zu verletzen. Dieses Konzept ist bei den Workflow-Pattern unter dem Begriff der Chained Execution bekannt und wurde als solches auch im ersten Entwurf der BPEL4People-Spezifikation diskutiert, jedoch auf Grund der Komplexität und einer möglichen Missinterpretation (Verwechselungs- javamagazin

6 SOA Center SOA aus dem wahren Leben Teil 10 Abb. 4: Ein UI Mediator simuliert dem Benutzer Synchronität wird eine Lösung gesucht, die folgenden Anforderungen genügt: Sie kommt ohne Doppelimplementierung der Geschäftsprozesslogik und Geschäftsregeln im Frontend aus. Sie verbindet die gewünschten Maskenflüsse in gefühlter synchroner Weise. gefahr mit dem Frontend Controller Pattern) auf Eis gelegt. Abb. 5: SHIL als Implementierung des UI Mediator Pattern Vom Erl-Pattern zum SHIL Thomas Erl formulierte den von uns ausgearbeiteten Lösungsvorschlag für dieses Problem unter dem Namen UI Mediator Pattern in seinem Buch SOA Design Patterns. Dort beschreibt das Pattern auf sehr abstrakter Ebene die Problemstellung und das Lösungsprinzip. Im Folgenden möchten wir aus Praxissicht eine Implementierungsvariante des UI Mediator Pattern vorstellen, die wir bereits in Projekten erfolgreich umgesetzt haben: den Service Human Interaction Layer (SHIL). Anforderungen: Ausgleich synchron (Mensch) und asynchron (Prozess) Zur Umsetzung des UI Mediator Patterns im SOA-Umfeld in Verbindung mit WS-BPEL und WS-BPEL4People Der zweite Aspekt steht im Mittelpunkt des Service Human Interaction Layers (SHIL): Der SHIL simuliert dem Benutzer Synchronizität, obwohl technisch eigentlich asynchron gearbeitet wird. Nicht mehr der Benutzer muss in seinem Postkorb nach neuen Aufgaben Ausschau halten, dies übernimmt der SHIL transparent. Dies wird in Abbildung 4 verdeutlicht. Damit wird die Zahl der Postkorbeinträge so weit wie möglich reduziert, wodurch der Anwender das Gefühl hat, im Rahmen einer aktuell anstehenden Aufgabe selbstbestimmt zu arbeiten und nicht in die fein gegliederten Aufgaben in einer Aufgabenliste eingepfercht zu sein. Synchron bedeutet also hier, dass der Anwender selbst auf bestimmten Benutzeroberflächen arbeiten kann und bei Anfragen an den Server, die er auslöst, sofort, also synchron, eine Antwort erhält und nicht asynchron auf eine Antwort warten muss. Wir sehen also, dass ein Mensch gerne synchron mit einem System arbeitet, während ein automatisch ablaufender Geschäftsprozess einen Menschen als nichts anderes als einen asynchronen Service auffasst: Der Prozess benötigt eine Information, und da er diese Information nicht sofort bekommen kann, stellt er die Anfrage asynchron und wartet, bis ein Mensch vor seinem Rechner sitzt und die Antwort liefert. Diesen Konflikt zwischen bevorzugten Kommunikationsmechanismen löst der SHIL auf. Lösungsdesign Zum Design der UI-Kommunikation im SOA-Umfeld über den SHIL sind zwei Flow Controller notwendig: der Mikro- Flow Controller und der Makro-Flow Controller. Der Mikro-Flow Controller ist gewöhnlich ein UI Controller, wie er in Struts, JSF oder SpringWebFlow zum 96 javamagazin

7 Einsatz kommt. Er implementiert alle anwendungsfallbezogenen Maskenflüsse und GUI-Mensch interaktionen im Frontend. Einzelne Maskenflüsse sind über definierte Flow-IDs zu starten, d. h. man hat die Vorstellung von frei fliegenden Webseiten, die von außen (Makrosicht) angestoßen werden können. Der Makro-Flow Controller ist zwischen GUI und Geschäftsprozessschicht angesiedelt und steuert die Kommunikation zwischen GUI und Prozess. Aber Achtung! Eine Maskenflusssteuerung der GUI soll hier nicht implementiert werden. Eine Makro-Flow-Sprache wie BPEL ist dafür ungeeignet, da sie zu starr ist. Der eigentliche Page Flow verbleibt in der Anwendung (Mikro-Flow). Wird in der Prozessschicht ein Anwendungsfall mit UI-Interaktion benötigt, schaltet sich der Makro-Controller ereignisgetrieben ein und teilt dem Mikro-Flow Controller mit, welcher Anwendungsfall bzw. Frontend Flow zur Ausführung kommen soll. Dazu reicht in der Regel das Mitteilen des logischen Namens des fachlichen Maskenflusses. Diese transparente Zwischenschicht bezeichnen wir als Service Human Interaction Layer (SHIL). Beim SHIL handelt es sich um einen typischen Querschnittsaspekt, der sich durch AOP (aspektorientierte Programmierung) leicht in die GUI-Interaktion einfügen lässt. Der Vorsatz der Transparenz schließt mit ein, dass die Vermittlungsschicht keinerlei Anwendungslogik enthalten darf. Die zur Korrelation benutzten Daten (z. B. die Session-ID der Benutzersession) werden im Nachrichten-Header des Payloads untergebracht. Die Flow-ID, anhand derer die GUI den nächsten Mikro-Flow auswählen und starten kann, wird fest vereinbart und von der BPEL-Schicht an den SHIL übermittelt. Die Entscheidung, welcher Mikro-Flow (Use Case) dann tatsächlich als Nächstes auszuführen ist, wird allein seitens der UI im Mikro-Flow Controller getroffen. Bei Abbruch einer Transaktion muss die Konsistenz des Prozesses gewährleistet sein. Der Benutzer muss in die Lage versetzt werden, auch wenn er die Bearbeitung der Aufgabe aussetzt, den Browser schließt oder die Verbindung auf eine andere Weise abbricht, die Bearbeitung zu jedem anderen Zeitpunkt wieder aufzunehmen. Die Nutzung des Postkorbs ist deshalb auch in diesem Lösungsszenario von elementarer Bedeutung. Der SHIL interagiert mit dem Postkorb und wird lediglich durch einen Push vom Prozess über neue eingestellte Nachrichten und die zugehörige Flow-ID benachrichtigt. Zusammenfassend lassen sich daraus die folgenden Merkmale für den SHIL ableiten (Abb. 5): Es handelt sich um eine reine Vermittlungsschicht, die den Nachrichtenfluss zwischen der UI und dem BPEL- Prozess regelt und die Techniken wie AOP und BPEL4People nutzt. Es darf keine Anwendungslogik in dieser Schicht abgelegt werden. Der SHIL ist ein Querschnittsaspekt und kann mit AOP-Mitteln transparent in die GUI-Steuerung integriert werden. Die Entscheidung, welcher Mikro- Flow als Nächstes auszuführen ist, liegt alleine bei der UI und wird dort aufgrund der Information entschieden, die vom Geschäftsprozess (BPEL) übermittelt wird. Alle Prozessnachrichten benötigen einen zusätzlichen Header, um die Flow- ID und die Korrelations-ID durch die Prozesse zum SHIL zu transportieren. Takeaways Die Automatisierung von Geschäftsprozessen erfordert meist die Beteiligung von Menschen im Prozessablauf. In den meisten Fällen reichen klassische Workflowlösungen, die Menschen über Postkorbansätze einbinden, vollkommen aus (z. B. BPEL mit Workflowservices). Über die Implementierung des UI Mediator Pattern kann eine deutliche Komfortsteigerung für den Bediener erreicht werden, da ein quasi synchrones Arbeitsverhalten simuliert wird. Die typischen Forderungen der Fachseite nach sofortigen, synchronen Rückantworten werden oft besser mit schnell antwortenden asynchronen Architekturmustern umgesetzt. Anzeige

8 SOA Center SOA aus dem wahren Leben Teil 10 Zur Fehlerbehandlung und -vorbeugung, z. B. um Abbrüchen durch Endbenutzer entgegen zu wirken, wird als Puffer der Postkorb (Workflow-Service) verwendet. Das Emulieren des synchronen Verhaltens bei kurzläufigen asynchronen Prozessen (< 10 Sec) wird auf der GUI- Seite durch den SHIL mit blockierender Wartemeldung implementiert. Abbruch und Meldung auf der UI-Seite bei länger laufenden Prozessen wird durch den SHIL geregelt. Wie fühlt sich der SHIL an? Wir haben oben gefordert, dass der Benutzer möglichst wenig über Postkörbe gesteuert wird, sondern möglichst lange in einem gefühlt synchronen Modus mit dem Server kommunizieren kann. Das folgende Szenario beschreibt, wie ein Anwender nun tatsächlich die Interaktion mit dem Prozess erlebt, nachdem der SHIL unter der Haube werkelt. Nachdem der erste Use Case komplett im UI bearbeitet ist, wird der Prozess gestartet. Hier springt der SHIL ein und stellt alle nötigen Korrelationen her (Benutzersession, Prozessinstanz-ID). Sollte der Prozess in sehr kurzer Zeit antworten (in weniger als 1 Sekunde), dann wird die Antwort vom SHIL direkt an die Benutzeroberfläche geleitet, die daraufhin die nächste Seite anzeigen kann. Dauert die Verarbeitung länger (max. 10 Sekunden), so blendet der SHIL dem Anwender einen Wartedialog ein und beendet diesen wieder mit einem Sprung auf die Ergebnisseite. Sollte ein Timeout auftreten (z. B. größer als 10 Sekunden), verwirft der SHIL den Wartedialog, entschuldigt sich beim Nutzer, dass der gewünschte Komfort über die Pseudosynchronisierung leider aktuell nicht geleistet werden kann und verweist auf eine neue Aufgabe, die dem Postkorb des Benutzers asynchron hinzugefügt wird, sobald sich der Prozess das nächste Mal meldet. Fazit Zur Integration von Prozessen und Benutzeroberflächen bietet sich der klassische Workflowansatz über Arbeitslisten an: Bestehende Oberflächen lassen Berthold Maier arbeitet als Chefarchitekt für Oracle Consulting Deutschland und hat mehr als 15 Jahre Erfahrung als Entwickler, Coach und Architekt im Bau von komplexen Enterprise-Anwendungen und Integrationsszenarien. Seit 2006 hat er die Rolle des Chefarchitekten für die gesamte deutsche Consulting-Organisation übernommen und ist in dieser Rolle verantwortlich für Referenzarchitekturen rund um Integration, JAVA EE und die hauseigenen Entwicklungsframeworks. Berthold ist bekannter Konferenzsprecher, Buch- und Artikelautor. Hajo Normann ist SOA/BPM-Architekt bei EDS. Er beschäftigt sich als Autor und Konferenzsprecher mit dem Zusammenspiel automatischer Geschäftsprozesse und SOA Services, die in die Gesamtbebauung eines Unternehmens greifen, sowie mit den architektonischen und organisatorischen Herausforderungen, die mit der Einführung einer Enterprise SOA einhergehen. Hajo ist Oracle ACE Director und leitet zusammen mit Torsten Winterberg die DOAG SIG SOA. Bernd Trops ist Leiter Consulting bei der SOPERA GmbH. In dieser Funktion ist er verantwortlich für die Kundenprojektbetreuung und die SOPERA Trainings. Als System Engineer war er in verschiedenen Projekten für GemStone, Brokat und WebGain tätig und verfügt daher über umfangreiche Erfahrungen im Bereich J2EE. Von 2003 bis 2007 war Bernd Trops als SOA Architect bei Oracle beschäftigt. Er hat bereits auf vielen Messen und Kongressen zu SOA und Open Source gesprochen. Clemens Utschig-Utschig arbeitet im SOA Suite Product Management Team der Oracle Corporation. Er ist mitverantwortlich für die Strategie und die Entwicklung Richtung neuer Standards. Im Moment arbeitet er mit dem Fusion Applications Development Team als dessen SOA-Architekt und Advisor. Er ist regelmäßiger Sprecher auf Konferenzen wie der Oracle Open World, der JAX und OOP und publiziert in englischprachigen Magazinen rund um SOA. Torsten Winterberg arbeitet als Direktor für Strategie und Innovation sowie als Leiter des Competence Centers SOA bei der OPITZ CONSULTING GmbH. Er ist bekannt als Autor von Fachartikeln und Sprecher auf diversen Konferenzen und besitzt langjährige Erfahrung als Trainer, Projekt-Coach und Architekt rund um die Erstellung von Java- EE-Anwendungen. Sein besonderes Interesse liegt im Design und der Entwicklung von komplexen IT-Systemen unter Berücksichtigung von BPM, BPEL, ESB, BAM sowie allgemein den serviceorientierten Architekturen. Links & Literatur sich einfach um die so genannten Postkörbe erweitern, die dem Menschen über Aufgabenzuweisungen einen leichten Weg bieten, in den Ablauf eines Prozesses einzugreifen. Dieser Ansatz ist zudem sehr gut geeignet, wenn rollenübergreifend gearbeitet werden kann oder soll. Technisch kommen hier proprietäre Workflowsysteme oder BPEL- und BPEL4People-basierte Lösungen zum Einsatz. Jede BPM- Software bringt heute entsprechende Funktionalitäten mit. Hat man es jedoch mit Prozessen zu tun, die in sehr kurzen Abständen immer wieder demselben Menschen es findet kein Rollenwechsel statt eine Aufgabe in den Postkorb einstellen würden, lässt sich über die Implementierung des UI Mediator Pattern eine deutliche Komfortsteigerung für den Bediener erreichen. Hier wird intern asynchron gearbeitet, dem Bediener aber ein quasi synchrones Arbeitsverhalten simuliert. Den Gewinn an Komfort erkauft man sich mit erhöhtem Implementierungsaufwand. Wichtig für eigene Projekte ist die Schaffung des Bewusstseins, dass Anwendungen für die Interaktion mit laufenden Prozessen speziell entworfen werden müssen und die typischen Forderungen der Fachseite nach sofortigen, synchronen Rückantworten oft besser mit schnell antwortenden asynchronen Architekturmustern umgesetzt werden, um die immer angestrebte Flexibilität auch erreichen zu können. [1] Erl, Thomas: SOA Design Patterns. The Prentice Hall Service Oriented Computing Series 2008 : [2] WS-HumanTask: [3] Maier, Berthold; Normann, Hajo; Trops, Bernd; Utschig-Utschig, Clemens; Winterberg Torsten: Rent your Car Service-oriented, in Java Magazin javamagazin