Das folgende Garrett IT Architektur Diagramm zeigt eine Referenz auf einen Flow, der die Schritte einer Hotelbuchung kapselt:

Transkript

1 Das folgende Garrett IT Architektur Diagramm zeigt eine Referenz auf einen Flow, der die Schritte einer Hotelbuchung kapselt: 2

2 Das folgende Diagramm zeigt den Hotelbuchung-Flow des vorherigen Diagramms mit entry und exit point: Ein Spring-erfahrener Java Entwickler oder Web Application Developer (z.b. SCWCD/OCWCD) kann also einen Flow mittels der simplen XML-basierten Flow Definition Language anlegen oder editieren, wie hier im Beispiel. Das erwähnte Beispiel findet sich hier zum Download bereit. <?xml version="1.0" encoding="utf-8"?> <flow xmlns=" xmlns:xsi=" xsi:schemalocation=" </flow> Ein Spring Web Flow kann eine View rendern ( view-state ) und besteht aus einer Folge von Zuständen ( States ), die über Zustandsübergänge ( Transitions ) miteinander verknüpft sind ( transition-on ), weshalb die Flow XML Definitionen natürlich entsprechende Elemente enthalten, wie im Beispiel hier zu sehen ist. <flow xmlns=" xmlns:xsi=" xsi:schemalocation=" <input name="hotelid" /> <on-start> <evaluate expression="bookingservice.createbooking(hotelid, currentuser.name)" result="flowscope.booking" /> </on-start> 3

3 <view-state id="enterbookingdetails"> <transition on="submit" to="reviewbooking" /> </view-state> <view-state id="reviewbooking"> <transition on="addguest" to="addguest" /> <transition on="confirm" to="bookingconfirmed" /> <transition on="revise" to="enterbookingdetails" /> <transition on="cancel" to="bookingcancelled" /> </view-state> <subflow-state id="addguest" subflow="createguest"> <transition on="guestcreated" to="reviewbooking"> <evaluate expression="booking.guests.add(currentevent.attributes.guest)" /> </transition> <transition on="creationcancelled" to="reviewbooking" /> </subflow-state> <end-state id="bookingconfirmed" > <output name="bookingid" value="booking.id"/> </end-state> <end-state id="bookingcancelled" /> </flow> Üblicherweise sind Flows mehr als nur Navigations-Logik Elemente zwischen verschiedenen zu rendernden Views, sondern müssen auch Business Logik mittels Services aufrufen oder weitere Actions bzw. deren Action Handler Methoden aufrufen. Hierfür gibt es verschiedene Unterbrechungspunkte: On flow start (on-start) On state entry On view render (on-render) On transition execution On state exit On flow end Actions werden unter Verwendung der Expression Language definiert, wie sie aus den JSF-xhtml Views bekannt ist (also die Version mit dem # anstatt dem $ wie in JSPs), die sog. Unified EL. Das wohl am häufigsten verwendete Action Element ist das <evaluate expression /> tag in den folgenden Ausprägungen: a) Evaluierung einer Expression an einem Punkt in einem Flow, um Spring Beans Methoden aufzurufen, oder andere Flow Variablen zu evaluieren: <evaluate expression="entitymanager.persist(booking)" /> b) Evaluierungs-Ergebnis eines Methodenaufrufs in der Flow DataModel Instanz flowscope speichern: <evaluate expression="bookingservice.findhotels(searchcriteria)" result="flowscope.hotels" /> c) Evaluierungs-Ergebnis umwandeln in den mittels result-type spezifizierten Typ: <evaluate expression="bookingservice.findhotels(searchcriteria)" result="flowscope.hotels" result-type="datamodel"/> Input-Attribute werden an Flows übergeben mittels <input > Element, in den folgenden Ausprägungen: a) Deklaration eines Input Attributs vom unbestimmten Typ: <input name="hotelid" /> b) Deklaration eines Input Attributs eines bestimmten Typs (hier long): <input name="hotelid" type= long /> c) Deklaration eines Input Attributs eines bestimmten Typs (hier long) und speichern im Objekt hotel des flowscope: <input name="hotelid" type= long value= flowscope.hotel.hotelid /> d) Deklaration eines Input Attributs eines bestimmten Typs (hier long) und speichern im Objekt hotel des flowscope, wobei das Input Attribut weder leer noch null sein darf (genau wie bei JSF mittels required= true Attribut): <input name="hotelid" type= long value= flowscope.hotel.hotelid required= true /> 4

4 Output-Attribute werden in Flows innerhalb von <end-state > Elementen deklariert, die spezifische Flow Endzustände bzw. Ergebnisse definieren, in den folgenden Ausprägungen: a) Deklaration eines Output Attributs, welches unter diesem Namen direkt aus dem flowscope gelesen wird: <end-state id="bookingconfirmed"> <output name="bookingid" /> </end-state> b) Deklaration eines Output Attributs, welches mittels value Expression aus dem flowscope gelesen wird: <end-state id="bookingconfirmed"> <output name="confirmationnumber" value= booking. confirmationnumber /> </end-state> Variablen Klassen sollten java.io.serializable implementieren, da ihr Zustand zwischen mehreren Flow Requests persistiert wird. Ein Flow kann eine oder mehrere Instanz Variablen deklarieren, welche allokiert werden, sobald der Flow startet. annotierte Objekt-Referenz auf nicht zu serialisierende Objekte (transient), wird wieder hergestellt, sobald der Flow beendet wird. Hier eine Beispiel-Deklaration: <var name="searchcriteria" class="com.mycompany.myapp.hotels.search.searchcriteria"/> SubFlows können von einem anderen Flow aufgerufen werden. Der aufrufende Flow wird, wie bei einem blocking call, warten, bis der SubFlow beendet wurde und abhängig von der Rückgabe des SubFlows weiterlaufen: <subflow-state id="addguest" subflow="createguest"> <transition on="guestcreated" to="reviewbooking"> <evaluate expression="booking.guests.add(currentevent.attributes.guest)" /> </transition> <transition on="creationcancelled" to="reviewbooking" /> </subflow-state> Im Beispiel ruft der sub-flow addguest wiederum den sub-flow createguest auf und wartet, bis dieser beendet wurde. Im Fall eines Ergebnisses guestcreated des sub-flows, wird der neue Gast der Liste booking.guests hinzugefügt und zwar mit Hilfe des Attributs currentevent.attributes.guest, welches den neu angelegten Gast enthält. Danach redirected der sub-flow, wie im Fall eines Abbruchs ( creationcancelled ) zur View reviewbooking. Input Attribute werden an SubFlows mittels input Element übergeben: <subflow-state id="addguest" subflow="createguest"> <input name="booking" /> <transition to="reviewbooking" /> </subflow-state> Hinweise beim Gebrauch der Expression Language (EL) mit Spring WebFlow: Im folgenden Beispiel bekommt eine view der Id error in Abhängigkeit von der im externalcontext verfügbaren Locale mittels einer template Expression den Namen einer entsprechenden Fehler-View zugewiesen: <view-state id="error" view="error-${externalcontext.locale}.xhtml" /> 5

5 Bei der Verwendung einer Standard Expression ist keine Expression Language in Form von ${ } oder #{ } erforderlich, sonst wird eine IllegalArgumentException generiert und ausgelöst: <evaluate expression="searchcriteria.nextpage()" /> Prinzipiell wird die Expression Language zu folgenden Zwecken verwendet: Um auf Daten des Web-Clients zuzugreifen: flow input Attribute, request Parameter Um auf implizite, interne Datenstrukturen zuzugreifen: flowscope, viewscope, requestscope, flashscope, conversationscope, requestparameters currentevent, currentuser, messagecontext, resourcebundle, flowrequestcontext, flowexecutioncontext, flowexecutionurl, externalcontext (wie bei JSF) Um Methoden von Spring Beans aufzurufen Um Zustandsübergangs-Kriterien aufzulösen, um sub-flow Ids aufzulösen, oder view Namen Um in Views, die von Flows gerendert werden, auf Flow Datenstrukturen zuzugreifen Um eine Variable in einem der Flow Scopes zu speichern, ist die Angabe des Flow Scopes erforderlich, um sie einfach per evaluate expression auszulesen bzw. einen Methodenaufruf zu machen, jedoch nicht, da wie bei Servlets/JSPs die Scopes bei fehlender Scope-Angabe bei Verwendung der EL einfach analog der Suchreihenfolge pagescope requestscope sessionscope applicationscope durchsucht werden. <set name="requestscope.hotelid" value="requestparameters.id" type="long" /> <evaluate expression="entitymanager.persist(booking)" /> Natürlich können Werte auch als Attribute in der sessionmap der User Session mit Hilfe des externalcontext gespeichert werden: <evaluate expression="searchservice.suggesthotels( externalcontext.sessionmap.userprofile)" result="viewscope.hotels" /> Aber was sind nun diese impliziten, internen Datenstrukturen, auf die Spring WebFlow mittels EL zugreift, einmal näher betrachtet. Sie erinnern stark an eine Mischung aus den in der Servlet bzw. JSP-Spec definierten Strukturen (z.b. pagescope, requestscope, sessionscope und applicationscope) und den JSF-Strukturen (z,b, externalcontext). Die internen Datenstrukturen von Spring WebFlow: - flowscope: - wird verwendet, um eine flow Variable zuzuweisen. - wird allokiert, wenn ein Flow beginnt und - wird mit ungültiger Referenz verfügbar für den Garbage Collector, wenn der flow endet. Wird die default Implementierung des flowscope verwendet, so ist es erforderlich, dass Objekte, welche im flowscope gespeichert werden sollen und mittels flowscope-zugriff wieder verfügbar sein sollen, das java.io.serializable Marker Interface implementieren müssen, um serialisierbar zu sein. Hier ein Beispiel, um das per hotelid gefundene Hotel-Object unter dem Attributnamen bzw. Key hotel im flowscope zu speichern: <evaluate expression="searchservice.findhotel(hotelid)" result="flowscope.hotel" /> - viewscope: - wird verwendet, um eine view Variable zuzuweisen. - wird allokiert, wenn ein view-state beginnt bzw. erreicht wird und ist nur innerhalb eines view-state verfügbar - wird mit ungültiger Referenz verfügbar für den Garbage Collector, wenn der view-state endet bzw. verlassen wird. Wird die default Implementierung des viewscope verwendet, so ist es erforderlich, dass Objekte, welche im viewscope gespeichert werden sollen und mittels viewscope-zugriff wieder verfügbar sein sollen, das java.io.serializable Marker Interface implementieren müssen, um serialisierbar zu sein. Hier ein Beispiel, um das gefundene Hotel in den viewscope zu stellen und mittels einem DataModel-Rückgabetyp zu rendern: <on-render> <evaluate expression="searchservice.findhotels(searchcriteria)" result="viewscope.hotels" result-type="datamodel" /> </on-render> 6

6 - requestscope: - wird verwendet, um eine Request Variable/ein Request Attribut zuzuweisen. - wird allokiert, wenn ein Flow aufgerufen bzw. angefragt wird und - wird mit ungültiger Referenz verfügbar für den Garbage Collector, wenn das Ergebnis des flows gerendert wird, die Response also comittet ist. Hier ein Beispiel, um die hotelid des Hotel Objects unter dem Attributnamen bzw. Key hotelid, erhältlich aus dem Request Parameter id, in den requestscope zu setzen: <set name="requestscope.hotelid" value="requestparameters.id" type="long" /> - flashscope: - wird verwendet, um eine Flash Variable zuzuweisen. - wird allokiert, wenn ein Flow aufgerufen bzw. angefragt wird und wird geleert (Löschen aller enthaltenen Objects) jedesmal nachdem eine View gerendert wurde, die Response also comittet wurde, - wird mit ungültiger Referenz verfügbar für den Garbage Collector, wenn der flow endet. Wird die default Implementierung des flashscope verwendet, so ist es erforderlich, dass Objekte, welche im flashscope gespeichert werden sollen und mittels flashscope-zugriff wieder verfügbar sein sollen, das java.io.serializable Marker Interface implementieren müssen, um serialisierbar zu sein. Hier ein Beispiel, um das Attribut namens statusmessage mit dem Wert BookingConfirmed in den flashscope zu setzen: <set name="flashscope.statusmessage" value="'booking confirmed'" /> - conversationscope: - wird verwendet, um eine Conversational Scope Variable zuzuweisen. - wird allokiert, wenn ein top-level Flow startet und - wird mit ungültiger Referenz verfügbar für den Garbage Collector, wenn das Ergebnis der top-level flows endet. - hat den Scope seines top-level Flows und kann von allen SubFlows des top-level Flows verwendet werden. Wird die default Implementierung des conversationscope verwendet, so ist es erforderlich, dass Objekte, welche im converstaionscope gespeichert werden sollen (somit also in der Http Session gespeichert werden) und mittels coversationscope-zugriff wieder verfügbar sein sollen, das java.io.serializable Marker Interface implementieren müssen, um serialisierbar zu sein und somit typischerweise bei einer Session Replikation von einer Virtual Machine zur nächsten Virtual Machine berücksichtigt zu werden. Hier ein Beispiel, um das per hotelid gefundene Hotel-Object unter dem Attributnamen bzw. Key hotel im conversationscope zu speichern: <evaluate expression="searchservice.findhotel(hotelid)" result="conversationscope.hotel" /> - requestparameters: - wird verwendet, um auf einen Client Request Parameter lesend zuzugreifen (nur Request Attribute können als Variablen in den requestscope gesetzt werden, Request Parameter dagegen nicht): Hier ein Beispiel, um die hotelid des Hotel Objects unter dem Attributnamen bzw. Key hotelid, erhältlich aus dem Request Parameter id, in den requestscope zu setzen: <set name="requestscope.hotelid" value="requestparameters.id" type="long" /> - currentevent: - wird verwendet, um auf den aktuellen Event und dessen Attribute zuzugreifen: Hier ein Beispiel, um aus den currentevent-attributen, das mit dem key guest per evaluate expression auszulesen: <evaluate expression="booking.guests.add(currentevent.attributes.guest)" /> - currentuser: - wird verwendet, um auf den eingeloggten, authentifizierten Principal User zuzugreifen: Hier ein Beispiel, um mit dem currentuser-attribut name und der hotelid auf dem bookingservice per Methodenaufruf createbooking eine Buchung anzulegen und das Ergebnis im flowscope unter dem Key booking zu speichern: <evaluate expression="bookingservice.createbooking(hotelid, currentuser.name)" result="flowscope.booking" /> 7

7 - messagecontext: - wird als Nachrichten Kontext verwendet zur Erzeugung und zum Auslesen von Flow Execution Nachrichten einschließlich Error oder Success Nachrichten: Hier ein Beispiel, um mittels call-by-reference die Ergebnis-Nachricht des Methodenaufrufs von validate auf dem bookingvalidator-object im messagecontext zu speichern: <evaluate expression="bookingvalidator.validate(booking, messagecontext)" /> - resourcebundle: - wird als Ressourcen-Zugriff verwendet, um auf definierte Erfolgs- oder Fehler-Nachrichten zuzugreifen Hier ein Beispiel, um aus dem resourcebundle eine Nachricht der ID successmessage dem Attribut namens successmessage im flowscope zuzuweisen: <set name="flashscope.successmessage" value="resourcebundle.successmessage" /> - flowrequestcontext: - wird verwendet, um auf das RequestContext API zuzugreifen, welches eine Repräsentation des aktuellen Flow Requests ist. - flowexecutioncontext: - wird verwendet, um auf das FlowExecutionContext API zuzugreifen, welches eine Repräsentation des aktuellen Flow Zustands ist. - flowexecutionurl: - wird verwendet, um auf die Context-relative URI des view-state der aktuellen Flow Ausführung zuzugreifen. - externalcontext: - wird verwendet, um auf die client environment zuzugreifen, einschließlich der User Session Attribute: Hier ein Beispiel, um das User Session Attribut userprofile für den Hotelvorschlag bei einer Hotelsuche mittels Zugriff externalcontext.sessionmap.userprofile zu verwenden und das Ergebnis des searchservice.suggesthotels(..)-aufrufs danach im viewscope-attribut hotels zu speichern: <evaluate expression="searchservice.suggesthotels(externalcontext.sessionmap.userprofile)" result="viewscope.hotels" /> Allgemein gilt beim Schreiben in einen der genannten Scopes, dass der Scope genannt werden muß, diese Angabe also erforderlich ist, beim Lesen ist dies jedoch optional, da die Scopes ansonsten in der Reihenfolge request, flash, view, flow, und conversation Scope durchsucht werden (also prinzipiell sehr ähnlich wie beim Durchsuchen der Contexte bei JSPs). Wird kein Attribut dieses Attributnamens bzw. dieses Schlüssels in einem der Scopes gefunden, so wird eine EvaluationException generiert und ausgelöst. 8