Procesy wedle sekwencji

Usługi 'pod spodem'

Godne uwagi są usługi oferowane przez warstwę usługową i motor WF. Stan przepływu można zawsze "zapisać", zatrzymać jego wykonywanie, by potem je wznowić - co ważne, niekoniecznie na dotychczasowym komputerze. Można także zamknąć proces przepływu w ramach transakcji. A tak przy okazji, bardzo rzadko cały proces musi być objęty jedną transakcją - zwykle tylko pewne operacje muszą być transakcyjne. Definiując czynności dla danego systemu IT, można (podobnie jak ma to miejsce w COM+/Enterprise Services) definiować czy dana operacja wymaga transakcji, czy może użyć już istniejącej itp. Oczywiście - transakcja może ograniczać się do jednej czynności.

W WF można definiować "transakcje długotrwałe", za które przyjmuje się zazwyczaj transakcje, w których udział bierze człowiek. W takim przypadku wymagane jest, by każdy parametr używany w ramach przepływu podlegał serializacji, by mógł być zapisany w bazie jako unikalny. WF wykorzystuje wtedy opisany wyżej mechanizm utrwalania i w przypadku wycofania operacji przywraca uprzednio zachowany stan obiektów. Oczywiście programista może samodzielnie zdefiniować własny mechanizm wycofywania długich transakcji - jednak WF definiuje mechanizm domyślny, który w większości przypadków działa prawidłowo (w odwrotnej kolejności cofane są operacje wykonywane przez poszczególne czynności przepływu).

Kolejnym interesującym elementem jest narzędzie do śledzenia postępu w wykonywaniu przepływu. Dostępne są różne mechanizmy "gromadzenia" zdarzeń, można samodzielnie wysyłać komunikaty dotyczące postępu albo wykorzystywać zdarzenia gromadzone automatycznie. Żeby nie było wątpliwości - jest to narzędzie do gromadzenia informacji "technicznych", a nie biznesowych. Aby monitorować proces biznesowy (czyli odfiltrować niepotrzebne zdarzenia), trzeba odpowiednie mechanizmy zaimplementować samodzielnie.

Jedną z ciekawszych implementacji WF jest mechanizm przepływów zastosowany w SharePoint 3.0, w którym wszystkie procesy związane m.in. z obiegiem dokumentów (np. zatwierdzaniem) są obsługiwane właśnie przez Windows Workflow Foundation. Przy okazji SharePoint jest przykładem realizacji tzw. human workflow, czyli diagramu, w którym systemowy przepływ współpracuje z użytkownikiem.

Nie EAI i nie SOA

Warto podkreślić, czym różni się WF od systemów klasy BPM (Business Process Management, jak BizTalk, Tibco itp.). Windows Workflow Foundation jest biblioteką funkcji API dla programisty, która pozwala opisać i kontrolować przepływ. To od programisty zależy jak proces będzie uruchomiony, w jaki sposób operacje będą śledzone czy jakie usługi zostaną udostępnione dla przepływu. Oprócz mechanizmu przepływów klasyczny system BPM oferuje dodatkowe mechanizmy pozwalające na interakcję z szeroko pojętymi systemami IT, jak obsługa EDI, transformacje komunikatów, subskrybować zdarzenia. Zawierają też mechanizmy monitorowania procesów biznesowych (a nie technicznych aspektów przepływu).

Oczywiście, używając WF można napisać własny mechanizm integracyjny, natomiast jego niezbędne elementy i tak trzeba stworzyć samodzielnie. Patrząc z innej strony, rozwiązania typu BizTalk są raczej przeznaczone do nadzorowania procesów integracyjnych. Jakkolwiek więc diagramu BizTalk 2004 czy 2006 można użyć jako zwykłego komponentu aplikacji, jest to zwykle rozwiązanie "zbyt ciężkie". WF nadaje się do opisu procesu biznesowego i nie ma raczej sensu zastępować tym mechanizmem każdej instrukcji warunkowej w programie. Tak samo niewielki sens (poza może edukacyjnym) ma np. implementacja klasycznych algorytmów czy metod numerycznych jako przepływów WF.

Wbrew pozorom WF nie jest również alternatywną implementacją wizji SOA. Architektura SOA definiuje model, w którym granice między autonomicznymi usługami realizującymi ustalony kontrakt i warstwą komunikacji między nimi są bardzo jasno określone. Komunikacja obejmuje wiele systemów informatycznych, ale zapewnia pełną izolację poszczególnych składników. Używając WF mamy wprawdzie do czynienia z czynnościami, które na pierwszy rzut oka wyglądają na quasi-usługi. Co więcej, część z nich rzeczywiście może być realizowana jako usługi Web i wprost realizować model SOA. To jednak nie to samo.

Podstawowym zadaniem Windows Workflow Foundation jest obsłużenie długotrwałego procesu i przechowanie "stanu" takiej operacji. Infrastruktura pozwala również definiować transakcje i scenariusze kompensacji dla nich, jeśli nie zostaną wykonane, a także zamrozić/wznowić wykonywanie ciągu czynności itp. Elementem przepływu może być człowiek, tymczasem architektura SOA zakłada pełną automatyzację procesu. Człowiek (operator) pojawia się ewentualnie na początku i końcu procesu, ale nie bierze udziału w samym procesie i nie ma nań bezpośredniego wpływu. Ponadto przepływ ze swojej natury jest elementem elastycznym - łatwym do wymiany i dostosowania do zmieniających się warunków biznesowych. Dzięki WF jest to możliwe bez modyfikacji kodu całego rozwiązania.

WF, a nie WWF

Początkowo Windows Workflow Foundation miało skrót WWF - jednak zaprotestowała organizacja zajmująca się zapasami (wrestling) i stąd WF. Obecnie Windows Workflow Foundation dostępne jest w wersji Beta 2. Microsoft udostępnił także licencję "go-live", co pozwala wykorzystać ten mechanizm w produkcyjnych systemach. Główna strona poświęcona tej technologii tohttp://www.windowsworkflow.net/ oraz MSDN (http://msdn. microsoft.com/workflow ).

Przepływ zgodnie z regułami

W kilku przypadkach działanie czynności zależy od określonych warunków. Na przykład gdy decyzja w przepływie zależy od kwoty zamówienia, wartość tej kwoty może być dynamicznie aktualizowana przez zmianę elementu przepływu, ale także przez czynność polegającą na zmianie określonego parametru. Definiując warunki, ustala się tak naprawdę zestaw reguł (RuleSet). Może to być przygotowany przez programistę kod uruchamiany warunkowo lub też zdarzenie globalne (na poziomie klasy przepływu) generowane automatycznie w momencie, gdy trzeba podjąć decyzję. W ten sposób podejmowaną decyzję warunkową można modyfikować spoza przepływu.

RuleSet może mieć formę wyrażenia regularnego opartego na określonych właściwościach - zdefiniowanych w klasie przepływu na etapie definiowania bądź już w trakcie działania przepływu. Można także pogrupować wyrażenia w tzw. PolicyActivity - globalnych obiektach wykorzystywanych, gdy trzeba podjąć określoną decyzję. W ramach takich zasad można definiować priorytety reguł, dynamicznie włączać lub wyłączać pewne wyrażenia itp. W ten sposób wiele operacji można sparametryzować bez konieczności modyfikacji samego przepływu.


TOP 200