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 Eric Gunnewegh at 7:38 on Tuesday 20 March    Add 'QCon ten einde' site to delicious  Add 'QCon ten einde' site to technorati  Add 'QCon ten einde' site to digg  Add 'QCon ten einde' site to dzone

Na een relatief relaxed begin van de QCon met twee tutorial dagen, zijn de conferentie dagen voorbij gevlogen. Meteen na de laatste presentaties moesten we al weer op weg naar het vliegveld, Samuael naar Gattwick en ik naar City Airport. Wat ons betreft kunnen we terug kijken op een geslaagde conferentie met een zeer gevarieerd aanbod aan tracks. Vaak was het moeilijk om een keus te maken uit het aanbod. Zo heb ik minder SOA gerelateerde presentaties kunnen volgens dan ik aanvankelijk had gewild.

De conferentie trok zo’n 400 – 500 bezoekers, waarvan ongeveer 40% uit de UK. De rest kwam voornamelijk uit andere Europese landen. De laatste dag sprak ik nog even met een medewerkster uit het organisatie team. Ze wist mij te vertellen dat de organisatie tevreden was met het aantal bezoekers en dat het de verwachting is dat de QCon net zo’n groei zal doormaken als de JAOO de afgelopen jaren, dat nu zo’n 1200 bezoekers trekt. Voor ons als bezoekers van de eerste QCon was het in ieder geval prettig dat het aantal zitplaatsten meestal ruimschoots het aantal toehoorders overtrof. Een enkele keer had de organisatie zich verkeken op de populariteit van een presentatie. Bij de presentatie van eBay hebben aardig wat mensen op de grond moeten zitten. Andere populaire presentaties waren die van Jeff Sutherland over de toepassing van Scrum bij Google, de presentaties van Rod Johnson en die van John Davies over Banking Arcitectures.

Posted by Eric Gunnewegh at 7:31 on Tuesday 20 March    Add 'Leveraging the Web for Services at Yahoo!' site to delicious  Add 'Leveraging the Web for Services at Yahoo!' site to technorati  Add 'Leveraging the Web for Services at Yahoo!' site to digg  Add 'Leveraging the Web for Services at Yahoo!' site to dzone

De track host had al een aantal keer op de laatste dag van de QCon genoemd dat bij Yahoo de beste developers werken, maar niet de beste managers. Mark Nottingham, die zich zelf tot de eerste groep rekende, werkt bij de Yahoo Media Group (Y!Music, Y!TV, Y!Games, etc) en gaf een interessante presentatie over de ontwikkelingen bij Yahoo de laatste jaren. Yahoo is vanaf 1994 gegroeid van een bedrijf met 100000 gebruikers, tot 500 miljoen gebruikers nu. Het aantal dagelijkse page views is vanaf 1997 gestegen van 65 miljoen tot 4 miljard. Hier is weer duidelijk zichtbaar dat scalability een belangrijk aandachtspunt is. Ook heeft Yahoo de nodige integratieproblemen gekend, vanwege verschillende acquisities, het aangaan van samenwerkingsverbanden met partners en de eigen applicatie onderdelen die aanvankelijk onafhankelijk van elkaar werkten. In eerste instantie bestond Yahoo uit onafhankelijke front-end applicaties met hun eigen databases, met als backend een master database. Deze arcitectuur gaf onder andere problemen met het pushen van data vanuit de master database, en het vastleggen van user-generated content. Daarnaast was het toevoegen van extra database capaciteit nogal duur.

Belangrijke requirements voor een nieuwe architectuur waren:
- massive scalability
- flexible deployement
- highly dynamic content
- separation of concerns

Het antwoord werd gevonden in een service georienteerde architectuur. Via een cache maken front-end applicaties gebruik van back-end servers via http, zonder gebruik te maken van SOAP. Voor caching maakt men gebruik van Squid, een open Source chaching server. Doordat men gebruik maakt van een Open Source oplossing voor caching, kon men hier makkelijker functionaliteit aan toevoegen dan mogelijk geweest zou zijn met een off-the-shelf vendor oplossing. Vooral op het gebied van statistics en metrics heeft Yahoo aan functionaliteit er het nodige aan toegevoegd.

Posted by Eric Gunnewegh at 7:20 on Tuesday 20 March    Add 'Voca, UK’s largest payment processing engine running Spring' site to delicious  Add 'Voca, UK’s largest payment processing engine running Spring' site to technorati  Add 'Voca, UK’s largest payment processing engine running Spring' site to digg  Add 'Voca, UK’s largest payment processing engine running Spring' site to dzone

Na de presentatie over eBay’s web architecture, was er nu een presentatie over Voca als voorbeeld van een enterprise architectuur waarbij scalability ook enorm belangrijk is. Helaas voor de twee presentatoren, William Soo en Meeraj Kunnumpurath moest de sessie concurreren met een presentatie over de Google Web Toolkit waardoor de zaal ineens wel erg leeg over kwam na de zeer druk bezochte sessie van eBay.

Voca is een bedrijf dat betalingsprocessen ondersteunt voor de grote banken in de UK. Zo’n 90% van alle salarissen en de betalingen van 70% van rekeningen in de UK worden verwerkt door Voca. In 2006 werden er 5,5 miljard transacties verwerkt. Deze getallen maken duidelijk dat ook voor Voca scalability een belangrijk requirement is voor hun architectuur. Andere factoren die Voca er toe aanzetten om voortdurend hun technologie te vernieuwen zijn het streven naar een goedkopere infrastructuur en een snellere verwerking van transacties en data integrity (gegarandeerd geen verlies van data) in een 24*7*365 operatie.

Belangrijk onderdeel van de applicatie architectuur is de Payments Engine die in hoge volumes in een workflow parallel data verwerkt over persistente queues. JMS wordt gebruikt als message service, waarbij alleen locaal transaction management wordt toegepast (geen XA transactions). Applicaties draaien in een JDK 1.4 / J2EE 1.4 BEA Weblogic 9.2 applicatie server, en een Oracle 10g RAC database. Complexe business logic wordt in Java afgehandeld, en niet in de database. Veel gebruikte data wordt gecached.

In Juli 2006 is een nieuwe versie van de Payments Engine live gegaan, die gebouwd is op basis van Spring. Voca heeft met name voordeel gehad van de functionaliteit die Spring biedt op het gebied van transaction management, JDBC en ORM. De Spring container zorgt bovendien voor een minimale koppeling tussen de diverse onderdelen van de applicatie modules. Ook maakt men veelvuldig gebruik van de testfaciliteiten die Spring biedt (easy mocking). Bij Voca is men tot de conclusie gekomen dat de development productiviteit met meer dan 30% is gestegen dankzij Spring.

Voor de toekomstige architectuur wordt gekeken naar hergebruik van de huidige services en componenten, waarbij integratie kan plaats vinden met commercial-off-the shelf (COTS) producten of met open source oplossingen. Belangrijk aandachtspunt is de integratie met de back office systemen van hun klanten. Verder staan de volgende zaken in de planning:
- upgrade naar JSE 5.0 / JEE5
- gebruik van JPA / Hibernate 3.2
- gebruik van Mule 1.4 / 2.0
- gebruik van SEAM
- uitfasering Struts

Posted by Eric Gunnewegh at 7:52 on Monday 19 March    Add 'The eBay Architecture – Striking a balance between site stability, feature velocity, performance and cost' site to delicious  Add 'The eBay Architecture – Striking a balance between site stability, feature velocity, performance and cost' site to technorati  Add 'The eBay Architecture – Striking a balance between site stability, feature velocity, performance and cost' site to digg  Add 'The eBay Architecture – Striking a balance between site stability, feature velocity, performance and cost' site to dzone

In de eerste presentatie ging Dan Pritchett in op de architectuur van eBay, waar hij als Technical Fellow werkzaam is. De volgende getallen zullen duidelijk maken waarom een goede architectuur, waarbij schaalbaarheid en manageabilty belangrijke requirements zijn, noodzakelijk is. Er zijn 212 miljoen geregistreerde gebruikers in 33 landen die gebruik maken van eBay, dat 24 uur per dag in de lucht moet zijn. Er zijn 1 miljard page views per dag, afkomstig van 30 miljoen gebruikers. Per kwartaal worden er 300 nieuwe features gereleased en komen er meer dan 100000 regels code bij. Ondanks de enorme groei van eBay de afgelopen jaren, is de beschikbaarheid omhoog gegaan van 97% in 1999 tot 99,94% nu.

Belangrijke requirements met betrekking tot de architectuur zijn:
- beschikbaarheid
- schaalbaarheid
- betrouwbaarheid
- security
- onderhoudbaarheid en de mogelijkheid om snel nieuwe features op te leveren.

De applicaties van eBay draaien in een J2EE applicatieserver met een MSXML framework voor de presentatielaag. De data is in databases verdeeld aan de hand van de functionele deelgebieden (bijvoorbeeld: aparte hosts voor users / items / accounts / feeback / etc). Er wordt onderscheid gemaakt in meer dan 70 functionele deelgebieden. Het gebruik van database resources wordt geminimaliseerd door hier geen business logic neer te leggen en geen gebruik te maken van stored procedures. CPU-intensieve logica wordt verplaatst naar de applicatie laag, waarbij je ook moet denken aan het bijhouden van referentiele integriteit, het maken van joins en het sorteren van data. Er wordt verder veel gebruik gemaakt van prepared statements en het binden van variabelen. Om deadlocks en concurrency problemen te voorkomen wordt er geen gebruik gemaakt van gedistribueerde transactions (alleen auto-commits vanuit de database). Voor ORM gebruikt eBay een framework dat zelf ontwikkeld is: het Data Access Layer (DAL) framework.

Vanaf 2002 werd eBay zo groot dat de search engine tegen de grenzen van zijn kunnen aanliep. Vanaf die tijd wordt er een zelf gebouwde search engine gebruikt. Vanwege unieke eisen aan de search engine, kan eBay geen gebruik maken van een off-the-shelf product. Zo moet de search engine namelijk real-time zijn. Gebeurtenissen zoals een bod of een verkoop moeten direct zichtbaar zijn in de zoekresultaten. Hiervoor gebruikt men technieken als real-time indexing, in-memory-indexing en caching van dure en veel gevraagde queries.

De eBay development teams gebruiken een Eclipse IDE met hun eigen plug-ins om de productiviteit de vergroten.

Posted by Eric Gunnewegh at 7:50 on Monday 19 March    Add 'Architectures you always wondered about' site to delicious  Add 'Architectures you always wondered about' site to technorati  Add 'Architectures you always wondered about' site to digg  Add 'Architectures you always wondered about' site to dzone

Vrijdag heb ik voornamelijk presentaties bijgewoond uit de track Architectures you have always wondered about. De track werd gehost door James Governor, Principal Analyst en oprichter van RedMonk. In een inleidende presentatie ging James in op de verschillen en overeenkomsten tussen web-applicaties en traditionele enterprise applicaties. James benadrukte dat schaalbaarheid niet slechts van belang is voor web-appicaties, maar ook voor traditionele enterprise applicaties. Architecten uit beide werelden kunnen op dit gebied van elkaar leren. Schaalbaarheid was een thema dat als een rode draad door de track heen liep en in de verschillende presentaties van de dag steeds aan de orde kwam.

Posted by Eric Gunnewegh at 7:30 on Monday 19 March    Add 'Test Driven Develoment: How we know we’re done' site to delicious  Add 'Test Driven Develoment: How we know we’re done' site to technorati  Add 'Test Driven Develoment: How we know we’re done' site to digg  Add 'Test Driven Develoment: How we know we’re done' site to dzone

Steve Freeman, een onafhankelijk consultant van M3P probeerde in zijn presentatie duidelijk te maken dat iedereen aan TDD zou moeten doen, De voordelen zijn:
- het aantal bugs in de software daalt met 50%
- de productiviteit blijft gelijk, ondanks dat het aantal regels code voor testcases in orde grootte ongeveer gelijk is aan het aantal regels in de eigenlijke software
- de kwaliteit van de software gaat omhoog
- de developer zal een comfortabel gevoel houden over de software, ook naarmate de hoeveelheid regels code groter en groter wordt.

De strategie bij TDD is globaal als volgt:
- kijk naar een requirement en schrijf er een testcase voor
- implementeer de functionaliteit, en doe niet meer dan nodig om de test te doen slagen
- breidt de testset uit in kleine stappen
- implementeer de functionaliteit en refactor waar nodig
Dit is wat Steve de Red/Green/Refactor cycle noemt.

Aan de hand van een demo in Eclipse met JUnit4 en JSE5 werd een en ander toegelicht. Refererend naar de ondersteuning van JUnit in Eclipse liet Steve zien hoe je steeds naar de green line toewerkt en dat je hier nooit ver vanaf zit. Naar mate de code base groter wordt, zal de groeiende hoeveelheid testcases de developer een comfortabel gevoel geven.

TDD is niet alleen een manier van ontwikkelen, maar het is ook een ontwerp techniek. Door eerst te testcases te schrijven, wordt er van buiten naar de classes gekeken hoe ze gebruikt worden in plaats van dat er meteen van binnenuit naar de implementatie wordt gekeken. Een ander voordeel van TDD dat genoemd werd is dat testers vroeg bij het ontwikkelproces betrokken zijn. Hoewel het schrijven van testcases tijd kost, moet dit niet gezien worden als verloren tijd. Een groot deel van deze tijd kun je beschouwen als analyse tijd.

Posted by Eric Gunnewegh at 21:13 on Thursday 15 March    Add 'High Performance Enterprise Service Bus' site to delicious  Add 'High Performance Enterprise Service Bus' site to technorati  Add 'High Performance Enterprise Service Bus' site to digg  Add 'High Performance Enterprise Service Bus' site to dzone

In de intruductie in Banking Architectures had John Davies al gesproken over de Front, Middle en Back Office systemen die van belang zijn bij investment banks. Deze systemen sturen over en weer berichten naar elkaar, veelal in XML format. Een Enterprise Service Bus is de middleware die daar voor zorgt. Dat zo’n ESB cruciaal is blijkt wel uit het feit dat sommige berichten bedragen kunnen representeren van miljarden dollars. Een bericht dat verstuurd wordt en pas een dag later een exception geeft heeft op zo’n moment alleen al aan rente een enorm bedrag gekost. Kortom, er is dus genoeg aanleiding om in een aparte presentatie de betekenis van een ESB voor een investment bank nader toe te lichten.

Belanrijke eigenschappen van een ESB zijn:
- scalability
- resilience (fouten moeten goed afgehandeld kunnen worden)
- performance (efficient gebruik van de beschikbare resources)

Banken kunnen voor hun ESB kiezen uit commercial off the shelf (COTS) producten, of zelf een ESB bouwen. Voor COTS producten zijn IBM, BEA, MS en Tibco de belangrijke spelers, maar geen van deze vendors kan volgens John alles bieden wat een bank nodig heeft ook al wordt dit beloofd.

Een ESB bestaat uit een Bus en adapters die de koppeling vormen tussen de Bus en de applicaties. De belangrijke features voor de bus zijn:
- routing
- management and monitoring
- message replay en message ordering

De features voor adapters die genoemd werden zijn:
- validation
- rules and constraints
- transformation (XSLT / XQuery)
- enrichment

Er zijn nogal wat problemen op te lossen:
- validation: xml schema’s kennen hun beperkingen (datum validaties, time-zones en time-offsets / cross-validaties)
- messages in non-XML format: er zijn nogal wat applicaties die CSV files genereren met miljoenen regels
- persisistence: FpML kent meer dan 4000 elementen en kan meer dan 10 levels diep zijn
Echter, in de meeste gevallen is XML goed genoeg.

Bij verreweg de meeste banken wordt MQ-series gebruikt als middleware omdat dit op veel platforms ondersteund wordt (zOS, Windows, Unix, Linux). In een Java omgeving komen ook alternatieven in beeld, zoals bijvoorbeeld ActiveMQ. Een nieuwe ontwikkeling om in de gaten te houden is AMQP. ESB vendors zijn hier serieus naar aan het kijken. Zodra een aantal vendors dit gaat aanbieden, wordt het interessant om te gaan gebruiken.

Posted by Eric Gunnewegh at 21:09 on Thursday 15 March    Add 'Business drivers for IT' site to delicious  Add 'Business drivers for IT' site to technorati  Add 'Business drivers for IT' site to digg  Add 'Business drivers for IT' site to dzone

In een aparte presentatie van Greg Heimark en Chris Swan werd dieper ingegaan op de invloed van de business van investment banks op de IT. Eerst werd uiteen gezet in welke competitieve omgeving een bank zich bevindt. De volgende invloeden werden genoemd:
- clients: de klanten en de wensen van klanten veranderen
- new entrants: nieuwe banken ontstaan
- suppliers: suppliers kunnen de business rules veranderen
- traditional competitors: andere banken veranderen

Als het gaat om financiele producten, zijn er enerzijds complexe exotische producten, en anderzijds cash products in grote volumes. Voor de complexe producten geldt dat er hoge marges zijn. Hier is het voor het risico management belangrijk te realiseren dat het loont om te investeren in intensive computing (computing grids). Voor de cash products in grote volumes is de snelheid van verwerking juist belangrijk om in te investeren.

Een aantal andere invloeden vanuit de business op de IT zijn:
- turn over time van nieuwe producten
- de toenemende vraag naar groene producten (environmental concerns)
- wet- en regelgeving: Markets in Financial Instruments Directive (MiFID) , Single Euro Payments Area (SEPA)

Posted by Eric Gunnewegh at 18:37 on Thursday 15 March    Add 'Banking Architectures' site to delicious  Add 'Banking Architectures' site to technorati  Add 'Banking Architectures' site to digg  Add 'Banking Architectures' site to dzone

John Davies was de voorzitter van de track Banking Architectures. Een van de redenen om een track als deze op te nemen in de Qcon is het feit dat er in Londen heel wat te doen is op dit gebied, zeker voor Java developers. John heeft een jarenlange ervaring met architecturen bij diverse investment banks.

In zijn introductie zette John uiteen waar een investment bank zich doorgaans mee bezig houdt en wat voor architecturen er belangrijk zijn. Diverse Lines of Businesses (LoBs) spelen een rol bij investment banks, zoals:
- Futures and Options (F&O)
- Foreign Exchange (FX)
- Fixed Incomes (FI)
- Equity Derivatives (EQD)
- Bonds
- etc.

Over het algemeen wordt deze business ondersteund door Front, Middle en Back office systemen. Voor de communicatie tussen deze systemen is er een ESB nodig, waar John later een aparte presentatie aan zou wijden. In het kort kan het volgende gezegd worden over de systemen.

Front Office:
- De traders in de trader room gebruiken de front office systemen. Hier begint de life cycle van een trade.
- Traders hebben een aantal schermen tot hun beschikking om te besluiten hoe te handelen.

Middle Office:
- Traders hebben informatie nodig om beslissingen te nemen. Deze informatie komt real-time vanuit de middle office systemen.
- De informatie op basis waarvan risico analyse gedaan wordt is enorm belangrijk. Kleine percentages in verschil in analyses kunnen enorme bedragen representeren.

Back Office:
- Hier vindt de financiele afhandeling van een trade plaats (settlement).
- Vaak wordt de data geaggregeerd, waardor het per bericht aan de back office om miljarden dollars kan gaan.

Bij de meeste banken werkt men met systemen gebaseerd op Java op Linux en Solaris. Windows wordt slechts gebruikt op desktop workstations. Calculatie engines zijn regelmatig gebouwd in C of C++. PERL kom je hier en daar tegen, maar verder zijn andere talen zeldzaam.

Nog wat getallen over de berichten die de systemen verzenden:
- Front office: hoge volumes (100 – 10000 / sec), simple XML
- Middle office: hoge volumes (1 – 1000 / sec), complexe XML zoals FpML of SwapsWire formats.
- Back office: lage volumes (100 – 1000 / hour), de berichten representeren zeer grote bedragen, Swift format

Posted by Eric Gunnewegh at 18:33 on Thursday 15 March    Add 'Banking Architectures en een beetje Agile' site to delicious  Add 'Banking Architectures en een beetje Agile' site to technorati  Add 'Banking Architectures en een beetje Agile' site to digg  Add 'Banking Architectures en een beetje Agile' site to dzone

Het was lastig om vandaag een keus te maken uit de tracks en de presentaties. Banking architectures stond hoog op mijn lijst, maar de andere tracks leken mij niet minder interessant. We hebben het dan over Agile Foundations, Java Emerging technologies en Soa: Bridging business and technology. Uiteindelijk is het Banking Architectures geworden met een beetje Agile.


© 2018 Java Competence Network. All Rights Reserved.