Web-dialoger som komponenter

06 October 2006 // Johan Eltes

SOA i allmänhet och SCA i synnerhet ger oss en kraftfull modell för återanvändning av funktionalitet när vi skapar tjänstelagret i en ny applikation. Men många gånger sitter det ett ännu större värde i att kunna återanvända web-gränssnitt som är skapade mha existerande tjänster. Det verkar inte finnas någon tydlig best-practice för att att skapa återanvändbara web-dialoger inom ramen för Java EE.

Det var ju så enkelt förr…

Sök-funktioner har ofta stort återanvändingsvärde. I operativa system spelar systematisk uppbyggnad av sökfunktioner för olika klasser av information ofta en central roll. I den “gamla” världen av klient/server och main-frame-dialoger, finns tydliga best-practice för hur en registreringsapplikation kan återanvända / integrera en existerande sökbild i registreringsfunktionen. Dialogerna anropas som under-dialoger (ofta modala) som låter användaren söka fram ett objekt som ska länkas till huvudbildens fokus-objekt. Det kan till exempel gälla att integrera en dialog för kundsökning i en orderhanteringsapplikation.

Varför blev det krångligt i web-åldern?

Den klassiska ansatsen kan med möda reproduceras i rika klienter, t.ex. mha Java-script. Men vilka möjligheter står tillbuds inom ramen för html-baserade web-applikationer utan pop-up-fönster och annan klient-baserad integration?

Några olika aspekter som behöver adresseras är..

1. Binda in ett existerande web-flöde som under-flöde i en ny web-applikation
2. Få underflödet att kunna “avsluta” genom att återkoppla till den nya applikationen, som ju inte fanns när underflödet utvecklades (dvs kund-sök-flödet).
3. Paketera allt som underflödet behöver på ett sätt att det kan integreras i “run-time”, som en komponent, men ändå kunna användas i den ursprungliga web-applikationen (t.ex. registervårdsapplikationen för kunder).

Vad kan man göra med existerande ramverk?

Spring Webflow löser på ett kraftfullt sätt upp frågeställningarna i punkt 1 + 2 ovan. Återanvändbara flöden kan paketeras i jar-filer för komponent-baserad återanvändning i olika web-appar. jar-filen innehåller flödesdefinitionen, ev. Strus-konfig-filer, action-klasser m.m. Utmärkt! Men tyvärr räcker inte detta, om vi använder Java EE-standarden för generering av html-koden. Java Server Pages (JSP) - inte ens om vi gör det via Java Server Faces (JSF). Java EE-standarden stödjer inte laddning av JSP-filer från jar filer (via klassladdaren). JSP-filerna för kund-sök-dialogen måste finnas i WEB-INF-katalogen i varje applikation som ska återanvända den.

Portlets är en teknik som det är lätt att associera till i detta sammanhang. Portlets fyller dock ett annat syfte - att leva sida-vid-sida med andra funktioner inom ramen för en portal-sida. Det är en integration som tjänar andra syften än att återanvända dialoger som komponenter i andra dialoger.

JSP passar inte för komponent-baserad utveckling

Så vad kan man göra åt JSP-filerna? Man kan förstås använda något annat än JSP. Om vi använder Velocity (t.ex. tillsammans med Tapestry), XSLT eller annan teknik som inte är kopplad till WEB-INF-katalogen är vi hemma.

Om företagets policy styr mot Java EE-standarden (dvs JSP), skulle man kunna tänka sig att ta hjälp av bygg-systemet. Man skulle då kunna automatisera “transplantationen” av JSP-filer från en återanvändbar Web-komponent (WAR) till WEB-INF-katalogen i “återanvändaren”, dvs order-registreringsappen. Maven är ett byggsystem som stödjer komponent-baserad utveckling, genom dess koncept för beroende-hantering och integrerade enterprise-arkiv av versionerade komponenter.

Genom att anpassa WAR-hanteringen i Maven, skulle man kunna lägga till stöd för att deklarera ett beroende som “reuse”. Maven skulle då kunna leta i den återanvända WAR-filens WEB-INF efter JSP-filer som kopieras in i återanvändarens WAR. För att undvika kaos, behöver man standardisera en katalogstruktur inom WAR-filerna - som en form av name-space för att undvika krock mellan namn på JSP-filer. Det är mao något som är svårt att inför i efterhand, men skulle förmodligen kunna vara en framkomlig väg om standarden etablerats inför t.ex. ett större projekt.

Spring Webflow behövs förstås ändå! Kanske kan Struts Shale vara ett alternativ, men Spring Webflow verkar vara som klippt och skuret för en ansats som denna.