Windows Workflow Foundation - nowy, zapowiadany przez Microsoft zestaw narzędzi API - trafił w końcu na rynek wraz z premierą platformy .Net 3.0.

Już od pierwszego dnia listopadowej konferencji TechEd 2006 Microsoft poinformował, że zakończone zostały prace nad platformą .Net 3.0. Jest to kolejna odsłona zestawu bibliotek API przeznaczonych dla programistów i znanych dotychczas pod nazwą WinFX. Środowisko .Net Framework 3.0 może działać pod kontrolą systemów Windows Vista, Longhorn Server, Windows XP SP2 i Windows 2003 SP1. Nazwa .Net 3.0 może być trochę myląca. O ile bowiem między wersjami 1.x a 2.0 zmieniły się bazowe mechanizmy .Net (w tym język pośredni MSIL), to .Net 3.0 jest przede wszystkim nowym zestawem API, który wykorzystuje typy ogólne i metody anonimowe wprowadzone już wcześniej w .Net 2.0.

Net 3.0 API składa się z czterech podstawowych technologii: Windows Workflow Foundation (nowe API do realizacji przepływu zadań, informacji i dokumentów), Windows Presentation Foundation (API do budowy interfejsów użytkownika), Windows CardSpace (mechanizm bezpiecznego udostępniania informacji wymaganych do autoryzacji użytkowników) i Windows Communication Foundation (API komunikacyjne). Oczywiście nowe biblioteki API są w pełni zgodne z wcześniejszymi. Można używać starych mechanizmów i usług Web realizowanych w standardowy sposób, a także .Net Remoting lub tworzyć interfejsy użytkownika przy użyciu Windows Forms. Można też łączyć API. Przykładowo, gdy jest już gotowa i przetestowana kontrolka WinForms, bez problemu można ją osadzić w oknie WPF. W tym artykule przedstawiono najważniejsze elementy oraz możliwości zastosowań i implementacji Windows Workflow Foundation (WWF).

Łatwa modyfikacja przepływów

W większości aplikacji pojawiają się fragmenty, które odpowiadają za ogólną strukturę jakiegoś procesu biznesowego. Zwykle jest to rozbudowany ciąg instrukcji warunkowych wywołujących inne funkcje, albo rozbudowana struktura obiektowa z różnymi specjalizacjami. Problem polega na tym, że taki fragment aplikacji jest bardzo mało elastyczny, a procesy biznesowe wciąż podlegają zmianom i modyfikacjom. Z punktu widzenia programisty, raz wykonanej, złożonej implementacji najlepiej nie ruszać, bo taka operacja wymaga sporej pracy i przeprowadzenia kolejnych czasochłonnych testów. I właśnie w takich sytuacjach może się przydać API Windows Workflow Foundation, które pozwala zapisać proces w postaci graficznego diagramu, a następnie go uruchomić.

Tym, co zostaje uruchamiane w ramach WWF, jest tzw. aktywność. Może to być jedna z wielu gotowych, predefiniowanych aktywności lub własna, specjalnie napisana dla potrzeb danego projektu. Przykładami takich aktywności są pętle, instrukcje warunkowe lub operacje klonowania zadań. Aktywnością może też być operacja ogólna, np. "wykonaj kod" lub "wywołaj usługę Web". Natomiast przepływ to, z punktu widzenia .Net, klasa, która dziedziczy funkcje i parametry typu Workflow. Wszelkie warunki definiowane w przepływie mają postać reguł. Taka reguła może być metodą zapisaną w kodzie lub wyrażeniem, które będzie odwoływać się do określonych cech przepływu i jego właściwości. Przy uruchamianiu przepływu łatwo można zmieniać zestawy reguł lub parametryzację. W ten sposób np. instrukcja warunkowa, która w zależności od wartości zamówienia definiuje dalszy proces jego obsługi, raz może określać, że w specjalny sposób traktowane są zlecenia powyżej 1000 zł, a innym razem, że dopiero po przekroczeniu 20 000 zł.

Architektura Windows Workflow Foundation

Architektura WWF składa się z trzech głównych elementów. Pierwszy to diagram, który definiuje to, co ma być wykonywane. Jego mechanizm wykorzystuje API aktywności oraz zawiera mechanizmy przetwarzania reguł, które pozwalają parametryzować wykonywane operacje. Kolejny to motor uruchomieniowy, który tworzy środowisko pracy dla danego przepływu. Składa się on z motoru parsującego reguły, mechanizmów przechowania stanu itp. Niżej znajduje się kolejny element - warstwa usług, która zapewnia podstawową funkcjonalność i pozwala działać środowisku uruchomieniowemu. Warstwa ta określa, gdzie i w jaki sposób będzie przechowywany stan aplikacji, jak będą wykorzystywane wątki itd.

Microsoft dostarcza zestaw wzorcowych usług, ale programista może samodzielnie tworzyć własne mechanizmy, implementując odpowiednie interfejsy. W momencie startu procesu, który wykorzystuje przepływ, dodawane są do niego odpowiednie instancje obiektów realizujących np. transakcje lub logowanie. Dzięki temu Windows Workflow Foundation może wymagać dostępności bardzo niewielu zasobów i np. służyć do sterowania przepływem w interfejsie użytkownika. Jeśli w danym scenariuszu nie są wykorzystywane transakcje, to po prostu nie jest inicjowana odpowiadająca im warstwa usługowa. Warstwa usług oraz motor uruchomieniowy muszą być hostowane w ramach jakiejś aplikacji .Net - może to być własny serwis działający na serwerze, albo po prostu procedura w aplikacji Windows Forms. Można też skorzystać z ASP.NET.

WWF to przede wszystkim zestaw API, ale również odpowiednie kolekcje i struktura obiektowa. Oprogramowanie umożliwia łatwe, dynamiczne dodawanie kolejnych węzłów w przepływach oraz dynamiczne modyfikowanie struktury. Oprócz tego pozwala na przekazywanie plików XML (w formacie XOML), które są dynamicznie parsowane i generują odpowiednie struktury obiektowe.

Udostępniane elementy i mechanizmy

Dobrym pomysłem jest wprowadzenie do WWF polisy. Jest to mechanizm pozwalający zdefiniować zasady wyliczania pewnych wartości w ramach przepływu. Polisa składa się z ciągu warunków określających, kiedy poszczególne operacje będą wykonywane. Każdy z nich ma priorytet, operacja może zmieniać wartość właściwości lub też wykonywać inne czynności. Podobnie jak reguły, także polisy mogą być zmieniane przez zewnętrzne mechanizmy w stosunku do przepływu. W ten sposób można np. określić algorytm wyliczania kwoty za usługę lub upustu, a są to elementy, które w realnych systemach często ulegają zamianie.

W ciekawy sposób zostały rozwiązane transakcje ACID. W ramach przepływu, aktywności można gromadzić w tzw. pojemnikach. Jednym z nich jest TransactionScope. Wtedy, o ile jest dodana warstwa usługowa realizująca transakcje, uruchamiana zostaje nowa lub wykorzystywana istniejąca transakcja, do której dołączane są wykonywane operacje. Zastosowana semantyka jest taka sama jak w przypadku COM+. Wykorzystywany jest motor rozproszonego koordynatora transakcji DTC. W ten sposób, w wypadku niepowodzenia, operacje mogą być wycofywane. Dzięki mechanizmowi, który zapisuje wszystkie zmienne, wartości, właściwości itd. w sekwencji szeregowej, przy wycofywaniu transakcji możliwe jest cofnięcie się do początkowego stanu przepływu i podjęcie próby wykonania operacji w inny sposób.

W przypadku przepływu, gdzie część operacji zależy od wyboru użytkownika, stosowanie transakcji ACID nie ma sensu. Wówczas wykorzystywany jest pojemnik CompensatableTransactionScope i programista może zdefiniować własne operacje wycofujące zmiany dokonane przy normalnym przepływie. W tym wypadku, nawet jeżeli w dalszej części operacji realizowanej poza tym pojemnikiem zgłoszony zostanie wyjątek lub instancja przestanie działać, to kompensacja może odwrócić wykonane wcześniej zmiany. Innym typem pojemnika jest SynchronizationScope przeznaczony do synchronizacji dostępu do dzielonych zmiennych. Dostęp do bloku kodu jest wówczas w odpowiedni sposób szeregowany i dzięki temu można uniknąć pojawienia się konfliktów.

W ramach API Workflow Foundation dostępny jest także designer, który można osadzać w innych aplikacjach. Jest to ten sam designer, co używany przez Visual Studio 2005.

Praktyczne wykorzystanie funkcji

Przy wykorzystaniu WWF do budowy aplikacji programista staje przed dwoma wyzwaniami. Po pierwsze, przepływ jest uruchamiany asynchronicznie w oddzielnym AppDomain (procesie .Net). Programista wywołujący tę procedurę uruchamia przepływ, przekazując albo typ .Net, czyli klasę, która implementuje dany proces, albo wskazując konkretny plik XOML, który opisuje przepływ i wówczas otrzymuje identyfikator instancji (guid). Następnie, chcąc np. potwierdzić wykonanie jakiegoś etapu w procesie, za pośrednictwem hosta uruchamiającego przepływ - należy wysłać informację wskazując guid instancji, do której ma dotrzeć komunikat. Można też definiować własną właściwość, która będzie jednoznacznie identyfikować instancję przepływu, przypisując jej atrybut - CorrelationParameter. Do komunikacji z przepływem wykorzystywane są specjalne aktywności, które współpracują z warstwą usługową dodawaną do hosta. Definiuje się też interfejs oznaczony atrybutem ExternalDataExchange, który określa metody i zdarzenia używane do komunikacji. Następnie należy utworzyć implementację interfejsu i dodać ją jako składnik do usługi ExternalData Exchange Service, rejestrowanej w runtime Windows Workflow Foundation.

Alternatywnie, zamiast definiować własne mechanizmy komunikacji, można wykorzystać wbudowane aktywności WebServiceInput i WebServiceOutput. Wtedy zatwierdzenie danego etapu procesu sprowadza się do wywołania odpowiedniej usługi Web. Częścią runtime WWF jest gotowa infrastruktura, która hostuje runtime w ramach aplikacji ASP.NET i zajmuje się identyfikacją procesów. Publikacja przepływu na stronie ASP.NET wymaga wyboru zaledwie jednej opcji w menu i dokonania kilku wpisów w pliku konfiguracyjnym web.config danej witryny.

Drugim wyzwaniem jest sama organizacja aktywności. Nie ma sensu zamieniać każdej instrukcji warunkowej w programie na odpowiedni przepływ. Najlepiej przyjąć zasadę, że WWF jest wykorzystywany tylko tam, gdzie można przewidzieć, że w niedługim czasie elementy procesu biznesowego ulegną zmianie. Tu może pojawić się kilka wątpliwości. Przykładowo, pojedynczą aktywnością w przepływie może być operacja kompletacji wykorzystywana m.in. w systemach do obsługi magazynów, gdzie w kodzie wykonywane są odpowiednie operacje. Ale, jeżeli można przewidzieć, że za jakiś czas kompletacja będzie wykonywana inaczej, bo zmienią się wymagania klientów lub typ towaru, to warto rozbić taką operację na kilka etapów i zapisać przy użyciu WWF. W efekcie od projektanta zależy, czy rzeczywiście przy użyciu Windows Workflow Foundation zostanie zaprojektowany diagram, który sprawi, że aplikacja będzie elastyczna i łatwa do dostosowania po zmianie warunków biznesowych, czy też WWF będzie tylko czynnikiem komplikującym tworzenie oprogramowania.

Warto dodać, że dla Windows Workflow Foundation dostępna jest także finalna wersja projek-tanta diagramów zintegrowana z Visual Studio 2005. Po zainstalowaniu SDK dostępna jest także wyczerpująca dokumentacja wy-posażona w liczne przykłady, a więc w zasadzie wszystko, co jest niezbędne do nauczenia się tej technologii.