Processorienterad design

Jag hade en diskussion med Fredrik Normén idag där en intressant fråga kom upp. Antag en inköpsprocess där en av aktiviteterna ska notifiera chefen om att en ny order ska attesteras. Notifieringen skall ske via email, men en kodare känner igen diskussionen och vet att inom kort ska kanske ett annat sätt hantera notifieringen som exempelvis via SMS-meddelande. Frågan vi ställde oss var om man 1) ska skapa en specifik aktivitet för varje scenario som man i processen byter ut när kraven ändras eller 2) en generell aktivitet som kan hantera notifiering rent allmänt så att implementationen av processen alltid förblir densamma.

Det självklara svaret kan anses vara att man borde skriva en generell aktivitet som kan hantera olika transportsätt. Men eftersom processmotorer är byggda för att just kunna modifera processerna så borde det första alternativet inte ge något overhead vid förändring. Det kan till och med vara tydligare att i processen kunna se hur meddelandet ska skickas.

Jag skulle nog i alla fall vilja påstå att just styrkan med kombinationen av tjänster och process hantering skapar den bästa lösningen. Nedan så implementeras processen med en generell notifieringsaktivitet. Självfallet ska inte implementationen av aktiviteten köras inne i processmotorn utan skickas som ett service anrop via ett Mediation Layer, en Enterprise Service Bus (ESB). Däri ligger ansvaret för att hantera hur meddelandet ska nå användaren vilket kontrolleras genom policies för notifieringstjänsten.

För processen finns det inga fysiska tjänster att tillgå, utan enbart virtuella tjänster som exponeras genom ESB:n. Inne i bussen routas meddelandet beroende på innehåll och yttre omständigheter samt transformeras för att passa just det transportsättet och den mottagaren av den fysiska implementationen av notifieringstjänsten. Det här är en klassisk kombination av Business Process Management och Service Oriented Architecture som visar vad som ligger inom respektive arkitekturs ansvarsområde.