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!