Naar deze presentatie had ik echt uitgekeken en niet in het minst voor de spreker: Scott Ambler. Deze Canadees is bekend voor zijn straffe uitspraken. Zo had hij het enkele jaren geleden over modelling en (de onzin van) data modelling in het bijzonder. Volgens hem kan je van modelling geen voltijdse bezigheid maken (een developer werkt in modelling storms: toetst zijn model met een stukje code) en data modelling zonder application modelling heeft al helemaal geen zin (alsof je in een class diagram alleen attributen zou opnemen).

Deze presentatie beloofde meer van hetzelfde. Hij was duidelijk van plan enkele heilige huisjes in te trappen, zowel van de traditionalisten (de waterval-methodiek) als de "echte" agilisten (de extreme programmers en de scrummers). De ondertitel van zijn presentatie was:

---

Addressing the unconfortable issues we've managed to avoid until now

---

 

Zijn presentatie ging over scaling agile development (naar teams van 100 personen en meer) en daarmee sneuvelen al direct enkele populaire XP-principes. Want met een team van 100 personen kan je moeilijk:

• iedereen op dezelfde werkvloer samenbrengen (meestal zitten zulke teams geografisch verspreid)
• iedereen continu laten roteren (bij geografisch verspreide teams worden specialisaties vaak samen gebracht op 1 locatie)
• aan pair programming doen (toch niet met iedereen)

De traditionele aanpak

De klassieke waterval

Dat de agile approach zijn nut bewijst, dat staat als een paal boven water. Daarover zijn ondertussen cijfers genoeg beschikbaar. Een project volgens de klassieke waterval-methodiek aanpakken, is eerder een risicofactor, omdat:

• je business in het begin de volledige scope van het project moet kunnen bepalen (en daarom ook ALLES als even belangrijk beschouwt)
• de planning maar 1 keer gebeurt (bij het begin van het project)
• scope changes worden ontmoedigd (of zelfs worden afgestraft)
• testen pas op het eind van de rit worden uitgevoerd en door onderschatting van de workload (je kan niet alles vooraf correct inschatten) veel te weinig tijd krijgt
• de business enkel bij het begin en op het einde van het project betrokken wordt (tijdens de uitvoering van het project niet meer betrokken wordt)

Het gevolg van dit alles is een systeem met meer kans op bugs, waarvan een groot deel van de functionaliteit niet wordt gebruikt (wegens eigenlijk niet belangrijk of zelfs achterhaald). M.a.w.: de klassieke waterval is "down the drain".

Governance

Het governance proces in een traditionele aanpak laat business analisten en architecten documenten schrijven en regels opleggen. Maar volgens Scott Ambler smijten ze het probleem over de muur. Van zodra zij hun documenten hebben opgeleverd, moeten de implementatieteams de echte problemen oplossen, want dan zij de BA's en architecten al lang met iets anders bezig en weten ze niet meer precies wat was bedoeld mete paragraaf X op pagina Y...

Scott Ambler pleit daarom voor een meer lean governance model: geen command & control maar meer self organized teams. Op die manier creëer je gemotiveerde teams.

Agilists onderuit gehaald

Het onvolledige verhaal van de XP-boekjes

Maar ook de extreme programmers moeten eraan geloven. Want als je hun boekjes erop naleest, dan lijkt het alsof een project ineens "ontstaat". Alsof er nooit een initiating stage is, waarin requirements worden bepaald, high-level architectuur wordt uitgetekend en de initiële modellen worden uitgewerkt. En als de programmatie is afgelopen, is er ook nog zoiets als delivery:

• documentatie
• training
• deployment
• eventueel data conversies (want alleen in de XP-boekjes staan projecten volledig op zich)

Dit wordt nooit aangehaald in de XP-boekjes, maar het moet wel gebeuren.

Test driven development: onvoldoende

Nog zo een heilige huisje van XP: test driven develoment (test-first development). Bij XP moet je eerst je unit-test schrijven en dan pas de code met de logica die moet worden uitgevoerd. Ook moeten alle unit-tests altijd foutloos kunnen lopen (ev. moet je een unit-test aanpassen na je laatste aanpassingen/toevoegingen). Maar... TDD is niet scalable. De Extreme programmers beschouwen de user story en de unit test als de spec. Maar dat betekent dat je Just In Time (JIT) specificaties schrijft. Dan kan je niet doen op grote schaal. Want dant creëer je ene onsamenhangend monster. Dat kan je alleen maar oplossen door te modelleren.

Bovendien is unit testing onvoldoende om een totaal systeem te testen. Het test elk individueel blokje op zich, maar daarmee heb je niet heel je systeem getest. Er is ook nood aan:

• exploratory testen (break the system)
• scenario testing (klopt het verhaal van voren naar achteren?)
• systeem testen (is het ding performant genoeg?)
• user testen (wat is de user experience?)

Al deze aspecten geven aan dat een gespecialiseerde tester een belangrijke rol speelt in een project.

On-site customer/product owner

Ook hierover had hij één en ander te zeggen. Bij XP-projecten wordt 1 gebruiker opgenomen in het projectteam. Dit moet beslissingen kunnen nemen over inhoudelijke vragen. Is er geen echte business-medewerker beschikbaar, wordt er gewerkt met ene proxy-user. Maar... als er bij de realisatie van een project verschillende businesses betrokken zijn, dan betekent dat dat er tegengestelde belangen kunnen wegen. Die ene product owner kan onmogelijk de belangen van ALLE businesses verdedigen. Bovendien is de gebruiker die wordt vrijgemaakt om mee te werken aan een project vaak niet de grootste specialist op het volledige vlak (de business unit kan tijdens het verloop van het project zijn business niet stilleggen, kan dus niet zomaar zijn beste medewerker vrijmaken). Bovendien betekent slechts 1 product owner ook een risico: als die persoon ziek valt, of het bedrijf verlaat, dan valt het project stil... Er moet wel iemand zijn die de projectmedewerkers bij de juiste business-personen kan brengen voor specifieke vragen (een soort proxy, dus, maar niet eentje die de beslissingen moet nemen).

Agile data modelling

Ja, het kwam toch weer naar boven: database refactoring is te vaak de bottleneck in een project. We kunnen prachtige methodieken uitwerken voor programmatie en project management, maar wat als de database-jongens niet mee willen? Ook hier is er nood aan een andere aanpak: test driven database design. De standaardvraag die Scott Ambler hier dan stelt, is:

---

Hoelang duurt het om een kolom in een tabel te hernoemen?

---

 

Als dit langer dan 1 dag duurt, dan heb je een probleem. Volgens hem moeten ontwikkelaars voldoende database-kennis hebben, zodat ze kunnen meedenken en suggesties doen bij de data modellers en database administrators.

Scrum-master: big business

Scrum is een populaire methodiek voor agile project management. In tegenstelling tot Extreme Programming, waarbij de focus eerder ligt op de werkuitvoering, focust Scrum zich eerder op de beheersprocessen. De projectleiding is in handen van de Scrum-master. Maar... Om Scrum te mogen toepassen, m.a.w. om de rol van Scrum-master te mogen opnemen, moet je gecertifieerd zijn. Dat is een dure opleiding (ben even gaan kijken: 1300 EUR voor 2 dagen). Op 2 dagen leer je dus hoe je een project moet leiden volgens de Scrum-methodiek. En iedereen slaagt?!? Wat is dan de waarde van zulke opleiding? Ben je na 2 dagen werkelijk in staat om een Scrum-project te leiden???

Planning

Agile managed projecten geven voor leken (of beter: de niet-agilists) de indruk van chaos: ze laten dingen aan het toeval over, weten niet wat ze precies zullen opleveren, plannen hun werk niet, ... Het tegendeel is echter waar: de GANTT chart mag dan misschien niet het favoriete hulpmiddel zijn voor agilists, maar dat betekent niet dat ze niet plannen. Ze plannen niet up-front! Ze plannen voortdurend, en sturen hun planning voortdurend bij, bij elke iteratie, omdat elke iteratie wordt bepaald wat er precies moet worden opgeleverd.

Uitdagingen voor agile aanpak

Scott Ambler zag volgende uitdagingen voor de agile aanpak, door verschuivingen in de manier van werken:

• van kleine teams naar grote teams
• van collocated (het team op 1 plaats) naar global teams
• van kleine, low risk applicaties naar kritische systemen
• van single platform naar multi-platform
• van in-house ontwikkeling naar 3rd party ontwikkeling

Die elementen zijn een realiteit. de XP-boekjes behandelden tot nog toe voornamelijk de kleinere, niet-kritische, geïsoleerde applicaties, in-house ontwikkeld door een klein team, op 1 locatie. Hierdoor was er een harde scheidingslijn tussen de agile aanpak voor de kleinere projecten een de klassieke waterval voor de grotere. Agile aanpak is op een punt gekomen dat de credibiliteit en de adoptie ervan het niveau van de kleinere projecten overstijgt. Het is tijd om een agile manier van werken op grote schaal toe te passen.

Conclusie

Deze presentatie van Scott Ambler was er weer eentje om geamuseerd te volgen. Hij durft rake uitspraken doen, maar doet de waarheid daarbij zeker geen geweld aan. Zijn uitspraken zijn gefundeerd. Agile in the large: zijn werkgever (IBM) bewijst wel degelijk dat het kan. Het Eclipse platform wordt namelijk volgens een agile aanpak gerealiseerd met een team van 70 ontwikkelaars verspreid over de hele wereld.

Meer info:
http://www.agilemodeling.com/
http://www.ambysoft.com/

Ondertussen ligt Javapolis 2007 al weer enkele weken achter ons, maar ik moest nog een en ander neerschrijven over de laatste dag van Javapolis. In tegenstelling tot andere jaren, was de laatste dag toch nog een interessante dag. Bewijs daarvan is het feit dat is nog op elke sessie een (interessante!) presentatie hebt gevolgd. Dit is het verslagje van de eerste presentatie van de dag...

De Kanban-presentatie was de eerste agile-gerelateerde presentatie die ik dit jaar bijwoonde. De voorbije jaren had ik al heel wat presentaties over agile approach gevolgd (o.a. Agile in the large, LEAN, ...). De term Kanban was mij dus niet onbekend (kwam ook ter sprake in de LEAN-presentatie van Mary Poppendieck van 2 jaar geleden).

Kanban komt oorspronkelijk uit de industrie, meer bepaald van Toyota. Daar waar een klassiek lopende band principe werk vooruit pusht, zal het Kanban principe pas toelaten om nieuw werk toe te voegen als er iets anders gerealiseerd is. Het pull-principe dus. Doel van dit alles: reduce work in progress & eliminate waste. Want als er continu werk wordt gepushed, zal dit de kwaliteit niet ten goede komen.

Visualisatie

Deze presentatie met heel wat foto's hoe de Kanban in de praktijk in een software project gevisualiseerd werd. Zoals bij alle agile approaches is het whiteboard van essentieel belang. Elke fase wordt voorgesteld door een kolom (analyse, ontwikkeling, test, opgeleverd... ev. verder verfijnd). Taken worden op post-its gewerkt voor workitems. Er worden verschillende kleuren gehanteerd voor:
- change requests
- bugs
- maintenance
- ...
Per release cycle kan er ook hoogstens 1 silver bullet worden gedefinieerd. Dat is een workitem dat absolute prioriteit moet krijgen boven al de rest (wijkt dus af van de normale geplande items). De ervaring leerde dat het aantal silver bullets eerder beperkt was, want bij het aanvragen van een silver bullet moest een manager de andere betrokkenen overtuigen van de noodzaak van zijn silver bullet (was dus eerder beschamend, omdat je daarmee de prioriteiten van de andere managers opzij schuift).

Bij een bepaald team was er b.v. een apart vak op het bord voorzien voor een "waste bin". Hierin kwamen work items terecht die door de business werden afgevoerd. Op die manier werd aan de business duidelijk gemaakt dat voor deze items tijd en resources werden verloren.

Delivery

Het principe dat wordt gehanteerd, is dat fixed delivery dates kunnen, maar niet worden aangemoedigd. De enige reden voor fixed delivery dates, is dat iets wettelijk vereist is. De beslissing over de inhoud van een release wordt pas 5 dagen voor de eigenlijke opleveringsdatum genomen (= delay decisions). Opleveringen kunnen snel gebeuren (b.v. elke 14 dagen), maar dat betekent niet dat workitems maximaal 14 dagen in beslag mogen nemen (er zijn workitems die b.v. tot 100 dagen kunnen duren). En workitem wordt trouwens pas opgeleverd als het echt afgerond is.

Specialisten

De spreker had ervaring met teams van specialisten. Zo waren er b.v. analisten met een spcialisatie in financiële aangelegenheden. Die hadden een specifieke banktechnische kennis. Zulke mensen kon je dus niet zomaar laten roteren in een team. Bovendien kan je ook niet van iedereen verwachten dat ze de rol van deze specialisten zomaar kunnen overnemen.

Dit principe staat lijnrecht tegenover de idee van rotatie en shared ownership dat binnen extreme programming wordt gehanteerd.

Daily standup

Dit is niks nieuws. Dat gebeurt bij zowat alle agile methodologieën, onder welke naam dan ook (standup, daily scrum, ...). Het verschil met de standup van XP of de scrum van... Scrum is echter wel dat een standu hier met heel het team (b.v. 40 personen) tegelijk verloopt en dat dit toch maar 10 minuten duurt. Geen nood dus aan een scrum of scrums. De standup bij deze Kanban gebeurt aan het bord, met focus om de issues. Het is dus niet de bedoeling dat iedere individuele developer komt vertellen hoever hij staat en wat zijn problemen zijn, want iedereen ziet op het bord waarmee iedere persoon bezig is (post-its met workitems geven aan waarmee iemand bezig is).

Ook het remote werken hoeft geen belemmering te zijn, want het is de bedoeling dat er wordt gewerkt met een proxy: iemand die in jouw plaats de post-its van afgehandelde workitems verplaatst (of je kan ook met een digitale versie van het whiteboard werken).

Conclusie

Het Kanban principe staat in contrast met andere principes, zoals Scrum en Extreme programming, waarbij de focus eerder ligt op time boxing. Dit Kanban principe lijkt me eerder van toepassing voor langlopende projecten of ontwikkeltaken in een operationele omgeving met een continue stroom van taken (kleine change requests). Het was een andere kijk op "agile in the large", maar daarom niet minder interessant!

Meer info: http://www.agilemanagement.net

De sessie over OpenSSO werd gegeven door Superpat, Pat Patterson van Sun, die ook al de sessie over SAML had gegeven. Zijn opener was leuk:

---

 Het is een fully featured WAM, maar dan volledig open source, net zoals Glassfish van Sun een fully featured Web Application Server is.  Het is de core van 2 andere - commerciële - producten van Sun:

• Sun Access Manager
• Sun Federated Access Manager

Het beginvan deze presentatie was wat herhaling van wat in zijn presentatie over SAML werd besproken; niks nieuws dus (kan je nalezen in mijn blog post over die sessie).

De rest van de presentatie ging dan voornamelijk/uitsluitend over het product OpenSSO en de aanwending ervan, want een aantal sites zijn effectief in productie met OpenSSO als access manager ervoor. Pat verwees hiervoor o.m. naar SSOCircle.com, waarmee je via federation toegang krijgt tot je Google GMail mailbox en Google Calendar en de Google office applicaties. Maar naast deze demo-site was b.v. ook audi.co.uk zou beveiligd zijn met OpenSSO: dus het product is echt bruikbaar in een productie-omgeving. Niet voor niks werd het door Gartner in het magic kwadrant voor WAM-producten gepositioneerd.

Op zich was dat allemaal leuk om te zien. Maar... Mij leek dit - afgezien van het onderwerp Security - eerder een presentatie voor een Partner Slot...

Josh Bloch had normaal een talk voorzien over een ander onderwerp (effective Java reloaded) maar heeft onderweg naar Javapolis effe snel een andere presentatie in elkaar geboxt over Closures. Maar, zo zei hij, wie absoluut zijn presentatie over effective Java wou zien, kon die vinden op YouTube (je moest maar google'n).

Zijn opener was duidelijk: hij liet een voorbeeld zien uit een boek van Angelika Langer over Generics, meer bepaald eentje over wildcards. Dat stuk code was zoooo onleesbaar... Wildcard hell is dus wekelijk een bron van hard to find bugs. En als je Closures op eenzelfde manier zou aanpakken...

Er was een bepaalde proposal implementatie voorzien. Josh liet een aantal code samples hiervan zien. Die dingen zagen er werkelijk verschrikkelijk uit. Onleesbaar en een gigantische bron van fouten!

Allereerst moest het JSR team zich de vraag stellen of ze wel die richting wilden uitgaan, vooraleer de goedkeuring te geven over een of andere proposal. Anders zaten we binnen de kortste keren met een wildcards2 story opgezadeld. En dan zou heet gauw steil bergaf gaan meet Java! Al waarvoor Java nu stond - above all leesbare code - zou hiermee van tafel geveegd worden. Bloch pleitte eerder voor een lightweight approach:

• ARM Blocks (automatic resource management blocks) konden worden getackled via een intelligenter try/finally blok:
  try (InputStream i = new FileInputStream("xxxx")) {
     i.read();
     ...
  } finally {
     ...
  }
  De scope van al wat tussen de haakjes achter het try statement staat, is beperkt tot de code tussen de accolades. M.a.w. eens buiten dat stuk (zelfs al in de finally) waren de resources verdwenen (wat door de compiler kon worden opgevangen als: close resources).
• Locks: zelfde principe: je zet een lock voor het stuck code binnen de accolades wordt uitgevoerd en geeft de lock weer vrij na de uitvoering.
• Timers: alweer hetzelfde principe: de doorlooptijd van de code kon op die manier worden getimed en gelogd.

En that's basically it! Verder gaan met closures dan deze 3 cases zou de taal Java gene goed doen. Het Java platform, de runtime environment is een perfect geschikt vehikel om dat soort van fancy (lees: onleesbare) code te draaien (Groovy bij voorbeeld), maar laat dit pleeez uit de taal!

Closures? Voor mij case closed!

 

De eerste talk of the day die ik volgde, was er eentje over Java SE7. Deze presentatie ging over wat er allemaal zit aan te komen voor de volgende standard edition. De focus ligt niet zozeer op echt zwaar vernieuwende dingen - zoals dat bij Java 5 wel het geval was met generics, annotations, enums, autoboxing and the like (hoewel: closures?). De wijzigingen zullen eerder subtiel zijn. Want de JRE is momenteel een beetje een mastodont aan het worden, terwijl de gemiddelde applicatie slechts een deel van de totale functionaliteit nodig heeft...

Dit is zo een beetje een overzicht van wat er zit aan te komen: 

• super packages: hiermee bundel je een deel van de imports die je wil gaan gebruiken
• Modules: hiermee wordt er afgestapt van de klassieke JAR-file want die zit zo een beetje aan zijn limiet. een JAM is een bundel van class files, JAR's, DLL's, SO's, ...
• Swing verbeteringen: jaja, Swing is springlevend. De Superclass Application wordt in het leven geroepen, waardoor de source code voor een Swing applicatie een heel stuk kleiner wordt. Al wat je vroeger programmatorisch moest configureren, zoals font name, size, kleuren, etc. wordt nu afgezonderd in properties files. het doet een beetje denken aan het vroegere principe van DLG--files (dialogs) in OS/2: die bevatte ook geen programma code. Je eigen programmacode kan daarom meer gefocusd zijn op event handling.
• Bean properties: Java beans properties waren vroeger eerder een convention matter: je hebt een attribuut, b.v. private String name, en  daarvoor definieerde je getters en setters die moesten voldoen aan de naming convention public String getName() en public void setName (String newName). Heel dit gedoe wordt nu geformaliseerd met ECHTE bean properties.
• JavaFX: Hier ligt de focus meer op designers dan op applicatie ontwikkelaars, met meer mogelijkheden voor eye candy. Laathet ons gewoon het antwoord van Sun op Adobe Flex noemen. Want dit IS een nieuwe taal, die wel Java-achtig is, maar toch weer net iets anders. De toepassing is toegespitst op mobile devices (vandaar dus de keynote die begon over Java ME waar ik was gaan lopen...), home entertainment en ook wel desktops.
• Modularisatie van de runtime: de JRE zal worden opgedeeld in dingen die echt essentieel zijn om een hello world applicatie te draaien (de kernel, zeg maar) en al hetgeen er specifiek voor die applicatie bijhoort. Die dingen worden geladen als die echt nodig zijn. Dat heeft als grote voordeel dat een applicatie veel sneller zal starten.
• En zoals altijd: performance! zo zal de Hotspot weer een beetje sneller worden gemaakt met onder meer een verbeterde garbage collector.

Ik zou Closures nog vergeten... Dat is een joint JSR van Bejug en de Brasiliaanse JUG. Maar dat is voer voor een andere blog topic, want daarover had Joish Bloch van Google een en ander over te vertellen...

Adobe Flex/AIR

De eerste keynote van vandaag was er eentje van Adobe en ging over Flex en AIR. Deze presentatie was opgezet als een soort vraaggesprek tussen Bruce Eckel (die van de Thinking in Java boeken) en iemand van Adobe (dat wisselde, al naargelang het onderwerp). Dat zag er allemaal heel mooi en consistent uit, met ondersteuning van clusters van servers en local caching (in het geval van AIR applicaties) en recovery en dynamic updates a la DWR... Ja, heel indrukwekkend allemaal! Maar... 't Is geen Java en ook de real Java boys (zoals James Gosling) zijn daarmee niet echt happy.

Parleys.com

De tweede keynote leunde heel sterk aan bij de voorgaande. Stephan Janssen, head of Bejug (de organisatoren van Javapolis) kwam zijn verhaal vertellen over het ontstaan en succes van de eerste versie van Parleys.com. Die was gebaseerd op Ajax, begonnnen met Dojo maar door problemen moeten overschakelen naar Scriptaculous en Prototype. Een aantal vragen en verbeteringsvoorstellen waren niet langer implementeerbaar in de bestaande versie en daarom moest er een nieuwe versie worden gebouwd. Ajax was deze keer definitly out of scope. Swing: jammer genoeg was Romain Guy niet beschikbaar, dus ook geen Swing. JavaFX was (6 maanden geleden, toen het ei van Parleys 2 werd gelegd) nog quasi niks. Dus bleef er over... Flex!

Wat volgde was een demo om de hond van Pavlov jaloers op te maken : schitterende rich client experience in een browser. En dat was niet alles, want Stephan had een Flex champion gevonden in Duitsland die al dat fraais voor hem heeft ontwikkeld. Het toemaatje was een local client die in staat was om presentaties lokaal te downloaden en deze van op je harde schijf te bekijken! Really nice! Zo ineens was de perceptie van Flex net even anders dan een half uur daarvoor.... Benieuwd wat het antwoord van JavaFX hierop zou zijn.

(De nieuwe Parleys.com site zal pas productief worden gesteld in februari 2008; tegen dan zullen Flex en AIR ook finaal zijn). 

JavaFX

De derde keynote ging over JavaFX... althans dat was de bedoeling. Jammer genoeg begon de spreker eerst een verhaal af te steken over Java in de mobile wereld, en dat interesseerde mij nu net geen moer . Ik ben dus niet blijven wachten tot JavaFX echt ter sprake kwam maar ben mijn blog gaan aanvullen...

eigenlijk had die eerder "De koffieklets over computing" moeten heten... Koffie-klets was nog toepasselijk geweest ook, gezien het event.

In het panel zaten niet de minsten:

• James Gosling, Sun, founding father van Java
• Josh Bloch, ex-Sun, nu Google, o.m. verantwoordelijk voor de Collection-API
• Neil Gafter, ex-Sun, nu Google, was in charge voor de compiler van Java 5
• Martin Odersky
• Carl Quinn, Google, moderator

Wat volgde was een 1 uur durende leuke babbel, doorspekt met anecdotes en grappen (vooral Bloch was de grapjas van het gezelschap). Je moest het gewoon gezien hebben, alleen al om wie die personen eigenlijk zijn, maar inhoudelijk had het eerlijk gezegd weinig om het lijf.

Maar ja, het was de laatste sessie van de dag en op zo'n moment heb je ook geen zin in een talk over, zeg maar, Liberty Alliance's Identity Web Services Framework

De SAML presentatie was er ook eentje waarvan ik eigenlijk wel een en qnder verwachtte. Omdat we momenteel bezig zijn met een security related project en SAML in die context al enkele keren ter sprake was gekomen, wilde ik nu eindelijk wel eens weten wat dat voor een beest was. Toegegeven, ik kon net zo goed SAML opzoeken in Wikipedia, maar daarvoor was ik een beetje te lui... Het is altijd interessanter als iemand anders het "voorleest" in plaats van dat ik het zelf moet lezen .

Single Signon

Anyway, het begin van de presentatie klonk zeer vertrouwd: hoe een Web Access Manager zorgt voor de authenticatie, een cookie met een random token genereert (session cookie) en een proxy je op basis van role based security (met LDAP als informatiebron)  je al dan niet toelaat de target URL te accessen. De volgende keer zal je je niet meer moeten authenticeren, want je hebt die cookie in je browser: je bent dus gekencd. Sounds familiar, sounds WebSeal & TAMeB.

Single Signon in the large - SAML

Dit is allemaal heel eenvoudig als je binnen de muren van 1 company blijft, maar wat als je b.v.  enerzijds op de systemen van je eigen bedrijf wil werken en anderzijds ook de systemen van het sociaal secretariaat naar waar de perasoneelsadministratie is uitbesteed? En wat later ook nog op een ander systeem (voor dienstreizen, ofzo)...? Password hell.... een scherm vol post its. En dan kan SAML een handje helpen... 

Pat Patterson, de spreker van dienst gaf de historiek van SAML aan, met het ontstaan van Liberty Identity & Federation Framework en... Microsoft die weer zijn eigen ding moest doen (WS-Federation). Op een bepaald moment heeft Liberty zijn spec volledig overgedragen aan Oasis en SAML2 was finaal aanvaard... maar niet door Mickeysoft! Die moesten hun ding blijven doen met hun WS-Federation. Ondertussen wordt SAML ondersteund door tal van major vendorsm waaronder Sun, IBM, CA, maar niet M$.

SAML algemeen 

Hoe werkt dat nu? Zonder al te veel in details te treden: je probeert access te krijgen tot een service. Je bent niet aangemeld. je wordt geredirect naar een identity provider. De identity provider kan geen redirect terug doen naar je applicatie dus geeft een response, waarin een SAML assertion vervat zit in een form EN een Javascript die onmiddellijk na het laden van de pagina een post doet van de informatie naar de service die je wou accessen. Die applicatie ontvangt de SAML assertion en moet die alleen worden ge-interpreteerd...

Federated access

OK, dat is nu het authenticeren via SAML tokens, maar geen federated access... hoe werkt dat dan? Als je van die ene applicatie (op het netwerk van je eigen bedrijf) naar een applicatie van je sociaal secreriaat wil, dan zal die SAML token worden doorgegeven aan die applicatie, met de context (van Company A naar Company B). De applicatie van Company B kent niemand met die token en vraagt je om opnieuw te authenticeren. Vervolgens wordt je gevraagd of je SAML assertion moet worden bewaard. Die assertion bevat overigens GEEN persoonlijke informatie, noch informatie van Company A. Als je  authenticeert op het systeem van op Company B, is de context binnen company B gekend.

De eerst volgende keer dat je van op het netwerk van Company A een applicatie access't van Company B, is die assertion gekend en moet je je niet meer aanmelden.

Ik dacht altijd dat federated access ervoor zorgde dat je je helemaal niet meer moest authenticeren... Dus dat was een klein beetje een ontgoocheling. Maar ja, om het met de quote van op het einde van de presentatie te zeggen: "SAML is not rocket science".

Deze sessie gaf een overzicht van wat er allemaal zit aan te komen in de volgende Java Enterprise Edition. Deze nieuwe edition wordt volledig open source ontwikkeld, binnen Project Glassfish. Deze edition bouwt voort op de fundamenten van Java SE6.

De grootste focus van deze edition ligt op size reduction. Want momenteel is de JEE een alles of niks situatie. Je hebt een gigantische set aan API's en om JEE compliant te zijn, moet je appserver vendor Al die API's implementeren... Daarvan willen ze nu eigenlijk afstappen. De bedoeling zou zijn om enkel die componenten te selecteren die je echt nodig hebt. Heb je b.v. enkel nood aan een JSP en servlet engine (zoals een Tomcat), dan moet je er niet ook JMS of Java Connector Framework bijsleuren...

Hiervoor wordt gedacht aan verschillende technieken:

• Profiles
  In eerste instantie zal de expert group zich focussen op 1 profile, namelijk  puur Web applications. Later kunnen er andere profiles bijkomen (zoals b.v. Web services, ...)
• Pruning
  Opties die achterhaald zijn of enkel in zeer specifieke gevallen gebruikt worden, kunnen achterwege gelaten worden. Zo wordt b.v. gedacht aan Entity Beans (die ondertussen vervangen zijn door JPA), die misschien enkel voor legacy redenen nog moeten worden voorzien, maar anders niet meer nodig zijn.
• Extensibility
  Dit moet toelaten om gemakkelijk open source frameworks en scripting talen toe te voegen.

Verder is er de focus op ease of development. En ja hoor, ook hier steken de Annotations weer de kop op: @Servlet om aan te duiden dat je class eigenlijk een servlet is, waardoor de web deployment descriptor overbodig wordt. Ook wordt er ondersteuning voorzien voor RESTful web services (JAX-RS).

Er zal verder gewerkt worden aan enkele JSR's die al een tijdje in de koelkast zaten (Timer en WorkManager voor scheduling van taken). Ook zal de BeanValidation extra aandacht krijgen.

De servlet API krijgt ook een extra boost: zo zal er werk worden gemaakt van framework pluggability (steek er Struts onder en je moet je van je servleet niet veel meer aantrekken...), asynchrone request processing, file uploads en natuurlijk de annotations.

Milestones:

• Q1 2008: public review
• Q3 2008: proposed final draft
• Q4 2008: reference implementation beta
• Q2 2009: final release

Java EE6 is dus nog niet voor morgen. Big Blue heeft dus nog massa's tijd om... achter te lopen . Want zoals de spreker bij het begin van zijn presentatie aangaf: "Wat houdt je tegen om met JEE5 te werken? Dan is het antwoord in de meeste gevallen: WebSphere".

Maandag was er al een university sessie over verschillende AJAX frameworks. Daarbij kwam GWT al ter sprake. Deze conference sessie (1 uur) was volledig gewijd aan de Google Web Toolkit. Het informatieve gedeelte was interessant om te weten. Dat de Javascript code wordt gegenereerd, wisten we al. Dat deze wordt gegenereerd volgens de target browser (dat je als applicatie-ontwikkelaar niet moet weten of je applicatie op een Firefox, Opera, Safari of Internet Exploder draait), wisten we ook al.

Maar een leuk weetje is dat er zoveel mogelijk wordt gecached. Als alles maar eenmalig moet worden ingeladen, dan heb je misschien een vertraging bij de initiële download t.o.v. "traditionele" applicaties, maar de volgende call verloopt supersnel. En voor het versnellen van deze initiële download zijn alle truken goed:

• single character functions en attributes
• alle images in 1 grote image file, zodat je met 1 download alle images  hrbt; de javascript knipt die dan wel zelf in stukjes...

En dan was er demo time...

Deze sessie begon eigenlijk al met een demo van enkele Javascript games... Moest je het niet weten, je zou denken dat het Flash games waren.. Maar nee, het was gegenereerde Javascript! 

De echte demo toonde hoe simpel het allemaal was om een GWT HelloWorld applicatie te bouwen en toe te voegen aan je social network page (zeg maar MySpace, LinkedIn, Plaxo, ...). Daarvoor heeft Google nog een leuke API op de plank liggen: OpenSocial (gewoon te downloaden via http://code.google.com/apis/opensocial). Dit is een uniforme API die wordt geïmplementeerd door tal van social networking sites, zodat je op dezelfde manier je eigen applicaties (je eigen Google Gadgets, zeg maar) kan toevoegen op je persoonlijke pagina. 

Die HelloWorld maken, was geen werk. Dat is gewoon de standaard sample. Maar de snelheid waarmee die gadget op die Rokut pagina stond, was wel verbluffeld.

En dan de vragen...

Er kwamen een aantal terechte vragen uit de zaal. Zoals je ondertussen weet (uit een vorige blog post), is GWT een object oriënted approach van web development. Je event handling gebeurt op een erg AWT-achtige manier. Maar... page designs? Uiteindelijk moet je applicatie wel op een browser draaien.

Wel, het goede nieuws is: er zouden plugins zijn voor WYSIWYG design van GWT enabled pagina's... Maar die werden niet gedemonstreerd . Ook zou er een hook zijn waarmee je bestaande HTML pagina's (templates) kan gebruiken voor je GWT applicaties. Zo zijn de web designers toch niet werkloos...