Avslutande tankar

Konferensen är nu slut och det är dags att sammanfatta intrycken från konferensen. Jag är imponerad över kvalitén och bredden på presentationerna under den här konferensveckan. Det är häftigt att IBM flugit in i princip alla chefsarkitekter och huvudutvecklare för deras WebSphere-produkter för att presentera det senaste kring produkterna och de problem som de löser. Det gör att presentationerna inte blir så säljaktiga utan istället fokuserar på de problem som ska lösas och hur man tänkt kring lösningarna. Man får även en unik inblick i de problem som IBM nu fokuserar på och vart produkterna är på väg.

Det som jag uppskattar med IBM är att de har produkter och tänk kring många områden, vilket blir väldigt tydligt på en sådan här konferens. Det som är IBM:s styrka är att produkterna och tänket fungerar bra tillsammans för att lösa större och komplexare problem så som att få ihop en bra SOA-lösning för ett större företag. Det finns säkert många konkurrenter som har produkter som är "bättre” inom sina specifika områden men om man bara får/vill välja en leverantör och vill att alla produkter ska integrera bra med varandra idag och i framtiden så är IBM ett säkert val. Det är ju den bilden IBM vill måla upp för sina kunder och partner på den här konferensen och jag måste säga att man lyckas väldigt bra.

Summa summarum så var konferensen mycket bra och gav en hel del ny kunskap som jag och de kunder jag konsultar åt kommer att ha nytta av.

Versionshantering av tjänster

När man börjar bygga upp SOA-arkitekturer är det vanligt att man inte tänker på versionshantering av tjänsterna. Och det fungerar ett tag. Sedan får man stora problem när de första tjänsterna behöver uppdateras eller bytas ut. Eller för att citera IBM:s Greg Flurry: "Change happens.", "Change is painful."

IBM har gjort ett arbete för att ta fram en fungerande modell för versionshantering. Den bygger dels på teori, dels på erfarenheter från några kunder. Modellen är uppbyggd kring begreppet servicespecifikation (service specification). Specifikationen är indelad i fyra delspecifikationer, beteende, interface, interaktion och drift.

Servicespecifikationen versionshanteras, delspecifikationerna versionshanteras inte separat, utan versionsnumreringen följer servicespecifikationen oavsett om en vis delspecifikation uppdaterats eller inte. Versionsnummer består av major.minor. Man börjar alltid på version 1.0, för varje bakåtkompatibel version ökas minor-komponenten (t ex 1.0 till 1.1), om bakåtkompatibiltet saknas för en uppdatering ökas major-komponenten (t ex 1.0 till 2.0).

För riktigt stora ändringar skapar man en helt ny service. Det är ett fall som IBM:s modell inte täcker. Den nya servicen har, versionsmässigt, inga band till den gamla.

Det finns ett betydligt större djup i modellen än vad jag kan ta upp här, men skriv gärna en kommentar om det verkar intresant, så ska jag se om jag kan leta upp några resurser i ämnet.

DataPower åt folket

I och med att vi skapar fler och fler Web Services och andra tjänster som tar emot XML-information från externa kunder/partner så öppnar vi också upp oss för en massa XML-attacker. Ett exempel är så kallade DOS-attacker där det kan räcka med att skicka ett enkelt XML-meddelanden som om det inte hanteras korrekt då sänker hela tjänster/servrar. Ett exempel är Billion Laughs attacken. Ett annat exempel är att skapa ett XML-meddelande med en massa (1000) name space deklarationer vilket gör att den stackars XML-parsern får problem. Grundproblemet är att vi låter våra applikationer göra en massa arbete innan dess att vi vet att meddelandena inte är det vi förväntade oss och då är det för sent. Lägger vi på WS-Security så innebär även detta att vi ytterligare ökar mängden arbete som behöver göras för att processa meddelandena. IBM:s lösning på problemet är att installera deras hårdvarubox DataPower som har hårdvara för att hantera XML och kryptering samt en inbyggd XML-brandvägg. Genom att sätta upp regler vilka typer av XML-meddelanden som accepteras (t.ex. att det högst får vara 100 name space deklarationer) och sedan processa meddelandena med en "tänkande" XML-parser så sparar man en massa jobb åt applikationen och förhindrar de flesta XML-attackerna. Det finns även utmärkt stöd för att hantera de olika WS-säkerhetsstandarderna för att på så sätt även slippa hantera detta i applikationerna.

Den allra häftigaste/dyraste versionen av DataPower har även stöd för att agera ESB och transformera meddelanden och konvertera mellan olika protokoll.

Enligt IBM bör alla som har viktiga tjänster som hanterar någon typ av XML utifrån Internet eller från externa parter köpa en DataPower-box och ställa framför tjänsterna. Efter att ha sett listan av olika XML-attacker samt vet hur prestandakrävande och svårt det är jobba med XML och säkerhet för Web Services så kan jag förstå hur dom tänker. Sedan blir det ju alltid en kostnads- och riskfråga om det är värt att investera i boxen, men att den skulle göra nytta på många ställen är helt klart.

IBM om open source

IBM har ett stort engagemang inom open source-världen, de har gott om advokater, mycket egen utveckling och många olika licens och distributionsformer. Sammantaget är det rätt intressant att veta vad IBM har för syn på att använda open source.

Innan IBM väljer att plocka in open source i sina produkter går man igenom en ganska omfattande lista med kriterier och väger för och nackdelar. Det man tittar på är saker som hur lätt är det att integrera med egen kod, hur aktivt community finns det, är licensen acceptabel i det aktuella sammanhanget, är koden "ren" osv. Timing är också viktig, en open source produkt måste finnas tillgänglig i rätt tid förstås, men också med rätt road map så man inte kör in i en återvändsgränd.

För IBM är smittad kod ett orosmoment, man vill absolut inte ta in kod där det är tveksamt vem som egentligen äger koden, eller där det finns risk att utvecklare sitter på flera stolar samtidigt. Därförs görs en omfattande granskning av kodens stamtavla, var kommer den ifrån, hur har den varit licensierad, vem har upphovsrätten till olika delar av koden. Även de som bidragit till koden kan granskas för att se om det finns risk att bidragen kod lånat för mycket av andra projekt som bidragsgivaren kan ha varit inblandad i. (Normalt tittar man kanske snarare på om ansvarig organisation själva har rutiner för att ta emot bra bidrag.)

Bra licenser, ur IBM:s synvinkel, är licenser där det klart framgår vem som har copyright och som ställer få krav på hur koden får användas. Exempel är BSD, Apache, CPL (förstås (eftersom IBM själva tagit fram den licensen)). GPL fungerar som ett virus, all kod som inkluderar GPL-kod måste lämnas tillbaka till GNU, och är överhuvudtaget en dålig licens, säger IBM, vilket jag hävdar en förenkling som är så grov att den kan jämställas med en ren lögn. Även CDDL verkar de ha "missupfattat".

Jag tror att vi som är aktiva i mindre företag kan komma långt bara genom att se till att använda open source som kommer från pålitliga organisationer som har råd att försäkra sig om att juridiken är under kontroll. En produkt som används av IBM, Apache eller SUN t ex, har troligen granskats av respektive legal department. Men det är, precis som när det gälla alla andra affärsbeslut, i slutändan upp till vår egen organisation att göra en avvägning mellan nytta och risk.

Upplägg och sMash in

Jag och Pierre deltog idag i en labb kring IBM:s nya produkt WebSphere sMash. Det produkten ska hjälpa till med är att på ett enkelt och smidigt sätt bygga MashUps, d.v.s. webbapplikationer som sammanställer information och funktionalitet från fler av varandra oberoende källor. Jag måste säga att jag tycker det är roligt att IBM satsar på en sådan produkt där de tekniker som främst används är dynamiska skriptspråk (de som stöds är Groovy och PHP) och Webb 2.0 tekniker (AJAX, REST, JSON, osv.), vilket kanske inte direkt är de tekniker som man förknippar med IBM. Att IBM gör denna satsning kan också hjälpa till att föra in t.ex. Groovy-applikationer in i drifthallarna hos större företag eftersom IBM kan bistå med support och underhåll av infrastrukturen.


Utvecklingen i sMash görs i en utvecklingsmiljö som körs i en webbläsare vilket gör att utvecklaren inte behöver installera någonting på sin egen maskin. Utvecklingsmiljön var faktiskt riktigt trevlig att arbeta i och eftersom den använder en massa AJAX så blev användarupplevelsen bra. Labben bestod i att skapa enkla REST-tjänster som hämtade och uppdaterade information ur en Derby databas samt att även leverera informationen med en ATOM feed. Enkelt och smidigt var det i alla fall när man hade labbinstruktioner att följa. Om du vill ladda ner och testa är det bara att gå till projectzero.org och ladda ner Silverstone M2 CLI. Installationen går snabbt och smidigt och bör inte ta mer än 10 minuter.

Jag var senare under dagen på en föreläsning där man visade applikationer man byggt med sMash och då man använt en massa AJAX-teknik, flera av dessa applikationer var mycket imponerande. Det AJAX-ramverk som IBM använder är Dojo med Dijits (widgets till Dojo) och Dojox (ytterligare utökningar till Dojo).

SOA Sandbox

I sin iver att driva SOA-utvecklingen framåt har IBM skapat en häftig tjänst de kallar SOA Sandbox. Det är en tjänst som består av två delar:

1. Info center - Detta innehåller en mängd information kring SOA, men framför allt patterns och best practices. Informationen baseras på erfarenheter från över 7000 kunder!
2. Software Trial - IBM ger gratis tillgång till en labbmiljö via Citrix där alla nödvändiga IBM-produkter finns förinstallerade. Med hjälp av labbar och guider (Eclipse Cheat Sheets) kan man enkelt prova att själv implementera SOA!

För att prova behöver man bara att ladda ner Citrix, registrera sig och sen logga in via webbläsaren. I fyra timmar kan man sen leka fritt i sandlådan!

Utöver detta ingår även SOA Configurations, vilket innehåller exempel på implementationslösningar. Varje konfiguration innehåller demos, arkitekturguider och implementationsguider. Antalet konfigurationer växer hela tiden.

Fem i rad!

Efter en förvånande mängd studier har vi tagit veckans IBM-certifieringar. Det blev fem stycken till slut inom områdena WebSphere MQ samt SOA.