Java Frameworks. Enterprise Integration. Java EE in de cloud bij... Een gegeven paard of paard van Troje? met Camel en ActiveMQ. Microsoft?!

Transcriptie

1 DUKE. Java Frameworks Een gegeven paard of paard van Troje? Enterprise Integration met Camel en ActiveMQ Java EE in de cloud bij... Microsoft?!

2 DUKE? Voor je ligt de eenmalige uitgave van DUKE, een magazine voor de Java professional en alle andere mensen die interesse hebben in Java technologie. DUKE is het eindresutaat van het afstudeerproject van Meike Tilman (student Bedrijfscommunicatie aan de Hogeschool Utrecht) in opdracht van Sogeti Nederland BV. Waarom de naam DUKE? Naast het feit dat de Duke dé mascotte van Java is, staat het woord ook voor leider. Aangezien Java momenteel één van de meest toonaangevende ontwikkelplatformen is, past het dus uitstekend om de mascotte van Java zijn eigen magazine te geven. Een enthousiast redactieteam heeft nauw samengewerkt met de Java community van Sogeti om DUKE te kunnen realiseren. Het doel was met DUKE een magazine te maken met inhoudelijk aantrekkelijke artikelen over het Java vakgebied, vormgegeven in een aansprekende opmaak. DUKE is verspreid onder alle leden van de NLJUG en andere geïnteresseerden. Met de gehele redactie hopen wij jou met dit magazine te prikkelen met interessante vakinhoudelijke artikelen en opinie-stukken over Java technologie. Mocht je op de hoogte willen blijven de Java community binnen Sogeti, volg ons dan op Twitter Ik wens je veel leesplezier toe! Roy Wasse Sogeti is Business Partner van de NLJUG 2

3 In DUKE 6 Java Van de voorpagina... Frameworks Een gegeven paard of het paard van Troje? Enterprise Integration met Apache Camel en ActiveMQ Twee open source frameworks die elkaar aanvullen op het gebied van Enterprise Integration. Hoe snel kun je ermee aan de slag? Jouw Java EE Applicatie in de cloud bij... Microsoft?! Veel verschillende plaatsen waar je een Java applicatie kan hosten. Zo gemakkelijk kan het bij Microsoft Windows Azure platform. Volkert de Buisonjé Eric Gunnewegh Patriek van Dorp 4Think double about Singleton Uniek. Tot op zekere hoogte. 9Jelastic: de Java platform as-a-service oplossing Cloud oplossing voor Java met Jelastic. Alweer een community? Verder... Zoveel communities met allemaal een eigen specialisatie. Wat maakt de community zo speciaal? Certiferen? Waarom zou ik? Waarom zijn certificeringen belangrijk en wat kan certificering voor jou als Java professional betekenen? Meer weten? Alle bronvermeldingen en links voor extra informatie zijn hier terug te vinden. Hugo Groeneveld Jeroen Kops Roy Wasse Willem van de Griendt 3

4 Think double about double Voor het ontwikkelen van software bestaan diverse design patterns (sjablonen) die voor veel voorkomende problemen een herbruikbare oplossing bieden. Het idee hierachter is dat je snel bewezen technieken kunt toepassen, waardoor er meer tijd over blijft voor de belangrijke activiteiten van het ontwikkelen. Althans, dat is de theorie Af en toe toch nog eens kritisch naar de aangeboden oplossing kijken kan achteraf veel tijd besparen. Zeker als de implementatie omgeving complexer wordt, zoals ik in dit artikel ga laten zien. Singleton Hugo Groeneveld Dit ga ik doen aan de hand van het Singleton design pattern. Dit is een design pattern dat ervoor zorgt dat er slechts één instantie van een bepaald object bestaat. Dit kan wenselijk zijn wanneer het aanmaken van het object relatief duur is of wanneer een bepaalde resource centraal beheerd moet worden. Dit kan je forceren in Java op diverse manieren, maar de meest gangbare manieren zijn als volgt: Klassieke manier: public final class Singleton { private static class SingletonLoader{ private static final Singleton INSTANCE = new Singleton (); } private Singleton() { if (SingletonLoader.INSTANCE!= null) { throw new IllegalStateException( Already instantiated ); } } public static Singleton getinstance() { return SingletonLoader.INSTANCE; } } IETS KORTER SINDS JAVA 5: public enum Java5Singleton { INSTANCE; } MET DE KOMST VAN EJB Er is veel kritiek te vinden op het pattern op sites zoals stackoverflow.com, en het klassieke Singleton pattern is door velen al herdoopt als anti-pattern. Dit ondanks dat de enum Singleton wordt aangedragen door onder andere Josh Bloch in zijn Effective Java Reloaded talk bij Google I/O In veel andere gevallen is er kritiek op de naam, alsmede het idee achter de Singleton dat zou garanderen dat er slechts een unieke instantie bestaat. Verder is er een kleine waslijst aan redenen waarom het toepassen van het Singleton pattern niet optimaal is (zie kader 1). Serialiseren en de-serialiseren van de instantie kloont het object alsnog (enum type Singleton voorkomt dit, de klassieke manier vergt creatieve oplossingen). Singleton implementatie (kort door de bocht global state ) zorgt nagenoeg altijd voor high coupling binnen de code. In no time staat er in iedere klasse Singleton. getinstance(). Het is moeilijker testen/mocken met een Singleton in een applicatie, indien deze afhankelijkheden verbergt. Een Singleton zou niet thread safe zijn.* Geen lazy loading ondersteunen.* Zou eventueel gekloond kunnen worden als de Singleton een clonable klasse extend.* *Oplossingen beschikbaar Kader 1: Voorbeelden van mogelijke security issues Als laatste wordt op diverse sites aangevoerd dat zelfs wanneer je de meeste eigenschappen zou verbeteren, er nog steeds slimme programmeurs zijn die jouw Singleton om zeep kunnen helpen door middel van reflectie. Dus waarom zou je dit pattern überhaupt nog gebruiken? Feit is namelijk dat het pattern voornamelijk is afgevallen door het excessieve en invalide gebruik. Het pattern wordt nog steeds succesvol toegepast in veel frameworks zoals log4j, maar ook in de Java core zelf zoals in java.lang.runtime. Tijdens een portal project werd een goede implementatie voor dit pattern opgemerkt. Het Singleton pattern leek erg geschikt om diverse gegevens uit de database te cachen. Deze gegevens zijn statisch van aard en de verwachting bestond dat deze hooguit eens per jaar geüpdatet zouden worden. Hierbij zou de applicatie een herstart krijgen, zodat de gegevens automatisch ook opnieuw geladen zouden worden. Voor deze use case zou een stateless Singleton perfect voldoen, zeker als je met team en beheer afspreekt dat je niet middels reflectie (eventuele gekloonde) Singletons gaat hacken. Dus, was dit inderdaad één van de, volgens sommige, zeldzame gevallen waar een Singleton goed gebruikt kon worden? Toch niet! Of althans, niet helemaal. 4

5 Het eerder beschreven scenario is inderdaad geschikt voor Singleton, maar dan moet de Singleton wel stateless blijven. En wat bleek: vlak nadat we begonnen waren met bouwen, besloot de opdrachtgever dat het toch handig zou zijn om deze gegevens te updaten nadat iemand in een portlet op een knop zou drukken. Dus: een statefull Singleton. Dit zou misschien nog geen onoverkomelijk probleem zijn als het uiteindelijk niet in een cluster (meerdere JVM s) gedeployed zou worden, waardoor een druk op de knop welliswaar een instance zou updaten, maar de andere ongemoeid zou laten. Aardig detail hierbij is dat de Singleton EJB volgens de JSR 318 specificatie ook geen garanties biedt bij een geclusterde omgeving. Er is gekozen voor een middenweg, gebaseerd op de laatste oplossing. Dit betekent dat de Singleton naast de laatste update tijd ook een update counter bijhoudt die tevens in de database staat. Zodra er een update plaats vindt, wordt deze counter met één opgehoogd. Zodra de Singleton vaststelt dat zijn venster verlopen is, haalt hij alleen deze counter op en vergelijkt deze met zijn eigen waarde. Pas bij een verschil zal hij alle andere gegevens gaan updaten. Een kanttekening: dit kan alleen als de klassieke implementatie wijze van Singleton gehanteerd wordt, omdat de update logica in de getinstance() wordt afgevangen. Dus, dan maar de Singleton verwijderen uit het project vanwege deze nieuwe requirement? Dat is inderdaad één van de, zij het niet zo aantrekkelijke, mogelijkheden. Afhankelijk van de requirements en de implementatie omgeving zijn er namelijk meerdere opties. 1De Singleton behouden, maar deze alleen gebruiken als proxy naar de cache provider van de EE container. Een aantal containers bieden ondersteuning voor een geclusterde cache zoals de DistributedMap in Websphere Application Server. 2 Memcached1, Terracota 2 of JBoss Infinispan 3 kunnen ook uitkomst bieden, maar deze vergen relatief veel tijd om op te zetten als dit niet meegenomen is tijdens de implementatie van het cluster - zoals in ons geval. Hoewel de bovenstaande oplossingen qua schaalbaarheid uitkomst bieden voor het beschreven probleem, zorgt het voor extra complexiteit in het project. In het huidige voorbeeld resulteert dit in een slechts jaarlijks mogelijke update. Wat zijn hiervoor de oplossingen? 1Gebruik maken van message driven beans of een andere JMS implementatie met een publish-subscribe model. Iedere node zou zich kunnen registreren voor een mogelijke update en in de onmessage() de Singleton kunnen updaten. Zolang alle nodes up zijn en naar behoren werken, is dit een prima oplossing. Echter, zodra er één opnieuw gestart wordt, zal deze weer (mogelijk nieuwere) gegevens inlezen en een discrepantie in het systeem kunnen veroorzaken. Het laatste geval daargelaten, draagt ook deze oplossing niet bij aan schonere of beter leesbare code. 2De Singleton behouden en per tijdsinterval laten updaten. In dit geval maakt het niet uit dat de Singleton geen absolute Singleton is, maar het reduceert het aantal database calls aanzienlijk. De Singleton houdt zijn laatste update tijd bij en update zichzelf indien de tijd verstreken is. Het nadeel bij deze oplossing is dat de gekozen tijdspanne een discrepantievenster wordt, waarin het mogelijk is dat omgevingen verschillende gegevens hanteren. In feite, hoewel significant kleiner, bestaat dit venster ook bij de eerste twee oplossingen. Dit is zeker het geval als deze resultaten eerst ter bewerking worden aangeboden aan de gebruikers (in iedere hoedanigheid) voor ze verwerkt worden. Het venster zou dus idealiter zo klein mogelijk gehouden moeten worden, maar daarmee neemt het aantal database calls weer dramatisch toe. Er zijn altijd nog slimme programmeurs die jouw Singleton om zeep kunnen helpen. Deze oplossing werkt in dit geval inderdaad. Maar let op, dit artikel is in geen geval bedoeld om deze methode te promoten. In plaats daarvan wilde ik nogmaals onderstrepen wat anderen al jaren roepen op sites als stackoverflow.com: Zorg dat je er absoluut zeker van bent dat je requirements een Singleton pattern toestaan, bekijk wat de impact is als dit later toch moet worden veranderd en begin als laatste alvast naar deze oplossing te kijken! Misusing an anti-pattern might seem like a double negative, however not feeling bad doesn t equal feeling good when it comes to Java. Hugo Groeneveld (31) Senior Software Engineer Sogeti Nederland B.V. Favoriete Framework: Java-EE 5/6 & JQuery Meer informatie hierover is te vinden op pagina 25

6 Java frameworks: een gegeven paard, of het paard van Troje? Volkert de Buisonjé In een veelgebruikte programmeertaal hoef je het wiel nooit opnieuw uit te vinden. Geen functionaliteit zo gek, of er bestaat wel een framework voor. Logisch natuurlijk, want als je alle componenten van een gemiddelde Java Enterprise applicatie zelf regel voor regel zou moeten programmeren, zou dat niet alleen een veelvoud aan tijd kosten om een product op te leveren, maar ook ongetwijfeld veel meer bugs met zich mee brengen. Dat is nou eenmaal een feit met nieuwe code: het is nog niet blootgesteld aan dezelfde hoeveelheid tests en peer reviews als veelgebruikte en reeds bewezen software. Waar veel softwareontwikkelaars niet bij stilstaan is dat je bij een dergelijk framework veel meer functionaliteit cadeau krijgt dan je van plan bent om in je applicatie toe te passen. Het hele punt van frameworks is tenslotte dat het algemene bouwstenen zijn, niet toegespitst op specifieke projecten en bedoeld om zoveel mogelijk ontwikkelaars van nut te zijn. Je integreert dus veel ongebruikte code in je project en daarmee (per definitie) ook meer bugs, want: meer code betekent meer bugs. Je gaat er wellicht vanuit dat ongebruikte delen van software van derden geen invloed zouden mogen hebben op je code, maar daarmee doe je dan wel een aanname over het default gedrag van software die je zelf niet hebt geschreven. Je kunt uiteraard een beroep doen op de documentatie, maar ook die is niet altijd volledig of correct. En open source is mooi, maar meestal review je die code zelf niet. Het zal allemaal wel secure by default en proven zijn, toch? verleid om te denken dat alle security gerelateerde zaken automatisch voor hen worden opgelost. Het zal allemaal wel secure by default en proven zijn, toch? Reality Check Het blijkt helaas niet zo eenvoudig. Er zijn twee bekende voorbeelden van mogelijke security issues die zich kunnen voordoen, indien men het Spring MVC framework niet op een correcte en veilige manier toepast (zie kader 2). ModelView Injection : het vanuit de client side kunnen toevoegen van velden aan een web form in een request, die vervolgens automatisch aan de serverkant worden gemapped op het business-model. Data Submission to Non-Editable Fields : het vanuit de client side kunnen manipuleren van data die read-only zou moeten zijn. Het is aannemelijk dat de kwaliteit van een framework toeneemt naarmate het langer bestaat, het regelmatig doorontwikkeld en onderhouden wordt, en het door meer mensen wordt gebruikt. De kans dat fouten worden ontdekt neemt daarmee immers toe. Maar dit maakt het soms wel verleidelijk om er blindelings vanuit te gaan dat een populair framework foutloos zal zijn en zich altijd gedraagt zoals beschreven of verwacht. Het Spring MVC Framework is het voorbeeld van een zeer populair webontwikkelings-framework in de Java wereld. Het is zo populair, dat het (in elk geval door veel ontwikkelaars van webapplicaties) inmiddels bijna als standaard onderdeel van de Java taal wordt beschouwd. Veel ontwikkelaars passen het dan ook toe in projecten met een gevoel van vanzelfsprekendheid, zonder er ook maar bij stil te staan dat ze daarmee duizenden regels code aan hun projecten toevoegen, die door andere feilbare mensen zijn geschreven. Daarnaast wordt men dan ook Kader 2: Bekende kwetsbaarheden van Spring MVC Deze kwetsbaarheden zijn inmiddels jaren bekend en zijn niet slechts aan de frameworkzijde via een patch op te lossen. Ze zijn namelijk het gevolg van het feit dat veel architecten en software developers bij het ontwerpen en het ontwikkelen onvoldoende rekening houden met security. Het is dus onvermijdelijk dat ontwikkelteams die het Spring MVC framework wensen toe te passen in hun projecten, rekening dienen te houden met deze zwakheden bij de totstandkoming van hun applicaties. Uiteindelijk komt het er bij beide issues op neer dat de cliënt (de browserkant) nooit in staat gesteld mag worden om te bepalen welke data aan de serverkant wordt verwerkt en op welke manier. Is het Spring MVC framework dan nog wel bruikbaar? Natuurlijk, mits men het goed toepast. 6

7 Zo doet Ounce Labs, 4 het bedrijf dat deze zwakheden in het Spring MVC framework heeft geconstateerd, ontwikkelaars de volgende aanbevelingen om deze te mitigeren: Remember Never directly use data that a user can control, through hidden fields, cookies or direct form submissions to control the actual views that are rendered in the MVC pattern. Always use the setallowedfields method to limit the autobinding of all fields to only those fields that are required for the form. that validation is not just about protecting against SQL injection and XSS, but you need to validate all data that can be used to control a business process. Laten we deze adviezen eens nader beschouwen en toelichten. klikken. Dan geef je de gebruiker minder (onnodige) controle over de invoer. Denk er dus goed over na of er voor alle soorten input überhaupt een vrij invoerveld nodig is. Zo verklein je de zogeheten attack surface. Door echt alleen de specifieke tekens en de maximale lengte toe te staan die noodzakelijk zijn voor de soort invoer, reduceer je de kans op injectieaanvallen. Over injectieaanvallen gesproken, gebruik voor het uitvoeren van SQL queries altijd Prepared Statements. Deze voorkomen SQL Injections, leveren een aanzienlijke performancewinst op en zijn via JPQL eenvoudig te implementeren. Er is geen enkel excuus om dit niet te doen. Er is geen enkel excuus om geen gebruik te maken van Prepared Statements voor het uitvoeren van SQL queries. Het eerste advies is simpelweg het security principe never trust the cliënt. Het is belangrijk dat er aan de server-kant wordt gecontroleerd dat de gebruiker geen ongeoorloofde acties uitvoert, alvorens wat met de invoer te doen. Cliënt-side security bestaat niet. Het tweede advies is een ander algemeen security principe, namelijk het feit dat men altijd white-listing dient toe te passen in plaats van black-listing. Met andere woorden: begin met alle deuren dicht en zet vervolgens voorzichtig uitsluitend hetgeen open dat noodzakelijk is voor de functionaliteit die de gebruiker nodig heeft. Dit ligt weliswaar voor de hand, maar nog veel te vaak wordt juist met een open systeem begonnen, dat men vervolgens geleidelijk dichttimmert. Als gevolg daarvan vergeet men dan altijd wel ergens een openstaande raam of deur. Altijd white-listen dus, in alle facetten van de te ontwikkelen applicatie. Bij sommige soorten invoer is het bepalen van een geldig formaat nog complexer. Een voorbeeld daarvan is het valideren van adressen. Vaak zijn daarbij reguliere expressies nodig. Deze zijn een taal op zich. Het loont voor een ontwikkelaar zeker de moeite om zich die taal eigen te maken. Vergeet echter niet dat de complexiteit van reguliere expressies het noodzakelijk maakt dat daar ook aparte (unit) tests voor worden geschreven. Een fout in een reguliere expressie is immers op het oog niet snel op te merken. Vergeet bij het testen van inputvalidatie niet om naast het toestaan van correcte invoer ook het weigeren van incorrecte invoer expliciet te testen. Als derde advies noemt men inputvalidatie. Vertrouw niet zomaar wat je binnenkrijgt van de cliënt(s). Check altijd of het wel geldige input betreft en geen rare zaken die tot onvoorspelbaar gedrag (of toegang tot verboden gebieden in de applicatie of omgeving) kunnen leiden. Ook dit advies komt in feite weer neer op white-listen. Pas op de invoer van de gebruiker altijd contextspecifieke inputvalidatie toe. Twee voorbeelden worden hier genoemd (kader 3). 1Laat in een postcodeveld alleen invoer toe die bestaat uit precies vier cijfers gevolgd door twee letters, en niets anders. Sta in een datum- en/of tijdveld alleen invoereen correct 2 datum- en tijdformaat toe. Dit is wellicht iets ingewikkelder, omdat geldige datum- en tijdformaten uiteraard verschillen per regio. Laat ook hier uitsluitend tekens toe die nodig zijn voor dergelijke invoer. Dus cijfers, het scheidings teken tussen uren en minuten, eventueel de strings am en pm. Kader 3: Voorbeelden contextspecifieke inputvalidatie In het geval van het laatste voorbeeld is het zelfs beter om een gebruiker gewoonweg in een grafische kalender de datum te laten aan- 4 Meer informatie hierover is te vinden op pagina 25 7

8 Defense in depth Naast het valideren van input is het ook belangrijk om output (van de server naar de cliënt) contextspecifiek te coderen. Zo voorkom je dat de cliënt mogelijk schadelijke data ontvangt (bedoeld danwel onbedoeld). Door inputvalidatie en output-encoding te combineren pas je gelaagde bescherming ( defense in depth ) toe, hetgeen nog robuuster is. Voor contextspecifieke inputvalidatie en output-encoding in webapplicaties bestaan uiteraard ook frameworks. Een interessant framework dat contextspecifieke validatie- en encoding-implementaties biedt voor veel voorkomende datatypes (bijvoorbeeld datum/tijd, adressen, enzovoorts) is het ESAPI-framework van OWASP. Op ESAPI kom ik straks nog even terug. De zojuist beschreven adviezen, namelijk: nooit de cliënt vertrouwen, altijd white-listen, nooit black-listen, input altijd contextspecifiek valideren, Prepared Statements gebruiken en output altijd contextspecifiek coderen, hebben niet alleen betrekking op de specifiek genoemde zwakheden in Spring MVC. Dit zijn algemene best practices ten behoeve van applicatiebeveiliging. Voor mensen die denken dat ze alleen voorzichtig dienen te zijn met third party frameworks en dat ze altijd nog blind kunnen vertrouwen op de officiële Java API, noem ik nog één laatste, recent aangetoonde, kwetsbaarheid: het risico op hash collision attacks. Recentelijk is (niet alleen bij Java, maar bij de meeste op het web gebruikte talen) een zwakte aangetoond in de manier waarop hashes worden berekend van webrequests die cliënts naar een webserver sturen. Over de details van een dergelijke aanval is veel te vinden op het internet, maar kortgezegd is een denial of service aanval (het platleggen van een site) met slechts een enkele cliënt mogelijk, door een bepaalde request uit te voeren naar een server waarbij meerdere POST-parameters in People think of security as a noun, something you go buy. In reality, it s an abstract concept like happiness. Openness is unbelievably helpful to security. James Gosling identieke hashes resulteren. Als gevolg van dergelijke hash collisions binnen een enkel request moet een CPU opeens veel meer moeite doen om zo n request te verwerken. Het is zelfs zo erg dat op deze manier met een enkele cliënt en een bescheiden hoeveelheid bandbreedte al met gemak een hele webserver plat te krijgen is. Oracle heeft besloten om het hashing algoritme dat gebruikt wordt in de String-implementatie van hun Java implementatie niet te vervangen en kiest ervoor om het probleem in de middlewarelaag op te vangen, met patches in WebLogic en Glassfish. Nieuwere versies van Tomcat zijn inmiddels ook voorzien van een fix voor ditzelfde probleem. Maar let er wel op dat de kwetsbaarheid aanwezig blijft in de Java taal (alles wat String.hashCode() gebruikt, waaronder HashMap en hashtables). De voorspelbare Math.random() implementatie in Java dient ook te worden vermeden. Overweeg dus om hiervoor veiligere alternatieven te gebruiken, bijvoorbeeld ESAPI of Apache Commons. Geen angst, maar bewustwording Je zult inmiddels wel denken: is er dan niets veilig? Hoe kan ik dan toch een veilig en robuust product bouwen als ik nergens op kan vertrouwen? Geen paniek. Mijn doel is niet om ontwikkelaars bang te maken. Mijn boodschap is: doe geen aannames. Houd rekening met het feit dat er ook fouten kunnen zitten in de bouwstenen waarmee je jouw product bouwt, en neem je kennis van het risico mee in alle stappen van de ontwikkeling van je applicatie of systeem. Als je een upgrade van een library of framework uitvoert op je applicatie, voer dan al je handmatige en geautomatiseerde tests altijd opnieuw uit, net alsof je een wijziging aan je eigen code hebt aangebracht. Doe geen aannames over wijzigingen of behoud van eerder gedrag. Als een framework het toestaat om bepaalde componenten los te gebruiken, onderdruk dan je instinct (dat wil pakken wat het pakken kan) en integreer uitsluitend datgene wat je daadwerkelijk nodig hebt. Hoe minder code, hoe minder bugs. Zo simpel is het. Ga er vooral niet van uit dat een framework je automatisch zal beschermen tegen alle security issues. Wat jij als onveilig of onverwacht gedrag beschouwt, is niet per se een bug, of juist wel wenselijk gedrag voor anderen. Omgekeerd geldt hetzelfde. Security dient bovendien meegenomen te worden in alle facetten van de Software Development Lifecycle, van concept tot uitrol en alle stappen daartussen. Hoewel de Secure Development Lifecycle genoeg stof biedt voor een apart artikel, noem ik dit toch maar even. Ik noem ook nog even het eerder genoemde ESAPI-project. ESAPI biedt, zoals gezegd, direct bruikbare en kwalitatief goede implementaties voor input-validatie en output-encoding. Ook bevat het een zeer goede en veilige random number generator die zelfs beter is dan SecureRandom. Daarnaast heeft ESAPI nog veel meer nuttige features voor het beveiligen van webapplicaties. 5 Tenslotte wijs ik de gebruiker graag op een recentelijk uitgekomen onderzoeksrapport van Aspect Security, die de 31 meest populaire Java Frameworks analyseert op zwakheden en daarbij een aantal belangrijke conclusies trekt. Het downloaden van dit nuttige rapport vereist echter wel een (gratis) online registratie. 6 Volkert de Buisonjé (34) Senior Java Developer en Security Sogeti Nederland B.V. Favoriete Framework: ESAPI & 5 6 Meer informatie hierover is te vinden op pagina 25

9 Jelastic: De Java platformas-a-service oplossing Jeroen Kops Jelastic is een Java Platform-as-a-Service (PaaS) oplossing die sinds 16 februari 2012 commercieel beschikbaar is. Hivext is het Amerikaanse bedrijf achter Jelastic. Jelastic is interessant voor bedrijven die hun Java applicatie willen hosten in de cloud. Het voordeel is dat Jelastic verschillende applicatieservertypes aanbiedt. Dit in tegenstelling tot de cloud oplossingen van bijvoorbeeld Oracle en JBoss die respectievelijk Weblogic en JBoss georiënteerd zijn. Ben je geïnteresseerd in Java cloudoplossingen dan geven onderstaande vragen en antwoorden je inzicht in wat Jelastic te bieden heeft. Hoe kan ik mijn omgeving beheren? Met de Jelastic Manager, de zeer complete web interface van Jelastic, kan je je omgeving beheren. Het kiezen van je type applicatieserver en database is erg gemakkelijk. Ook complexere taken zoals Hoeveel applicatieservers wil ik tot mijn beschikking hebben? en Wanneer moet er een applicatieserver worden bijgeschaald? zijn simpel te beheren. Indien je er toch niet uitkomt en hulp nodig hebt, kan via de support link een issue worden aangemaakt. Het support team van Jelastic zal deze vragen dan beantwoorden. Via een link vanuit de Jelastic Manager kan worden doorgelinkt naar de admin console van de gekozen applicatieserver. Het voordeel hiervan is dat je niet hoeft te wennen aan een andere interface, maar gebruik kan maken van de webinterface die je applicatieserver al biedt. Databases kunnen worden beheerd via de webinterfaces van phpmyadmin en phppostgesql, die ook via een link vanuit de Jelastic Manager te bereiken zijn. Binnen de Jelastic Manager kunnen de logfiles worden ingezien en configuratiebestanden worden aangepast. Tevens is het via de Jelastic Manager mogelijk om met de upload button bestanden te uploaden. Dit is bijvoorbeeld makkelijk voor het uploaden van een jar file voor de JDBC connectie. Welke applicatieservers, databases en Java versies worden door Jelastic aangeboden? Op dit moment worden JDK 6 en JDK 7 door Jelastic ondersteund. Daarnaast worden nu drie verschillende Java applicatieservers ondersteund: Tomcat, Jetty en Glassfish. Van Tomcat worden versie 6 en 7 aangeboden, van Jetty versie 6 en van Glassfish versie Jelastic is een van de weinige PaaS oplossingen die met Glassfish een Full Profile JEE6 applicatieserver biedt. Jelastic biedt zowel relationele databases als NoSQL databases. De relationele databases die op dit moment worden aangeboden zijn MySQL, phppgadmin en MariaDB. De NoSQL databases die worden aangeboden zijn MongoDB en CouchDB. NB: Op de Jelastic website wordt aangegeven dat JBoss in de toekomst ook zal worden ondersteund. Voor het bereiken van een nog groter publiek zou het voor Jelastic een toevoeging zijn om naast open source ook closed source applicatieservers en databases te ondersteunen zoals WebSphere, JBoss EAP, Oracle en MSSQLserver. dogado POWERED BY HOST EUROPE Jelastic Activate coupon Vote for Features? Help Switch on SSL + Name Create environment Status Deployed Usage Requests SSL ON Balancer jkops Java jkops.jelastic.dogado.eu GlassFish x2 Running roller javaee.war 4 14/ /32 RED - Run me Execu on Container 5 Horizontal scaling Replicated instance Deployment manager all MySQL 5.5 Nginx Duration jkops : glassfish : log 1 hour Interval 1 min Admin Panel panel jkops : glassfish : statistics CPU RAM Network HDD Auto refresh 1 1 1/0 1/1 JDK version Build node JDK 7 Tomcat 7 Maven MariaDB MongoDB Applica on servers type & version SQL Database NoSQL Database CPU, [Mhz] RAM, [MB] :20 08:30 08:40 08:50 09:00 08:20 08:30 08:40 08:50 09:00 Network, [MB] HDD, [MB] 0 08:20 08:30 08:40 08:50 09:00 08:20 08:30 08:40 08:50 09:00 Tasks Date Name 09:07 11 Apr 2012 Reading log from jkops Status Success Afbeelding 1: Jelastic manager - aanmaken omgeving Afbeelding 2: Jelastic manager - beheren omgeving 9

10 Een webapplicatie waarvoor je 1GB geheugen nodig hebt en 1.6 GHz CPU kost 8 Cloudlets. Stel, je wilt dat deze applicatie geloadbalanced wordt over twee servers, dan kost dit 16 Cloudlets. Als deze applicatie 24 uur per dag beschikbaar moet zijn, dan is de totaalprijs per jaar als volgt: 16(cloudlets) * 24 (uur) * 365 (dagen) * 0,016 (prijs per uur per Coudlet, Dogado) = 2.242,56 Euro. Voor dit bedrag is het niet meer nodig om zelf hardware aan te schaffen en te beheren. Je kunt je volledig richten op configuratie van de omgeving, het bouwen én beheren van de applicatie. With the cloud, individuals and small businesses can snap their fingers and instantly set up enterprise-class services. Roy Stephan (2011) (Director of IT Architecture and engineering - Intelligent Decisions) Jeroen Kops (34) Technologiespecialist Sogeti Nederland B.V. Favoriete Framework: Java EE Mijn bedrijf wil een cluster dat High Available is. Is dit mogelijk? Met een HA (High Availibility) knop in de Jelastic interface maak je van je cluster een High Availability cluster. Dit houdt in dat applicatieservers stand by meedraaien. Indien een active server crasht zal één van deze stand by servers actief worden. Daarbij wordt rekening gehouden met lopende sessies. Via een session failover wordt de sessie van de gecrashte server overgenomen door de geactiveerde stand by server. Wat kost het? De munteenheid van Jelastic wordt een Cloudlet genoemd. Een Cloudlet staat voor 200MHz CPU en 128MB RAM. Als je je Java omgeving aanmaakt in Jelastic kan je kiezen tussen twee hosting providers en de prijs van een Cloudlet verschilt per hosting provider. Kies je voor ServInt, dan betaal je 0.02$ Cloudlet per uur. Kies je voor Dogado, dan betaal je Euro per uur. Bij een applicatie update willen wij dat de downtime minimaal is. Biedt Jelastic hier ondersteuning voor? Zolang je geen database wijzigingen wilt doorvoeren is het mogelijk om je applicatie te updaten vrijwel zonder downtime. Dit kan door gebruik te maken van de clone en swap domains functies. Door eerst je omgeving te clonen en daarna de URL s te swappen, wordt een kopie gemaakt van je omgeving. Doordat je originele omgeving nog steeds actief is, maar draait onder een andere URL, kun je de applicatie updaten zonder dat dit de productie verstoort. Als de update goed is doorgevoerd, swap je vervolgens de URL s weer. Hierna staat de update in productie. Ik bouw mijn applicaties met Maven. Kan ik met Maven mijn applicaties deployen op mijn Jelastic omgeving? Ja, dit kan zelfs op twee manieren. De eerste manier is om je Subversion/CVS repository locatie op te geven binnen je Jelastic omgeving. Je kan je code dan laten builden en deployen door Jelastic. Het nadeel van deze oplossing is dat je inloggegevens van SVN of Subversion op de Jelastic server komen te staan. Vanuit security oogpunt is dit niet wenselijk. De tweede manier is om de Maven Jelastic plugin te gebruiken. Na het configureren van deze plugin in de pom.xml van je project, kan je door middel van een mvn jelastic:deploy de applicatie deployen op je Jelastic omgeving. Moet ik mijn bestaande applicatie aanpassen om op Jelastic te kunnen deployen? Nee, je bestaande applicatie hoef je niet aan te passen. Na het aanmaken van je environment kan je je applicatie deployen via de Jelastic Manager of via de admin console van de gekozen applicatie server. Vervolgens zal je alleen nog het één en ander moeten configureren, zoals de JDBC connectie. Kan ik dit zelf ook uitproberen? Ga naar en maak daar je eigen account aan. Daar kan je zelf met de Jelastic Manager je eigen omgeving aanmaken en je eerste Java applicatie in de cloud deployen. Verder kan je Jelastic nieuws volgen op Twitter 7 en op Facebook

11 Wie nu niet denkt in oplossingen, lost straks vanzelf op. Ga verder met ICT van Sogeti. Voor wie tijdens de crisis wil investeren in plaats van stagneren, is Sogeti de ideale partner. Want Sogeti is niet zuinig met ICT-oplossingen. Wij ontwerpen, bouwen, implementeren en beheren. En lopen voorop op het gebied van testen en architectuur. Opdrachtgevers in alle sectoren helpen wij verder met toepassingen van morgen. Vakmanschap en passie voor ICT, dat maakt ons uniek. sogeti.nl Staat voor resultaat

12 Enterprise Integration met Apache Camel en ActiveMQ Eric Gunnewegh Software systemen en applicaties staan zelden op zichzelf en communiceren vrijwel altijd met andere systemen en applicaties. Vaak bestaan in een enterprise tientallen applicaties die informatie met elkaar uitwisselen. Het is eerder regel dan uitzondering dat deze applicaties communiceren via verschillende protocollen (jms, file, http, etcetera). Ook kunnen ze via verschillende berichtformaten (zoals xml en csv) communiceren, zodat de integratie van deze applicaties al snel complex wordt. In dit artikel zal ik proberen te laten zien hoe deze complexiteit verminderd kan worden door het toepassen van Enterprise Integration Patterns (EIP s). Vervolgens kijken we aan de hand van een voorbeeld hoe Camel toegepast kan worden bij de implementatie van EIP s. Ook ActiveMQ wordt hierbij behandeld; een open source JMS provider die goed in combinatie met Camel gebruikt kan worden. Hoewel integratieproblemen in verschillende enterprises divers kunnen zijn, zijn de (deel)oplossingen vaak hetzelfde. In de vorm van EIP s kunnen software architecten en ontwikkelaars gebruik maken van oplossingen die zich in de praktijk bewezen hebben. Patterns beschrijven (deel)oplossingen onafhankelijk van de uiteindelijk gekozen technische implementatie. Dit maakt de EIP s uitermate geschikt om integratieoplossingen mee te beschrijven, omdat zij ook begrepen worden door betrokkenen die niet de kennis hebben van een bepaald integratieframework. Laat ik als voorbeeld een Content Based Router nemen. Een veel voorkomend probleem in systeemintegratie is dat een bericht op basis van de inhoud naar een bepaalde bestemming gerouteerd Content Based Router moet worden. De EIP s zeggen dat je hiervoor een Content Based Router moet nemen. Zo zijn er tientallen patterns, ingedeeld in diverse categorieën, zoals: routering, berichttransformaties en endpoints. Door een integratieprobleem op te delen in deelproblemen en hiervoor de juiste patterns te kiezen, kom je uiteindelijk tot een combinatie van patterns die de oplossing voor het gehele probleem vormen. De volgende stap is dat de patterns geïmplementeerd worden in een bepaalde technologie. Zoals gezegd, de EIP s schrijven geen bepaalde technologie voor. De ontwikkelaar die hiermee aan de slag gaat heeft de keuze uit diverse frameworks, zoals: Mule, Camel, Spring Integration of JBoss ESB. Elk van deze frameworks implementeren de meest gebruikte EIP s. De Java ontwikkelaar die de juiste kennis heeft van deze EIP s zal ervaren dat hij snel aan de slag kan met deze frameworks. Apache ActiveMQ Tot zover de theorie. Ik zal nu aangeven hoe Camel praktisch toegepast kan worden bij het implementeren van EIP s. Hiervoor wordt eerst ActiveMQ behandeld, dat in de praktijk vaak in combinatie met Camel gebruikt wordt. Behalve dat ActiveMQ een JMS provider is, kan het namelijk ook gebruikt worden als een container voor Camel EIP s. Om een beeld te krijgen van de mogelijkheden van ActiveMQ zullen eerst de installatie en verschillende configuratiemogelijkheden van ActiveMQ worden weergegeven en besproken. De installatie van ActiveMQ is simpel en snel. Na het downloaden en uitpakken van apache-activemq-<versienummer>.zip file heb je een default installatie waar je meteen mee aan de slag kunt. ActiveMQ wordt opgestart met bin/activemq.bat, waarna de administration console beschikbaar is op Hier kun je onder andere: queues, topics en messages bekijken. Door een integratieprobleem op te delen in deelproblemen en hiervoor de java patterns te kiezen, kom je tot een combinatie van patterns die de oplossing voor het gehele probleem vormen. In de praktijk zul je de ActiveMQ installatie naar eigen behoefte willen configureren. De default configuratie is vooral in verband met security niet geschikt voor een productieomgeving. ActiveMQ wordt geconfigureerd in de conf/activemq.xml file. Het is onmogelijk om hier alle configuratiemogelijkheden te behandelen, maar een aantal wil ik hier toch noemen. 12

13 Message Persistency 1 Standaard worden ActiveMQ berichten opgeslagen in de KahaDB message store op het filesysteem in de data/kahadb directory. De KahaDB message store is zo ontworpen dat de toegang tot de message store zeer snel is. ActiveMQ biedt ook de mogelijkheid om de berichten op te slaan in een JDBC message store, waarbij uit diverse databases gekozen kan worden. <bean id= oracle-ds class= org.apache.commons.dbcp.basicdatasource destroy-method= close > <property name= driverclassname value= oracle.jdbc.driver.oracledriver /> <property name= url value= jdbc:oracle:thin:@localhost:1521 /> <property name= username value= user /> <property name= password value= pwd /> </bean> <broker xmlns= > <persistenceadapter> <!-- The default file system storage <kahadb directory= ${activemq.base}/data/kahadb />--> <jdbcpersistenceadapter datasource= #oracle-ds /> </persistenceadapter> </broker> 2 Transport Connectors Transport connectors bepalen hoe ActiveMQ cliënts verbonden kunnen worden met ActiveMQ. In de default installatie is een niet-encrypted Openwire connector geconfigureerd. In de praktijk is een encrypted ssl connector echter te prefereren, eventueel inclusief cliënt-authenticatie. Een andere interessante connector is de Stomp (Streaming Text Orientated Messaging Protocol) connector. Deze connector is vooral geschikt voor niet-java cliënts, zoals: PHP, Ruby of Python. <sslcontext> <sslcontext keystore= file:${activemq.base}/conf/broker.ks keystorepassword= password truststore= file:${activemq.base}/conf/broker.ts truststorepassword= password /> </sslcontext> <transportconnectors> <transportconnector name= openwire uri= tcp:// :61616 /> <transportconnector name= ssl uri= ssl://localhost:61617?needclientauth=true /> <transportconnector name= stomp uri= stomp:// :61612?transport.closeasync=false /> </transportconnectors> 3 Monitoring en management ActiveMQ beschikt over een behoorlijk uitgebreide management API die benaderbaar is via JMX. Dit is handig voor bijvoorbeeld een ontwikkel- of testomgeving, maar voor een productieomgeving zou je dit toch enigszins willen afschermen. Standaard staat JMX support aan in ActiveMQ voor local access, maar uit voor remote access. Dit houdt in dat je de JMX management API alleen kunt benaderen op de machine waar ActiveMQ geïnstalleerd is. JMX support kan ook uitgezet worden voor local access, maar dat betekent ook dat de administration console niet meer gebruikt kan worden, omdat deze hiervan gebruik maakt. <broker xmlns= usejmx= true > <managementcontext <managementcontext createconnector= false /> </managementcontext> </broker> 13

14 4 Administration console Bij de default ActiveMQ installatie is de administration console niet beveiligd door middel van authenticatie of encryptie. Met twee kleine ingrepen in de conf/jetty.xml file kan hier snel wat aan gedaan worden. De basic authenticatie kan aangezet worden en de simpleconnector kan vervangen worden door een sslconnector. <bean id= securityconstraint class= org.eclipse.jetty.http.security.constraint > <property name= name value= BASIC /> <property name= roles value= admin /> <property name= authenticate value= true /> </bean> <bean id= sslconnector class= org.eclipse.jetty.server.ssl.sslselectchannelconnector > <property name= port value= 8443 /> <property name= keystore value= ${activemq.home}/conf/broker.ks /> <property name= keypassword value= password /> <property name= truststore value= ${activemq.home}/conf/broker.ts /> <property name= trustpassword value= password /> </bean> jms:orders Splitter Filter file:data/orders <?xml version= 1.0 encoding= UTF-8?> <orders> <order name= chair amount= 3 status= validated /> <order name= table amount= 1 status= validated /> <order name= book amount= 4 status= canceled /> </order> <order name= chair amount= 3 status= validated /> <order name= table amount= 1 status= validated /> Kader 4: Route met behulp van EIP s die van toepassing zijn Kortom, ActiveMQ is een veelzijdige JMS provider die relatief eenvoudig geïnstalleerd en geconfigureerd kan worden. Straks zullen we zien hoe ActiveMQ kan dienen als een EIP server voor Camel. Daartoe gaan we eerst naar een voorbeeld kijken dat illustreert hoe Camel een rol kan spelen in systeemintegratie. Apache Camel Hoe divers systeemintegratie ook kan zijn, het komt er in feite altijd op neer dat het ene systeem gegevens (berichten) produceert dat een ander systeem nodig heeft. De route die de berichten volgen van het ene systeem naar het andere is precies datgene wat Camel regelt. Routes zijn dan ook een belangrijk begrip in Camel, evenals de Endpoints die het begin of het einde van een Route representeren. Tussen de Endpoints kan nog veel gebeuren met de berichten, zoals: filtering, splitting, aggregation en enrichment, om systemen op elkaar te laten aansluiten. Ook dat zijn aspecten waarvoor Camel oplossingen biedt in de vorm van de EIP s die het implementeert. Als ontwikkelaar heb je de keus uit diverse DSL s om Routes te beschrijven. In het voorbeeld dat volgt beperk ik mij tot Java en Spring XML. Als voorbeeld nemen we een systeem dat berichten produceert die per bericht meerdere orders bevat. De orders kunnen gevalideerd In de praktijk zal je de Active MQ installatie naar eigen behoefte willen configureren. De default configuratie is vooral in verband met security niet geschikt voor een productieomgeving. zijn of gecanceled. Het ontvangende systeem kan alleen gevalideerde orders verwerken, in de vorm van één order per bericht. Het producerende systeem communiceert via JMS, terwijl het ontvangende systeem de berichten op een filesysteem verwacht. De taak van Camel is dus om de berichten van de JMS queue af te halen, die vervolgens te splitsen, waarna de gecancelde orders hieruit gefilterd worden. De overgebleven orders worden weggeschreven op het filesysteem. In kader 4 is deze Route weergegeven met behulp van de EIP s die van toepassing zijn. 14

15 ActiveMQ als Camel Integration Pattern Server Met ActiveMQ als JMS provider voor het orders producerende systeem, kan eerder voorbeeld met behulp van Camel gerealiseerd worden door de Route in Spring XML te configureren en te laten opnemen in de ActiveMQ configuratie. De Camel configuratie ziet er als volgt uit en wordt opgeslagen in de conf/camel.xml file (zie kader 5). In de Camel configuratie is te zien dat een Route wordt geconfigureerd binnen de Camel context. De Route begint bij de JMS queue (<from>) en eindigt bij het filesysteem (<to>). Dit zijn de Endpoints. Endpoints worden geconfigureerd met een Endpoint URI. Deze zien er in Camel als volgt uit: kan bijvoorbeeld ook gebruikt worden wanneer berichten weer geaggregeerd zouden moeten worden. Eerder voorbeeld met ActiveMQ en Camel laat goed zien dat je met slechts één configuratiefile al een groot gedeelte van de integratiefunctionaliteit kunt configureren. Ook toont het aan dat Camel eenvoudig geïntegreerd kan worden in ActiveMQ. De constatering dat er nog geen Java code aan te pas is gekomen, is illustrerend voor de krachtige manier waarop EIP s door Camel geïmplementeerd worden. scheme:context[?options] Met het scheme wordt aangegeven welke Camel Component benodigd is voor het Endpoint. Dit kan een default Component zijn of een verwijzing naar een Component die als bean geconfigureerd is, zoals hierboven met de ActiveMQ Component. Out-of-the-box levert Camel Components voor tientallen soorten Endpoints (FTP, CXF, HTTP, JPA, LDAP, Quartz, SMTP, enzovoorts). In de Camel configuratiefile is daarnaast ook een aantal voorbeelden te zien van de Simple Expression Language waarmee je in Camel met ${...} placeholders toegang hebt tot allerlei (built-in) functies en variabelen. Zo bevat ${body} de body van het Camel bericht en verwijst ${property.camelsplitindex} naar de CamelSplitIndex property variabele die door Camel gezet wordt na het splitsen van een bericht. In dit geval wordt deze gebruikt om er voor te zorgen dat de resulterende file namen een volgnummer krijgen, maar de CamelSplitIndex Tussen de Endpoints kan nog veel gebeuren met de berichten, zoals filtering, splitting, aggregation en enrichment, om systemen op elkaar te laten aansluiten. <camelcontext id= camel xmlns= > <route> <from uri= activemq:orders /> <split> <xpath>/orders/order</xpath> <log message= Processing ${body} /> <filter> <xpath>/order[not(@status= canceled )]</xpath> <to uri= file:data/orders?filename=msg-${date:now:yyyymmdd-hhmmss}- ${property.camelsplitindex}.xml /> </filter> </split> </route> </camelcontext> <bean id= activemq class= org.apache.activemq.camel.component.activemqcomponent > <property name= connectionfactory > <bean class= org.apache.activemq.activemqconnectionfactory > <property name= brokerurl value= vm://localhost?create=false&waitforstart=10000 /> </bean> </property> </bean> Deze file wordt met een standaard import in de activemq.xml opgenomen: <import resource= camel.xml /> Kader 5: Camel configuratie 15

16 Camel in Java DSL Tot nu toe hebben we al aardig wat van Camel gezien zonder één regel Java code. Uiteraard kan Camel ook los van ActiveMQ gebruikt worden, als stand-alone applicatie of gedeployed in een applicatieserver. Een Camel context kan geschreven worden in Spring XML, zoals hierboven, maar ook in Java. Zie hieronder een Java codevoorbeeld van de eerder beschreven Camel configuratie, waarbij ook de Camel context in Java gestart wordt (kader 6). Hoe klein dit voorbeeld ook is, dit is een complete Java applicatie met Camel. Het illustreert hoe weinig regels code nodig zijn om berichten van een JMS queue af te halen, te splitsen en te filteren om ze tenslotte weg te schrijven naar het filesysteem. Tot slot Apache Camel en Apache ActiveMQ zijn twee open source Java producten die uitstekend in combinatie met elkaar gebruikt kunnen worden bij het oplossen van integratieproblemen. De voorbeelden laten zien dat je met weinig code al snel veel functionaliteit kunt realiseren in Camel en geven een goed beeld van wat het werken met Camel inhoudt. Tegelijkertijd is er nog zo veel dat niet in dit korte stukje behandeld is. Denk hierbij bijvoorbeeld aan het configureren van ActiveMQ voor high availability, error en exception handling in Camel, de Camel JUnit extensies, transaction management, enzovoorts. Voor wie met ActiveMQ en Camel aan de slag gaat, zijn de boeken Camel in Action en ActiveMQ in Action zeer aan te raden. Deze boeken, die ruim een jaar geleden zijn uitgekomen, vormen een goede aanvulling op hetgeen er online aan informatie te vinden is. CamelContext context = new DefaultCamelContext(); context.addcomponent( activemq, ActiveMQComponent.activeMQComponent( tcp://localhost:61616 )); context.addroutes(new RouteBuilder() { public void configure() { from( activemq:orders ).split(xpath( //orders/order )).log( Processing ${body} ).filter().xpath( /order[not(@status= canceled )] ).to( file:data/orders?filename=msg-${date: now:yyyymmdd-hhmmss } + -${property.camelsplitindex}.xml ); } }); context.start(); Thread.sleep(10000); context.stop(); Kader 6: Java codevoorbeeld van de Camel Configuratie wie eenmaal een goed begrip heeft van EIP s en een framework zoals Camel, kan ook snel met Mule of spring Integration aan de slag. Eric Gunnewegh (43) Design & Software Sogeti Nederland B.V. Favoriete Framework: Apache Camel en Mule 16

17 Alweer een community? Communities. Ze zijn er in overvloed! Voor sporten, hobbies of fanclubs en ze kunnen online of offline zijn. Elke community heeft ook zijn eigen reden om te bestaan. Sogeti blijkt ook een Java community te hebben. Maar wat is een community precies? Het lijkt het om een groep mensen te gaan met dezelfde interesse. Waarom is deze community opgezet en waar wordt dit voor gebruikt? Roy vertelt over de ins en outs van de community. Wat een community kenmerkt? Het zelf onderhoudend vermogen. Er is geen management dat uitmaakt wie wat en wanneer vertelt. Mensen zoeken elkaar zelf op en organiseren op eigen initiatief activiteiten. Als zij hun werkgever daarbij kunnen gebruiken laten zij die aanhaken. Niet andersom., vertelt Roy, Unit Manager Java bij Sogeti. Communities kunnen verschillende achtergronden hebben, bijvoorbeeld liefhebbers van een bepaald spel, een specifiek merk, maar zeker ook een vakgebied. Dit geldt ook voor de Java community van Sogeti! De Java community is een gezelschap van professionals die bezig zijn met hun vakgebied. Zij hebben een stukje bezieling en streven ernaar om uit te blinken in hun vakgebied. Ze zijn geïnteresseerd in nieuwe technologieën en frameworks die voorbij komen. Hun kennis willen zij graag met elkaar delen. Privé en zakelijk blenden Gedreven Java professionals zijn dus de kracht achter de community. Maar hoe krijgen zij dit voor elkaar? Valt dit onder formele werktijd of is alle inspanning puur hobby? Roy vertelt dat hier geen duidelijke scheiding in is. Privé en zakelijk zijn lichtelijk geblend. Dit geldt voor de één net iets meer dan de ander, maar een heleboel professionals vinden hun vakgebied dusdanig interessant dat ze s avonds ook gewoon even wat willen uitproberen. Het klinkt alsof de professionals volledig in de ban van hun werk zijn. Maar.. vervolgt Roy, je ziet ook dat ze veel kennis delen waardoor vriendschappen ontstaan, wat zich uit in bijvoorbeeld een gezamenlijke wintersportreis. En dan loopt het in elkaar over. Kies wat je INBRENG Hoeveel tijd kost een community voor een Java professional? Die keuze blijkt met name bij jezelf te liggen. Je bent niets verplicht en vanuit de organisatie wordt ook geen druk uitgeoefend. De organisatie steunt wel de activiteiten van de community. Is het aansluiten bij een community dan geheel vrijwillig? Nee, niet geheel., benadrukt Roy. Er zit ook een bepaalde noodzaak aan. Ons vakgebied verandert ontzettend snel. Het is dus belangrijk altijd op de hoogte te blijven van wat er speelt. Doe je dit niet, dan loop je het risico dat je minder interessant wordt voor potentiële opdrachtgevers of minder uitdagende werkzaamheden krijgt toebedeeld. Dat is zeker een belangrijk doel van de community. Je krijgt een gevoel van wat er nu leeft, wat belangrijk is en hoe anderen denken over de veranderingen. Met openheid groei je Java en open source zijn twee woorden die onlosmakelijk met elkaar zijn verbonden. Dit geldt ook voor community en open source. Roy legt uit: Bij open source kan iedereen meedenken en ontwerpen aan een bepaald idee, met als doel het idee nog beter te maken. In plaats van mensen buiten te sluiten wordt er veel samengewerkt. Dit kenmerk van Java geldt ook zeker voor de Java community. De precieze datum waarop de community is ontstaan is niet te achterhalen. De Java expertise van Sogeti bestaat sinds medio jaren 90. Volgens Roy is de community ontstaan rond Het is iets dat organisch moet groeien. Het laat zich ook moeilijk meten wanneer een community er is. Liefde en gedrevenheid Naarmate Roy meer vertelt, blijkt dat in de community een aantal zeer gedreven professionals actief zijn met ontzettend veel liefde en passie voor hun vak. Zij worden ook wel het Java core team genoemd. Alles rondom de community organiseren zij zelf. Thomas de Bruin is één van de leden van het core team. Als je als professional bij Sogeti in dienst komt, ben je ook direct lid van de Java community. Hoe groot jouw aandeel hierin is, kun je geheel zelf bepalen. Vind je het leuk of wil je graag activiteiten organiseren voor de community, dan kan je jezelf gemakkelijk aanmelden voor het Java core team., vertelt Thomas. Zelf wilde ik ook graag een actievere rol. De activiteiten die hij organiseert met het core team zijn heel divers van aard. Wij organiseren verschillende activiteiten, zoals: technische meetings, programmeerwedstrijden en informele avonden met behulp van de gehele Java community. De spontaniteit en bevlogenheid van onze community is aanstekelijk. Martijn van der Salm is ook aangesloten bij de Java community maar niet bij het core team. Wel is hij actief geweest bij twee expertisegroepen (Java-PaSS en Java-Portals). Java- PaSS staat voor ProActive Security Strategy en houdt zich bezig met Security op het gebied van Java. Bij Java Portals waren we vooral bezig met het spreiden van kennis via de bekende Java portals die er zijn. Binnenkort geeft hij een korte presentatie over nieuwe Java certificeringen. Wat opvalt bij het gebruik van sociale media, is dat professionals uit de community vaak het logo en de naam van Sogeti gebruiken. Dit ondanks het vrijwillige karakter van de community. Waarom dan toch onder de vlag 17

18 van Sogeti? Roy vertelt dat dit een gevoel is dat zij zelf hebben binnen de organisatie. Zij voelen zich verbonden met Sogeti en willen daarom het logo gebruiken. Dit is niet van bovenaf opgelegd. Niet voor niets Het feit dat er vaak geen standaard werkuren beschikbaar zijn voor het onderhouden van de community wil niet zeggen dat er geen waardering is. Je ontwikkelt jezelf als professional en Sogeti heeft daar waardering voor. Die waardering betaalt zich in allerlei manieren terug, afgestemd op de persoon. Zo mag iemand een bijzondere cursus volgen, naar een conventie gaan of ontvangt deze een aardigheidje., aldus Roy. Behalve de juist genoemde waarderingen is het ook goed voor jezelf. Een community zoals bij de Java competentie van Sogeti kan enorm bijdragen aan je carrière. Je kunt je sneller naar een promotie toewerken, omdat je laat zien dat je bepaalde kennis in huis hebt en dat je die goed op papier kunt zetten. Of je mag meewerken aan bids en aanbiedingen voor klanten. Het is net wat je zelf wilt en bij jou past. Daarnaast vergroot je zo gemakkelijk je eigen netwerk. Als je Roy vraagt welke Java community hij het leukst vindt, is het antwoord vrij logisch. Met trots vertelt hij: De spontaniteit en Als de expertise groeit en bloeit, haal je daar energie uit. bevlogenheid van onze community is aanstekelijk. Iedereen is enthousiast over het vakgebied en dat stralen ze ook uit. Hierdoor is de opkomst van meetings groot. Als professional merk je dat je meedraait bij een organisatie dat dit heel belangrijk vindt. De organisatie zelf helpt ook zoeken naar nieuwe ontwikkelingsmogelijkheden voor je carrière. Toch lijkt hij te twijfelen bij de vraag of hij ontspanning uit de community kan halen. Je ziet gewoon dat wanneer de expertise groeit en bloeit, je daar veel energie uithaalt. Het is met veel bevlogenheid hard werken, maar dat is het waard. De community helpt Uit de gesprekken blijkt duidelijk dat de Java community vor Sogeti veel meerwaarde biedt. Het delen van kennis wordt zo erg gemakkelijk. Professionals zitten bij veel verschillende klanten. Hierdoor gebruikt iedereen andere producten, tools, frameworks en technieken. Door de Java community kunnen zij gemakkelijk hun expertise en best practices delen. Mensen raken daardoor meer gemotiveerd om zakelijk, maar ook privé nog meer te leren over hun vakgebied. De community is dus geen concept dat op papier is ontworpen. Het gaat om het gevoel en de energie die je er van krijgt, het is een natuurlijk proces dat moet groeien. De Java community van Sogeti is dus niet weer zomaar een community, maar één vol met gedreven personen die verliefd zijn op hun vakgebied. Dan rest nog één vraag. Wat zijn de toekomstplannen? Onze kracht is vakmanschap en een levendige community. En van daaruit streven we naar kwalitatieve groei qua kennis en aantal professionals. Why do JAVA GUYS WEAR GLASSES? BECAUSE THEY DON T C#. Roy Wasse (32) Unit Manager Oracle & Sogeti Nederland B.V. Favoriete Framework: Play 18

19 DENK JIJ IN OPLOSSINGEN? Doe dan nu mee en maak kans op een Asus Android Tablet! MEEDOEN? Kijk voor meer informatie op: java.sogeti.nl/prijsvraag Laat zien dat jij meedenkt!

20 Jouw Java EE applicaties in de Cloud bij Microsoft?! Patriek van Dorp Cloud Computing is de nieuwste ontwikkeling in de evolutie van de computer. Je kunt er haast niet meer omheen. De lage initiële investering, hoge mate van schaalbaarheid en de korte time-to-market maken het zeer aantrekkelijk voor bedrijven om hun applicaties bij een Cloud provider te hosten. Maar welke Cloud provider moet je kiezen? Microsofts Windows Azure platform wordt vaak niet overwogen bij deze keuze als het gaat om het hosten van Java applicaties. Dit vind ik onterecht, dus ik zal in dit artikel laten zien hoe eenvoudig het is om Java applicaties te deployen in Windows Azure. Wat verstaan wordt onder Cloud Computing hangt erg af van aan wie je het vraagt. Dit heeft te maken met de verschillende stijlen van Cloud Computing die we kunnen onderscheiden. In het kort zijn er drie smaken te onderscheiden; Infrastructure-as-a-Service (IaaS), Platformas-a-Service (PaaS) en Software-as-a-Service (SaaS). Bij IaaS wordt voor een klant tot aan de virtualisatielaag beheerd door de Cloud provider. De klant zal dan zelf verantwoordelijk zijn voor het configureren van het OS en de middleware. Ook draagt zij de verantwoordelijkheid voor het updaten van alle software en voor het hebben van geldige licenties. Amazon is een voorbeeld van een IaaS Cloud provider. Infrastructure Platform Software (as a Service) (as a Service) (as a Service) Bij SaaS biedt de provider een soort multi-tenant dienst aan die naar operationele ratio wordt verrekend. Voorbeelden van SaaS diensten zijn Office 365, SalesForce en Google Docs. Windows Azure is bedoeld als een open, flexibel platform waarop iedere technologie kan draaien die ook op Windows Server draait. You manage Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking Managed by vendor You manage Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking Managed by vendor Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking Managed by vendor Microsofts Cloud Platform Het Cloud platform van Microsoft heet Windows Azure. 9 Het Windows Azure platform is een PaaS en zorgt er dus voor dat klanten zich kunnen focussen op alleen de applicaties en data. Het Windows Azure platform bestaat uit een aantal services die het mogelijk maken om applicaties te hosten en data op te slaan in zowel NoSQL als in een relationele database. Daarnaast onderscheidt het platform zich door een aantal extra services te bieden. Deze services vergemakkelijken het realiseren van hybride oplossingen (Cloud en On-premises) zoals een service bus, identity provider en VPN. Afbeelding 3: Focus op wat meerwaarde levert aan het bedrijfsresultaat Bij PaaS hoeft een klant zich alleen nog te bekommeren over de applicaties en de data. Hiermee verliest de klant wat controle, maar daar tegenover staat dat de klant zich volledig kan focussen op dat wat meerwaarde levert aan het bedrijfsresultaat. Google en Microsoft zijn voorbeelden van PaaS Cloud providers. Wat veel mensen niet weten is dat Windows Azure is bedoeld als een open en flexibel platform waarop iedere technologie kan draaien die ook op Windows Server draait. Microsoft besteedt veel aandacht aan het optimaliseren van de ervaring die ontwikkelaars hebben met het platform. Zo bestaan er software development kits (SDKs) voor PHP, Node.js en Java2. Ook is er voor Eclipse een plugin gemaakt, waarmee het deployen van Java applicaties in Windows Azure heel eenvoudig is geworden. 9 Meer informatie hierover is te vinden op pagina 25 20