Links

  • 1. Sogeti
  • 2. JBoss
  • 3. IBM
  • 4. Oracle
  • 5. SpringSource
  • 6. NL-JUG
  • 7. Java

Archives

Syndication  RSS 2.0

RSS 1.0
RSS 2.0

Bookmark this site

Add 'JCN Blog' site to delicious  Add 'JCN Blog' site to technorati  Add 'JCN Blog' site to digg  Add 'JCN Blog' site to dzone

Posted by Tobias Groothuyse at 17:29 on Saturday 12 April    Add 'Where do Open source & Agile meet?' site to delicious  Add 'Where do Open source & Agile meet?' site to technorati  Add 'Where do Open source & Agile meet?' site to digg  Add 'Where do Open source & Agile meet?' site to dzone

In deze interessante presentatie ging de spreker (geen baard) in op de overeenkomsten tussen open source en agile software development. Hieruit bleek dat er zowel veel overlap is als veel verschillen. Een selectie van de argumenten:

Overeenkomsten

  • Continuous integration
  • Tight feedback loops
  • Lightweight processes
  • Collective code ownership
  • Small, self enabled teams

Verschillen

  • Agile: Pair programming
  • Agile: Daily standups
  • Agile: Iterative development
  • Open source: no user/product manager
  • Face to face communication

De conclusie was dat veel open source principes zijn overgenomen in de diverse agile methoden maar dat daarnaast agile een aantal andere zinnige principes heeft toegevoegd. Uit het publiek was de reactie dat open source veel van de agile principes op een andere manier invulling geeft. Mijn persoonlijke conclusie is in ieder geval dat de toegevoegde waar de van de “war room” (de kamer waarin alle agile teamleden werken) groot is. De  winst die behaald wordt door direct face-to-face communicatie  en  dagelijkse status  updates  is  groot.  Dit is natuurlijk lastig te realiseren in  open source projecten waar van nature door developers van over de hele wereld aan wordt gewerkt.

Posted by Tobias Groothuyse at 13:30 on Friday 11 April    Add '“All input is evil!” – Security with/despite Web 2.0' site to delicious  Add '“All input is evil!” – Security with/despite Web 2.0' site to technorati  Add '“All input is evil!” – Security with/despite Web 2.0' site to digg  Add '“All input is evil!” – Security with/despite Web 2.0' site to dzone

All input is evil! Validate all input! Escape all output! Met deze drie zinnen is de presentatie van Christian Wenz (geen baard) eigenlijk goed samen te vatten.

Ondanks de vele aandacht die security tegenwoordig krijgt in presentaties en op internet lijkt het niet echt te helpen. De spreker heeft recentelijk voor een it magazine een onderzoek gedaan naar 24 web 2.0 websites. Hierin werd maximaal 15 minuten besteed per site om een aantal security problemen op te sporen. De “success rate” van dit onderzoek was meer dan 50% en onder de onderzochte sites zaten ook grote namen zoals MySpace, Facebook en Orkut.

Een aantal redenen waarom veel websites/applicaties toch niet secure zijn ligt volgens de spreker aan een aantal dingen:
- Slecht danwel inconsistent advies in presentaties over de onderwerpen
- Gebrek aan tijd (security als laatste)
- AJAX technology maakt security leaks makkelijker
- WEB 2.0 sites zijn afhankelijk van user content en dat is gevaarlijk
- Veel nieuwe (ongeteste) API’s
- Veel code aan de client side, waardoor het systeem minder een black box is

Vervolgens werden een aatal voorbeelden van cross site scripting, cross site request forgery en SQL injection getoont. Met name op het gebied van cross site scripting liet de spreker goed zien dat je maar beter met een whitelist kan werken (welke HTML elementen en attributen sta ik toe in mijn user input) dan met een black list. Want er is altijd wel iets dat je over het hoofd ziet:

  • <img scr=”" onerror=”alert(123)” /> //Ontbreken van de src is een error en met de onerror heb je opeens toegang tot scripting
  • <style type=”text/javascript” > //Dit is valide
  • <img src=”…” style=”width: expression(alert(123))” /> //Ook dit is valide (niet in alle browsers)

SQL injection kan ook leiden tot een denial of service attack. Stel je maar eens voor dat je niet safe bent voor SQL injection en de gebruiker tikt in het inlog scherm in het name veld de volgende waarde:bogus name’ UNION SELECT null, null, BENCHMARK(1000000000000, md5(‘a’)) # DoS attack

Doe dit een aantal keer net zolang totdat alle cores van de webserver(s) md5′s aan het berekenen zijn en de site ligt plat.

Posted by Barend Garvelink at 13:28 on Friday 11 April    Add 'ApacheCon 2008 dag 2: Do you believe in users?' site to delicious  Add 'ApacheCon 2008 dag 2: Do you believe in users?' site to technorati  Add 'ApacheCon 2008 dag 2: Do you believe in users?' site to digg  Add 'ApacheCon 2008 dag 2: Do you believe in users?' site to dzone

Met deze quote uit Tron (en met de filmmuziek uit Tron!) begon Brian Fitzpatrick (met baard) zijn presentatie. De boodschap van Brian is dat je voor succesvolle software meer nodig hebt dan alleen technische excellence. In de Open richten we ons altijd enorm op de techniek, maar staan we te weinig stil bij marketing, customer service en aandacht voor de gebruiker. Zijn tips waren niet wereldschokkend: de perceptie (niet de werkelijkheid) is de werkelijkheid waarop je wordt afgerekend. Leg een zo laag mogelijke barrier-to-entry op aan potentiële gebruikers. Beloof minder dan je uiteindelijk oplevert, niet omgekeerd. De eerste indruk is belangrijk. Reputatie komt te voet en gaat te paard. Het aantal downloads van je product zegt niets. “Thirty-day active” is een veel interessanter metriek.

Maak het niet moeilijker dan nodig. Brian nam het opties scherm van de Eudora mailclient als voorbeeld, dit heeft achtentwintig pagina’s waaronder “mood watch”. Snelheid is belangrijk. Leuk rekenvoorbeeldje: als je een miljoen users hebt, die twintig requests per dag doen en je applicatie is 500ms te langzaam, dan heb je bij je gebruikers 116 dagen van hun leven verspild.

Het was een luchtige sessie met de eerste (en tot nu toe enige) versterkte f-bomb.

Posted by Tobias Groothuyse at 11:24 on Friday 11 April    Add 'Take a ride with Apache Camel' site to delicious  Add 'Take a ride with Apache Camel' site to technorati  Add 'Take a ride with Apache Camel' site to digg  Add 'Take a ride with Apache Camel' site to dzone

Apache Camel is de message routing API die onstaan is uit het ServiceMix project (zie een van de vorige posts). Apache Camel implementeerdt alle bekende enterprise integration patterns zoals beschreven in dit breed geaccepteerde boek. Naast deze patterns voegt Camel zelf nog een aantal nuttige patterns toe die uit noodzaak geboren zijn. Het krachtige aan Camel is dat alle patterns te gebruiken zijn middels een ontzettende makkelijke (Builder stijl) API. Ik denk dat een paar voorbeelden boekdelen spreken:

Content based routing:
from(“seda:a”).choice().when(header(foo)).isEqual(bar)).to(seda:b).otherwise().to(otherEndpoint);

Message Filter:
from(“activemq:topic:Quotes”).filter().xpath(“/quote/product = “widget’”).to(“mqseries:WidgetQuotes”);

Splitter:
from(“file://orders”).splitter(body().tokenize(“\n”)).to(“activemq:Order.Items”);

Custom logica binnen een eigen POJO:
from(“activemq:Topic:Orders”).beanRef(“myBean”).to(“activemq:Topic:Sales”);

Op deze manier is wordt message routing een stuk simpeler. Camel maakt gebruik van het Spring framework voor dependency injection en het gebruike van de application context, in dit geval de camelContext. Op dit moment wordt er gewerkt aan een grafische interface om routering te definieren. Ik denk zelf dat dat niet perse nodig is omdat deze stijl al erg goed leesbaar is.

Camel maakt het ook mogelijk om endpoints te binden aan je java classes. Onderwater gebeurt dit middels MessageDriven beans alleen de configuratie en het gebruik is stukken makkelijker:

@MessageDriven(uri=”activemq”)
public void onCheese(

@Xpath(“/foo/bar”) String name,
@Header(“JMSCorrelationID”) String id {

}

Bovenstaande methode zal worden aangeroepen voor alle berichten die via de activemq binnenkomen waarbij de name parameter automatisch gevuld wordt met de waarde uit het bericht gedefinieerd door de geannoteerde XPath expressie. De id parameter wordt eveneens gevuld met de gespecificeerde header attribuut van het bericht.

Posted by Barend Garvelink at 11:14 on Friday 11 April    Add 'ApacheCon 2008 dag 2: Cayenne OpenJPA, iBatis' site to delicious  Add 'ApacheCon 2008 dag 2: Cayenne OpenJPA, iBatis' site to technorati  Add 'ApacheCon 2008 dag 2: Cayenne OpenJPA, iBatis' site to digg  Add 'ApacheCon 2008 dag 2: Cayenne OpenJPA, iBatis' site to dzone

Na de luch (pizza, belegde broodjes) op donderdag de sessie “Cayenne, OpenJPA, iBatis” bijgewoond over deze drie ORM frameworks. Deze sessie werd gegeven door Henning Schmiedehausen (geen baard). Henning begon met de Object-Relational Impedance Mismatch, het ontstaan van ORM frameworks, stond kort stil bij de non-apache-license frameworks (iets met een H…) en kwam uit bij de evaluatiecriteria die je kunt gebruiken bij het kiezen van een framework. Buiten de licensing issues moet je o.a. kijken naar je access pattern (veel websites zijn overweldigend read-mostly terwijl kantoorapplicaties doorgaans een veel evenrediger verdeling van de CRUD operaties kennen), de kennis van je ontwikkelaars (kunnen ze SQL?), wil je transparante persistence of expliciete controle, etc.

Hierna ging Henning in op Cayenne en OpenJPA (beide volledige O/R mappers die een object database simuleren bovenop een RDBMS) en iBatis (een databinder waarbij je normale SQL schrijft). Van elk van de frameworks kwam een codevoorbeeldje langs en een lijstje met voor- en nadelen. De slides staan achter het linkje hieronder:

Henning’s presentatie

Ik vond het wel een aardige sessie. Ik heb zelf ervaring met straight JDBC, Hibernate en TopLink en het was nuttig om iets te zien van een drietal andere frameworks. Erg diepgaand was het allemaal natuurlijk niet.

Posted by Barend Garvelink at 8:56 on Friday 11 April    Add 'Keynote: “Apache and Steam engines”' site to delicious  Add 'Keynote: “Apache and Steam engines”' site to technorati  Add 'Keynote: “Apache and Steam engines”' site to digg  Add 'Keynote: “Apache and Steam engines”' site to dzone

Keynote “Apache and Steam engines” door Rishab Aiyer Ghosh (geen baard). Dit was een keynote over de economie achter open-source. De spreker (opvallend T-shirt: “Learn from your LEADERS – use VIOLENCE to solve your problems”) werkt voor de United Nations University in Maastricht en houdt zich daar al een aantal jaar met open source bezig. Rishab begon met de geschiedenis van de stoommachine. In de vroege 19e eeuw was Cornwall voor de stoommachine wat Silicon Valley nu is voor de computer. Hij vertelde een mooi verhaal over hoe James Watt met zijn patenten de ontwikkeling van die dingen dertig jaar lang in een wurggreep hield, en hoe na afloop van het patent een tijdschrift uitkwam dat bouwtekeningen van stoommachines publiceerde. Dit bracht de ontwikkeling van stoommachines in een stroomversnelling. De parallellen op dit punt naar open-source liggen erg voor de hand. Na dit geschiedenispraatje ging Rishab op de economische toer. Het leuke aan open-source is dat driekwart van de gebruikers aangeeft dat hij meer neemt dan dat hij geeft. Dit verklaart waarom bedrijven als IBM en HP er kapitálen in steken ondanks dat het beeld nog steeds bestaat dat open-source liefdadigheid is. Rishab gebruikte een heleboel grafiekjes om zijn betoog te onderbouwen. De brongegevens zijn terug te vinden op www.flossmetrics.org.

Posted by Tobias Groothuyse at 21:26 on Thursday 10 April    Add 'REST vs WS-*' site to delicious  Add 'REST vs WS-*' site to technorati  Add 'REST vs WS-*' site to digg  Add 'REST vs WS-*' site to dzone

Na een presentatie over REST te hebben gevolgd gegeven door Roy T. Fielding (geen baard). Ben ik in dezelfde zaal blijven zitten om een sessie over REST vs WS-* bij te wonen. In de eerste sessie maakte Fielding (auteur HTTP, HTML en URI spec)  duidelijk dat REST een architectuurstijl is en wel de architectuurstijl waar het WWW op gebaseerd is. REST is bij de meeste van ons met name bekend als een alternatief voor WS-* web services. Er wordt dan gesproken over RESTfull web services. Dit is echter niet meer dan het toepassen van de REST architectuur stijl op het web services principe.

Het principe achter REST is dat alles een resource is en dat alle resources via een uniforme interface te manipuleren zijn (HTTP GET, PUT, POST, HEAD, DELETE, etc). Door het definieren van meerdere content-types types is het mogelijk om dezelfde resource op een andere manier te bekijken. Zodat de ene view geschikt is voor een gebruiker, en de andere voor een systeem.

In de tweede presentaties werd ingegaan om een aantal mythes die rond REST en WS-* bestaan. Zoals daar waren:

  • REST is simpel
    • Dat valt dus wel mee. Een aantal operaties zijn verplicht idempotent. Wat betekent “delete” in elke context? De HTTP spec is een van de meest ingewikkelde spec, dit heeft invloed op het goed begrijpen van REST
  • WS-* is noodzakelijk om een web service te maken
    • Dat valt vaak erg mee. Ter indicatie als je SOAP header niets relevants bevat dan kun je net zo goed plain XML over HTTP gebruiken.
  • Met REST kun je alle web services bouwen
    • Nee helaas, met REST is het namelijk op dit moment niet mogelijk om gelaagde security features toe te voegen. Dat is ook het geval met reliability. WS-* biedt dit echter weer wel.

Posted by Tobias Groothuyse at 21:05 on Thursday 10 April    Add 'Lightning lottery talks (Beer and merriness sponsored by Google)' site to delicious  Add 'Lightning lottery talks (Beer and merriness sponsored by Google)' site to technorati  Add 'Lightning lottery talks (Beer and merriness sponsored by Google)' site to digg  Add 'Lightning lottery talks (Beer and merriness sponsored by Google)' site to dzone

De lightning lottery talks bestaan al tien jaar. Het concept is dat iedereen die iets relavants over Apache of OSS te vertellen heeft zich ter plekke kan registreren voor een praatje die niet meer dan 5 minuten duurt. Google was zo vriendelijk om het bier te sponsoren en dat droeg positief bij aan de sfeer.

Dit alles resulteerde in een aantal vermakelijke praatjes varierend van waarom Portal het beste spel ooit is (wie ziet de relatie tot OSS?) tot de reden waarom releases wel met PGP gesigneerd worden maar de releasenotes niet tot de problemen van een non-profit start-up (Literacy bridge). Al met al een erg vermakelijke en interessante afsluiting van de tweede conference dag.

Posted by Tobias Groothuyse at 13:46 on Thursday 10 April    Add 'Apache ServiceMix 4.0 vs Apache Synapse' site to delicious  Add 'Apache ServiceMix 4.0 vs Apache Synapse' site to technorati  Add 'Apache ServiceMix 4.0 vs Apache Synapse' site to digg  Add 'Apache ServiceMix 4.0 vs Apache Synapse' site to dzone

ServiceMix en Synapse zijn twee aparte projecten binnen Apache. Beiden zijn ESB’s en wij kregen de mogelijkheid om twee presentatie ná elkaar bij te wonen over deze projecten. Ik wil voornamelijk ingaan op de verschillen tussen de twee projecten want ze bieden beiden de standaard functionaliteit die we van een ESB mogen verwachten. Zo is er support voor meerdere transports, is het mogelijk om berichten te converteren en transformeren en is er support voor WS*.

ServiceMix 4.0 bevat een JBI 1.0 implementatie en gebruikt Apache Camel voor de routering. Verder maakt ServiceMix 4.0 veel gebruik van OSGI. Zo worden alle services en de registry beschikbaar gemaakt middels OSGI bundles door tijdens de deployment bundle te genereren voor de diverse artifacts. Dit is ook een groot verschil tussen ServiceMix en Synapse. Waar ServiceMix het mogelijk maakt om services in de ESB te deployen kan dat bij Synapse niet. Synapse is echt een pure ESB, dat wil zeggen dat het berichten tussen verschillende end points routeerd en daar eventueel conversie en transformatie op loslaat. Dit maakt dat Synapse een meer licht gewicht ESB is.

Synapse is ook op een flink aantal manieren te draaien: als war file, NT service & Linux deamon. Dit alles kan dan weer standalone gebeuren, in een cluster of zelfs volledig als distributed network. Er is support voor load balancing (gebaseerd op content), failover en het throttlen van requests. Synapse is ook zeer goed te extenden een repository van extensies is te vinden op http://esbsite.org/.

Mijn voorkeur zou op dit moment uitgaan naar Apachce Synapse met name omdat het focussed op het echte ESB werk wat de snelheid en complexiteit van de applicatie ten goede komt. Wil je echter services kunnen deployen op je ESB dan moet je met ServiceMix 4.0 aan de slag.

Posted by Tobias Groothuyse at 11:38 on Thursday 10 April    Add 'Scalable AJAX applications with Apache Comet' site to delicious  Add 'Scalable AJAX applications with Apache Comet' site to technorati  Add 'Scalable AJAX applications with Apache Comet' site to digg  Add 'Scalable AJAX applications with Apache Comet' site to dzone

Apachec Comet maakt het mogelijk om AJAX in push mode te kunnen gebruiken. Op dit moment is het AJAX model altijd pull based. Dit betekend dat de client altijd moet vragen aan de server of er relevante informatie beschikbaar is. Zeker wanneer de client events moet ontvangen die op de server onstaan zal de client constant moeten pollen bij de server of er al berichten zijn. Direct gevolg hiervan is dat, zeker met veel clients, de server wordt gehammered met request waarvan het overgrote deel overbodig zal zijn.

Apachec Comet biedt de mogelijkheid om informatie te pushen vanaf de server op het moment dat er een relevant event onstaat voor een bepaalde client. Er zijn twee verschillende mogelijkheden om dit te realiseren binnen de huidige HTTP specificatie. De eerste is “long poll”. In dit geval stuurt de client een request voor informatie “is er een event voor mij” en de server wacht net zo lang met een response tot dat event ook werkelijk aanwezig is. Een long poll is dus niet te onderscheiden van een erg langzame server. Voordeel van long poll is dat de er minder connecties moeten worden opgezet en afgebroken. Nadeel van long poll is dat er wel voor elke client een http connectie open blijft staan en een geblokkeerde thread.

Het alternatief voor long poll dat Comet biedt is streaming. In streaming mode dat de client een request waarop de server alleen de HTTP headers returneerd. Hierin staat dat de response multi-part is. Dit maakt het mogelijk voor Comet om de HTTP connectie open te houden. Elke keer dat er dan een relevant event voor de client onstaat wordt dit event als een stukje response naar de client gestuurd. Voordeel van streaming over long poll is dat er slechts 1 connectie nodig is per client.

Voor echte performance winst blijft dan nog het probleem van de TCP connecties die open moeten blijven en belangrijker, de Thread die de connectie afhandeld blijft veel langer in gebruik. Gezien het feit dat het aantal threads maar tot een bepaalde hoogte kan worden opgeschaald is dit een scalability probleem. De oplossing komt uit de hoek van NIO. Het NIO is het mogelijk om non blocking connecties te hebben. Dit houdt in dat alhoewel de TCP connectie open blijft staan, de Thread gereleased wordt op het moment dat de connectie normaliter zou blocken. Er werd ook vooruit gekeken naar de Servlet 3.0 spec. In deze spec zal ook volledig asynchrome communicatie worden opgenomen.


© 2018 Java Competence Network. All Rights Reserved.