Het eerste ISAAC tennistoernooi

Wie denkt dat ISAACi niet sportief zijn die heeft het mis. Afgelopen vrijdag was namelijk het eerste ISAAC tennistoernooi, en er waren maar liefs 12 deelnemers! Dit vond allemaal plaats op onze indoor tennisbaan, gelegen in de Wii-hoek. Hier volgt het verslag:

Het was een koele vrijdagmiddag in Eindhoven, toen de 12 deelnemers aan het eerste ISAAC tennis-toernooi zich mentaal voorbereidden op de veldslag die plaats zou gaan vinden. Het begon allemaal in de keuken onder het genot van een hapje en een drankje, maar al gouw kwam er gekreun en gescheld uit de Wii-hoek.

Merijn was de eerste die het onderspit delfde tegen niet-ontslagen Lars, waarna Xander al snel volgde door van Nick te verliezen. Jasper was veel te sterk voor JW, Edwin verbaasde vriend en vijand door van Rob te winnen, Bart had geluk en versloeg Koen, en Ronald versloeg langharige Rob in 3 games.

De tweede ronde bevatte minder verrassingen: Nick versloeg niet-ontslagen Lars in een zenuwslopende wedstrijd, die zelfs een Matchpoint voor niet-ontslagen Lars bevatte. Het was stil bij ISAAC toen Nick de genadeklap toebracht in de derde game... Jasper versloeg Edwin redelijk eenvoudig (Edwin was gehandicapt!) en Bart (in het roze!) versloeg Ronald.

De finalepoule ging tussen de titanen Nick, Bart en Jasper. Nick versloeg in de eerste wedstrijd Jasper in 2 games, maar daarna versloeg Bart Nick in 3 games... het ging dus allemaal om de laatste wedstrijd tussen Jasper en Bart. Als Bart zou winnen was hij de winnaar, maar als Jasper zou winnen dan zou er extra moeten worden gespeeld...

Maar Jasper was meer van de praatjes en verloor in 2 games, waardoor Bart onze eerste Wiisaac tennis-kampioen is! Gefeliciteerd Bart, en hulde!

Walt Disney World: twee toffe web-related systemen

Het zal voor een aantal van de lezers van dit blog geen geheim zijn dat ondergetekende nogal een themaparken-fan is, en dan van de Efteling en Disney in het bijzonder. Afgelopen anderhalve week was het dan ook weer tijd voor mijn inmiddels bijna jaarlijkse bezoek aan Walt Disney World, Florida. WDW (alle freaks zijn te lui om Walt Disney World steeds voluit te schrijven) is ’s werelds meest bezochte toeristische bestemming, meet ruim 100 vierkante kilometer en heeft daarop vier (!!!) Disneyparken, 22 resorts (met elk 2500+ kamers), 62.000 medewerkers, mijlen monorailverbindingen en nog een lading golfbanen, meren, waterparken en wat je al niet meer zou kunnen verzinnen. In totaal komen er meer dan 50 miljoen bezoekers per jaar op af.

Nu is dit natuurlijk het blog van een IT-bedrijf, en niet een timeshare-promopraatje van Disney (hoewel ik dat ook wel naar tevredenheid zou kunnen houden). Daarom wil ik het hier eens hebben over twee relatief nieuwe web-related WDW IT-systemen die ik de afgelopen vakantie heb kunnen gebruiken, en die, zeker gezien hun buitengewone schaalgrote, interessant zijn. Je bent immers niet voor niks IT’er; dan blijf je zoeken naar de techniek achter de grote grijzende Mickey Mouse-facades. De twee systemen die we gaan bekijken zijn “Disney’s PhotoPass” en “Postcard From The Future”. Laten we met die laatste (en qua schaal kleinste) beginnen.

Postcard From The Future
Postcard From The Future is een systeem dat sinds een jaar draait in Epcot, het futuristische toekomst- en culturenpark van Disney. Hét bekendste symbool van Epcot is de geodesische bol (naar een ontwerp van Buckminster Fuller) van 55 meter hoog, waarin de attractie Spaceship Earth is te vinden. Met een Carnaval-Festival achtig transportsysteem rij je in die bol in zo’n vijftien minuten langs scenes die de geschiedenis van de communicatie verbeelden; van prehistorische rotsschilderingen en de uitvinding van het schrift tot de eerste computers en de knutselgarage van Apple CEO Steve Jobs’s ouders aan toe. In 2007 is de sponsoring van deze uit 1982 stammende attractie overgenomen door Siemens, waardoor Disney een update van veertig miljoen dollar kon laten uitvoeren.

Alle honderden wagentjes van het systeem zijn vanaf nu voorzien van een touchscreen, wat vlak na het instappen in Spaceship Earth ook de eerste confrontatie met het “Postcard From The Future”-systeem is. Tijdens de eerste donkere tunnel van de attractie (je moet immers die 55-meter hoge bol in), kies je op dat touchscreen (formaat multimediazuil) één van de zes ondersteunde talen, en je geeft middels een fraai zoombare wereldkaart aan waar je vandaan komt. De taalkeuze heeft meteen ook effect op de in de wagentjes ingebouwde voice-over van de attractie; erg slim gedaan!

Tegen het einde van de donkere tunnel, vlak voor de eerste scène over grotschilderingen, moet je nog even naar een beeldscherm boven de wagentjes kijken; een flits en hop, een foto is gemaakt. Met die foto gaat “Postcard From The Future” aan de slag, zoals later zal blijken.

Tijdens de rit zelf zie je het systeem verder niet terug, tot het punt waar je, na de scènes met de garage van Steve Jobs en een Matrix-achtige sourcde-code projectie, begint aan de tocht terug naar beneden uit de bovenste delen van de hoge Spaceship Earth-bol. In de lange en donkere “descent tunnel” (waarin je relaxed half achterover in je wagentje ligt), floepen de touchcreens weer aan, en krijg je een aantal vragen over je ideale toekomst. Hou je meer van werk of vrije tijd? Van private transport of public transport, etc etc. Halverwege de tunnel krijg je op basis van de gemaakte keuzes op je individuele touchscreen een hele toffe en knap gerenderde animatie te zien op basis van je keuzes. Het meest bijzondere hieraan is wel, dat de hoofdjes van de animatifuguren zijn vervangen door de uitgesneden gezichten van jezelf en je medepassagier in het wagentje! De eerder gemaakte foto is dus door een stukje gezichtsherkenninssoftware gehaald, waarbij de gezichten netjes losgesneden zijn van de achtergrond. Daarmee is vervolgens een (waarschijnlijk) Flash-achtige animatie gerenderd. Het ziet er een beetje South-Park achtig uit natuurlijk, doordat er maar één standpunt beschikbaar is voor in de animatie, maar dat geeft het ook wel weer een leuke look.

Wanneer je uit de wagentjes stapt, kom je in de futuristische (veel neon en brushed steel) post-show ruimte terecht waar Siemens wat reclame maakt. Middenin staat een enorme verlichte wereldbol (meter of zes hoog), waarop in de oceanen de foto’s tevoorschijn komen van hen die net uit de attractie stappen. Hierop zie je dus ook wel jezelf, en met een boogje vliegt je foto dan naar de plaats waar je vandaan komt (die had je immers eerder ook opgegeven in de wagentjes). Op die plek blijft ook een klein wit stipje achter. Ik denk dat de wereldbol zich ’s ochtends reset, want er stonden pas een stuk of wat stipjes op noordwest Europa.

Rondom de wereldbol zijn zo’n tien fraai vormgegeven “zuilen” te vinden, met daarop een applicatie waarmee je een kaartje “vanuit de toekomst” (oftewel Epcot) naar huis kunt sturen. Wanneer je voor zo’n zuil gaat staan, zoekt het systeem met behulp van een camera en gezichtherkenning weer naar de juiste foto die in de rit gemaakt is. Dit werkt voor zo’n 90% vlekkeloos. De overige 10% moet even bladeren in een index. Met de applicatie op de zuil kun je het door “Postcard From The Future” gemaakte filmpje sturen naar een paar e-mail adressen naar keuze. Deze ontvangen een link naar de flash-animatie online. Zodra je je kaart verzonden hebt, komt een ansichtkaart-achtig frame uit die animatie ook weer op één van de grote projectieschermen in de post-show ruimte te staan. Deze wisselen dus naarmate bezoekers “Postcards From The Future” verzenden. Fancy!

Al met al een behoorlijk groot systeem; elk wagentje (ik schat dat er zo’n 250 zijn) heeft twee eigen touchscreens, en een individueel lokaal verwerkingssysteem. Vervolgens is er software (op servers neem ik aan) die de animaties rendert en de gezichtsherkenning uitvoert. We hebben de wereldbol met de locatieweergave. En dan zijn er ook nog de e-mail consoles (met overigens een hele mooie Flash-interface vol in en uitschuivende panelen en een on-screen keboard voor de e-mail input), die de animaties klaarzetten op een webserver. En dat voor 2500 bezoekers per uur!

Disney’s Photopass
Het tweede systeem waarvan ik onder de indruk was is “Disney’s Photopass”. In tegenstelling tot “Postcard From The Future” is dit niet beperkt tot één attractie, maar is het in alle parken van Walt Disney World in Florida en Disneyland in California actief (als één globaal systeem).

PhotoPass heeft als belangrijkste doel het opslaan, samenvoegen en online beschikbaar maken van de tientallen foto’s die Disney tijdens een bezoek aan het resort van je groep (party) of familie kan maken. In alle parken van WDW zijn Disney-fotograven te vinden die je op de foto kunnen zetten met het Disney-kasteel, een Disney-figuur (de zogenaamde “characters”, om even in Disney-jargon te blijven), een fraai stukje Disney-natuur of whatever-else Disney. Natuurlijk kun je al die foto’s ook gewoon door een aardige medebezoeker laten maken, maar dat is niet hoe Disney z’n dollars wil verdienen, en —gelukkig voor Mickey’s wallet— ook niet wat de meeste Amerikanen doen.

In totaal lopen er zeker op honderd plaatsen in de parken fotograven rond. Wanneer je voor het eerst op de foto gaat bij één van hen krijg je een plastic pasje van het PhotoPass systeem, met daarop een 16-digit (unieke) code (alfanumeriek) en een 2-dimensionale barcode. De PhotoPass-fotograaf scant die barcode met een klein extra dingetje aan zijn camera, waardoor de foto een unieke link krijgt met je PhotoPass ID. Om de paar minuten lopen ze even “backstage”, om daar hun memory card te legen op het Disney PhotoPass-netwerk, waardoor de (high res) foto’s altijd snel in het systeem beschikbaar zijn. Natuurlijk gebruiken Mickey, Pluto, Goofy en Peter Pan die tijd ook om (zonder hun warme pak) even bij te komen onder de airco. Bij een volgende fotograaf geef je gewoon weer even je PhotoPass, deze scant de barcode, et voila: weer een foto in je virtuele PhotoPass-album.

Een geavanceerder stukje van het PhotoPass-systeem zie je bij de zogenaamde “on ride”-foto’s. Dat zijn foto’s die tijdens een rit in een attractie door een automatische camera worden gemaakt, bijvoorbeeld in een achtbaan of waterattracties. We kennen ze hier in Nederland wel van de Python of het Carnaval Festival in de Efteling. Bij de Efteling staan bij de uitgang van de attractie wat monitoren waarop je de gemaakte foto kunt zien, en die bij een bemande balie ook meteen kunt laten afdrukken. In WDW hangen die monitoren er ook, maar eronder is een mooi PhotoPass barcode-scannertje geplaatst. Als je de tijdens de rit gemaakte foto tof vindt, scan je gewoon even je PhotoPass, en ook deze foto staat voortaan in je album.

Op verschillende plaatsen in het resort (en ook in de lobby van elk hotel) zijn PhotoPass Access Points te vinden, waar je door je pasje te scannen al je foto’s kunt bekijken, en, indien gewenst, meteen kunt laten afdrukken. Het staat daar natuurlijk vol met medewerkers die om het hardst roepen hoe tof en bijzonder je foto’s wel niet zijn, zodat je maximaal gaat investeren in prints. Deze PhotoPass Points kunnen ook de foto’s van meedere PhotoPasses combineren tot één album (twee pasjes scannen en klaar), of er wat eenvoudige bewerkingen op doen (leuk randje om de foto, jaartal erbij, handtekening van een Disney-figuur uit de database erop, etc etc). Allemaal via een toffe Flash-achtige user interface.

Natuurlijk kun je je PhotoPass-album ook online bekijken. Op een speciale website kun je inloggen met je PhotoPass ID, waarna alle foto’s mooi op park en datum gesorteerd inzichtelijk te maken zijn. Wil je je foto’s aan anderen laten zien? Geen probleem: er is een “Share With Friends” optie, waarmee je het album ook voor vrienden inzichtelijk kunt maken via een ge-emailde link. Natuurlijk heeft Disney daarvoor wel weer een naam en e-mail nodig, waardoor hun spam-emaillijst groeit als kool.

Als Disney eenmaal weet welk e-mail adres bij een PhotoPass ID hoort, gebruiken ze dat ook volop om je te blijven herinneren aan die toffe foto’s die je nog in je album hebt staan, en die schreeuwen om een print. Online even aanvinken welke je hebben wilt, de foto’s weer bewerken met wat fraaie edit-tools (allemaal in-browser), en je krijgt ze de zelfde week nog thuis gezonden. Als canvasschilderij, als sleutelhanger of als horloge-achtergrond wellicht? Ook geen probleem. Je krijgt alleen nooit zomaar toegang tot de high-res bronbestanden van de foto’s. Die houdt Disney —heel slim— zelf. Tenzij je de hele boel op een Kodak PhotoCD thuis laat sturen, maar dat kost je meer dan 100 dollar.

Als software-ontwikkelaar ben ik vooral erg onder de indruk van de omvang van het systeem. Honderden high-res foto’s per minuut moet dat systeem verwerken, die allemaal minimaal een maand behouden blijven op de Disney-servers. Ook de bewerkingsopties op de website zijn heel erg handig, snel en mooi ontwikkeld. Commercieel is het natuurlijk weer een typische Disney meesterzet. Je hoeft immers niet meer steeds snel in een park te beslissen of je een foto hebben wilt of niet, maar kunt dat rustig thuis —met de hotel en entreerekening al weer vergeten— doen. En dat is de money-making magic van Disney.

g Cr

Incase you don't know what the above means, it's simple, first of all is the symbol for Googol (or was it Googolplex? I always mix them up), and the second for Chromium. Combing them together with some missspelling results in something now known as Google Chrome.

This is a new browser, by Google, that is ought to take away the "pain" in webbrowsing. While I can't say everything about it, having used it for a mere 30 minutes, I can tell you my first impressions of this "beast".

But first of all, let us explain why I am not writing this in Dutch, even tough it's my native language. 1. It's late. 2. I'm lazy. 3. Context Language "switching" is expensive for me. And I may do a Dutch translation if there is enough demand. A later post may include a Dutch translation by default.

Anyway, back to Google Chrome! Before anyone can complain, these are my, and my alone, first impressions. So don't bother complaining. You know who I'm refering to. ;-)

1. For a supposedly new and innovative browser, it looks and feels remarkably like Opera, I haven't yet found a feature that isn't in Opera. With the possible exception of the multiple processes (see later) and the App mode. But the latter is a counterpart to Opera's Widget system. I suppos OmniWeb will feel similar as well, for Mac users (from what I've heard). Look and Feel also looks a lot like Opera.
2. It's, for now, XP/Vista only.
3. Installation was painless, just run the exe you download and say if you want to place a shortcut on the desktop/quicklaunch and if you want to import from IE or FireFox (strangely enough not Opera nor Safari), which you can't cancle after you accidently make a mistake (so I started with the RunMeFirst of IE as my homepage). One thing to note, it will plant itself into the the Local AppData of the running User (in Vista), no way to define something else. In XP this will be a similar place (ApplicationData for example).
4. The only "innovative" feature I could find was the 1 process per tab idea. I currently have eight tabs open, with a total of ten chrome processes. So one master monitoring process, one for the actual browser "chrome" (to use a FireFox term, it's the GUI around the actual web content), which, if the rumors are right is also a webpage. And one for each tab. So I guess the actual browser window is a webpage. Thread-wise the master process currently uses 27 threads, maybe a bit excessive, not sure. Each browser window 5 threads and roughly half the memory, even less for workingset memory. Each tab process has 2 threads. I think one for the JavaScript, and one for the, required, Windows Message Pump (it's a Win32 API thing). Or maybe for the rendering, if that's done my the tab process itself. Memory-wise it's similar to a window process, basicly confirming (yeah, not very scientific, I know) that a window is a webpage.
5. Scroll is too fast.
6. The Mozilla Prism/Adobe Air/MS Silverlight/Opera Widget part consists of placing a shortcut in either QuickLaunch or the Desktop telling the Chrome application to start with an url, the exact url from where you chose to create an app out of a webpage. Apps open in a new window. But share the infrastructure of the other Chrome apps (which means it will launch the master Chrome app if it's not yet present). If you open a page/tab in the new App window it will open a new tab in the last used window, that is not an App window. It also means it will start 2 new processes under the Chrome master process, which makes sense because a window is a webpage and the actual app is also a webpage.
7. It does not yet pass the Acid3 test (63%), even tough the nighlies of WebKit (which is the render engine used in Safari and most of the webbrowser-like applications found on the Mac, and on other platforms) already do for some time, and I believe the latest beta of Safari does this as well. Acid2 test also isn't yet pixel perfect (like it is on Opera ^_^), just like Safari. So I think they are currently using the WebKit (or a near) version to the one used in the latest stable Safari release.

That's it for now!
I'll might do a more indepth (and comparison with other browsers) article in the future.

--Maarten

PS.

Written from within g Cr!

PPS.

Next morning now, and I think I forgot to mention something last night. I put quotes around the word "innovative" in point 4, why did I imply sarcasm there? Well, a little language has been known to casually support tens of thousands of processes at the same time. What is the difference? Well, those processes are lightweight and use the shared nothing approach to concurrency. In fact, most processes/threads in Erlang are so called "green threads" or "fibers". In Chrome, they are spinning up real, heavy, processes. One for each tab.

But I have to admit, it is very Google in mentality (the spinning up of processes), Google's famous "MapReduce" is infact implemented to spinning up processes that do part of the job, actually they spin up entire machines for this!

Hug a developer today...

Star Trekavond en Pizzarecord

Na de drukte rond de verhuizing (met saaie zaken als tafels en bureaustoelen plaatsen), zijn we langzaamaan eindelijk weer toe aan het komen aan de essentiële zaken van het ISAAC-bestaan. Eén daarvan is het houden van de inmiddels "Befaamde Ende Traditionele" Star Trekavonden.

De benodigde beamer en het projectiescherm zijn vorige week al opgehangen in de Wii en Star Trekhoek, en hoewel we het nog zonder Dolby 5.1 geluid moeten doen, konden we gisteravond wel voor het eerst in het nieuwe kantoor genieten van Deep Space 9 en The Next Generation. Kortom: ISAAC Star Trekavond nummer II!

Tijdens de vorige Star Trekavond kregen we het voor elkaar om een New York Pizzabestelling te hebben van meer dan 80 euro, maar die paste nog wel nèt in één scooterbox van de bezorgpuber (met wat nadelige pleteffecten als gevolg). Dat moest natuurlijk dit keer overtroffen worden! Met wat zachte dwang besloot iedereen dit keer dan ook om rijkelijk side-dishes te bestellen; met daarbij ook een groter aantal Star Trekkijkers, kwamen we uit op een totaalbestelling van 126 euro! Daarmee was ook het expliciete doel van deze bestelling bereikt, namelijk om niet één, maar twee bezorgpubers-op-scooter tegelijk onze bestelling te laten bezorgen! Whoahahaa! Volgens mij moeten we intussen toch wel een key-account zijn bij NYP.

Op het programma stonden wat fijne Dominion en Cardassian afleveringen van Deep Space 9, met daarna de klassieke dubbelaflevering Decent uit The Next Generation. Dat is die episode waarin prof. Steven Hawking zelf ook nog even een cameo rolletje heeft.

Enfin, het was natuurlijk weer een groots succes, maar de doelstelling voor de volgende keer is een pittige. Want hoeveel pizza's moeten we wel niet bestellen om (in goede IT-traditie), van 2 naar 4 bezorgpubers te komen bij Star Trek Night III?

Live long and prosper!

Het is me in de (aard)bol geslagen

“In mathematics, you don't understand things, you get used to them.” von Neumann

En met dat in gedachte zal ik toch proberen om een verhelderend stuk te schrijven over dit favoriete vak van menig programmeur. Waar heb ik dat aan te danken, hoor ik je denken en ergens heb je gelijk. Waarom zou ik je lastig vallen met een onderwerp waar je vroeger al slecht in was en wat je sinds het behalen van je diploma waarschijnlijk achteraan in je hersenen hebt geduwd (nog achter die genante herinneringen van toen je veertien was en je je geluk waagde bij het mooiste meisje van de klas). Hiervoor verwijs ik je naar Google in Mountain View, Californië. Die bedachten enkele jaren geleden dat het grappig zou zijn om een virtuele aarde te maken met aaneengeregen foto’s. Google Earth is in een korte tijd uitgegroeid tot een begrip en steeds vaker word je geconfronteerd met opdrachten waarbij locatiegegevens en kaarten een rol spelen. Het is een kwestie van tijd voordat je oog in oog komt te staan met de opgave om de afstand tussen twee coördinaten te berekenen en erachter komt dat deze coördinaten (uitgedrukt in lengtegraden en breedtegraden) niet altijd even ver van elkaar af staan. Met alleen de stelling van Pythagoras, die je ooit uit je hoofd hebt geknald omdat je wiskunde docent je wist te vertellen dat je hiermee alles kon uitrekenen, kom je letterlijk en figuurlijk nergens. Wat jij nodig hebt is een stevige dosis haversinus.

De haversinus formule kun je gebruiken om de afstand tussen twee coördinaten te berekenen en wel op de volgende manier:

• Je neemt de radius van de aarde (R), 6371 km


• Je neemt het verschil tussen de twee breedtegraden (∆b = b1 – b2)


• Je neemt het verschil tussen de twee lengtegraden (∆l = l1 – l2)


• En dan gooi je die in de onderstaande formule:
  
  afstand = R * (2 * atan2(√(sin2(∆b/2) + cos (b1) * cos(b2) * sin2(∆l/2) ), √(1-a)))

Ho ho ho, even een stapje terug, wat was die laatste? Laat me het uitdrukken in Java code, dat begrijp je vast beter.


public double calculateDistance(double long1, double long2, double lat1, double lat2) {
Integer r = new Integer(6371);
Double deltaLong = Math.toRadians(long1 - long2);
Double deltaLat = Math.toRadians(lat1 - lat2);
Double x = Math.sin(deltaLat/2) * Math.sin(deltaLat/2) + Math.cos(Math.toRadians(lat1)) * Math.cos(Math.toRadians(lat2)) * Math.sin(deltaLong/2) * Math.sin(deltaLong/2);
Double y = 2 * Math.atan2(Math.sqrt(x), Math.sqrt(1-x));
Double z = r * y;
return z;
}

Ok, laten we het er maar op houden dat je in wiskunde niks begrijpt, maar er aan went.

Mozilla 3 Merge conflict

Mozilla heeft met Firefox 3 een behoorlijke verbetering geleverd op de vorige versie, minder geheugengebruik en snellere opstarttijden lossen het grootste probleem van de browser op. Maar dat neemt niet weg dat we niet nog een schop onder de gordel kunnen geven in de richting van Mozilla. Neem een kijkje naar de afbeelding, dit is de site zoals die live stond op de releasedag van Mozilla FireFox 3. Het ziet er naar uit dat er een SVN/CSV merge conflict door het net is geglipt.

Een webservice in 5 minuten

EJB 3.0 en webservice annotations maken het mogelijk om webservices te maken, zonder alle details te kennen van WSDL of binding of wat dan ook. Sterker nog, je kunt in enkele minuten een webservice maken. Het enige dat je nodig hebt is een interface klasse, een implementatie klasse en een paar annotations. Laten we dit eens van dichtbij bekijken met het aloude “Hello World” voorbeeld. Maak een EJB 3.0 project en maak daarin allereerst de interface klasse.

package nl.isaac.ejb.service;

import java.rmi.Remote;

import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

@WebService
@SOAPBinding(style = Style.DOCUMENT)
public interface HelloWorld extends Remote {
String hello(String name);
}

Hierin zie je twee annotations staan. De eerste “@WebService” geeft simpelweg aan dat het om een webservice gaat. De tweede geeft aan welk soort SOAP binding je gebruikt, hierin heb je twee smaken “RPC” en “Document”. In het voorbeeld gebruik ik “Document”, maar in dit geval maakt het niet uit om hier “RPC” van te maken (Het verschil tussen document en RPC is grofweg gezegd dat RPC maar een enkel element als resultaat geeft en document een uitgebreid XML document terug kan geven). In de interface klasse staat verder alleen onze methode gedefinieerd. Let er wel op dat de interface jave.rmi.Remote extend. Nu kunnen we onze implementatie klasse maken.

package nl.isaac.ejb.service;

import javax.ejb.Stateless;
import javax.jws.WebService;

@Stateless
@WebService(endpointInterface = "nl.isaac.ejb.service.HelloWorld")
public class HelloWorldImpl {
public String hello(String name) {
return "Hello " + name;
}
}

Let erop dat, ondanks dat dit de implementatie klasse van een interface is, je deze niet implementeert met de code “implements HelloWorld”. Dit gebeurt in de annotation @WebService, die in deze methode zijn endpoint interface instelt. Deze verwijst naar de interface klasse die we zojuist gemaakt hebben. Onze methode wordt geïmplementeerd en voilá, een webservice is geboren. Deploy je project in JBoss en controleer voordat je een client maakt of je service draait door de WSDL file aan te roepen. Dit kun je doen door de URL van je project in IE in te voeren met daarachter “/HelloWorldImpl?wsdl”, dit zou je een XML document moeten tonen met alle details over de webservice.

Onautomatiseerbaarheid

Onautomatiseerbare zaken... ze bestaan echt!

Soms begin je vol goede hoop aan het bedenken van requirements voor een systeem(pje), maar besef je na een paar uur analyseren dat je in een soort ondoordringbaar woud van verradelijke schaduwen, valse doorstruiken, moerassige dalen en onoverbrugbare kloven terecht bent gekomen. Dan kun je stevig door blijven hakken in dat woud in de (ijdele) hoop ooit nog eens aan de andere kant te komen. Of je kunt gewoon zuchtend opgeven. Neem nu een persoonlijk knutselprojectje waar ik al een tijdje over aan het denken ben: een prima voorbeeld van zo'n Mirkwood vol valse bijtspinnen. Althans, dat denk ik.

Ik ben zelf nogal een liefhebber van boeken. Correctie, van mooie boeken. Ingebonden, leeslint, Nigeriaans lammerleer, goud-op-snee, eerste druk, je kent dat wel. In de loop der jaren is dat (volgens de laatste gefundeerde schatting) uitgekomen op zo'n 3000 kloeke folianten op een kleine 80 meter plank. En daar begint langzaamaan een probleem te ontstaan: wat staat waar, en wat heb ik eigenlijk?

Nu ik laatst voor de derde keer -blij ende tevree van bevredigde hebzucht- een boek uit een postpakket haalde om enkele uren later vol frustratie te ontdekken dat exact zo'n zelfde exemplaar al op m'n planken staat, werd het tijd voor ondersteuning middels ICT. Keiharde registratie zonder enig respect voor de privacy van de betrokken boeken, hoe speciaal of zeldzaam ook. Minister Hirsch-Balin zal trots op mijn plannen zijn!

Wat moet zo'n registratiesysteem kunnen? Dat was de vraag die ik mezelf in goede IT-traditie stelde (niet erg Agile, ik weet het...) Wel, er moeten printbare lijsten uit kunnen komen. Op auteur, op titel, op taalgebied, op uitgever en wellicht ook op "reeks" (iets waar ik nogal waarde aan hecht, bijvoorbeeld alles uit de Baskerville-reeks van uitgeverij Atheneaum, of alles uit de Franse Bibliotheek van Van Oorschot). Die lijstjes zijn ideaal om mee te nemen op strooptocht in muffige antiquariaten (over zulke strooptochten op leven-en-dood is overigens een hilarisch boek verschenen van de duitser Walter Moers, "De Stad van de Dromende Boeken" - heerlijk zulke meta-literatuur!). En ik moet makkelijk en snel kunnen zoeken met mijn systeem om te zien of ik iets al heb. Liefst per SMS, maar dat is toekomstmuziek. Het vullen van het systeem moet eigenlijk met een barcode-lezer, maar dat is vast te moeilijk voor een high-level niet-embedded mannetje als ondergetekende. Dan maar ISBN-nummers kloppen.

Verder is sorteren, het heerlijke ordenen ook een belangrijke zaak. Want alleen met ordening kan ik ook élk boek meteen vinden op de plank, zonder lelijke planknummers te moeten gaan monteren. Nu koester ik de blijde gedachte dat mijn huidige ordening op de plank vrijwel ideaal is, zeker gezien constraints als plankhoogte, diepte-ruimte en visuele uitstraling. Maar in die plankordening komt dus veel complexere logica om de hoek dan iets triviaals als alfabet, auteur of aankoopdatum. Zulke zielloos efficiënte systemen zijn meer iets voor professionele biobliotheken, niet voor een persoonlijke thuisbibliotheek.

Boekomvang speelt dus een rol. Maar hoe orden ik daar digitaal op zonder elk boek te moeten nameten? De plankhoogte wil ik nog wel invoeren, maar 3000 keer een rolmaat trekken gaat zelfs mij te ver. Wellicht kan ik iets met een plugin van Amazon.com (Jeff Bezos en co hebben boekmaat in de database staan) en het Centraal Boekhuis. Maar die laatste heeft weer geen gratis toegankelijke API. En dan die visuele uitstraling van een boek. Die ordening gaat bij mij vaak op het type omslag. Is het leer of linnen, of toch gewoon stofomslag of (de horror!) een paperback? Die informatie is deels nog wel te vinden voor moderne boeken, maar niet voor een oude uitgave van Couperus uit 1950, of een obscuur museumgidsje uit 1972. En wat te denken van mijn (zeldzame maar her en der met zorg toegepaste) plankordening op basis van "ideologische compatibiliteit van de auteurs"? Je kunt Nietzsche niet zonder uitlokking van oorlog naast een lieve schat als Montesqieu zetten. En gaan Rimbaud en Verlaine alsnog in boekvorm hun relatie verdiepen als ik ze naast elkaar zet? Of wat te denken van een Wagner-biografie bij een facsimile-dagboek van Anne Frank? Dat gaat finaal mis natuurlijk! Maar hoe automatiseer je dat? Moet je de Wikipedia gaan parseren, een neuraal netwerk aanzwengelen en dat beslissingen laten nemen? En gaat dat algoritme zo zwaar op mijn arme core2duo CPU worden dat ik er een distributed computing project van moet maken via BOINC? Zucht... te veel vragen! Aargh! Scope Creep!

Ja, soms moet je eigenlijk gewoon al opgeven voor je beginnen gaat. Ik doe het wel met de hand, ja!

SOA in een web 2.0 omgeving

Software ontwikkelaars komen steeds vaker de term SOA of WebServices tegen. Deze twee termen zijn erg vergelijkbaar. SOA is misschien een wat ruimer begrip, maar hierover zijn de meningen verdeeld. Wat vaak niet wordt begrepen is dat SOA een essentieel onderdeel is van de zogeheten web 2.0 hype. Er wordt onder de noemer web 2.0 vaak veel gewerkt met technieken om rijke webapplicaties te ontwikkelen, maar er wordt vaak niet gedacht aan de gegevensbronnen die deze technieken moeten aansturen. Deze gegevensbronnen zijn het kloppend hart van de web 2.0 applicaties. In het komende artikel wordt dit verduidelijkt en wordt een introductie gegeven op SOA en WebServices.

Web 2.0

Het is de IT eigen om vage termen te bedenken. Web 2.0 is daar misschien wel het beste voorbeeld van. Er is niet echt een vaste definitie van web 2.0 te vinden, maar het baseert zich op het idee van bijdrage van gebruikers en het delen van data op het internet. Websites die onder de noemer web 2.0 vallen, zoals wikipedia of flickr, bieden de gebruiker meer dan alleen harde data, ze bieden de gebruiker de mogelijkheid om hun eigen inbreng aan deze data toe te voegen.

SOA

Wanneer men spreekt over web 2.0 wordt de term AJAX vaak gretig aangehaald. AJAX, ofwel Asynchronous Javascript and XML, is bedoeld om van de “ouderwetse” websites, rijke applicaties te maken, door zonder een browser refresh data van de server te halen. De term SOA is daarbij lange tijd ondergesneeuwd geraakt door de vele technieken om schitterende applicaties te maken. Toch is SOA de spil rond web 2.0. SOA staat voor Service Oriënted Architecture en slaat op de gedachte die ook achter web 2.0 staat, het delen van data. Of, iets gedetailleerder, het aanbieden van data in een uniforme wijze. Dit kan op allerlei manieren, denk aan XML, SOAP, kommagescheiden bestanden, dynamic link libraries, etc. Hierdoor kan de data hergebruikt worden en gedeeld worden (met bijvoorbeeld businesspartners, of zelfs de hele wereld). Vanuit een bedrijfsvoeringaspect kan men op deze manier ook dynamischer werken en sneller reageren op wat de concurrent doet. Vooral dit laatste heeft ervoor gezorgd dat de term SOA aan populariteit wint.

De opbouw van een webservice

Bij een service zijn drie partijen gemoeid, de requestor, de provider en de broker. De requestor is de cliënt die gebruik gaat maken van de service. De provider is de partij die de service implementeert en de verzoeken van de cliënt verwerkt. De broker kan worden gezien als een makelaar waarbij de cliënt terecht kan om de juiste service te vinden. In grote settings kan dit middels een UDDI register, maar vaak ontbreekt dit onderdeel.

Een WebService is opgebouwd uit een aantal componenten. Het contract, de implementatie en de interface. In het contract staat beschreven hoe de webservice is opgebouwd, welke techniek gebruikt wordt en hoe de service kan worden aangeroepen. De implementatie is de daadwerkelijke code die de verzoeken van clients verwerkt en beantwoord. De interface wordt door de client gebruikt om verzoeken naar de service te sturen.

Belangrijk bij een webservice is de zogeheten “interoperability”. Dit houdt in dat de implementatie van de provider dusdanig moet zijn dat de cliënt altijd hiervan gebruik kan maken, ongeacht de techniek die hij gebruikt. In de mooiste gevallen volgt men de richtlijnen van het Basic Profile, die het gebruik van SOAP en WSDL voorschrijft, maar vaak worden ook JSON (Javascript object notation) objecten, Dynamic Link Libraries of kale XML gebruikt. In deze gevallen zijn er vaak online API beschrijvingen te vinden over de services.

De mashup

Populair op het internet is de mashup. Een webapplicatie die gebruik maakt van verschillende services en gegevensbronnen en deze mengt tot nieuwe informatie. Denk bijvoorbeeld aan het koppelen van bedrijfsgegevens aan de plattegronden van Google Maps. Vaak worden er op internet mashups gemaakt, simpelweg voor de mashup. Zo is er een site waar men op een plattegrond kan aangeven hoe een bepaalde locatie ruikt, waarop men vervolgens kan zoeken waar op deze planeet het zoal stinkt naar rotte eieren. Maar een mashup kan voor een bedrijf van nut zijn. Door gebruik te maken van vrijelijk beschikbare data op het internet kan het zijn eigen data verreiken, of extra diensten aanbieden op zijn website. Denk bijvoorbeeld aan een persoonlijke routebeschrijving van een bezoekers’ thuis adres naar de dichtstbijzijnde bedrijfsvestiging.


ESB

Laten we om te beginnen een kijkje nemen naar een site die op een bescheiden manier gebruik maakt van een webservice. De site climacount.com bevat onder andere informatie over een aantal CO2 reductie programma’s. Hierbij maakt het gebruik van data die vrij beschikbaar is op internet om een kaart te laten zien van de omgeving waar een programma aan het werk is. Dit is natuurlijk maar een kleine invoeging van externe data en hierbij hoeft verder ook niet nagedacht te worden over de implementatie van externe data in de site, maar stel er worden van meerdere bronnen gegevens opgehaald. Het is dan onwaarschijnlijk dat al die bronnen met dezelfde techniek beschikbaar zijn. Zeker wanneer je gaat denken aan e-banking applicaties, waar nog vaak van zeer ouderwetse technieken gebruik gemaakt wordt zoals COBOL. Dan is het verstandig om na te denken over de architectuur van je applicatie om te voorkomen dat toekomstige wijzigingen het risico met zich meenemen dat de hele applicatie op de schop moet. Hier komt de term ESB, ofwel Enterprise Service Bus, in het verhaal. Het klinkt vreemd maar om het eerder genoemde risico te vermijden maak je een applicatie die niks anders doet dan gegevens van derden beschikbaar maken. Een soort service die de andere services omsluit, zeg maar. Je webapplicatie kan op die manier altijd de zelfde techniek gebruiken om gegevens op te halen bij de ESB en de ESB zorgt voor het aanroepen van de daadwerkelijke service. In de onderstaande illustraties zie je vrij duidelijk het voordeel van het introduceren van een ESB.

Situatie zonder ESB


Situatie met ESB

Nadelen van SOA en Web 2.0

De toevoeging van componenten om de services beschikbaar te maken, de XML lagen die over componenten geplaatst worden en de extra beveiliging die nodig is bij openbare services vereisen allemaal extra processorkracht en dus zwaardere servers.

Conclusie

In dit artikel heb je de basisideeën achter SOA en WebServices in een Web 2.0 setting kunnen lezen. Essentieel hierbij is het beschikbaar stellen van data, het gebruiken van data van derden en het letten op de interoperability van de data. Bij het gebruik van meerdere WebServices kan het gebruik van een ESB de architectuur van je software overzichtelijk houden en eenvoudig bij te werken of uit te breiden. Een nadeel is dat het werken met een SOA denkwijze voor overhead in de software kan zorgen die extra processorkracht vereist en de hardwarekosten kan verhogen.

Heb je zin gekregen om zelf aan de slag te gaan met SOA, maar weet je niet goed waar je moet beginnen, neem dan een kijkje op http://www.programmableweb.com waar een opsomming van allerlei API’s en WebServices te vinden is.