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.
Inga kommentarer:
Skicka en kommentar