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.

SOA-kartläggning

För ett tag sedan skrev Tamina Vahidy en artikel om resultatet av en undersökning som gick ut på att kartlägga vilka komponenter som användes mest för att uppnå en SOA.

• 71% Web Services
• 61% Portalramverk
• 46% Applikationsserver
• 43% Integrationsramverk
• 36% Säkerhetsramverk
• 18% Analysramverk
• 18% Datacentralisering
• 14% ESB
• 14% BPM

Tamina konstaterar "- That's an excellent illustration not just of how companies are building SOA, but of SOA's complexity". Hon säger att SOA är inte en applikation, utan en paradigm. SOA är allt ovan, från portalramverk till datacentralisering. Det är det som gör det komplext!

Sedan kan man ju konstatera att prioriteringarna (av siffrorna ovan att dömma) är något förskjutna mot EAI och inte de delar som implementerar det unika med en SOA, nämligen BPM och ESB. Det är bara att konstatera att vi kommer få se negativa erfarenheter av SOA så länge man inte uppnår målen med SOA. Ronan Bradly beskyller produktleverantörerna för att paketera sina gamla EAI-produkter som ESB:er, vilket jag skriver under på.

SOA och DSL

Det har alltid funnits ett stort gap mellan problembeskrivaren och problemlösaren när det kommer till programutveckling. Det gapet har med tiden försökts att överbryggas på alla tänkbara sätt. Problem beskrivs av personer som har kunskaper inom problemdomänen, medan lösningen skapas av personer som har kunskap i verktygen som används för att konstruera lösningen.

En väg att minska gapet och som fått alldeles för stort genomslag är CASE-verktygen, som exempelvis Rational. I ett CASE-verktyg enas problembeskrivaren och problemlösaren i ett gemensamt språk och metodik som ex. UML/RUP. Det finns generellt sätt mängder av problem med den här typen av modeller, men i synnerhet ett som har förpassat UML & Co till 90-talet. UML kan nämligen inte exekveras!

Att UML inte kan exekveras har man försökt att åtgärda med hjälp av kodgenerering. Det blev aldrig, av förståliga skäl, någon hit eftersom den genererade koden inte fick några fans bland utvecklarna som hela tiden låg steget före med ny teknik. UML är även ett problem med tanke på underhåll eftersom man blev tvungen att underhålla både kodbasen och modellen. UML nådde heller inte fram till roten av problemet, att minska gapet, utan skapade istället två nya raviner. Det första mellan problembeskrivaren och modellen, men även mellan modellen och problemlösaren. Den fylldes med nya roller som titulerade sig analytiker, kravhanterare och andra former av "fördyrande mellanhänder".

DSL (Domain Specific Languages) är ett annat sätt att minska gapet. Det går ut på att skapa språk som kan exekveras samtidigt som det närmar sig problembeskrivaren genom att "prata" samma språk som honom. Det viktiga med DSL är just att det, precis som UML, ska ge möjligheten att modellera inom problemdomänen samtidigt som det ger ett resultat som kan exekveras.

Ett enda språk kan inte lösa alla problem. Därför måste det finnas en mängd språk som på olika nivåer skapar lösningen. Vissa språk är nära problembeskrivaren och andra är närmare tekniken. Det är lite som idén med .NET (även om MS väljer att ersätta alla andra programspråk med C#) där flera språk enas runt en exekveringsmodell, tillskillnad från Java där alla kodare enas runt ett språk som ska passa alla problem.

En SOA är ett nätverk av komponenter av DSL:er som samspelar med det gemensamma i Web Services. Web Services ger även möjligheten att konstruera arkitekturer av komponenter utvecklade för olika exekveringsplattformar, vilket betyder att man kan uppnå fördelarna med .NET utan att för den delen vara fullt beroende av en exkeveringsmodell.

Skikten av språk som används, nära problembeskrivarens domäner ned till tekniken skiljer sig mellan en traditionel arkitektur och en SOA. I en klassisk skiktad arkitektur så finns en hierarki där ju närmare problemet man kommer desto mer finns behovet av DSL:er. Att knyta samman alla språken i ett gemensamt meta-språk kommer säkert ge de stora leverantörerna något nytt att bråka om framöver (se SCA och SDM).

Oavsett vem som bygger det ultimata meta-meta-meta-...-språket så är en SOA ett klockrent exempel på hur olika DSL:er samspelar i en arkitektur. Där finns det nämligen ingen hierarki som avgör vem som orkestrerar vem. En SOA är ett nätverk och inte en skiktad arkitektur.

WS-Management

WS-Management (eller MS-Management) har publicerats här.

Läs mer om WS-Management här.

Enligt denna källa kommer WCF i.o.m. R2 supporteras av WS-Management.

Tjänsteorientering IV - Första steget

Att uppnå en SOA är ingen enkel omställning. Att gå från en applikationsorienterad IT-miljö till en tjänsteorienterad kräver stora förändringar inom IT.

Applikationer har karaktäriserats som en paketering av tjänster, där just paketering har ingivit en positiv trygghetskänsla. Trygghet både för den som använder applikationen, men även för den som erbjuder tjänsterna. Det negativa med applikationen är att den är som en svart låda som säger "jag erbjuder allt eller inget" i form av tjänster.

Applikationer saknar förmågan att kunna kopplas ihop med omvärlden om man inte gör det på applikationens villkor. Dels mellan lager som gränssnitt, logik och data, men även tjänstevis. En SOA måste kunna erbjuda samma trygghet som en applikationen ger, men även uppfylla de delar som anses vara negativa med applikationer. Ett tjänstenätverk måste kunna gruppera tjänster i vita lådor, eller meta-applikationer. En meta-applikation är en paketering av tjänster i en SOA som ska garantera samma trygghet man fick med en vanlig applikation.

Meta-applikationen har en rörlighet som en traditionell applikation saknar. Den består av ett tjänstenätverk som en del av ett större nätverk. Gränserna för meta-applikationen manageras av verktyg som kan upprätthålla dess förväntade tjänstenivå.




Här måste SOA börja, d v s att applikationerna förändras. Att bygga en SOA är ett jobb som arbetar sig bottom-up. Sitter man på en applikationmiljö som behöver integreras m h a en broker-lösning eller ett middleware så kan man definitivt göra det som en start. Men en SOA handlar om att få bort applikationerna och byta ut dom mot meta-applikationer i ett tjänstenätverk.

Så trycket måste ligga på applikationsutvecklarna om SOA ska bli en realitet. Tillsvidare får IT nöja sig med applikationsintegration, vilket tyvärr ändå verkar vara det enda så gått fram till IT som en definition av SOA.

Måsteläsning

http://download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/ws-soa-whitepaper.pdf

Tjänsteorientering III - Vägen dit

Vägen till en SOA tar sig olika beroende på var man befinner sig. Många kan relatera till bilden nedan med ett antal applikationer sammankopplade till varandra efter behov och med webbar som gör anropar direkt mot applikationerna. Det här är en vanlig arkitektur och kallas i integrationskretsar för "spagetti" eftersom allt hänger samman genom peer-to-peer.



Andra har byggt ett Middleware á la 90-tal, baserat på ett integrationsramverk utvecklat på J2EE eller Windows DNA. Kostnaderna har här mest att göra med underhållsproblem och integrationskostnader när det ska ske tillägg eller förändringar i ramverket.



Möjligen har man investerat stora pengar i ett integrationsnav eller en "Integration Broker". I så fall har man skapat bra förutsättningar för att integrera applikationer. En integrationsplattform är en öppen lättskött miljö för att integrera applikationer.



Men för att nå en SOA så måste siktet vara inställt på att skapa ett komplett tjänstenätverk istället för applikationer. En SOA bygger på standarder och kan enbart fungera i en värld där man som konsument och producent av tjänster kan lita på sin motpart.



SOA handlar alltså om tjänster som i sin tur handlar om tillit. Tillit handlar om Service Level Agreements, standarder, kontrakt, policies och säkerhet. För att kunna bygga upp ett tjänstenätverk måste man bygga tillit på just dessa komponenter. OASIS och W3C definierar just dessa komponenter som ska garantera tillit i ett tjänstenäteverk. Produktleverentörer inom SOA måste förhålla sig till standarder för att nätverket ska fungera.