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.

JSR 303 bij ISAAC

De afgelopen twee dagen heb ik samen met Jan Willem JSR 303 (Bean Validation) besproken. Tijdens de gesprekken heeft hij zijn ervaringen met deze specificatie in wording uit de immer spreekwoordelijke doeken gedaan. Aangezien ik zelf de afgelopen maanden meer in de frontend hoek heb gezeten (flex, dojo) was het een voor mij zeer interessant gesprek. JSR 303 is een poging om het valideren van JavaBeans te standaardiseren en bouwt voort op de gebleken 'best practices' van XWork en Hibernate validator.

De kracht van Bean Validation is dat de programmeur declaratief controles kan definiëren die moeten worden uitgevoerd op de waarden van javabean properties. In plaats van dit soort controles te vangen in code, kan je deze logica met annotaties definiëren. Met behulp van een standaard validatie framework worden de annotaties uitgelezen en gebruikt om de bean te controleren. Dus in plaats van bijvoorbeeld de volgende code in bijvoorbeeld PersonFacade.java te moeten schrijven:

if (person.getEmailAddress() == null) {
 throw new ValidationException("person.email.isNull");
} else if (person.getEmailAddress().length() > 100) {
 throw new ValidationException("person.email.tooLong");
} else if (!isValidEmailAddress(person.getEmailAddress()) {
 throw new ValidationException("person.email.notValid");
} else {
 person.makePersistent();
}

kan het volgende worden geschreven in de EJB Person.java

@NotNull
@Length(max=100)
@EmailAddress
private String emailAddress;

en in PersonFacade.java vervolgens:

person.validate();
person.makePersistent();

Alle "heavy lifting" vindt plaats achter de schermen, hoeft maar eenmalig te worden geschreven en kan eenvoudig als een component worden gebruikt binnen verschillende projecten.

Ik heb in de interne ISAAC wiki een artikel geschreven waarin ik onze aanpak uit de doeken doe. Daarnaast staat daar wat voorbeeld code en enkele sequence diagrammen waarin uit wordt gelegd hoe het valideren precies in zijn werk gaat.

Mocht je verder willen lezen, hier zijn enkele intressante artikelen over JSR 303 op Gavin King's blog: 1, 2 en 3

Swingende Nick

Stel je eens voor: Je rijdt in je auto naar je werk. Het is als redelijk laat en de meeste files zijn al opgelost. De snelheidsmeter wijst vrolijk naar de 135 kilometer per uur. Uit je speakers knalt een oude van AC/DC (uiteraard nog met Bon Scott) en net kwam Motorhead nog even voorbij gedenderd. Je bent een jonge man aan het begin van een veelbelovende carriere bij het snelgroeiende en ass kickende (web)software bedrijf ISAAC. De afgelopen maanden waren nogal zwaar, want een tijdje terug is beslist dat jij de Java Swing frontend gaat bouwen op een redekijk complexe JBoss backend. Je hebt nog niet veel ervaring met deze techniek, maar je bent al hard aan het studeren voor je SCJP. Bovendien heb je net de klassiekers "Concurrency in practice", "Thinking in Java" en "Effectice Java" verslonden. Je ademt Java, kan genieten van elegante code en sinds Javapolis 2007 ben je stiekem een beetje verliefd op Fabrizio Giudici (omdat hij zulke mooie swing demo's kan geven). Gisteren heeft je collega Jan Willem de JBoss remoting koppeling over HTTP beschikbaar gesteld, dus je kan niet wachten om die te koppelen. Je wil doorgaan, meer listhandlers schrijven, meer race conditions spotten en vooral kijken of die nieuwe nimbus look and feel wellicht al stabiel is, zodat die trage substance eindelijk kan worden vervangen. Je hebt immers inmiddels meer dan genoeg van al die collega's die telkens melden dat "het er leuk uitziet, maar wel wat traag is.". Tsss, ze zullen hun woorden terugnemen zodra jij klaar bent. "Java is niet traag, kijk maar naar Eclipse. Of nou ja... wellicht is dat niet zo'n goed voorbeeld.", denk je terwijl je bridgestones de paardenkrachten aan het asfalt overdragen.

"Oh fuck! Niet nu! Ik zit in mijn auto op de fucking snelweg, dit is NIET handig!" schiet het door je hoofd, meteen gevolgd door een hoestbui waar de Marlboro man een puntje aan kan zuigen. Je klapt dubbel op je stuur en stuurt je auto zo goed en zo kwaad als het kan naar de kant van de weg. Je hebt het gevoel dat je longen een verblijf buiten je borstkas zoeken. De hoestbui waar je in vastzit, zorgt ervoor dat je maag nog van streek raakt ook. "Toch jammer van dat gebakken ei van vanmorgen", denk je als je ontbijt met een antiperistaltische beweging op dezelfde manier naar buiten komt als waarin het in eerste instantie in je maag terecht is gekomen. Als de hoestbui na een minuut of drie tot bedaren is gekomen en je de restjes ei met melk van je voorruit veegt, besef je eens te meer dat de dokter het toch waarschijnlijk bij het rechte eind had toen hij de diagnose kinkhoest stelde. Je baas Mark had dan wel gelijk toen hij zei dat het "Wel redelijk rock 'n' roll, is, als je 's ochtends in je auto de boel onderkotst", maar jij geeft dan toch zelf de voorkeur aan grote hoeveelheden bier als reden in plaats van een allesverzengende kinkhoest aanval.

"Dus nu is hij aan het rondzwerven en zullen we hem moeten vervangen.", zegt de arts met zijn typische ""kijk eens hoe ik met je meevoel" artsenstem. "Waarschijnlijk is het gebeurd tijdens een van uw hoestaanvallen.", vervolgt hij zijn verhaal. Het metalen plaatje dat enkele jaren geleden in je lies is bevestigd om de liesbreuk te fiksen, is inderdaad losgeschoten en nu moet je dus onder het mes om hem opnieuw te laten bevestigen. Het zit je niet mee. Eerst kinkhoest, dan wordt je huis leeggeplunderd door een inbreker, een sterfgeval in je naaste familie en nu ook nog eens opnieuw een liesbreuk. Je kan je nog goed herinneren dat de eerste drie weken na je vorige liesbreuk operatie geen pretje waren. Verdomme! En net nu het zo lekker ging met het ontwikkelen van de swingclient. De koppeling werkt nu als een tierelier. De CLP engine begint ook vorm te krijgen en we zijn zo dicht bij ons doel. Java code schrijven is toch wel wel veel leuker dan twee weken plat te moeten liggen. Hopelijk gaat het dit keer minder pijn doen dan de vorige keer.

Helse pijnen, al twee weken. Je kan amper lopen en langer dan een half uurtje zitten kan je wel vergeten. De operatie is dan wel goed verlopen, maar je verdenkt je chirurg er wel van een roestend tweedehands plaatje met weerhaken te hebben bevestigd. De vrolijke tijden waarin je de zelfgeschreven imageviewer aan de swing applicatie toevoegde lijken ver weg. Ah ja, die imageviewer die je laatst nog op java.net hebt gezet en een heuse reactie kreeg van Fabrizio. Je glimlacht als je denkt aan je java.net gebruikersnam: cuswatesl, ze zouden eens moeten weten waar dat voor staat. Auw! Het glimlachen was overgegaan in een grinnik, maar daar je is lies toch nog echt niet aan toe. "Hoe zou het nu gaan op het werk?", vraag je je af, meteen gevolgd door vrolijk bellen van de deurbel. Mark, je baas staat daar, met een heus cadeau van al je collega's van ISAAC. En helemaal in ISAAC stijl is het geen bos bloemen, of een lullig fruitmandje, maar een heuse VLEESMAND. Kijk, daar knapt een jonge rockgod van op: worsten en varkenslappen. Fuck de pijn! Het leven is goed!

Korte Eclipse tip

Een korte Eclipse tip voor iedereen die vind dat zijn Eclipse te traag is. Start Eclipse op met de volgende parameters:

-vmargs -Xmx1024m -XX:MaxPermSize?=128m

Op deze manier maak je een gig beschikbaar aan geheugen en 128Mb aan PermSize (voor het laden van Classes)

Gratis Photoshoppen met Photoshop Express

Iedereen die 'iets met websites' of 'iets met internet' doet komt er op een gegeven moment niet onderuit een plaatje te moeten bewerken in Photoshop. Aangezien Photoshop voor dat af en toe een plaatje bewerken vrij duur is en illegale software natuurlijk illegaal is, is er nu een gratis en legale manier: Adobe Photoshop Express.

Maak gratis een account aan en je kunt gratis en online foto's bewerken en opslaan met 2GB aan eigen online opslagruimte.

Natuurlijk niet zo uitgebreid als Photoshop maar wel met de standaard benodigdheden als rode-ogenreductie, de kleurinstellingen en de mogelijkheid om foto’s bij te snijden en het formaat aan te passen.

Check Photoshop Express

Tail via Windows Powershell

De meeste programmeurs kennen wel het tail commando uit Linux, een ideaal programma om log files bij te houden. Windows kent geen tail commando, hoofdzakelijk omdat Windows maar een zeer beperkte command prompt kent. Er zijn welliswaar talloze programma's op de markt om de functionaliteit van tail na te bootsen in Windows, maar allen missen de eenvoud van het origineel. Tijd dus voor iets nieuws, tijd voor Windows PowerShell. Windows PowerShell is een uitgebreidere variant op de Windows command prompt, met mogelijkheden om niet alleen het filesysteem te benaderen, maar bijvoorbeeld ook het register en gebruikerssettings. Met een eigen bash-achtige scripttaal is het mogelijk om vrij complexe taken uit te voeren. Dus ook het volgen van een log-file. Met het volgende commando kun je een file "tailen":

Get-Content [filename] -Wait

Simpel, maar waarom zou je daar stoppen, met een klein beetje fantasie kun je al je log-files veel makkelijker leesbaar maken.

Vrijdagmiddag, Wii-middag

Flex: De volgende iteratie van het internet?

Hoera! Flex 3 is uit! Meteen downloaden en in een nieuw project gebruiken (youw8.com op het moment). Leuk leuk, betere debugging (vooral memory leaks heb ik ergens gelezen), nieuwe charts, werkt beter samen met Myeclipse 6, compileert naar kleinere swf files, i18n zonder verschillende swf's te hoeven compileren, etc etc. Jammer alleen dat we net voor 600 Euro Flex 2 charting hebben gekocht en nu weer 250 Euro (de upgrade) moeten betalen voor Flex 3 pro met charting. Booo!

Het begon natuurlijk allemaal met HTML en de verschrikkelijke FONT en CENTER tags "back in the day of Web 1.0". Toen Web 2.0 de kop opstak waren we nog steeds bezig met HTML (alleen stond er nu een X voor en hadden we CSS en een krachtigere versie van JavaScript erbij gekregen). De droom was om browseronafhankelijke webapplicaties te bouwen die de gebruiker in staat stelde om complexe taken uit te voeren in je browser (en overal contextgevoelige reclame in te verstoppen en op die manier rijk te worden). Al snel bleek dat we het wiel telkens opnieuw uitvonden en dat we wel erg veel tijd kwijt waren om-dat-ene-dingetje-ook-in-die-ene-versie-van-IE-te-laten-werken. Het aantal uren dat ik heb doorgebracht om dat ene uitlijning probleempje in FF of IE6 te fixen is denk ik niet iets waarmee ik graag wordt geconfronteerd. Dure uren voor isaac en voor de klanten. Ik schat dat in de projecten waarin ik heb gewerkt meer dan de helft van de uren op zijn gegaan aan het bouwen van de interfaces, waarvan weer minimaal een kwart is opgegaan aan het fixen CSS glitches. Enter the client side webframeworks. Wij hebben hier zelf vooral wat gespeeld met Dojo 0.4 en nu dus dojo 1.0. Hun dijit framework belooft ons een component gebaseerde interface die niet langer is gestoeld op de browser pagina ervaring (een van de beperkingen van de manier waarop het internet nu eenmaal werkt). Ik heb hier zelf maar beperkte ervaring mee, maar nadat ik Collin, een stagiare die ik toch wel tot een van de slimmer durf te rekenen, een applicaties heb laten (horen @#$%^) maken met dojo, ben ik van mening dat de HTML gebaseerde webframeworks zoals dojo en jquery toch echt HACKS blijven. HTML (ook DHTML met Javascript en CSS) is gewoon niet bedoeld voor het soort rijke ervaring die je graag zou creëren als je bouwt aan een echte webAPPLICATIE. Uiteraard zijn ze zeer geschikt om popups te maken en leuke effecten te wrappen of zelfs om een enkele "rijke" pagina mee te bouwen, maar volledige applicaties.. NAH. Ga zelf maar eens na: hoeveel webapplicaties zijn er die je echt het gevoel geven in een stabiele omgeving te werken (behalve gmail en google calendar). Webapplicaties waarbij je niet eerst even je getikte tekst in copy-paste naar notepad voordat je op de back knop klikt om even wat anders op te zoeken alvorens je verdergaat met je stuk. Ikzelf schrijf deze tekst nu niet in de blogger interface, maar in apple's teksteditor, omdat mijn ervaring is dat je wel eens helemaal opnieuw zou moeten kunnen gaan beginnen na je eerste 1000 woorden.

Werken met Flex is op veel fronten een verademing als je veel hebt gewerkt met XHTML/CSS. . De worst die Adobe ons voorhoudt met hun Flex platform is dan ook een vette. Browser onafhankelijk (zo goed als), mooiere interface bouwen in minder tijd, programmeren in een echte IDE (de eclipse plugin werkt lekker) met een strongly typed programmeertaal erachter, component gebaseerd en (en dit is voor iemand die alleen maar webapps heeft gebouwd even wennen) geen pagina gebaseerde interfaces meer. Desktop applicaties in een browser worden weer net even iets gemakkelijker. Eigenlijk min of meer gelijk aan de ervaring van het bouwen van old school desktop applicatie in een echte IDE.

En daarom vind ik het zo jammer dat mijn eerste ervaring met Flex me toch weer zo nu en dan terugwerpt in de bekende AAARGH modus. Flex 3 (en 2 voor zover ik die heb gebruikt eigenlijk ook), is simpelweg niet stabiel. De API's doen niet altijd wat ze beloven en je bent nog steeds veel tijd kwijt met het oplossen van die kleine irritante dingen die bijvoorbeeld ineens verdwijnen als je je commentaar verplaatst in de mxml source. Begrijp me niet verkeerd: Flex doet veel dingen erg goed, maar het behoeft nog zevenduizend manjaar aan schaafwerk.

Toch is het een stap vooruit: de dingen die moeilijk zijn in XHTML/JavaScript/CSS zijn doodeenvoudig in Flex, maar als vanzelf ga je verder en loop je toch al snel weer tegen de grenzen aan van de techniek van het moment. Ik vraag me af hoe silverlight en java fx het gaan doen... Leuk voor de volgende keer wellicht.

Binnenkort ondersteuning van Java op iPhone en iPod Touch

Normaal gesproken blijf ik weg van alles wat met Apple of iPod's te maken heeft, maar als Java programmeur kan ik niet anders dan hier een melding over maken. Sun is druk bezig met het maken van een virtual machine voor Apple's iPhone en iPod Touch. De virtual machine moet vergelijkbaar zijn met Java ME, maar Sun sluit niet uit dat laterna meer mogelijkheden worden toegevoegd.

Sun is begonnen aan de virtual machine dankzij het vrijgeven van de SDK van de iPhone en iPod Touch door Apple eerder deze maand.

De nieuwe milieuactivist

Als je iemand vraagt hoe volgens hem de gemiddelde milieuactivist eruit ziet, dan zullen een aantal woorden geheid vallen. Woorden als "Batik", "Geitenwollensok", "Sandalen" en "Baardaap", bijvoorbeeld. Een vooroordeel over een bepaalde minderheid in deze samenleving die in stand wordt gehouden door de eigenaren van natuurwinkels en beoefenaars van Reiki en andere zweverige hobbies. Het is tijd om deze vooroordelen in twijfel te trekken en eens kijken hoe de milieuactivist van de 21ste eeuw er echt uit ziet. Het is namelijk mijn mening dat, misschien wel geheel ongewild, een andere groep mensen tegenwoordig als "milieuactivisten" beschouwd kunnen worden. Dankzij een aantal ontwikkelingen van de afgelopen paar jaar is het concept "global warming" door de wereldbevolking geaccepteerd en wil iedereen een steentje bijdragen. Bedrijven springen hier handig op in en proberen op allerlei manieren de wereld te tonen hoe groen ze zijn. Twee belangrijke pijlers hierin zijn de co2 compensatie programma's en de papiervervangers (zoals, bijvoorbeeld, online rekeningoverzichten). In beide categorieën speelt één groep mensen een belangrijke rol, de IT-ers. Onmisbaar omdat juist deze mensen voor dit soort programma's kan zorgen. Ook binnen ISAAC is deze trend zichtbaar, sites met online documenten die eerder in papieren vorm naar de klant gingen, online rekeningoverzichten en co2 compensatie programma's maken steeds vaker onderdeel uit van de te ontwikkelen software. Maar zijn al deze programma's ook wel zo milieuvriendelijk als ze pretenderen te zijn?

In de jaren zeventig werd de term "the paperless office" voor het eerst uitgesproken. Gedacht werd dat bedrijven steeds minder papier gingen gebruiken en steeds meer digitaal zou gaan doen. Het uiteindelijke doel was om een geheel papierloos kantoor te hebben. Dit zou niet alleen geld besparen, maar ook goed zijn voor de productiviteit en natuurlijk het milieu. Minder papier betekend immers dat er minder hout gekapt hoeft te worden, waardoor er meer bomen zijn om co2 uit de lucht te halen. Geheel papierloos zal een kantoor natuurlijk nooit worden, veel mensen vinden het niet prettig om vanaf een beeldscherm te lezen en ook regelgevingen gooien roet in het eten. Toch zijn er een heleboel zaken digitaal geworden en is onze behoefte naar papier afgenomen. Veel van de software die bij ISAAC wordt gemaakt bevat onderdelen die papieren documenten dienen te vervangen en draagt zo bij aan het minder afhankelijk worden van papier. Dit brengt echter één nadeel met zich mee. Door minder afhankelijk te zijn van papier, zijn we juist weer meer afhankelijk van energie. Energie die onze server vierentwintig uur per dag online moet houden, energie die de computer van de klant moet laten draaien en energie die gebruikt wordt bij het vervaardigen van al deze programma's. Energie die in Nederland nog steeds voornamelijk van aardgas en aardolie afkomstig is. Het zal nog vele jaren duren voordat vernieuwbare energie voor het grootste aandeel zal zorgen en tot die tijd zal het vervangen van papier slechts gedeeltelijk een milieuvoordeel opleveren (in de vorm van minder houtkap en dus meer bomen).

Co2 compensatie is nog vrij nieuw, maar groeit enorm. Het is tegenwoordig mogelijk om veel meer dan alleen je vliegreis co2 neutraal te maken. Een eenvoudig idee, waarbij een aantal bomen geplant worden die de hoeveelheid co2 die jij ergens bij verbruikt hebt op kunnen nemen. Dit om een natuurlijk balans in stand te houden tussen de hoeveelheid co2 die wordt uitgestoten en de hoeveelheid co2 die door de natuur weer wordt opgenomen. Ook co2 compensatie is terug te vinden in steeds meer producten van ISAAC en het ziet er naar uit dat het een steeds grotere rol gaat spelen binnen de software die we maken.

We mogen dus stellen dat wij software ontwikkelaars de nieuwe milieuactivisten zijn, of we dit nou willen of niet.


Op de afbeelding is één van de redenen te zien dat men zich zorgen maakt over ons klimaat. De linker afbeelding is een gletsjer in de jaren zeventig, de middelste afbeelding is diezelfde gletsjer in de jaren negentig en de rechter afbeelding toont de gletsjer zoals deze er nu bijligt.