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.