10% av utvecklingsbudgeten kan kapas med Spring Webflow

06 October 2006 // Johan Eltes

En kollega har varit “lead developer” i ett projekt som pågått i två år. Projektet har utvecklat en komplex, verksamhetskritisk applikation för övervakning av produktionen i en bilfabrik. I syfte att dra nytta av erfarenheterna inför kommande projekt, ombads kollegan att lyfta fram områden som upplevs som särskilt kostsamma.

Efter en stunds övervägande, anges siffran 10% som svar på en ledande fråga:

• Hur mycket utvecklingstid hade projektet sparat, om det funnits en robust, generell mekanism som tar hand om funktionalitet relaterat till navigering mellan web-sidor?

10% - av all utvecklingstid!

Projektet i fråga har reducerat mycket av komplexiteten i att uppnå återanvändning och i att få en robust arkitektur för att leverera en tjänsteorienterad portfölj. När områden som modularisering, subsystemindelning, versionering, komponera nya tjänster utifrån existerande komponenter etc finns på plats, hamnar fokus på det ständiga sorgebarnet - webgränssnitt:

• Vart kommer jag när jag trycker på back-knappen?
• Hantering av sub-dialoger som användaren kan nå från olika bilder
• Vad händer om jag öppnar ett nytt browser-fönster? Kan jag fortsätta interagera med båda fönstren parallellt?

Många av oss har använt kommersiella, erkända web-applikationer, så som Confluence, Jira och diverse ehandels-siter. Påfallande ofta blir man förvånad över vilken sida man kommer till när man trycker på “cancel”-knappen i en under-dialog.

Med tio procents besparingspotential, är det väl inte mycket att orda om - inför någon av lösningarna (dvs “generell mekanism som tar hand om funktionalitet relaterat till navigering mellan web-sidor”) i nästa projekt!

Som nämnts i tidigare artikel i bloggen, kan lösningarna kategoriseras i några huvudtyper:

1. Flödes-koordinator med stöd för sub-flöden
2. Webramverk som tillför stöd för Continuations till Java via byte-kodsgenerering
3. Implementera web-dialoger med språk som har inbyggt stöd för Continuations

Kandidaterna inom vart och ett av dessa kategorier är antingen “bleeding edge”, så som Seam (2), RIFE (2) och Spring WebFlow (1), alternativt scriptspråk som innebär att man lämnar Java EE. Ruby (3) är ett exempel på det senare.

Sun’s Glad Bracha skriver i sin blog att problemen som kostat oss 10% av projektbudgeten, är övergående och att lösningar bara är “workarounds” på ett underliggande problem - man ska inte använda html/http-baserade tekniker för gränssnitt i Web-applikationer. Han menar att AJAX frammarsch är en indikation på att vi tillslut insett fakta, utan att för den skull förutsätta att AJAX blir nästa milstolpe.

Det känns som att vi sedan början av 90-talet, tvingats inleda varje projekt med frågan “med vilken teknik ska användargränssnittet utvecklas”? För applikationslogik är frågan enklare, även om beslut som dependency injection och databas-access väcks till liv då och då.

Så vad är alternativen till att se nästa projekt som ett research-projekt för AJAX, eller att stanna kvar i web/html och ta flödesstyrningsproblematiken på allvar (förresten tror jag inte de frågorna försvinner med AJAX)?

Ett alternativ är kanske att göra som SAP - de har ju trots allt överlevt ett antal teknikskiften, genom att hålla sig till sina egna ramverk, språk och middleware. Man kan tycka vad man vill om användarvänligheten i SAP, men tack vare “minsta gemensamma nämnare”-syn på användargränssnintt har SAP AG tagit sin produkt genom åtskilliga teknikskiften. SAP m.fl. leverantörer av standardsystem har uppfunnit ett hög-nivå-format för att beskriva användar-dialoger. De möter sedan nya teknologier genom att lägga till “plug-ins” som översätter hög-nivå-formatet till respektive plattform.Det innebär förstås att man underutnyttjar grafiska möjligheter i de flesta plattformarna.

Å andra sidan - har någon mätt alternativ-kostnaden i form av kompromissernas konsekvenser för effektiviteten i organisationen?

I vart fall finns ett starkt business case för att lyfta frågan!