Windows Workflow Foundation to uniwersalny mechanizm do opisu procesów i przepływów - zwłaszcza takich, w których uczestniczą ludzie. Nie jest to gotowe środowisko integracyjne typu BPM, ale zestaw technologii, które pozwalają takie środowisko zbudować.

Jednym z nowych elementów systemu Windows Vista będzie Windows Workflow Foundation - zestaw interfejsów API wchodzących w skład biblioteki WinFX, która z kolei jest następcą dotychczasowego API Win32. Oficjalne informacje o tym komponencie systemu Windows pojawiły się dosyć późno, dopiero na konferencji PDC 2005. Dla porównania - WPF (wtedy jeszcze Avalon) i WCF (Indigo) były pokazane dwa lata wcześniej. Oprócz Windows Vista, biblioteka będzie działać na Windows XP i Windows Server 2003.

Zgodnie z tym, co sugeruje nazwa, nowe funkcje API są przeznaczone do realizacji mechanizmu workflow - pozwalają zdefiniować lub narysować diagram, a następnie użyć go we własnej aplikacji jako sposób opisu pewnego procesu. WF to technologia bardzo uniwersalna. Za jej pomocą można definiować np. zasady akceptacji wydatków (w zależności od wysokości, kategorii itp.), zasady przepływu dokumentu, który wpłynął do centrali, czy też opisywać działanie zaplecza automatycznego aparatu zgłoszeniowego, w którym dzwoniący wybiera opcje z klawiatury telefonu i odsłuchuje odpowiednie przykłady (np. z SDK).

Na podobnych zasadach przepływem jest nawigacja użytkownika po stronach serwisu internetowego czy poruszanie się po ciągu formatek w aplikacji okienkowej. Stąd np. w świecie Javy pojawiła się koncepcja PageFlow czy Struts, a w .Net - mechanizm User Interface Process Application Block, które pozwalają ująć nawigację po aplikacji w ramy pewnego workflow.

Przepływy i stany

WF ma dwa główne mechanizmy do tworzenia diagramów. Pierwszy to tzw. diagram przepływów (flowchart) przypominający klasyczny formalny zapis algorytmów, w którym odpowiednie kształty reprezentują instrukcje warunkowe, pętle, bloki operacji itp. W ten sposób krok po kroku można wyrazić przebieg pewnego procesu.

Drugi mechanizm to tzw. diagram stanów (stateflow), w którym definiowane są zdarzenia określające (wyzwalające) operację "przechodzenia" pomiędzy poszczególnymi etapami. W przypadku diagramu stanów możliwe jest stworzenie rozwiązania, które np. w momencie przekroczenia bramki uruchomi proces sprawdzania, jakie operacje zidentyfikowany użytkownik może wykonać. Oczywiście można łączyć te dwa modele przepływu.

Architektura WF obejmuje trzy części. Pierwsza to sam diagram, czyli to co ma być wykonywane. Ten mechanizm wykorzystuje API aktywności i mechanizmy przetwarzania reguł, dzięki którym można łatwo parametryzować wykonywane operacje. Kolejny element to środowisko uruchomieniowe zawierające parser reguł, mechanizmy przechowania stanu itp. "Niżej" znajduje się trzeci element - warstwa usług, które zapewniają podstawową funkcjonalność i pozwalają działać środowisku uruchomieniowemu.

Microsoft dostarcza "wzorcowe" usługi, programista może oprogramować interfejsy samodzielnie. W momencie startu procesu odpowiedzialnego za konkretny przepływ dodaje się do niego odpowiednie instancje obiektów realizujących np. transakcje czy logowanie. Równocześnie pozwala to "odchudzać" cały mechanizm w momencie, gdy w danym scenariuszu nie wykorzystuje się określonej warstwy usługowej. Jako środowisko uruchomieniowe dla przepływu można wykorzystać dowolny proces. Net (AppDomain). Natomiast konkretny sposób hostowania zależy od decyzji programisty. Może to być globalna usługa Windows albo aplikacja ASP .Net. Workflow może także działać po stronie klienta.

Przepływ może być definiowany na kilka sposobów. Z punktu widzenia motoru uruchomieniowego workflow to pewne drzewo obiektów "do wykonania". Takie drzewo może być zbudowane przy użyciu API WF, ale dostępne jest także graficzne narzędzie do projektowania, które integruje się z Visual Studio 2005. Warto dodać, że takie samo narzędzie może być osadzone we własnej aplikacji. W ten sposób, jeżeli logika aplikacji zostanie oparta na Windows Workflow Foundation, można pozwolić, by użytkownik samodzielnie modyfikował przebieg i/lub parametry procesów biznesowych, np. zasady obsługi zamówienia.

Jest także trzecia możliwość. W WF, podobnie jak w Windows Presentation Foundation (WPF), do opisu "wyglądu" (struktury, parametrów) przepływu można użyć języka opartego na XML. W WPF jest to XAML, zaś do opisu przepływów wykorzystywany jest jego dialekt, zwany XOML. Podobnie jak w WPF czy ASP .Net, plik XML może zawierać całość opisu lub też odwoływać się do zewnętrznego kodu.

Na podstawie takiego formatu można wygenerować gotowy kod w C# czy VB .Net, który po kompilacji zbuduje normalny pakiet (assembly) zawierający "drzewo" przepływu. Można też postąpić inaczej: strumień (plik) XAML/XOML przekazać do konstruktora, który dynamicznie zbuduje drzewo. W ten sposób bez trudu można będzie w przyszłości, gdy zmienią się warunki biznesowe, "podmieniać" definicje przepływu będące elementem większej aplikacji bez naruszania jej konstrukcji.

Świat pełen czynności

Przepływ składa się z czynności (activity) uruchamianych w ramach określonego procesu. Technicznie rzecz biorąc, czynność to klasa .Net - dziedziczona z odpowiedniej klasy bazowej i przesłaniająca metodę "wykonaj". Można też w ramach takiego obiektu zagregować inne czynności, wykorzystując stosowne narzędzie do projektowania. Czynnością może być na przykład uruchomienie kodu osadzonego w takiej klasie, wywołanie metody zewnętrznej biblioteki itp. Można także definiować czynności, które zmieniają stan obiektu lub czekają na wystąpienie określonego zdarzenia (subskrypcja). Czynnością może być wywołanie innego przepływu. Można także określić, że cały przepływ jest uruchamiany przez zewnętrzną usługę Web lub też pozwolić przepływowi toczyć się dalej pod warunkiem dostarczenia odpowiedniej informacji, np. potwierdzenia, że użytkownik zaakceptował decyzję.

Dostępne są także "pojemniki" i rozgałęzienia grupujące czynności. Mamy tu np. instrukcję warunkową umożliwiającą jedną z dwóch opcjonalnych czynności lub ich sekwencji w zależności od tego, czy pewien warunek jest spełniony, czy też nie. Równolegle dostępna jest pętla (operator while) wykonująca sekwencję czynności dopóty, dopóki dany warunek jest spełniony. Można także uruchamiać równolegle "zestawy" czynności, replikować dany zestaw czynności itp.

Wokół WF powstało pewne środowisko deweloperów, które stworzyło na bazie API WF "centralny serwer dodatkowych czynności". Obejmuje ono m.in. komunikację z usługami Windows Management Extensions (WMI), co pozwala np. uzależnić działanie przepływu od faktu, że na określonym serwerze powstał proces o pewnej nazwie, czy też np. że w logu systemowym pojawił się dodatkowy wpis.

Dostępna jest m.in. pętla foreach mogąca operować na elementach dowolnej kolekcji obiektów, mechanizmy obsługi baz danych, wybieranie rekordów w celu wykonania pewnej operacji na każdym z nich lub też aktualizacji bazy zgodnie z kolejnością zapisaną w definicji przepływu. Także podstawowe operacje sieciowe są opakowane jako czynności, co daje sporą elastyczność, np. pozwala stworzyć rozgałęzienie przepływu na podstawie wykrycia niedostępności określonej usługi lub serwera.

Czynności mogą być uruchamiane w pojemnikach, dzięki którym łatwo można łączyć model oparty na stanach z modelem diagramu przepływów. Innym typowym przykładem jest procedura wołana w momencie przechwycenia wyjątku (i wystąpienia nieoczekiwanego błędu). Specjalnym przypadkiem jest także kompensacja transakcji. Jest to operacja, w której ręcznie wycofywane są czynności wykonane przez zatwierdzoną transakcję, w momencie gdy np. użytkownik anuluje cały proces. Tego typu operacja jest stosowana w tzw. "długich" przepływach, w których pojawiają się punkty warunkowe, zmieniające kierunek przepływu w wyniku działania podjętego przez człowieka.

Czynność może być usługą Web. W szczególności, zakładając że aplikacje branżowe zapewniają dostęp do poszczególnych modułów zgodnie z założeniami SOA, WF można traktować jako narzędzie do zarządzania wykonywaniem procesów obejmujących wiele systemów. W wersji Beta 1 WF dostępne były czynności typu WaitForData, które pozwalały przepływowi oczekiwać, aż zewnętrzne zdarzenie "dostarczy" odpowiednie informacje. W wersji Beta 2 został wprowadzony znacznie wygodniejszy i bardziej uniwersalny mechanizm, w którym używając atrybutów i odpowiednich interfejsów, definiuje się dodatkową warstwę usługową - w tym przypadku dostarczającą/pobierającą dane. Dostępny jest też mechanizm "nasłuchiwania" w formie dedykowanej "czynności oczekującej na zdarzenie".