Överraskande positiva erfarenheter från Eclipse RCP

15 September 2007 // Jan Västernäs

Vid starten av projektet jag jobbar i skulle en klient-teknologi väljas. Valet blev Eclipse Rich Client Platform http://www.eclipse.org/home/categories/rcp.php. Det innebar ganska stora skillnader jämfört med den struts-baserade HTML-klient som använts tidigare. Men det som innebar störst effekt för utvecklarna var en oväntad sidoeffekt.

Främsta skälet att välja Eclipse Rich Client Platform var att användarna ville ha möjligheter att ha MDI-stuk på sin klient med många fönster uppe samtidigt. Det är inte så enkelt att åstadkomma i en HTML-klient, skulle i så fall kräva stor instats av ett antal AJAX-ramverk eller andra produkter som antingen kändes omogna eller av andra anledningar inte var aktuella att använda.

Eftersom serversidan bygger på spring-bönor med dependency injection låg det nära till hands att använda spring remoting för att få respektive klient att kommunicera med servern. Det har fungerat väldigt smidigt, på klienten är det helt transparent hur servern anropas och klienter typar sina referenser med samma interface som bönan på servern implementerar.

Servern exekverar i Websphere 6.1 och utvecklingsmiljön är Rad 7. Att utveckla klienten med en teknologi som på ett smidigt sätt erbjuder en rik klient-applikation har givetvis varit en stor fördel men en de största effekterna av RCP-valet var ganska oväntad:

Det visade sig nämligen att vi med ganskla enkla medel kan styra via en system-property om klienten skall anropa en server remote via spring remoting och HTTP eller om klienten själv skall ladda upp hela server-sidans spring-konfiguration och anropa server-sidan bönon så att säga “in-process”. Det här snabbar upp cykeltiderna i utvecklingen oerhört.

Innan den här featuren infördes så var det följande scenario. Antag att en klientutvecklare ville ändra på en detalj i server-koden. Då var han tvungen att

• bygga om servermodulen A som innehåll ändringen
• bygga om ear-projektet ( som innehåller servermodul A som en dependant jar )
• refresha ear-projektet i RAD-en vilket leder till en
• republish på den interna Wepsphere-server i Rad-en
• starta om klienten

Efter blir det följande scenario

• bygga om servermodulen A som innehåll ändringen
• bygga om klient-projektet ( som innehåller servermodul A i ett lib )
• refresha klient-projektet i RAD-en
• starta om klienten

Skillnaden mellan dessa alternativ kan vara 1 minut i stället för 4.

Att ha servern startat hela dagen innebär också att radden slöas ner rent allmänt.

En annan situation är att man vill testa klienten (utan att ändra på serversidan) men servern är inte startat. Skillnaden i det här fallet är 10 sekunder i stället för 3 minuter. I 50 % av fallen misslyckas en start av den inbyggda servern pga bygg- eller klassladdningsproblem och man får göra om alltihop igen. Inklusive lite tid för att svära och ligga ner och banka armar och ben i golvet så är vi snabbt upp i 10 minuter.

Att man sedan slipper allt annat strul som kan inträffa då och då med den inbyggda server-miljön är en ren bonus. Däremot måste man givetvis testa mot en remote-server då och då eftersom det kan introducera ett annat beteende som man inte märker när allt testas in process.

Fundamentet för att det hela skulle fungera fanns redan, för att möjliggöra en smidig test-miljö så hade arkitektur-gruppen byggt upp en inkapsling av springsböne-laddningen. Två uppsättningar spring-config-filer finns, en för att köra inom j2ee som kopplar upp sig mot en datasource och använder applikationsserverns transaktionstjänster, en som har egen transaktionshantering och kopplar upp sig direkt mot datakällan. Den senare används för junit out-of-containertester men får numera också tjänstgöra för att möjliggöra en smidig client-utveckling.