vrijdag 26 juni 2009

Frontcontrollers


Tijdens het volgen van een SCWCD (Sun Certified Web Component Developer) training kom je de coolste dingen tegen om een webapplicatie te ontwerpen en implementeren. Er wordt voortdurend op gehamerd dat je elk component in een webapplicatie (POJO, EJB, Servlet, JSP e.d.) moet gebruiken waar het voor dient, en ze niet misbruikt door bijvoorbeeld logica in een JSP te gaan stoppen omdat dat ook wel werkt. Neen! Men doet er verstandig aan de verschillende lagen van een applicatie te scheiden, het voornaamste voorbeeld hiervan is het MVC (Model-View-Controller) model. De details hiervan laat ik even achterwegen (Wikipedia is your friend) maar kort gezegd krijg je door dit model te implementeren een applicatie waarin de bussiness logic, het ophalen van data uit de bussiness logic en het tonen daarvan van elkaar gescheiden zijn.

Bovenstaande kan gerealiseerd worden door in bijvoorbeeld een servlet de bussiness logic (via EJB o.i.d.) aan te spreken en het resultaat te delegeren naar JSP's die gevuld worden met deze data. Echter is dit model op deze manier ook niet perfect. In een website met omvangrijke grootte kan het schrijven van dergelijke code redundant en onoverzichtelijk worden. Je voelt het misschien al aankomen, maar inderdaad, ze hebben ook hier iets op gevonden. Een techniek (eigenlijk een design-pattern) met een vrij algemene naam "frontcontroller". Frontcontrollers zijn kleine frameworkjes die je kunt gebruiken om de code die je in je controllerlaag gebruikt om de bussiness logic aan te spreken evenals de code die je gebruikt om de view-laag aan te spreken in herbruikbare objecten te stoppen. Op die manier hoef je code om requests af te handelen niet steeds opnieuw te schrijven voor elke servlet die je in je applicatie gebruikt. Dit leidt al gauw tot meer overzicht in de code die makkelijker onderhoudbaar is. Een belangrijke kenmerk van een frontcontroller is dat het een centraal punt vormt in een applicatie voor het ontvangen van requests en het delegeren daarvan.

Een keerpunt van een dergelijke techniek is dat je al je logica zult moeten implementeren in de frontcontroller, wat tot heel wat configuratie en omslachtigheid kan leiden. Bijvoorbeeld het delegeren van een bepaald request naar een bepaalde servlet kun je dan niet even snel met een RequestDispatcher doen, maar je zult een object moeten schrijven dat de configuratie en logica voor die delegatie bevat. Op die manier is het gebruik van een frontcontroller aan de ene kant een zegen en aan de andere kant een vloek. Zoals een bekende voetballer ooit zei (ja, Kruijff): elk noadeel heb een foordeel!

Een bekende Java implementatie van een frontcontroller is Jakarta Struts, wat niet bij iedereen geliefd is. Dit geldt echter ook voor Spring, wat minder bekend is maar ook gebruikt wordt in de webwereld om je controller en view netjes neer te zetten. Spring heeft echter ook roots in de modellaag, eigenlijk een frontcontroller++ :P. Beide technieken implementeren het frontcontroller pattern op hun eigen manier, en je wilt ermee werken of niet. Mij persoonlijk lijkt het gebruik van Struts wel interessant, en misschien zelfs wel nuttig. Echter denk ik niet dat je het moet gebruiken in websites van kleine omvang omdat je dan waarschijnlijk niet het potentieel eruit haalt.

vrijdag 19 juni 2009

Open Source


Open source wordt vaak gezien als iets dat te maken heeft met software. Zo kennen we veel handige open source tools in het land van Java. Voorbeelden hiervan zijn onder andere Hibernate als ORM laag tussen databases en de eigen Java applicatie en Wicket een web framework voor java.

Maar er zijn ook nog andere vormen van open source. Zo is er bijvoorbeeld de "open game license", ontworpen voor role playing games. Deze licentie is in 2000 ontworpen door Wizards of the Coast voor het 'd20 systeem'. Helaas is er ook kritiek op de licentie, onder andere door de controle die Wizards of the Coast er over heeft, aangezien deze een aantal uitgevers de kop gekost heeft.

Nog een interessant open source product is de openmoko. Dit is een open source smartphone waar alle aspecten van de telefoon open zijn gehouden (met uitzondering van een aantal chips, voor zover ik weet), dus niet alleen de software. Je kunt de schemas van de electronica en de CAD files gewoon downloaden op de website. Wel moet er gezegd worden dat het nog een "work in progress" is. De software om alle hardware aan te sturen is nog niet af. Zelfs de hardware heeft nog bugs, maar dat is op te lossen voor mensen die niet al te bang zijn en durven te solderen in hun telefoon. Gelukkig is de tweede versie van de telefoon (GTA02 Freerunner) al een stuk beter als de eerste. De volgende blog post zal de openmoko verder uitdiepen.

Meer Taart voor ISAAC


Een van de ISAAC teams werd vandaag blij verrast met taart. Laser Nederland, Een van ISAACs partners, heeft vandaag taart laten bezorgen als dank voor de extra inzet rondom nieuwe release.

Wij zijn natuurlijk erg blij dat onze inzet wordt gewaardeerd. Dus Laser Nederland bedankt!

vrijdag 12 juni 2009

Van ontwikkelomgeving naar test- en productieomgeving

Een van de dingen waar een applicatieontwikkelaar mee te maken krijgt, is het configureren van de software voor verschillende omgevingen. De applicatie wordt ontwikkeld op een ontwikkelomgeving, gaat daarna in het algemeen naar een omgeving waar de klant een en ander kan bekijken en testen, en wordt vervolgens op een productieomgeving geplaatst, al dan niet na een aantal aanpassingen. Deze omgevingen hebben hun eigen instellingen nodig. Bij het uitrollen van een nieuwe versie van de applicatie naar een omgeving moet de omgeving de juiste instellingen krijgen en/of houden. Er zijn veel manieren om dit mogelijk te maken, een van de eenvoudigste is via files in verschillende bestandsformaten. Er worden dan verschillende files gemaakt met per omgeving de specifieke configuratie. Vaak is er een file met standaard instellingen, die overschreven kan worden om specifieke eigenschappen aan te passen. Deze files moeten op een goede manier worden beheerd en uitgerold. Er zijn veel verschillende frameworks en tools om dit te realiseren. Een ervan is de Commons Configuration van het Apache Commons project, te vinden op de Apache website. Hiermee kan configuratie worden ingelezen vanuit bijvoorbeeld properties files, XML files, Windows INI files, System properties, etc. Eigenschappen kunnen meerdere waardes hebben indien gewenst, en zijn bovendien van een bepaald type. De toegang tot de eigenschappen verloopt via de generieke Configuration interface.
ISAAC heeft inmiddels in verschillende projecten naar tevredenheid gebruik gemaakt van de XMLConfiguration van Apache Commons. Handmatige aanpassingen na het uitrollen van een applicatie zijn voor deze projecten niet meer nodig.