Web applicaties schrijven is een compleet andere tak van sport dan het maken van desktop applicaties. Er zijn allemaal lastige obstakels waar je rekening mee moet houden. Zo weet elke browser je html weer iets anders te interpreteren. Ook moet je elke keer de keuzen maken: vertrouw ik de client genoeg of is die server check echt nodig? En natuurlijk wordt je applicatie niet door één, maar door een heleboel mensen tegelijk gebruikt. Zou het niet handig zijn als je een applicatie kon schrijven, die vervolgens zowel op desktop en als web applicatie kan draaien zonder na te denken over de consequenties van het gekozen platform?

Dat is precies wat het Eclipse Rich Ajax Platform mogelijk maakt: een API om zowel desktop als web applicaties te schrijven. Dezelfde code wordt door Eclipse net zo makkelijk in een executable gecompileerd als dat er een war van gemaakt kan worden, die te draaien is in een willekeurige web container.

Zowel de linker als de rechter schermafbeelding tonen dezelfde applicatie. Links is de RCP variant gestart en rechts als RAP applicatie.

What’s in a name?

Het klinkt zo simpel: dezelfde API voor desktop en web applicaties. Hoe hebben ze dat voor elkaar gekregen? Als basis is gekozen voor het Rich Client Platform van Eclipse, of specifieker voor de Standard Widget Toolkit. SWT is net als Swing een framework om desktop UIs in elkaar te zetten. Relatief ongebruikelijk voor in de Java wereld is SWT’s platform afhankelijkheid. Widgets worden van het besturingssysteem geleend. Zo kan de performance van een native UI worden benaderd en is een native look & feel gewaarborgd.

Om dit te realiseren is uitgegaan van de kleinste gemene deler. Tekstvelden, knoppen of een canvas zijn op elk OS wel beschikbaar. Elementen die ook prima in de browser te renderen zijn.

RWT is een implementatie van de SWT API en is daarom transparant uitwisselbaar te gebruiken door hogere lagen.

Helaas is SWT nooit opgezet om meerdere implementaties te ondersteunen. De implementatie voor RAP genaamd de Rich Widget (of Web) Toolkit kent wel dezelfde klassen met precies dezelfde methoden; er worden geen interfaces gedeeld. Je kan dus niet zowel RWT als SWT op je classpath hebben staan; ze delen dezelfde namespace. Anders gezegt door een paar jar files te vervangen tover je een desktop applicatie om in een web applicatie of vica versa. In Eclipse kan dit heel makkelijk door een ander target platform te kiezen.

Maar….

Is er dan helemaal geen enkele aanpassing aan mijn code of configuratie mogelijk, vraag je je misschien af? En dat is terecht, want er zijn helaas een aantal kleine aanpassingen nodig inderdaad.

Ten eerste verloopt het opstarten anders. RCP applicaties worden geladen door een implementatie van de IApplication interface te laden (zie ook: Rich Clients met Eclipse RCP). Deze maakt vervolgens de workbench aan de hand van een advisor. Dat is voor web applicaties niet mogelijk, omdat deze binnen een container moeten draaien. RAP applicaties zijn te benaderen via een IEntryPoint; het equivalent van een RCP IApplication. Het mooie is dat een entry point veel eenvoudiger is dan een application, omdat de RAP servlet al het zware werk doet!

public class MyApp implements IEntryPoint {
   public int createUI() {
      return createAndRunWorkbench(createDisplay(),
                   new ApplicationWorkbenchAdvisor());
   }
}

Het tweede belangrijke verschil is terug te leiden tot het gebruik van statische variabelen om gebruiker gerelateerde data in op te slaan. In RCP applicaties worden resource bundles geladen door een subklasse van de NLS API te maken. Zodra deze klasse geladen wordt, zullen de properties uit de resource bundle aan de gelijknamige statische velden van de klassen gekoppeld worden. Dit zou in een multi-user web omgeving betekenen, dat alle bezoekers de applicatie in de taal van de eerste bezoeker voorgeschoteld krijgen!

Voor RAP is daarom een andere API ontwikkeld, die geen statische content kent. Helaas is deze niet compatible. Het is daarom te hopen dat ook RCP applicaties afstappen van de statische NLS klasse, zodat ook op dit punt een uniforme API komt.

Moet ik nu al mijn web applicaties omzetten naar RAP?

Het Rich Ajax Platform is ongetwijfeld een cool stukje techniek. Zonder grote aanpassingen wordt het mogelijk om bestaande RCP applicaties om te zetten naar het web. De gebruiker hoeft niet langer software te installeren, maar heeft genoeg aan een browser.

Er zijn ook nadelen te noemen. Hoewel de UI van een RAP applicatie zich in de browser van de gebruiker bevindt, blijft de state op de server. Elke actie van de gebruiker betekent dus communicatie met de server. Het zal daarom al snel blijken dat de latency van de verbinding bepalend is voor de gebruikers ervaring. Als je voor elke knop die je klikt, 1 seconde moet wachten is de lol er snel vanaf. Ook zal de server een groot geheugen moeten hebben om al die gebruiker sessies op te slaan.

Om die twee redenen zie ik RAP ook eerder als een techniek om intranet applicaties mee te implementeren, en minder geschikt voor web applicaties met duizenden bezoekers.

Links en lectuur

1. RAP project website met o.a. online demo applicaties.
2. IBM RAP Tutorial: Rich Ajax Platform, Part 1: An introduction.
3. Bron code van de door mij gemaakte demo applicatie.