SOA != WS

Inte för att jag söker jobb men var jag inne på Monster för att kolla av hur hett det är med SOA i annonserna nu för tiden. Söker man på SOA så få man upp det här resultatet.

Det intressanta med resultatet är att i många av annonserna så blandar man ihop SOA med WS.

Ex:

Kravprofil
Du bör ha erfarenhet av följande teknikområden:

.Net
SOA
XML
MS SQL eller annan relationsdatabas

Överlag är det konsultbolag som annonserar utvecklarkompetens som inte fått kläm på vad de frågar efter.

In english

Jag har skapat en blog på engelska med samma innehåll för att kunna nå en större publik från 3 stycken personer till förhoppnings fler :|

Virtualisering III

Vad man vill sträva efter är att virtualisera till den grad att det är hanterbart, vilket det inte riktigt är på objektnivån som virtualiseras i JVM eller CLR.

En annan virtualiseringsnivå än den JVM och CLR bidrar till är Web Services (WS). WS har en mycket speciell förmåga att virtualisera eftersom oberoendet är implementerat i det som kopplar samman WS i arkitekturen. Oberoendet finns i protokollet som binder samman Web Services istället för en runtime som WMware, Virtual Server, CLR och JVM baseras på.

Web Services sägs även kunna virtualisera funktioner i ett företag, dvs tjänster som ingår i en SOA. Genom SOA blir nyttjandegraden av funktioner i en IT-miljö väldigt hög samtidigt som rörligheten och möjligheten att hantera Web Service är i fokus.

Virtualisering II

Från förra bloggen om virtualisering så kan man ta med sig att virtualisering skapar ett oberoende till underliggande arkitektur som ger bättre rörlighet och resursutnyttjande genom metoder och verktyg för hantering av instanser som nyttjar de virtualiserade resurserna.

Frågan är nu på vilken nivå man ska virtualisera för att uppnå bättre rörlighet och resursutnyttjande?

Det finns flera nivåer av virtualisering och den enda förmågan en virtualiseringnivå måste ha är att den skapar ett oberoende till underliggande arkitektur. Det som de sedan skiljer dem åt är förmågan att låta sig hanteras. Operativsystem som kan köras i virtuella miljöer är en nivå där man kan uppnå ett högt resursutnyttjande av hårdvaran, men ett lågt resursutnyttjande av funktioner i operativsystemet. De olika s k gästerna i en hårdvaruvirtualiserad miljö är helt isolerade från varandra och delar inget annat än den underliggande hårdvaran.

Hårdvaruvirtualisering används främst då man inte vill röra de applikationer som kör på ett operativsystem. Har man däremot möjlighet att virtualisera på en högre nivå så ska man göra det eftersom det ger ett ännu bättre resursutnyttjande. Bättre resursutnyttjande är positivt i många bemärkelser, men kan ställa till problem i andra. Önskar man isolerade miljöer så ska man antingen inte virtualisera eller göra det på en hög nivå.

Virtualisering I

En IT-guy förknippar virtualization med produkter som VMware och MS Virtual Server medan en utvecklare främst tänker på JVM eller CLR. Vad båda försöker uppnå är att abstrahera bort ett beroende mellan två nivåer i arkitekturen. IT-killen virtualiserar för att på en operativsystemnivå skapa ett oberoende till underliggande hårdvara, medan kodaren skapar ett oberoende till underliggande operativsystem.

Oberoendet till underliggande arkitektur gör att man dels skapar än bättre rörlighet men även möjligheten till bättre resursutnyttjande. Rörligheten får man på grund av den lösa kopplingen som en instans eller objekt har till den underliggande arkitekturen. Graden av resursuttnyttjandet förbättras genom möjligheten att hantera den virtualiserade arkitekturen.

Hårdvara är inte en bristvara idag och det är inte dyrt att köpa. Men kostnaden för att hantera nyttjandet av hårdvaran är dyr samt att det är ett problem att migrera från äldre hårdvara till nyare. Virtualisering kopplar loss beroendet men bidrar även tillsammans med metoder och verktyg till en flexiblare hantering av resurserna.

Metoderna och verktygen handlar om att skapa en brygga mellan det IT-killen gör om dagarna och det utvecklarna hade i tanken med sin programvara. Microsoft kallar det för Managing Dynamic Systems och bygger upp ett förhållningssätt kring det som kallas Dynamic Systems Initiative (DSI). Till DSI kopplas ett antal modeller som ska supportera DSI beroende på vad som ska hanteras i en IT-miljö. En av modellerna är System Definition Model (SDM) som ska bidra till DSI för hantering av applikationer i distribuerade miljöer. En annan modell är Service Modeling Language (SML) som avser hantering av WS-* tjänster. Verktyg som bidrar till hanteringen är Microsoft Operations Manager och Virtual Machine Manager.

SOA möjliggör BPM

Ismael Ghalimi skrev för inte länge sedan en liten notis som jag snappade upp hur han ser på relationen mellan SOA och BPM. Nu utvecklar han sitt resonemang och det finns riktigt intressanta delar där för den som följer hur SOA och BPM växer fram som de två stora giganterna av buzzwords.

Värt att notera är att leverantörer av SOA-verktyg (ESB) ser BPM som en del av en SOA, medan BPM-folket ser SOA som en möjliggörare för BPM.

Det är A:et i SOA som gör det!

Om A:et i SOA står för den arkitektur som ger hanterbarheten av dina tjänster, innebär det då att enbart SO står för anarki? Ja, är det korta svaret jag har. Det långa är att SO har en historia, inte så lång, men väldigt ärorik. SO fick t o m ett antal lärosatser eller axiom som i många sammanhang fick alldeles för stor betydelse. SO slog på kort tid sönder och samman OO som programmeringsmodell för distribuerade system. Det gjordes så bra att OOA inte fick en chans att bekänna färg mot SOA. Men egentligen har SO S:et att tacka för framgångarna, eftersom S:et lade grunden till segern.

S står egentligen för WS. Normalt sätt är det ingen som pratar om S:et i någon annan bemärkelse än WS och är det någon som gör det så anses det vara av akademiskt betydelse. Ser man till WS historia så är det där man kan hitta svaret på framgången, nämligen W. Egentligen är det i W (som i Web eller i folkmun WWW) som vi hittar sanningen bakom framgångssagan. WWW har öppnat dörren för SO som programmeringsmodell och gjort den till vad den är idag. Det är WWW som SO bygger sitt fundament uppå.

WWW, ett virrvarr av hemsidor som slukat mängder av domänadresser, upptagit miljoner IP-adresser, konsumerat enorma mängder bandbredd, påverkat ungdomar negativt. Ja, listan kan göras lång för det är en anarki som råder där. WWW var en disruptiv teknologi som slog undan benen på allt och skapade en ny värld av möjligheter. Nu är vi på samma nivå med en teknik för distribuerade system som alla världens kritiska affärssystem och transaktionssystem ska använda in i framtiden. Är det så illa? Nej, är det korta svaret. Det långa är ja, om vi låter anarkin få fortsätta råda. Låt istället varje S vara en del av en SOA, tänk WWW när du bygger dina applikationer med SO men glöm aldrig att det är A:et i SOA som gör det.

WCF - för bra för ditt eget bästa?

Windows Communication Foundation (WCF) kommer att vara den mest utbyggbara implementationen av en Web Service stack som sätt ljuset när den till slut släpps med .NET Framework 3.0. Med WCF är det möjligt att förändra hela sekvensen som ett meddelande går igenom, från början av en endpoint ned till implementationen.

Men bara för att det är möjligt så betyder det inte att man ska använda sig av den möjligheten. Har det varit något du intresserat dig av tidigare när du exempelvis programmerade COM-objekt? Det var inte ofta man behövde implementera custom marshalling för att på så vis kunna styra över serialisering, encoding, routing, säkerhet i DCOM. Lita på mej, det är inte något som bör intressera dig (som tjänsteutvecklare) nu heller, även om det är lika enkelt som att andas luft (jämfört med DCOM).

Vad som däremot är intressant när man har ett antal tjänster är att skapa en SOA som bygger på att man kan administrera sina tjänster på en högre nivå och då kommer fördelarna med WCF in i bilden. I en SOA är det viktigt att kunna skapa nya versioner (förändra address, binding, etc) av tjänster. Man vill även kunna skapa virtuella kontrakt som passar en grupp av konsumenter. Routing, för att kunna distribuera anropen baserat på policies eller andra villkor. Transformering, att kunna modifiera meddelandet på vägen genom WS-stacken. Det är mängder av olika anledningar (och jag ska återkomma till fler framöver) till att kunna hantera sina tjänster och det är det som är anledningen till att WCF är så flexibelt.

Motsatsen till en SOA är att ha lite tjänster här och lite tjänster där, vilket tillslut blir ohanterligt. Det betyder heller inte att man ska bygga administrativa verktyg genom möjligheterna med flexibiliteten i bl a WCF. Det finns sådana produkter och det är dessa man ska använda sig av. Amberpoint är en leverantör av administrativa produkter för en SOA som även kan skapa hooks till andra implementationer än WCF. På så sätt får man en central dashboard av funktioner för att administrera sina tjänster oavsett plattform. Tillskillnad från Amberpoint så finns det produkter (BizTalk, Enterprise Service Bus) som kräver att alla tjänster ska implementeras i verktyget för att kunna administrera dom, vilket inte är troligt att man önskar i en heterogen värld.

Så tipset är att bygga tjänster som är hanterbara och där kontrollen ligger i verktyg som administrerar dina tjänster och inte i genom hemmasnickrade hooks till WCF.

Är SOA vägen till instabilitet?

Jag tänkte säga emot mig själv i den här posten angående förträffligheten med en SOA.

SOA är arkitekturen som ska göra delarna i arkitekturen nåbara, återanvändbara och hanterbara. De två första målen är inte så nya inom mjukvaruindustrin eftersom alla typer av distribuerade teknologier har strävat efter att göra komponenter nåbara på ett nätverk eller mellan processer och återanvändbara för andra applikationer. Däremot så är hanterbarhet något som en SOA ska uppfylla och göra möjligt, men är det något gott eller kan det missbrukas?

Med hanterbarhet menas möjligheten att centralt kunna gruppera sina tjänster, versionshantera, styra om, ändra policy, binding, adress, etc baserat på meta-information för varje tjänst. Hanterbarhet eftersträvas för att få en lättrörlighet och god ordning av alla länkar mellan delarna i arkitekturen.

Hanterbarhet kan göras omöjligt genom hårdkodning, hårda kopplingar mellan komponenter och properitära format. Hårdkoda som att spara adressen till en COM komponent eller Connection String i koden. Hårda kopplingar som mellan två komponenter med samma typsystem. Properitära format som mellan två komponenter som pratar RMI över IIOP.

Web Service är en nödvändighet för en SOA eftersom det möjliggör hanterbarhet. Men är det hanterbarhet vi vill ha? Vem är det som kommer att hantera alla kopplingar som tidigare var gömda i en svart låda. Har man inte alltid sagt att "rör inte det som fungerar"?

Tänk dig en framtid där alla kopplingar mellan tjänster kan administreras från en punkt. Där ska då IT-gubbarna (kanske till och med affärsfolk) sitta och mecka runt med dina tjänster och byta policies on-the-fly. Är det överhuvudtaget mänskligt att kunna administrera IT på det här viset, eller är det bara en utopi som istället kommer visa vägen till instabilitet?

ORMen som kröp iväg

Innan jag skrev den här posten så stängde jag av mina Comments för att inte riskera att blir bränd på min egen blog ;) Nja, anledning till att jag knäppte av det beror på att det inte kom in några kommentarer ändå. Jag ska inte chockera på samma sätt som Ted Neward gjorde i sin jämförelse mellan Vietnamkriget och O/R-mappare i The Vietnam of Computer Science utan mer visa på vilken liten betydelse ORM spelar i den processorienterade världen.

ORM (Object Relational Mapping) som är en teknik för att länka den objektorienterade världen med relationsdatabaser har fått en rejäl uppmärksamhet bland applikationsutvecklare runt omi världen. O/R-mappare kallar man implementationen som hanterar den kopplingen och det finns mängder av sådan, mer eller mindre lyckosamma (många blev inte mer än betor men läs mer om det på Ted N blog). Det finns lika många förespråkare av O/R-mappare som det finns motståndare. Jag o andra sidan är motståndare till allt som delar upp åsikterna i två lika stor läger. Men det är inte det jag kommer att trycka på nu, utan den egentliga nyttan av O/R-mapparen i en applikation.

Jag skrev tidigare en post om hur data representeras och hanteras i processdriven utveckling (Processdriven utveckling IV – Data). Det viktiga att ta med sig därifrån var att processen skyddar datat, dvs att den information som direkt hör till en process skyddas av den samma. Det finns bara ett sätt att få åtkomst till datat och det är genom processen. System som definierar och hanterar processer kallas för BPMS (Business Process Management Systems) som har en speciell egenhet, de hanterar nämligen processens tillstånd och dess data under hela transaktionen (processens livstid) utan att man behöver implementera datalagring.

Det är inte O/R-mapparen som i första hand tappar sin betydelse utan objektlagret i ett transaktionssystem. Objektlagret bygger på att datat är centralt och åtkomligt av vem som helst, när som helst under en transaktion (LRT). Vissa begränsningar kan läggas in, men det implementeras i så fall inte i objektlagret eller i O/R-mapparen. Relationsdatabaser är också datacentriska och faller in under samma kategori av oordnad data access.

Men i processorienterad utveckling är datat sekundärt och följer bara med processen som här är central. Om och när processen serialiseras och persisteras är upp till varje BPMS. Visst kan processen (inkl data) persisteras till en relationsdatabas, men det är inte relevant eftersom man ändå inte har access till den informationen under processens livstid. Men när processen är klar så kan man självfallet lagra undan datat i en relationsdatabas, men då mer av historisk betydelse.

Jag skulle gissa att om inte lång tid framöver när WF, BPEL och andra BPM-verktyg slår igenom och processorienterad utveckling blir vanligare bland applikationsutvecklare så kommer intresset för O/R-mappare och relationsdatabaser att svalna rejält. Databaser blir mer av nytta för Data Warehousing än för transaktionssystem och objektlager får en mindre betydelse.

BAM - att se in i en transaktion

Ett problem med Business Intelligence (BI) och OLAP är att man inte har tillgång till den färskaste information för analys. I en verksamhet görs många beslut baserat på olika analyser av den information och data som förekommer i diverse databaser och system. Det kan vara beslut som förändrar exempelvis en affärsprocesser därför att den visat sig vara ineffektiv. Det kan även vara kostnadsbesparingar baserat på analys som visar att vissa resurser inte nyttjas fullt ut. Den informationen som används för att dra dessa slutsatser bygger på data från OLTP-system i verksamheten. Data hämtas in (ETL) till ett OLAP-system från bland annat dessa OLTP-system där informationen aggregeras in i OLAP-kuber. Analysen bygger på datat som finns i dessa kuber och presenteras på olika sätt i olika verktyg.

BI baseras på information som skapats av avslutade transaktioner. Den mest färska information som finns att tillgå finns inom transaktionerna. Informationen som befinner sig mitt i en transaktion är ofta inte tillgänglig för hämtning för att man inte vill vill störa transaktionerna. Vi pratar då inte om ACID transaktioner utan om långa transaktioner (Long Running Transactions). Det kan exempelvis vara en faktureringsprocess där den avslutade transaktionen ger uppgift om hur faktureringen gick efter det att den avslutats för en viss kund. Den informationen kan då komma att bli underlag för BI. Men vad man inte får är uppgifter om faktureringen under själva transaktionen.

Business Activity Monitoring (BAM) kallas det för när man analyserar tillståndet inom en transaktion. BAM ska analysera information som behövs snabbt för att hinna göra snabba förändringar. Det kan exempelvis visa sig att orderingången ökar kraftigt så att man därför snabbt behöver beställa nödvändiga varor från leverantörerna. BAM förknippas med BPMS (Business Process Management Systems) som exempelvis BizTalk. Dessa system bygger upp processbeskrivning mha aktiviteter som i runtime sedan kan monitoreras genom BAM. BAM kommer i dessa system som en komponent och är en av de mest dramatiska förbättringar man får med processorienterad utveckling och BPMS.

Ajax - Del II

Så vilka krav ställer SOA på Ajax om det nu ska vara en frälsare som kommer med något nytt till den krampaktiga ställning webben befunnit sig i sedan sent 90-tal?

De första Ajax-applikationerna använder säkert den nya tekniken för att dra fördelar av den asynkrona kommunikationen. Detta är ju knappast något nytt eftersom man har kunnat göra det i vilken .NET, Java eller Win32 applikation som helst innan. Ett stort steg för webben dock.

Ajax implementeras alltså som ramverk som anropar Web Services från Javascript i browsern. Anropen mellan browsern och ramverket är asynkrona, vilket betyder att man får hantera resultatet från anropet i en event handler. Vad Ajax däremot inte supporterar är asynkron kommunikation mellan ramverket och servern eftersom Ajax inte själv kan sätta upp en endpoint och därmed finns ingen väg tillbaka från servern.

Bristen på en asynkron kommunikation mellan ramverket och en Web Service omöjliggör vissa scenarios som är vanliga i en SOA.

Scenario 1 - Callbacks
Callbacks används vid asynkron kommunikation mellan 2 parter. En part gör ett tjänsteanrop till en annan part som tar lång tid på sig att utföra jobbet och därför erbjuder sig att göra ett anrop tillbaka till den anropande parten då den är klar. För det krävs att bägge parter kan kommunicera med den andra.

Scenario 2 - Events
Events avser kommunikation från en part till en annan då specifika händelser inträffar som ska notifieras (ex. genom WS-Eventing). Om en part ska kunna prenumurera på händelser som inträffar hos en annan part så måste händelserna kunna kommuniceras till en service endpoint.

I och med att Ajax inte kan sätta upp en Web Service endpoint så kommer webbapplikationerna fortfarande att leva utan dessa scenarios. Ska Ajax spela en större roll i framtiden så måste dessa supporteras. Idag finns det omvägar för den som önskar 2-vägskommunikation. Man kan använda sig av protokoll som stödjer full duplex för att kommunicera fram och tillbaka eller pollning där man frågar servern om något nytt hänt vid jämna intervall. Det finns även ramverk som sköter pollningen åt dig (Periodic Refresh).

Men så länge Ajax inte stödjer service endpoints så är det inte att betrakta som varken en disruptiv teknologi eller något stort teknikskifte för webben.

Funktioner jag vill ha i min Zune

Efter att ha använt en iPod Video under en tid så skulle jag önska följande funktioner för min Zune:

• WiFi - jobbigt med synkronisering från PC/USB
• RSS Reader - saknas i iPod men något man använder dagligen
  
• Mail - saknas i iPod och borde klara sync med Exchange
• GPS Navigator - en feature som borde byggas in
• Podcasts - finns i iPod och blir allt vanligare
• Videocasts - finns i iPod och på nätet men mest i ostrukturerad form (ex. Channel9)
• Media Player - mp3, mpeg, etc
• Recorder - för audio, video, photo
• Phone - antar att Skype inte installeras men något liknande alla fall
• Spel - det ultimata tidsfördrivet
  

Ajax - Del I

Efter lite latjo med Ajax (Atlas för ASP.NET) den senaste tiden så börjar man se igenom hypen och sortera bort det som mest är förhoppningar för att istället se till möjligheterna.

Rent tekniskt så ger Ajax din browser möjligheten att asynkront anropa web services via javascript. Det förhöjer först och främst användarens upplevelse av web applikationen eftersom klienten inte behöver att ladda om sidan eller ramen, vilket gör det grafiska gränssnittet mer responsivt och lättarbetat.

Men kommer Ajax med något nytt?

Dels kan man dra ganska stora växlar på att det öppnar upp vägen för Web 2.0 (allt som skrivs som "pick-a-technology" 2.0 står nämligen för något disruptivt). Bland annat ser man Ajax som en dörröppnare för Office 2.0 (hehe) där alla dina Office-dokument, -applikationer och -favoriter finns åtkomligt var du än befinner dig. Man ser även Ajax som ett hot mot traditionella operativsystem som Windows, Linux eller MacOS (OS 2.0, känns inte det igen föresten ;)).

Nej, det är nog att begära alldeles för mycket av en teknik. Att Ajax ska kunna slå undan benen för operativsystemen och de etablerade programvaruhusen är en utopi som Google mfl delar. Viktigt dock att det finns en dröm ...

Vad som däremot gör Ajax intressant är förmågan att kunna prata Web Services. Just av den anledningen att Web Services används för kommunikation (mellan browsern och servern) gör att Ajax blir en naturlig del av en SOA.

CBE™

:)

Coordination Patterns

För inte länge sedan tog jag del av CCR och fick då en förhoppning om att även utvecklare ska börja tänka processorienterat mha av detta ramverk. Fundamentet för processorienterad utveckling handlar nämligen om koordinering av asynkron meddelandehantering. Med det menas att kunna kontrollera inkommand och utgående kommunikation till och från processen.

CCR är ett ramverk till C# 2.0 och kan jämföras med bland annat CSP för Java, men även med BPEL. CCR är en bredare produkt som tillsammans med C# kan användas i många fler sammanhang än orkestrering av web service, som är BPELs huvudsakliga uppgift.

Men låt oss ändå jämföra hur BPEL och CCR utmanar 2 vanliga koordineringsmönster. För fler mönster som relaterar till workflows och meddelandehantering se här och där.

Racing Incoming Messages Pattern

En instans ämnar ta emot fler än ett inkommande meddelande, men är bara intresserad av det första. Exemplet nedan visar hur man enbart tar emot det först inkommande budet på en auktion.

BPEL:

<pick>
 <onMessage operation="receiveBet" partnerLink="partner1" 
     portType="port1" variable="bet1">
  <!-- Handler code belongs here -->
 </onMessage>
 <onMessage operation="receiveBet" partnerLink="partner2" 
     portType="port2" variable="bet2">
  <!-- Handler code belongs here -->
 </onMessage>
</pick>

CCR:

Arbiter.Activate(taskQueue,
 Arbiter.Choice(
  Arbiter.Receive(true, port1, receiveBet1),
  Arbiter.Receive(true, port2, receiveBet2)
 )
);

Synchronization Pattern

I ett parallellt flöde behöver man synkronisera två eller flera sekvenser. Exemplet nedan visar hur man låter båda budgivarna få en chans att bjuda i auktionen.

BPEL:

<flow>
 <links>
  <link name="bet1" />
  <link name="bet2" />
 </links>
 <receive name="receiveBet1" operation="receiveBet" 
     partnerLink="partner1" portType="port1" variable="bet1">
  <source linkName="bet1"/>
 </receive>
 <receive name="receiveBet2" operation="receiveBet" 
     partnerLink="partner2" portType="port2" variable="bet2">
  <source linkName="bet2"/>
 </receive>
 <anyBPELActivity>
  <target linkName="bet1"/>
  <target linkName="bet2"/>
 </anyBPELActivity>
</flow>

CCR:

Arbiter.Activate(taskQueue,
 Arbiter.JoinedReceive(true, bet1, bet2, anyHandler)
);

Vilket språk föredrar du?

Choreography vs Orchestration och fotboll

Ibland stöter man på orden Choreography och Orchestration när man pratar om processer. Koreografi handlar om att koordinera rörelser (dans), medan dirigera (orchestration) handlar om att skapa musik från toner med hjälp av flera instrument. Medan dans inte är en lika exakt konst, så är musik desto mer komplex i sin sammansättning. Dans ger utrymme för kreativitet, medan musik som dirigeras styrs av dirigenten. En dansare kan avvika från koreografin utan att skapa oreda, tillskillnad från orkestermedlem som om han avviker blir mer påtagligt.

Jämför med fotboll, som är en koreografi där spelarna ofta använder sin kreativitet för att föra bollen till mål. Om fotboll skulle dirigeras skulle det bli ganska förutsägbart, vilket säkert också skulle gynna motståndaren.

En affärsprocess o andra sidan kan antingen definieras genom koreografi eller dirigering, beroende på kulturen i affären. En affär som toppstyrs har ofta en företagskultur där man med respekt för komplexiteten dirigerar hur processerna skapar "musiken". En kultur där man istället låter ansvaret för processerna ligga hos de ingående delarna, utnyttjar kreativitet bättre.

Det är lätt att se att den kultur vi är vana vid i sverige, är den som förespråkar kreativitet och koreografi framför dirigering. Dirigering ser vi ofta utomlands ibland företagskulturer där. Varför det är på det viset kan du läsa om här.

Företagskulturen i sverige smittar även av sig på utvecklaren. Han vill ha frihet att kunna jobba på ett kreativt sätt. Han vill inte dirigeras och jobbar helst inte med verktyg och språk där den designmodellen premieras. I sverige är det exempelvis ingen som intresserar sig för BPEL (som en branchkollega mycket vänligt upplyste mig om). Kanske kan Culture-Driven Design som jag försökte införa som begrepp bli något att ta hänsyn till som arkitekt?

Gick det bra för Volvo att lämna löpandebandet och jobba mer med arbetslag som skulle främja kreativiteten?

BPM vs SOA

Jag läste en blog från Ismael Ghalimi där han positionerade BPM och SOA som två sidor av samma mynt.

"BPM is SOA’s killer application, while SOA is BPM’s enabling infrastructure."

(nu handlade egentligen den bloggen om middle-out eller top-down, men än då)

Asynkron koordinering med CCR

I XOML eller BPEL så är asynkron koordinering av kommunikation första klassens medlemmar.

CCR (Concurrency and Coordination Runtime) ger C#-utvecklare samma möjlighet till detsamma.

SOA 2.0

Web 2.0, Office 2.0 och nu SOA 2.0 visar att man kan sätta versionsnummer även på arkitekturer.

Åsikterna går i sär och är du en av dom som inte gillar det så skriv då på ett anti-SOA 2.0 petition.

BPEL vs WF

Om vi tar med oss jämförelsen från förra bloggen om Aktiviteter och tjänster, alltså att:

"Man kan alltså säga att processer består av aktiviteter som i sin tur kan, men behöver inte, nyttja andras resurser och tjänster."

Utifrån det så kan man se skillnaderna mellan Workflow Foundation och BPEL4WS mycket mer tydligt.

WF stämmer mycket väl in på beskrivningen ovan efter som man har ett val att i implementationen av ett workflow/process välja om man vill nyttja andra tjänster för arbetet som krävs i en aktivitet eller utföra arbetet själv. Möjligheten ligger i förmågan hos WF att nyttja XAML som är flexibelt på så sätt att det går att bygga ut som språk. Man kan alltså skapa aktiviteter som kan utföra vilket arbete som helst med dina egna resurser.

BPEL4WS o andra sidan stämmer delvis in i beskrivningen ovan. BPEL måste nyttja tjänster och kan inte själv klara av det arbete som en aktivitet kräver (med undantag av mycket enkla sådana). BPEL är inte som XAML utbyggbart utan förlitar sin flexibilitet till tjänsteutnyttjande.

Aktiviteter och tjänster

I workflow-sammanhang så nämns ofta ordet aktivitet, exempelvis i Workflow Foundation från Microsoft. Ordet tjänst och andra sidan känner vi från då man exempelvis pratar om Web Services, men även i vanligare sammanhang som att utföra ett jobb åt någon annan. Men, vad har de med varandra att göra?

För att förklara det så måste vi se till ordet process som är nära besläktat med workflows. En sökning i wikipedia på ordet process ger följande:

”De aktiviteter som genomförs för att åstadkomma en förändring av ett objekt över tiden.”

Söker man på susning.nu efter ordet aktivitet ger det:

”Aktivitet är en händelse i tid, som involverar en eller flera resurser”

Som vi väl känner till så kan ordet arbete även representera det som händelsen resulterar i.

Kommer vi då även till ordet tjänst så säger susning.nu:

”En tjänst är ett visst arbete som utförs till nytta för någon annan.”

Man kan alltså säga att processer består av aktiviteter som i sin tur kan, men behöver inte, nyttja andras resurser och tjänster.

Processdriven utveckling IV – Data

Processorientering innebär att det är processen som kontrollerar access till och skyddar datat. Vilket data? Jo det som direkt hör till processen. I en faktureringsprocess så är det fakturainformationen som kontrolleras, ex det fakturerade beloppet eller faktura- och förfallodatum. Dit hör inte produkt- och kundinformationen, som även den står på en utskriven faktura. Produkt- och kundinformationen har sina egna processer där data skyddas.

I en klassisk arkitektur skyddas informationen enbart av en databas under korta transaktioner (ACID). Men under en längre tid, som t ex en faktura lever innan den betalats, kan data vara åtkomligt för vilken process som helst och ligger helt oskyddad för förändringar. Samma sak gäller diverse objekt-ramverk (ex. Spring el. EJB). Där görs fakturaobjektet åtkomligt för vilken process som helst under en fakturas livstid. Man kan ändra tillståndet i vilken ordning man vill och från vilken process som helst.



I ett processorienterat perspektiv skyddas fakturan (entiteten) under processens livstid. All access till fakturan går via klara definierade regler för vem och när de kan få tillgång till fakturainformationen och förändra dess tillstånd.



Man kan se processen som en pipeline där bilderna ovan är tvärsnittet av den skyddande processen. En pipeline har definierade access-punkter (end points) som rent semantiskt beskrivs i en processdefinition eller ett processpråk (BPEL4WS).

Repetetiva processer

När man jobbar med workflows stöter man ofta på delar av eller hela flöden som repeteras efter varandra. Det kan exempelvis gälla en fakturering där man sänder iväg fakturan första gången för att senare sända den på nytt inkl en förseningsavgift.

Anta ett sekventiellt flöde som består av 3 aktiviteter:

A - som utför ett jobb
B - som avgör om A ska köras igen eller gå till C
C - som också utför ett jobb

I processflöde så är det här ett vanligt scenario som kan implementeras på fyra olika sätt:

1. Repetetivt
2. Iterativt
3. Rekursivt
4. Separat

Repetetivt
Repetetivt innebär att flödet implementeras som en tillståndsmaskin där B avgör om A skall utföras på nytt. Den här typen av flöde utförs i en och samma instans, vilket är bra ur prestanda synpunkt. Ett problem är att det inte ger en tydlig bild över hur tillståndet har förändrats med tiden.



Iterativt
Iterativt liknar repetetivt men tar hjälp av iterativa aktiviteter som en While-sats.



Rekursivt
Rekursion innebär att processen anropar sig själv vilket skapar nya instanser för varje anrop. Det gör det enklare att spåra flödet men komplicerar och är mer krävande ur prestanda synpunkt.



Separat
Separata processer är det tydligaste alternativet och passar om det inte gäller för många repetioner. Här blir det enkelt att spåra flödet och komplexiteten är obefintlig, vilket är viktigt på en högre nivå.

SOA stort i Tyskland

Jag sökte på Monster för att se vad som var hett idag. Sökorden var SOA, C#, Java, BPEL och EAI för några EU-land. Första tabellen innehåller summa träffar och den andra hur de förhåller sig procentuellt till varandra per land.

Vi ska se hur det ser ut om några månader, men jag vågar tippa på att SOA och BPEL har ökat några procent.

Svenska SOA-kurser

Här är ett par SOA-kurser i Sverige (kan inte garantera kvalitén dock):

• Init
• Cornerstone
  
• Learning Tree
  
• Astrakan
  

Kan ni tipsa om fler? Kanske frukostseminarier eller konferenser i Sverige!

Active Endpoints har en beta för ActiveBPEL Enterprise på .NET Framework

Nu finns det en BPEL engine (native) värd namnet på .NET.

Besök gärna SweNUG den 17/5 i Stockholm för att se en presentation av ActiveBPEL och en jämförelse med Workflow Foundation.

Processdriven utveckling III – Språken & verktygen

Ett processhanteringsverktyg måste smälta samman med tekniken för att få fotfäste. Med tekniken menas den värld som utvecklare är van vid (.NET Framework, Java, Web Services, C#). Idag finns det varianter på processhanteringsverktyg men de kan grovt delas i att antingen strikt följa en standard eller inte.

De som väljer att inte följa en standard öppnar dörrarna till tekniken mer än de som följer standarder. De som följer standarder som exempelvis BPEL4WS drar teknikgränsen tidigt medan exempelvis Microsofts Workflow Foundation (WF) är öppnare och tillåter till och med utvecklaren att definiera sitt eget domänspecifika processhanteringsspråk. Oavsett vilken tekniknivå man valt med sin miljö för processorienterad utveckling så måste den supportera kraven på tillståndshantering, händelser och affärsregler.

I Workflow Foundation styrs flödet av XAML (Extensible Application Markup Language) som ser ut som XML och består av en del som är själva språket (Markup Language) och en annan del som kallas aktiviteter och syftar till Extensible Application. I BPEL4WS finns också en del som är själva språket och en annan som representerar aktiviteten. Det är bara det att i BPEL4WS finns det bara en aktivitet representerad, nämligen Web Services. Vill man i Workflow Foundation skapa en aktivitet som kan maila iväg en statusförändring så implementeras det som en .NET klass. I BPEL4WS så anropar man istället en Web Services som skickar iväg mailet.

Varför har den större delen av industrin valt att följa BPEL4WS medan Microsoft valt ett eget språk? Först av allt så ska sägas att Microsoft Workflow Foundation kan deserialisera BPEL4WS och inte bara XAML. Många menar att utvecklaren måste kunna skapa egna aktiviteter för att producera ett workflow, medan andra tycker att det man kan göra i aktiviteten lika gärna kan göras i en Web Service.

Processdriven utveckling II - Lösningen

Applikationer består bland annat av information, dess tillstånd, händelser och affärsregler. Men det finns en komponent som saknas här, nämligen definitionen av den ordning som händelserna inträffar (processen).

Processer är till för att styra och kontrollera händelseförloppet för tillståndförändringar i informationen. När man sitter ned och ska modellera informationen och dess tillstånd så utgår man alltid från hur flödet för information ser ut. Från flödet definieras sedan status som informationen kan anta. Därefter förkastar man processbeskrivningen och den blir sällan mer en ett Visio-dokument.

Att utveckla processorienterat handlar om att fortsätta med processbeskrivningen och aldrig jobba med tillstånden som statuskolumner, utan bara som positioner i ett flöde. Processorienterad utveckling handlar om att använda sig av händelser, tillstånd och affärsregler som första klassens medlemmar.

Varför har man då inte jobbat processorienterat? Bland annat beror det på just det att det kräver en förståelse för verksamheten för att inte låsa in sig i processer som inte kan följas. Det beror även på att det inte funnits de rätta verktygen, eller att det inte fått så mycket uppmärksamhet eller att verktygen varit undermåliga.

Processdriven utveckling I - Problemet

9 av 10 applikationer som jag varit med att utveckla har handlat om att hantera information i någon form. Varje gång så bygger jag en datamodell, GUI och ett objektlager om man orkar. Oavsett om man väljer att designa objekt- eller datamodellen först så står man inför det faktum att informationen ska definieras och modelleras.

Information generellt sätt ändrar sitt tillstånd med tiden. Det kan gälla en faktura, en inköpsorder, ett ärende eller ett betalningsuppdrag. Normalt sett tillför man därför ett antal statuskolumner i sina tabeller/objekt för att lagra tillståndet. En faktura definierar tillstånd som bl a beskriver om den skickats till kund, blivit krediterad, förfallit, skickats som påminnelse, blivit betalad eller delvis betalad. Tillstånd förändras med tiden och beror på händelser som inträffar inom och utanför applikationen.

Händelser kan implementeras på olika platser i applikationen. En faktura som förfaller kan implementeras i databasen som en trigger. En faktura som krediteras ändrar sitt tillstånd från ett formulär i GUI. En faktura som betalats ändrar sitt tillstånd på uppdrag från en Web Service. Man kan säga att händelser inträffar i många olika delar av applikationsarkitekturen som i sin tur påverkar tillståndet hos informationen.

Varje händelse inträffar då ett villkor uppfylls, en s k affärsregel. Affärsregler avgör om en faktura har förfallit eller om den betalats eller delbetalats. Villkor består av uttryck som sätts samman av operatorer och operander. Operanderna är information om fakturan och nyckeltal som styr över gränsvärden.

I vilken ordning som tillstånden förändras håller man däremot relativt öppet för tolkning. Ordningen kan oftast ändras från fall till fall och man låter det bero eftersom det känns stelt att definiera en process som passar alla scenarios. Bygger man applikationen på det här öppna sättet är det relativt enkelt att ändra tillståndet i valfri ordning istället för att hålla sig till en strikt hantering. Det är mycket vanligt att man har en öppenhet till att kunna ändra tillståndet för information med tiden, men varför är det så och vad är alternativen?

When money talks SOA ...

Har haft en liten konversation med WS-gurun David Chappell på hans blog. Det handlade om arkitekters och IT chefers relation till applikationer och tjänster. David har nog rätt i att de med pengarna har sin syn på SOA medan arkitekter har en annan. Vi är dock bara i startgroparna med SOA. På lång sikt är jag säker på att tjänstenätverket går segrande ut striden och inte den traditionella applikationen.

Service Oriented Architecture Conference 2006 Sweden

Anmäl dig här!

SAP NetWeaver

Efter att ha lyssnat på Dag Königs podcast med Lars Lindberg från SAP inser man vilket fotfäste SOA och öppna standarder har fått. Med NetWeaver tar SAP steget från bilden av det monolitisk ERP-systemet till en rörlig sammansatt arkitektur. Tidigare versioner av SAPs affärssystem har visserligen varit moduluppbyggt, men med NetWeaver har man skapat en plattform för exekvering, underhåll, managering, monitoring av affärsprocesser som öppnar sig med 10 tusentals tjänster.

Vad man också kan snappa upp från intervjun är SAPs vision att NetWeaver ska bli en plattform för att bygga nya komposita processer för olika verksamheters behov. Det innebär att de konkurerar mer och mer med teknikleverantörer som IBM, Oracle och BEA. Partners eller kunder ska kunna förändra och skapa nya processer ovanpå NetWeaver som bygger på öppna standarder som BPEL, SAML och WS-*.

SAP har kommit så långt inom SOA området eftersom visionen med just SOA härstammar från deras egen bakgård. Man kan säga att det är på grund av SAP som behovet på rörlig arkitektur har uppkommit ;).

Vilken roll SAP spelar gentemot BEA, Oracle, MS och IBM kommer snart att visa sig.

Ska man kunna ett eller flera språk i framtiden?

C# 1.0 släpptes som RTM i februari 2002 och innehöll ett språk lika utvecklat som flera generationer Java. Alldeles nyligen släpptes C# 2.0 som innehåller bland annat generics, anonymous methods och iterators. Om ett tag kommer C# 3.0 med lambda-uttryck, extension methods, anonyma typer och query expressions. Spännande kan man tycka, men varför utvecklas ett språk så mycket på en plattform som är byggd för att kunna köra program utvecklade i vilket språk som helst (bara det finns en kompilator)?

Glömde nämna C# 4.0!

Nu var det inte C# jag tänkte på utan programspråk i allmänhet och BPEL i synnerhet. Java förstår jag om man utvecklat med tiden eftersom varken Java-utvecklare eller Java-miljöer kunde något annat eller hade förmågan att kommunicera utanför Java-domänen.

BPEL 1.0 har fått mycket stryk för att inte kunna stå upp mot de krav som finns på flödesorienterad utveckling. Läs exempelvis David Chappells punkter:

• BPEL kan inte aktivera lokala objekt.
• BPEL kan bara kommunicera genom Web Services.
• BPEL kan inte kommunicera direkt med relationsdatabaser.
• BPEL kan inte kommunicera med människor.
• BPEL kan inte distribueras som en assembly

Precis som Chappell säger så var det inte meningen att BPEL skulle kunna något annat heller. Han menar ändå att BPEL inte har någon plats eftersom det saknar så pass mycket verklighetsförankring till den värld den ska styra flödet över. Så vad inte Chappell skriver, men som framgår tydligt är att XOML (Windows Workflow Definition) har det BPEL saknar.

• XOML kan aktivera lokala objekt
• XOML kan kommunicera med andra XOML
• XOML kan distribueras som .NET assemblies
• XOML kan anropa .NET kod och kan därför göra "allt" inkl anropa en databas
• XOML kan kommunicera med människor eftersom det kommer som en del i Office 12 :-)

Samtidigt som C# byggs ut för att kunna ersätta alla andra programspråk (dynamiska, logiska, funktionella etc) så släpps snart BPEL 2.0 med stöd för vissa av de "brister" som Chappell pekar på. Varför ska ett språk som konstruerats för ett visst syfte behöva uppfylla en massa annat som inte har med visionen för språket att göra? Varför kan man inte använda BPEL till det det är till för och istället uppfinna andra språk som uppfyller andra ändamål?

Hur som helst så får vi med Web Services samma fördelar som med .NET, dvs att kunna välja programspråk fritt efter behov. .NET är en stabil plattform för att bygga applikationer och tjänster på, men den är inte ett krav för att bygga sammanhängande arkitekturer i framtiden. Säger man Web Services idag så tänker man på interop mellan olika tekniska plattformar. Det är sant, men i framtiden kan WS vara det som knyter samman olika domänspecifika språk (se även). Kan man inte skapa nytta med .NET som plattform så får vi ändå hoppas att Web Services uppfyller det.

Wolfram Meyer pratar SOA

http://www.microsoft.com/sverige/msdn/msdntv/?category=SOA

Insikter om SOA under 2006

1. Verksamhets- och tjänsteperspektiv
En SOA har inget med teknik att göra, Web Services möjliggör bara (då de inte försvårar). Visionen med en SOA är att IT-stödet ska mappa 1-1 mot tjänster i verksamheten för ökad rörlighet i din Enterprise Architecture (EA).

2. SOA = Tjänster + Processer + Aktiviteter
En SOA består av tre pelare 1) tjänster som omfattar 2) processer som består av 3) aktiviteter. Produkter som implementerar stöd för SOA-paradigmen kallas Enterprise Service Bus.

3. Applikationen vs meta-applikationen
Det onda i en EA är applikationerna. EAI knyter samman applikationer och vittnar bara på ett sjukdomstillstånd. SOA knyter samman tjänster som supporteras i form av meta-applikationer.

4. Bygg inte ut integrationsramverket till en SOA
En SOA ska ersätta, inte bara det gamla integrationsramverket utan även alla monolitiska applikationer i din EA.

5. Skapa din SOA utifrån möjligheterna med BAM
Det finns många sätt att modellera en SOA. Att göra det utifrån ett aktivitetsperspektiv bygger på att den resulterande arkitekturen ska synliggöra ärenden som flödar via aktiviteterna i verksamhetsprocesserna. Business Activity Monitoring (BAM) är den enskilt största vinsten för en SOA som inte har med IT att göra.

6. Designa alla nya applikationer för SOA
Varje ny applikation som ska byggas i din EA ska byggas för SOA, dvs baserat på tjänstenätverket.