Sposób przepływu pracy: Omówienie programu Windows Workflow Foundation

David Chappell
Skojarzeń & Chappell

Kwiecień 2009 r.

Pobierz ten artykuł

• format programu Word
• PDF

Wprowadzenie do programu Windows Workflow Foundation

Każdy, kto pisze kod, chce tworzyć wspaniałe oprogramowanie. Jeśli to oprogramowanie jest aplikacją serwerową, częścią doskonałego skalowania jest dobre skalowanie, obsługa dużych obciążeń bez zużywania zbyt wielu zasobów. Świetna aplikacja powinna być również tak łatwa, jak to możliwe, zarówno dla twórców, jak i dla osób, które ją utrzymują.

Osiągnięcie obu tych celów nie jest łatwe. Podejścia, które ułatwiają skalowanie aplikacji, mają tendencję do dzielenia ich logiki na oddzielne fragmenty, które mogą być trudne do zrozumienia. Jednak pisanie ujednoliconej logiki, która znajduje się w jednym pliku wykonywalnym, może sprawić, że skalowanie aplikacji będzie niemożliwe. Potrzebny jest sposób na zapewnienie ujednoliconej logiki aplikacji, dzięki czemu będzie bardziej zrozumiały, jednocześnie umożliwiając skalowanie aplikacji.

Osiągnięcie tego celu jest głównym celem programu Windows Workflow Foundation (WF). Dzięki obsłudze logiki utworzonej przy użyciu przepływów pracy platforma WF stanowi podstawę do tworzenia ujednoliconych i skalowalnych aplikacji. Ponadto platforma WF może również uprościć inne wyzwania programistyczne, takie jak koordynowanie równoległych prac, śledzenie wykonywania programu i nie tylko.

Platforma WF została po raz pierwszy wydana z programem .NET Framework 3.0 w 2006 r., a następnie zaktualizowana w programie .NET Framework 3.5. Te dwie pierwsze wersje były przydatne, zwłaszcza w przypadku niezależnych dostawców oprogramowania (ISV), ale nie stały się głównymi technologiami dla deweloperów przedsiębiorstw. Wraz z wersją platformy WF, która jest częścią programu .NET Framework 4, jej twórcy mają na celu zmianę tego. Głównym celem tej najnowszej wersji jest uczynienie platformy WF standardową częścią zestawu narzędzi programistycznych dla wszystkich deweloperów platformy .NET.

Podobnie jak każda technologia, zastosowanie platformy WF wymaga zrozumienia, co to jest, dlaczego jest przydatne i kiedy warto z niego korzystać. Celem tego przeglądu jest jasne, aby te kwestie były jasne. Nie dowiesz się, jak pisać aplikacje WF, ale zapoznasz się z ofertami WF, dlaczego tak jest i jak może poprawić życie dewelopera. Innymi słowy, zaczniesz rozumieć sposób przepływu pracy.

Wyzwanie: pisanie ujednoliconej, skalowalnej logiki aplikacji

Jednym z prostych sposobów na napisanie programu jest utworzenie ujednoliconej aplikacji działającej w jednym procesie na jednej maszynie. Rysunek 1 ilustruje ten pomysł.

Rysunek 1. Logika aplikacji może być tworzona jako całość ujednolicona, a następnie wykonywana na określonym wątku w procesie uruchomionym na jednej maszynie.

Prosty pseudo-kod w tym przykładzie pokazuje rodzaje rzeczy, które zwykle wykonują aplikacje:

• Zachowaj stan, który w tym miejscu jest reprezentowany przez prostą zmienną ciągu.
• Pobierz dane wejściowe ze świata zewnętrznego, na przykład odbierając żądanie od klienta. Prosta aplikacja może po prostu odczytać z konsoli, podczas gdy bardziej typowy przykład może odbierać żądanie HTTP z przeglądarki internetowej lub komunikat PROTOKOŁU SOAP z innej aplikacji.
• Wysyłanie danych wyjściowych do świata zewnętrznego. W zależności od sposobu tworzenia aplikacja może to zrobić za pośrednictwem protokołu HTTP, komunikatu PROTOKOŁU SOAP, zapisując w konsoli lub w inny sposób.
• Podaj alternatywne ścieżki za pomocą logiki przy użyciu instrukcji przepływu sterowania, takich jak if/else i while.
• Wykonaj pracę, wykonując odpowiedni kod w każdym punkcie aplikacji.

W przedstawionym tutaj ujednoliconym podejściu logika aplikacji spędza całe życie na wątku wewnątrz określonego procesu na jednej maszynie. Takie proste podejście ma kilka zalet. Dla jednej rzeczy logika może być zaimplementowana w prosty, ujednolicony sposób. Pomaga to osobom, które pracują z kodem, zrozumieć go, a także jawnie określa dozwoloną kolejność zdarzeń. Na przykład na rysunku 1 widać, że pierwsze żądanie klienta musi poprzedzać drugi — wymaga tego przepływ sterowania programu. Po odebraniu drugiego żądania nie ma potrzeby sprawdzania, czy pierwsze żądanie zostało już obsłużone, ponieważ nie ma innego ścieżki za pośrednictwem aplikacji.

Kolejną zaletą tego podejścia jest to, że praca ze stanem aplikacji jest łatwa. Ten stan jest przechowywany w pamięci procesu, a ponieważ proces jest uruchamiany w sposób ciągły do czasu zakończenia jego pracy, stan jest zawsze dostępny: deweloper uzyskuje dostęp tylko do zwykłych zmiennych. Co może być prostsze?

Mimo to ten podstawowy styl programowania ma ograniczenia. Gdy aplikacja musi czekać na dane wejściowe, niezależnie od tego, czy użytkownik w konsoli programu , klient usług sieci Web, czy coś innego, zwykle będzie blokować. Zarówno wątek, jak i proces, którego używa, będą przechowywane do momentu nadejścia danych wejściowych, jednak długo trwa to. Ponieważ wątki i procesy są stosunkowo mało zasobów, aplikacje, które trzymają się jednego z nich, gdy tylko czekają na dane wejściowe, nie są bardzo dobrze skalowane.

Bardziej skalowalne podejście polega na zamknięciu aplikacji po oczekiwaniu na dane wejściowe, a następnie ponownym uruchomieniu po nadejściu tych danych wejściowych. Takie podejście nie powoduje marnowania zasobów, ponieważ aplikacja nie trzyma się wątku ani procesu, gdy ich nie potrzebuje. Umożliwia to również uruchamianie aplikacji w różnych procesach na różnych maszynach w różnym czasie. Zamiast być zablokowanym w jednym systemie, tak jak na rysunku 1, aplikację można zamiast tego wykonywać na jednej z kilku dostępnych maszyn. Ułatwia to również skalowalność, ponieważ praca może być łatwiej rozłożona na różnych komputerach. Rysunek 2 pokazuje, jak wygląda to.

Rysunek 2. Logika aplikacji może być podzielona na fragmenty, wszystkie współużytkujące wspólny stan, które mogą być wykonywane na różnych maszynach.

Ta przykładowa aplikacja zawiera tę samą logikę co poprzednio, ale jest teraz podzielona na oddzielne fragmenty. Po odebraniu pierwszego żądania klienta zostanie załadowany i wykonany odpowiedni fragment. Po obsłużeniu tego żądania i odesłaniu odpowiedzi ten fragment można zwolnić — nic nie musi pozostać w pamięci. Po odebraniu drugiego żądania klienta fragment obsługujący go jest ładowany i wykonywany. Jak pokazano na rysunku 2, ten fragment może zostać wykonany w innym wątku w innym procesie uruchomionym na innej maszynie od pierwszego fragmentu. Po obsłużeniu żądania ten drugi fragment można również zwolnić, zwalniając niezależnie od używanej pamięci.

Jednym z typowych przykładów technologii, która działa w ten sposób, jest ASP.NET. Deweloper implementuje aplikację ASP.NET jako zestaw stron, z których każda zawiera część logiki aplikacji. Po nadejściu żądania zostanie załadowana poprawna strona, wykonana, a następnie ponownie zwolniona.

Aplikacja wbudowana w tym stylu może korzystać z zasobów maszynowych wydajniej niż ta, która została utworzona przy użyciu prostszego podejścia pokazanego wcześniej, a więc będzie lepiej skalować. Jednak zapłaciliśmy za tę lepszą skalowalność ze złożonością. Dla jednej rzeczy różne fragmenty kodu muszą w jakiś sposób współdzielić stan, jak pokazano na rysunku 2. Ponieważ każdy fragment jest ładowany na żądanie, wykonywany, a następnie zamykany, ten stan musi być przechowywany zewnętrznie, na przykład w bazie danych lub innym magazynie trwałości. Zamiast uzyskiwać dostęp do zwykłych zmiennych, takich jak scenariusz przedstawiony na rysunku 1, deweloper musi teraz wykonywać specjalne czynności, aby uzyskać i zapisać stan aplikacji. Na przykład w ASP.NET aplikacjach deweloperzy mogą zapisywać stan bezpośrednio w bazie danych, uzyskiwać dostęp do obiektu Sesja lub użyć innego podejścia.

Innym kosztem tej ulepszonej skalowalności jest to, że kod nie zapewnia już ujednoliconego widoku ogólnej logiki programu. W wersji pokazanej na rysunku 1 kolejność, w jakiej program oczekuje danych wejściowych, jest oczywista — istnieje tylko jedna możliwa ścieżka przez kod. Jednak w wersji rysunku 2 ten przepływ sterowania nie jest widoczny. W rzeczywistości fragment kodu, który obsługuje drugie żądanie klienta, może wymagać rozpoczęcia od sprawdzenia, czy pierwsze żądanie zostało już wykonane. W przypadku aplikacji, która implementuje dowolny rodzaj znaczącego procesu biznesowego, zrozumienie i poprawne zaimplementowanie przepływu sterowania między różnymi fragmentami może być trudne.

Sytuacja jest następująca: Pisanie ujednoliconych aplikacji sprawia, że życie dewelopera jest łatwe, a kod jest prosty do zrozumienia, ale wynik nie jest dobrze skalowany. Pisanie fragmentów aplikacji współużytkujących stan zewnętrzny, takich jak aplikacje ASP.NET, umożliwia skalowalność, ale utrudnia zarządzanie stanem i traci ujednolicony przepływ sterowania. Chcemy wykonać obie czynności: pisanie skalowalnej logiki biznesowej przy użyciu prostego zarządzania stanem, ale nadal ma ujednolicony widok przepływu sterowania aplikacji.

Jest to dokładnie to, co zapewnia sposób przepływu pracy. W następnej sekcji pokazano, jak to zrobić.

Rozwiązanie: sposób przepływu pracy

Zrozumienie sposobu rozwiązywania tych problemów przez aplikację WF (i innych) wymaga przejścia przez podstawy działania platformy WF. Po drodze zobaczymy, dlaczego ta technologia może poprawić życie deweloperom w zaskakująco dużej liczbie przypadków.

Tworzenie logiki ujednoliconej aplikacji

Aplikacja oparta na przepływach pracy utworzona przy użyciu platformy WF wykonuje takie same rodzaje rzeczy jak zwykła aplikacja: utrzymuje stan, pobiera dane wejściowe ze świata zewnętrznego i wysyła dane wyjściowe do świata zewnętrznego, udostępnia przepływ sterowania i wykonuje kod wykonujący pracę aplikacji. Jednak w przepływie pracy platformy WF wszystkie te czynności są wykonywane przez działania. Na rysunku 3 pokazano, jak wygląda to, z ujednoliconym podejściem kodu pokazanym obok porównania.

Rysunek 3: W przepływie pracy platformy WF wszystkie prace programu są wykonywane przez działania.

Jak pokazano na rysunku 3, każdy przepływ pracy ma najbardziej zewnętrzne działanie, które zawiera wszystkie inne. W tym miejscu to najbardziej zewnętrzne działanie jest nazywane sekwencją i podobnie jak zwykły program, może mieć zmienne, które utrzymują jego stan. Ponieważ sekwencja jest działaniem złożonym, może również zawierać inne działania.

W tym prostym przykładzie przepływ pracy rozpoczyna się od działania ReceiveMessage, które pobiera dane wejściowe ze świata zewnętrznego. Następnie następuje działanie If, które (nic dziwnego) implementuje gałąź. Jeśli jest to również działanie złożone, zawierające inne działania (oznaczone etykietą X i Y tutaj), które wykonują pracę wykonywaną na każdej gałęzi. Po działaniu If następuje działanie SendMessage, które wysyła dane wyjściowe do świata poza tym przepływem pracy. Zostanie wyświetlone kolejne działanie ReceiveMessage, które pobiera więcej danych wejściowych, a następnie następuje działanie While. Zawiera inne działanie, Z, który wykonuje pracę tej pętli while. Cały przepływ pracy kończy się końcowym działaniem SendMessage, wysyłając wynik końcowy programu.

Wszystkie te działania odpowiadają funkcjonalnie różnym częściom typowego programu, co sugeruje dopasowanie kolorów na rysunku 2. Ale zamiast używać wbudowanych elementów językowych, jak robi tradycyjny program, każde działanie w przepływie pracy WF jest w rzeczywistości klasą. Wykonanie przepływu pracy jest wykonywane przez środowisko uruchomieniowe platformy WF— składnik, który wie, jak uruchamiać działania. Rysunek 4 ilustruje ten pomysł.

Rysunek 4. Środowisko uruchomieniowe platformy WF wykonuje działania w kolejności określonej przez przepływ pracy.

Po rozpoczęciu uruchamiania przepływu pracy środowisko uruchomieniowe platformy WF najpierw wykonuje najbardziej zewnętrzne działanie, które w tym przykładzie jest sekwencją. Następnie wykonuje pierwsze działanie wewnątrz tego, które w tym miejscu to ReceiveMessage, a następnie następne działanie itd. Dokładnie, które działania są wykonywane w każdej konkretnej sytuacji, zależą od ścieżki wykonywanej przez przepływ pracy. Na przykład uzyskanie jednego rodzaju danych wejściowych w pierwszym działaniu ReceiveMessage może spowodować działanie If do wykonania działania X, podczas gdy inny rodzaj danych wejściowych może spowodować wykonanie działania Y. To tak jak każdy inny program.

Ważne jest, aby zrozumieć, że środowisko uruchomieniowe platformy WF w ogóle nie wie o wewnętrznych działaniach, które wykonuje. Nie może powiedzieć if z komunikatu ReceiveMessage. Jedyną rzeczą, jaką wie, jak to zrobić, jest uruchomienie działania, a następnie uruchomienie następnego. Środowisko uruchomieniowe może jednak zobaczyć granice między działaniami, które, jak zobaczymy, jest przydatną rzeczą.

Ważną rolą jest to, że platforma WF nie definiuje żadnego konkretnego języka do opisywania przepływów pracy — wszystko zależy od działań, których deweloper zdecyduje się użyć. Aby ułatwić sobie życie, WF zawiera bibliotekę aktywności podstawowej (BAL), która zapewnia szeroko przydatny zestaw działań. (W rzeczywistości wszystkie przykładowe działania użyte w tym miejscu pochodzą z balu). Deweloperzy mogą jednak tworzyć inne działania, które lubią. Mogą nawet całkowicie zignorować BAL.

Oto oczywiste pytanie: Dlaczego warto przejść do tego wszystkiego problemu? Tworzenie programu przy użyciu działań różni się od tego, do czego służą deweloperzy, więc dlaczego ktoś powinien się przejmować? Dlaczego nie tylko pisać zwykły kod?

Oczywiście odpowiedzią jest to, że takie podejście może pomóc nam w tworzeniu lepszego kodu. Zauważ na przykład, że sposób przepływu pracy zapewnia deweloperowi ujednolicony przepływ sterowania. Podobnie jak w prostym przypadku pokazanym na rysunku 1 główna logika programu jest definiowana w jednym spójnym strumieniu. Ułatwia to zrozumienie i ponieważ logika nie jest podzielona na fragmenty, nie ma potrzeby przeprowadzania dodatkowych kontroli. Sam przepływ pracy wyraża dozwolony przepływ sterowania.

Reprezentuje to połowę naszego celu: tworzenie ujednoliconej logiki aplikacji. Jednak aplikacje WF mogą również osiągnąć drugą połowę, tworząc skalowalne aplikacje z prostym zarządzaniem stanem. W następnej sekcji wyjaśniono, w jaki sposób przepływ pracy umożliwia wykonanie tej czynności.

Zapewnianie skalowalności

Aby można było skalować, nie można zablokować aplikacji serwera w jednym procesie na jednej maszynie. Jednak jawne podzielenie logiki aplikacji na fragmenty, tak jak na stronach ASP.NET, dzieli to, co powinno być ujednoliconym przepływem sterowania. Wymusza również jawną pracę programisty ze stanem. Tak naprawdę chcielibyśmy, aby nasza logika była automatycznie podzielona na fragmenty, które mogą być wykonywane w różnych procesach na różnych maszynach. Chcemy również zarządzać stanem naszej aplikacji, więc wszystko, co musimy zrobić, to zmienne dostępu.

Jest to dokładnie to, co zapewniają przepływy pracy. Rysunek 5 przedstawia podstawy tego, jak usługa WF realizuje te rzeczy.

Rysunek 5. Środowisko uruchomieniowe platformy WF zwalnia przepływ pracy podczas oczekiwania na dane wejściowe, a następnie ładuje go ponownie po nadejściu danych wejściowych.

Podobnie jak każda aplikacja, przepływ pracy platformy WF blokuje oczekiwanie na dane wejściowe. Na przykład na rysunku 5 przepływ pracy jest blokowany w drugim działaniu ReceiveMessage czekającym na drugie żądanie klienta (krok 1). Środowisko uruchomieniowe platformy WF zauważa to i przechowuje stan przepływu pracy oraz wskazuje, gdzie przepływ pracy powinien zostać wznowiony w magazynie trwałości (krok 2). Po nadejściu danych wejściowych dla tego przepływu pracy (krok 3) środowisko uruchomieniowe platformy WF znajdzie stan trwały, a następnie ponownie załaduje przepływ pracy, zbierając wykonanie, w którym zostało przerwane (krok 4). Wszystko to dzieje się automatycznie — deweloper WF nie musi nic robić. Ponieważ środowisko uruchomieniowe platformy WF może zobaczyć w przepływie pracy, może obsłużyć wszystkie te szczegóły.

Jedną z oczywistych zalet tego podejścia jest to, że przepływ pracy nie zawiesza się w pamięci blokującej wątek i używając procesu podczas oczekiwania na dane wejściowe. Inną zaletą jest możliwość ponownego załadowania utrwalonego przepływu pracy na maszynie innej niż ta, na której pierwotnie była uruchomiona. W związku z tym różne części przepływu pracy mogą działać w różnych systemach, jak pokazano na rysunku 6.

Rysunek 6. Przepływ pracy może być uruchamiany w różnych wątkach, w różnych procesach i na różnych maszynach w okresie istnienia.

W tym przykładzie załóżmy, że przepływ pracy obsługuje pierwsze żądanie klienta w procesie na maszynie A. Gdy drugi komunikat ReceiveMessage powoduje, że przepływ pracy blokuje oczekiwanie na dane wejściowe, środowisko uruchomieniowe programu WF zwolni stan przepływu pracy do magazynu trwałości, tak jak opisano w tym temacie. Po odebraniu drugiego żądania klienta możliwe jest ponowne załadowanie tego przepływu pracy do procesu na maszynie B. Zamiast blokować określony wątek w określonym procesie na określonej maszynie, przepływ pracy platformy WF można przenieść w razie potrzeby. Deweloper uzyskuje tę elastyczność bezpłatnie — jest ona dostarczana automatycznie przez platformę WF.

Warto zwrócić uwagę, że środowisko uruchomieniowe platformy WF nie obchodzi, jak długo przepływ pracy musi czekać na dane wejściowe. Może pojawić się kilka sekund po utrwalonej przepływie pracy, kilka minut później, a nawet kilka miesięcy później. Tak długo, jak magazyn trwałości nadal znajduje się w stanie przepływu pracy, można uruchomić go ponownie. Dzięki temu platforma WF jest atrakcyjną technologią do tworzenia aplikacji, które implementują długotrwałe procesy. Pomyśl o aplikacji obsługującej na przykład proces zatrudniania, który obejmuje wszystko, od planowania początkowych wywiadów po integrowanie nowego pracownika z organizacją. Ten proces może trwać kilka tygodni lub miesięcy, dlatego zarządzanie stanem aplikacji przy użyciu platformy WF ma sens. Mimo to, chociaż WF może być dość przydatny w tym rodzaju długotrwałym procesie, ważne jest, aby zrozumieć, że nie jest to jedyny cel. Każda aplikacja, która wymaga ujednoliconej, skalowalnej logiki, może być dobrym kandydatem na platformę WF.

W rzeczywistości przyjrzyj się kolejnej ilustracji 6. Czy nie wygląda to podobnie do rysunku 2, w którym pokazano, jak aplikacja fragmenty (np. jedna utworzona wyłącznie z ASP.NET) osiągnęła skalowalność? A w rzeczywistości nie rysunek 6 ma również silną podobieństwo do rysunku 1, która pokazała ujednoliconą aplikację utworzoną przy użyciu przepływu sterowania liniowego? Rozwiązanie WF osiąga oba te elementy: przepływ sterowania aplikacji jest wyrażany w zrozumiały, ujednolicony sposób, a aplikacja może być skalowana, ponieważ nie jest zablokowana do pojedynczego procesu na jednej maszynie. Jest to piękno sposobu przepływu pracy.

I to nie wszystko; korzystanie z platformy WF ma również inne zalety. Może to ułatwić koordynowanie równoległej pracy, na przykład pomóc w śledzeniu postępu aplikacji i nie tylko. W następnej sekcji omówiono te aspekty technologii.

Inne zalety sposobu przepływu pracy

Przepływ pracy platformy WF składa się z działań wykonywanych przez środowisko uruchomieniowe programu WF. Zrozumienie świata WF wymaga pewnego nakładu pracy, jednak pisanie logiki aplikacji w tym stylu ułatwia szereg typowych wyzwań programistycznych, zgodnie z opisem w dalszej części.

Koordynowanie równoległych prac

WF BAL obejmuje działania, które odpowiadają znanym instrukcjom języka programowania. W związku z tym można pisać przepływy pracy, które zachowują się podobnie jak zwykłe programy. Jednak obecność środowiska uruchomieniowego WF umożliwia również tworzenie działań, które zapewniają więcej niż konwencjonalny język programowania. Ważnym przykładem jest użycie przepływu pracy w celu ułatwienia koordynowania równoległej pracy.

Nie należy mylić: W tym miejscu nie skupiamy się na pisaniu kodu równoległego, który jest uruchamiany jednocześnie na procesorze wielordzeniowym. Zamiast tego pomyśl o aplikacji, która, powiedzmy, musi wywołać dwie usługi sieci Web, a następnie poczekać na oba wyniki przed kontynuowaniem. Równoległe wykonywanie wywołań jest znacznie szybsze niż wykonywanie ich sekwencyjnie, ale pisanie tradycyjnego kodu, który to nie jest proste. I chociaż program .NET Framework zapewnia różne podejścia do asynchronicznego wykonywania tych wywołań, żadna z nich nie jest szczególnie prosta. Jest to kolejna sytuacja, w której przepływ pracy może świecić: WF sprawia, że jest to łatwe. Rysunek 7 przedstawia sposób.

Rysunek 7. Działania zawarte w działaniu równoległym są uruchamiane równolegle.

Na tym rysunku przedstawiono prosty przepływ pracy podobny do poprzedniego przykładu. Duża różnica polega na tym, że teraz wywołuje dwie usługi sieci Web, a następnie czeka na odpowiedź z obu przed kontynuowaniem. Aby wykonać te wywołania równolegle, twórca przepływu pracy owinął obie pary działań SendMessage i ReceiveMessage wewnątrz działania równoległego. Parallel jest standardową częścią podstawowej biblioteki działań platformy WF i wykonuje dokładnie to, co sugeruje jej nazwa: wykonuje działania, które zawiera równolegle. Zamiast sprawiać, że deweloper zajmuje się złożonością obsługi, środowisko uruchomieniowe WF i działanie równoległe wykonują ciężkie operacje podnoszenia. Wszystko, co deweloper musi zrobić, to zorganizować działania zgodnie z potrzebami, aby rozwiązać jej problem.

Zapewnianie automatycznego śledzenia

Ponieważ środowisko uruchomieniowe platformy WF może zobaczyć granice między działaniami przepływu pracy, wie, kiedy każde z tych działań rozpoczyna się i kończy. Biorąc pod uwagę to, zapewnienie automatycznego śledzenia wykonywania przepływu pracy jest proste. Rysunek 8 ilustruje ten pomysł.

Rysunek 8. Środowisko uruchomieniowe platformy WF może automatycznie śledzić wykonywanie przepływu pracy.

Jak pokazano w tym przykładzie, środowisko uruchomieniowe platformy WF może zapisywać rekord wykonywania przepływu pracy w magazynie śledzenia. Jedną z opcji jest rejestrowanie działań z rekordem zapisanym za każdym razem, gdy działanie rozpoczyna się i kończy wykonywanie. Na przykład na rysunku pokazanym na rysunku przepływ pracy wkrótce rozpocznie wykonywanie działania If, a więc środowisko uruchomieniowe programu WF zapisuje zdarzenie wskazujące to. Istnieje również możliwość śledzenia określonych zmiennych, tj. stanu przepływu pracy, rejestrowania ich wartości w różnych punktach wykonywania przepływu pracy.

Podobnie jak w przypadku innych aspektów platformy WF, automatyczne rejestrowanie nie wymaga zasadniczo żadnej pracy ze strony dewelopera. Może po prostu wskazać, że śledzenie powinno się zdarzyć, określając poziom, w jaki jest zainteresowany, a WF zajmuje się resztą.

Tworzenie działań niestandardowych wielokrotnego użytku

Działania w usłudze BAL WF zapewniają różne przydatne funkcje. Jak pokazano już, na przykład ten wbudowany zestaw zawiera działania dotyczące przepływu sterowania, wysyłania i odbierania komunikatów, równoległego wykonywania pracy i nie tylko. Jednak utworzenie rzeczywistej aplikacji zwykle wymaga utworzenia działań, które wykonują zadania specyficzne dla tej aplikacji.

Aby to możliwe, WF umożliwia tworzenie działań niestandardowych. Na przykład działania oznaczone jako X, Y i Z w przedstawionych wcześniej przepływach pracy są w rzeczywistości działaniami niestandardowymi, ponieważ rysunek 9 przedstawia jawność.

Rysunek 9. Działania niestandardowe umożliwiają przepływowi pracy wykonywanie zadań specyficznych dla aplikacji.

Działania niestandardowe mogą być proste, wykonywać tylko jedno zadanie lub mogą być działaniami złożonymi zawierającymi dowolnie złożoną logikę. Niezależnie od tego, czy są proste, czy złożone, działania niestandardowe mogą być używane na wiele różnych sposobów. Na przykład aplikacja biznesowa utworzona przy użyciu platformy WF może implementować logikę specyficzną dla aplikacji jako co najmniej jedno działanie niestandardowe. Alternatywnie dostawca oprogramowania korzystający z platformy WF może zapewnić zestaw działań niestandardowych, aby ułatwić życie swoich klientów. Na przykład usługi Windows SharePoint Services umożliwiają deweloperom tworzenie aplikacji opartych na programie WF, które współdziałają z osobami za pośrednictwem standardowych list programu SharePoint. Aby to ułatwić, program SharePoint zawiera niestandardowe działania do zapisywania informacji na liście.

Działania niestandardowe można pisać bezpośrednio w kodzie przy użyciu języka C# lub Visual Basic lub innego języka. Można je również utworzyć, łącząc istniejące działania, co pozwala na kilka interesujących opcji. Na przykład organizacja może tworzyć działania niestandardowe niższego poziomu dla najbardziej wykwalifikowanych deweloperów, a następnie spakować je do funkcji biznesowych wyższego poziomu, aby użytkownicy mniej techniczni mogli ich używać. Te działania wyższego poziomu mogą implementować dowolną wymaganą logikę biznesową, wszystkie starannie opakowane w pudełko wielokrotnego użytku.

Innym sposobem myślenia o tym jest wyświetlenie określonego zestawu działań wykonywanych przez środowisko uruchomieniowe WF jako język. Jeśli organizacja tworzy grupę działań niestandardowych, które mogą być ponownie używane do rozwiązywania konkretnych problemów w wielu aplikacjach, to to, co naprawdę robi, to tworzenie rodzaju języka specyficznego dla domeny (DSL). Po wykonaniu tej czynności osoby mniej techniczne mogą tworzyć aplikacje WF przy użyciu tych wstępnie spakowanych fragmentów funkcji niestandardowych. Zamiast pisać nowy kod w celu zaimplementowania funkcji aplikacji, przydatne nowe oprogramowanie może być tworzone wyłącznie przez zebranie istniejących działań. Ten styl DSL zdefiniowany w przepływie pracy może znacząco poprawić produktywność deweloperów w niektórych sytuacjach.

Uwidocznij procesy

Tworzenie aplikacji za pomocą tradycyjnego języka programowania oznacza pisanie kodu. Tworzenie aplikacji za pomocą platformy WF nie jest zwykle tak niskie. Zamiast tego co najmniej główny przepływ sterowania przepływu pracy można utworzyć graficznie. Aby to umożliwić, WF zawiera projektanta przepływu pracy, który działa w programie Visual Studio. Rysunek 10 przedstawia przykład.

Rysunek 10: Projektant przepływu pracy uruchomiony w programie Visual Studio umożliwia deweloperowi utworzenie przepływu pracy przez przeciąganie i upuszczanie działań.

Jak pokazano w tym przykładzie, działania dostępne dla dewelopera WF są wyświetlane po lewej stronie. Aby utworzyć przepływ pracy, może utworzyć te działania na powierzchni projektowej, aby utworzyć dowolną logikę wymaganą przez aplikację. W razie potrzeby projektant przepływu pracy platformy WF może być również ponownie hostowany w innych środowiskach, umożliwiając innym osobom korzystanie z tego narzędzia w ramach własnych ofert.

Dla niektórych deweloperów to graficzne podejście sprawia, że tworzenie aplikacji jest szybsze i łatwiejsze. Sprawia to również, że główna logika aplikacji jest bardziej widoczna. Udostępniając prosty obraz tego, co się dzieje, projektant przepływu pracy platformy WF może pomóc deweloperom szybciej zrozumieć strukturę aplikacji. Może to być szczególnie przydatne dla osób, które muszą obsługiwać wdrożone aplikacje, ponieważ nauka nowej aplikacji wystarczająco dobrze, aby ją zmienić, może być czasochłonnym procesem.

Ale co z działaniami niestandardowymi? Czy nadal nie ma potrzeby pisania kodu? Odpowiedź brzmi tak, a więc WF umożliwia również używanie programu Visual Studio do tworzenia niestandardowych działań w języku C#, Visual Basic i innych językach. Aby zrozumieć, jak to działa, ważne jest, aby zrozumieć, jak projektant WF reprezentuje różne części przepływu pracy. Na rysunku 11 pokazano, jak zwykle jest to wykonywane.

Rysunek 11. Stan i przepływ sterowania przepływu pracy są zwykle opisywane w języku XAML, podczas gdy działania niestandardowe mogą być zapisywane w kodzie.

Kompozycja przepływu pracy platformy WF — działania, które zawiera i jak te działania są powiązane — jest zwykle reprezentowana przy użyciu języka eXtensible Application Markup Language (XAML). Jak pokazano na rysunku 11, język XAML zapewnia oparty na kodzie XML sposób opisywania stanu przepływu pracy jako zmiennych i wyrażania relacji między działaniami przepływu pracy. Na przykład kod XAML dla najbardziej zewnętrznej sekwencji działań przepływu pracy zawiera działanie ReceiveMessage, a następnie działanie If, tak jak oczekiwano.

To działanie If zawiera niestandardowe działania X i Y. Zamiast tworzyć je w języku XAML, jednak te działania są zapisywane jako klasy języka C#. Chociaż istnieje możliwość utworzenia niektórych działań niestandardowych wyłącznie w języku XAML, bardziej wyspecjalizowana logika jest zwykle zapisywana bezpośrednio w kodzie. W rzeczywistości, chociaż nie jest to zwykłe podejście, deweloper może również pisać przepływy pracy w całości w kodzie — używanie języka XAML nie jest ściśle wymagane.

Korzystanie z programu Windows Workflow Foundation: niektóre scenariusze

Zrozumienie mechaniki platformy WF jest istotną częścią zrozumienia sposobu przepływu pracy. Nie wystarczy jednak: musisz również zrozumieć, jak przepływy pracy mogą być używane w aplikacjach. W związku z tym w tej sekcji przedstawiono, jak i dlaczego w niektórych typowych sytuacjach może być używana architektura WF.

Tworzenie usługi przepływu pracy

Tworzenie logiki biznesowej jako usługi często ma sens. Załóżmy na przykład, że ten sam zestaw funkcji musi być dostępny z przeglądarki za pośrednictwem ASP.NET, z klienta Silverlight i z autonomicznej aplikacji klasycznej. Zaimplementowanie tej logiki jako zestawu operacji, które można wywołać z dowolnego z tych klientów — czyli jako usługi — prawdopodobnie będzie najlepszym rozwiązaniem. Uwidacznianie logiki jako usługi umożliwia również dostęp do innej logiki, co czasami ułatwia integrację aplikacji. (Jest to podstawowa idea pojęcia SOA, architektura zorientowana na usługi).

Obecnie dla deweloperów platformy .NET flagową technologią tworzenia usług jest Windows Communication Foundation (WCF). Między innymi usługa WCF umożliwia deweloperom implementowanie logiki biznesowej, która jest dostępna przy użyciu interfejsu REST, protokołu SOAP i innych stylów komunikacji. W przypadku niektórych usług program WCF może być tym wszystkim, co jest potrzebne. Jeśli wdrażasz usługę, w której każda operacja jest autonomiczna, na przykład każda operacja może być wywoływana w dowolnym momencie bez wymaganego zamawiania — kompilowanie tych usług jako nieprzetworzonych usług WCF jest po prostu w porządku. Twórca usługi, której operacje uwidaczniają tylko dane, mogą być w stanie uciec z użyciem usługi WCF, na przykład.

Jednak w bardziej złożonych sytuacjach, w których operacje w usłudze implementują powiązany zestaw funkcji, sam program WCF może nie być wystarczający. Pomyśl o aplikacjach, które pozwalają klientom zarezerwować rezerwacje lotów lub robić zakupy online lub wykonywać inny proces biznesowy. W takich przypadkach warto użyć narzędzia WF do zaimplementowania logiki usługi. Ta kombinacja ma nawet nazwę: Logika zaimplementowana przy użyciu platformy WF i uwidoczniona za pośrednictwem usługi WCF jest znana jako usługa przepływu pracy. Rysunek 12 ilustruje pomysł.

Rysunek 12. Usługa przepływu pracy używa programu WCF do uwidaczniania logiki opartej na programie WF.

Jak pokazano na rysunku, program WCF umożliwia uwidacznianie jednego lub większej liczby punktów końcowych, które klienci mogą wywoływać za pośrednictwem protokołu SOAP, REST lub innego. Gdy klient wywołuje operację początkową w tej przykładowej usłudze, żądanie jest obsługiwane przez pierwsze działanie ReceiveMessage przepływu pracy. Zostanie wyświetlone następne działanie If, a które z zawartych w nim działań niestandardowych zostanie wykonane, zależy od zawartości żądania klienta. Po zakończeniu operacji If zostanie zwrócona odpowiedź za pośrednictwem funkcji SendMessage. Drugie żądanie klienta, wywołując inną operację, jest obsługiwane w podobny sposób: jest akceptowane przez komunikat ReceiveMessage, przetwarzany przez logikę przepływu pracy, a następnie odpowiedział na użycie funkcji SendMessage.

Dlaczego tworzenie logiki biznesowej zorientowanej na usługi w ten sposób jest dobrym pomysłem? Odpowiedź jest oczywista: Umożliwia tworzenie ujednoliconej i skalowalnej aplikacji. Zamiast wymagać, aby każda operacja zawierała testy — czy jest ona legalna, aby wywołać mnie teraz? — ta wiedza jest osadzona w samej logice przepływu pracy. Ułatwia to pisanie aplikacji i, równie ważne, łatwiejsze do zrozumienia dla osób, które muszą w końcu ją utrzymać. Zamiast pisać własny kod w celu obsługi skalowalności i zarządzania stanem, środowisko uruchomieniowe platformy WF wykonuje te czynności.

Usługa przepływu pracy pobiera również wszystkie opisane wcześniej korzyści, podobnie jak każda inna aplikacja WF. Należą do nich następujące elementy:

• Implementowanie usług, które wykonują równoległą pracę, jest proste: po prostu upuszczanie działań do działania równoległego.
• Śledzenie jest udostępniane przez środowisko uruchomieniowe.
• W zależności od domeny problemu może być możliwe utworzenie niestandardowych działań wielokrotnego użytku do użycia w innych usługach.
• Przepływ pracy można utworzyć graficznie z logiką procesu widoczną bezpośrednio w projektancie przepływu pracy platformy WF.

Używanie usług WF i WCF w następujący sposób — tworzenie usług przepływu pracy — nie było tak łatwe we wcześniejszych wersjach platformy WF. Dzięki platformie .NET Framework 4 ta kombinacja technologii łączy się w bardziej naturalny sposób. Celem jest jak najprostsze tworzenie logiki biznesowej w tym stylu.

Uruchamianie usługi przepływu pracy za pomocą polecenia "Dublin"

Jeden duży problem z przepływami pracy nie został jeszcze omówiony: Gdzie są uruchamiane? Środowisko uruchomieniowe WF jest klasą, podobnie jak działania. Wszystkie te elementy muszą być uruchamiane w procesie hosta, ale jaki jest ten proces?

Odpowiedź brzmi, że przepływy pracy platformy WF mogą być uruchamiane w prawie każdym procesie. Możesz utworzyć własnego hosta, nawet zastępując niektóre podstawowe usługi platformy WF (takie jak trwałość), jeśli chcesz. Wiele organizacji to zrobiło, zwłaszcza dostawców oprogramowania. Jednak tworzenie naprawdę funkcjonalnego procesu hosta dla platformy WF, wraz z możliwościami zarządzania, nie jest najprostszą rzeczą na świecie. A w przypadku organizacji, które chcą wydać pieniądze na tworzenie logiki biznesowej, a nie infrastruktury, unikanie tego wysiłku ma sens.

Prostszą opcją jest hostowanie przepływu pracy WF w procesie roboczym udostępnianym przez internet information server (IIS). Chociaż to działa, zapewnia tylko gołe rozwiązanie kości. Aby ułatwić życie deweloperom WF, firma Microsoft udostępnia kod technologii o nazwie "Dublin". Zaimplementowane jako rozszerzenia usług IIS i usługi aktywacji procesów systemu Windows (WAS), głównym celem "Dublin" jest uczynienie usług IIS i WAS bardziej atrakcyjnym hostem usług przepływu pracy. Rysunek 13 pokazuje, jak wygląda usługa przepływu pracy, gdy jest uruchomiona w środowisku "Dublin".

Rysunek 13: "Dublin" zapewnia zarządzanie usługami przepływu pracy i nie tylko.

Chociaż sama platforma WF zawiera mechanizmy utrwalania stanu, śledzenia i nie tylko przepływu pracy, zapewnia tylko podstawowe informacje. "Dublin" opiera się na wewnętrznej obsłudze WF, aby zaoferować bardziej użyteczne i możliwe do zarządzania środowisko. Na przykład wraz z magazynem trwałości opartym na programie SQL Server i magazynem śledzenia "Dublin" udostępnia narzędzie do zarządzania do pracy z tymi magazynami. To narzędzie, zaimplementowane jako rozszerzenia menedżera usług IIS, umożliwia użytkownikom badanie i zarządzanie utrwalone przepływy pracy (np. kończenie) utrwalone przepływy pracy, kontrolowanie, ile śledzenia jest wykonywane, badanie dzienników śledzenia i nie tylko.

Wraz z dodatkami do istniejących funkcji WF", "Dublin" dodaje również inne usługi. Na przykład "Dublin" może monitorować uruchomione wystąpienia przepływu pracy, automatycznie uruchamiając ponownie wszystkie te wystąpienia, które kończą się niepowodzeniem. Głównym celem firmy Microsoft w programie "Dublin" jest jasne: zapewnienie przydatnego zestawu narzędzi i infrastruktury do zarządzania usługami przepływu pracy i monitorowania ich hostowanymi w usługach IIS/WAS.

Używanie usługi przepływu pracy w aplikacji ASP.NET

Prawdopodobnie można powiedzieć, że większość aplikacji platformy .NET używa ASP.NET. Wprowadzenie głównego nurtu przepływu pracy oznacza, że platforma WF jest atrakcyjną opcją dla deweloperów ASP.NET.

We wcześniejszych wersjach platformy WF wydajność przepływu pracy nie była wystarczająca dla znacznej liczby aplikacji ASP.NET. W przypadku wersji .NET Framework 4 projektanci WF ponownie zaprojektowali ważne części technologii, co znacznie zwiększa wydajność. Ta wersja wraz z pojawieniem się "Dublin" sprawia, że aplikacje oparte na WF — szczególnie usługi przepływu pracy — są bardziej opłacalne dla deweloperów ASP.NET. Rysunek 14 przedstawia prosty obraz tego, jak wygląda.

Rysunek 14. Logika biznesowa aplikacji ASP.NET może zostać zaimplementowana jako usługa przepływu pracy

W tym scenariuszu ASP.NET strony implementują tylko interfejs użytkownika aplikacji. Jej logika jest implementowana w całości w usłudze przepływu pracy. W usłudze przepływu pracy aplikacja ASP.NET jest tylko innym klientem, natomiast w aplikacji ASP.NET usługa przepływu pracy wygląda jak każda inna usługa. Nie trzeba pamiętać, że ta usługa jest implementowana przy użyciu platform WF i WCF.

Po raz kolejny, wielkie pytanie brzmi: Dlaczego byś to zrobił? Dlaczego nie tylko napisać logikę ASP.NET aplikacji w zwykły sposób? Co kupujesz za pomocą platformy WF (i WCF)? W tym momencie większość odpowiedzi na te pytania jest prawdopodobnie oczywista, ale nadal warto je odtworzyć:

• Zamiast rozpowszechniać logikę aplikacji na wielu różnych stronach ASP.NET, logika ta może zostać zaimplementowana w ramach jednego ujednoliconego przepływu pracy. Szczególnie w przypadku dużych witryn może to znacznie ułatwić tworzenie i konserwowanie aplikacji.
• Zamiast jawnie pracować ze stanem w aplikacji ASP.NET, być może przy użyciu obiektu Session lub czegoś innego deweloper może polegać na środowisku uruchomieniowym platformy WF, aby to zrobić. Aplikacja ASP.NET musi śledzić tylko identyfikator wystąpienia dla każdego wystąpienia przepływu pracy (najprawdopodobniej jeden na użytkownika), na przykład przez zapisanie go w pliku cookie. Gdy aplikacja dostarczy ten identyfikator do adresu "Dublin", wystąpienie przepływu pracy zostanie automatycznie ponownie załadowane. Następnie rozpoczyna wykonywanie, gdzie zostało przerwane, ze wszystkimi przywróconymi stanami.
• Inne korzyści wynikające z platformy WF mają również zastosowanie, w tym łatwiejsze równoległość, wbudowane śledzenie, potencjał działań wielokrotnego użytku oraz możliwość wizualizacji logiki aplikacji.

Ponieważ usługa przepływu pracy nie jest powiązana z określonym procesem na określonej maszynie, może być równoważona obciążenie w wielu wystąpieniach "Dublin". Rysunek 15 przedstawia przykład tego, jak może to wyglądać.

Rysunek 15. Replikowana aplikacja ASP.NET może używać wielu wystąpień "Dublin" do wykonywania usługi przepływu pracy.

W tym prostym scenariuszu strony aplikacji ASP.NET są replikowane na trzech maszynach serwerowych usług IIS. Chociaż te strony obsługują interakcję z użytkownikami, logika biznesowa aplikacji jest implementowana jako usługa przepływu pracy uruchomiona z funkcją "Dublin". Uruchomiono dwa wystąpienia środowiska "Dublin", z których każdy jest na własnej maszynie. Gdy pojawi się pierwsze żądanie od użytkownika, moduł równoważenia obciążenia kieruje go do najwyższego wystąpienia usług IIS. Strona ASP.NET, która obsługuje to żądanie, wywołuje operację w usłudze przepływu pracy, która implementuje ten fragment logiki biznesowej. Powoduje to rozpoczęcie wykonywania przepływu pracy WF w wystąpieniu "Dublin" na najbardziej górnej maszynie na rysunku. Po zakończeniu odpowiednich działań w tym przepływie pracy wywołanie powraca do strony ASP.NET, a przepływ pracy jest utrwalany.

Drugie żądanie użytkownika jest kierowane do innego wystąpienia usług IIS. Strona ASP.NET na tym komputerze, z kolei, wywołuje operację w przepływie pracy (utrwalonej) na innej maszynie niż ta, która obsłużyła swoje pierwsze żądanie. To nie jest problem: "Dublin" po prostu ładuje wystąpienie przepływu pracy z magazynu trwałości, który współudzieli z innym serwerem. Ta ponownie załadowana usługa przepływu pracy obsługuje żądanie użytkownika, wybierając miejsce, w którym została przerwana.

Zrozumienie platformy WF (i WCF), a następnie nauczenie się tworzenia logiki w tym nowym stylu wymaga pewnej pracy. W przypadku prostych aplikacji ASP.NET wspinaczka na tę krzywą nauki może nie być warta wysiłku wymaganego. Każda osoba tworząca większe aplikacje internetowe przy użyciu platformy .NET powinna jednak przynajmniej rozważyć możliwość utworzenia logiki jako usługi przepływu pracy.

Korzystanie z przepływów pracy w aplikacjach klienckich

Do tej pory skupiono się wyłącznie na tworzeniu aplikacji serwerowych przy użyciu platformy WF. Jednak chociaż jest to sposób, w jaki technologia jest najczęściej używana dzisiaj, platforma WF może być również przydatna dla aplikacji klienckich. Jego aspekty skalowalności zwykle nie dodają wiele w tym przypadku, ponieważ kod uruchamiany na maszynach klienckich zwykle nie musi obsługiwać wielu równoczesnych użytkowników, ale nadal może być używany WF.

Rozważmy na przykład aplikację kliencką, która przedstawia użytkownika za pomocą interfejsu graficznego utworzonego przy użyciu windows Forms lub Windows Presentation Foundation. Aplikacja prawdopodobnie będzie mieć programy obsługi zdarzeń do przetwarzania kliknięć myszy użytkownika, być może rozpowszechniając logikę biznesową w tych programach obsługi zdarzeń. Jest to tak samo jak aplikacja ASP.NET rozłożona logikę między grupą oddzielnych stron i może tworzyć te same wyzwania. Przepływ aplikacji może być trudny do rozpoznania, na przykład, a deweloper może wymagać wstawienia kontroli, aby upewnić się, że elementy są wykonywane w odpowiedniej kolejności. Podobnie jak w przypadku aplikacji ASP.NET implementacja tej logiki jako ujednoliconego przepływu pracy WF może pomóc rozwiązać te problemy.

Inne aspekty platformy WF mogą być również przydatne na kliencie. Załóżmy, że aplikacja musi równolegle wywoływać wiele usług sieci Web zaplecza lub może korzystać ze śledzenia. Podobnie jak na serwerze platforma WF może pomóc w rozwiązywaniu tych problemów. Chociaż większość aplikacji WF jest obecnie uruchamiana na serwerach, ważne jest, aby pamiętać, że nie jest to jedyny wybór.

Bliższe spojrzenie: Technologia windows Workflow Foundation

Celem tego przeglądu nie jest utworzenie dewelopera platformy WF. Mimo to wiedza o technologii WF może pomóc w podejmowaniu decyzji, kiedy warto wybrać sposób przepływu pracy. W związku z tym ta sekcja przyjrzy się bliżej niektórym z najważniejszych części platformy WF.

Rodzaje przepływów pracy

W programie .NET Framework 4 deweloperzy platformy WF zazwyczaj wybierają dwa różne style przepływu pracy, wybierając różne najbardziej zewnętrzne działania. Te działania to:

• Sekwencja: wykonuje działania w sekwencji, po drugiej. Sekwencja może zawierać działania If, While działania i inne rodzaje przepływu sterowania. Nie można jednak przechodzić wstecz — wykonywanie musi zawsze iść naprzód.
• Schemat blokowy: wykonuje działania po drugim, takie jak sekwencja, ale umożliwia również sterowanie powrotem do wcześniejszego kroku. To bardziej elastyczne podejście, nowe w wersji .NET Framework 4 platformy WF, jest bliżej sposobu działania rzeczywistych procesów i sposobu, w jaki większość z nas myśli.

Chociaż zarówno sekwencja, jak i schemat blokowy mogą działać jako najbardziej zewnętrzne działania w przepływie pracy, mogą być również używane w przepływie pracy. Dzięki temu te działania złożone mogą być zagnieżdżone w dowolny sposób.

W dwóch pierwszych wersjach platforma WF zawierała również inną opcję najbardziej zewnętrznego działania przepływu pracy o nazwie State Machine. Jak sugeruje jej nazwa, to działanie umożliwia deweloperowi jawne utworzenie maszyny stanu, a następnie działanie wyzwalania zdarzeń zewnętrznych na tym komputerze stanu. WF w programie .NET Framework 4 jest jednak dużą zmianą, która wymagała ponownego pisania większości działań we wcześniejszych wersjach i utworzenia nowego projektanta. Ze względu na nakład pracy twórcy platformy WF nie będą dostarczać działań state machine z początkowej wersji programu .NET Framework 4. (Nawet zasoby firmy Microsoft nie są bez ograniczeń). Mimo to nowe działanie schematu blokowego powinno dotyczyć wielu sytuacji, które wcześniej były wymagane przy użyciu maszyny stanu.

Biblioteka działań podstawowych

Przepływ pracy może zawierać dowolny zestaw działań, które deweloper wybierze do użycia. Jest to na przykład całkowicie legalne, aby przepływ pracy zawierał tylko działania niestandardowe. Mimo to nie jest to bardzo prawdopodobne. W większości przypadków przepływ pracy platformy WF będzie używać co najmniej niektórych elementów udostępnionych w bibliotece działań podstawowych. Wśród bardziej przydatnych działań BAL udostępnianych przez platformę WF w programie .NET Framework 4 są następujące:

• Przypisywanie: przypisuje wartość do zmiennej w przepływie pracy.
• Kompensowanie: zapewnia sposób na rekompensatę, taką jak obsługa problemu występującego w długotrwałej transakcji.
• DoWhile: wykonuje działanie, a następnie sprawdza warunek. Działanie zostanie wykonane w całym czasie, o ile warunek jest spełniony.
• Schemat blokowy: grupuje zestaw działań wykonywanych sekwencyjnie, ale umożliwia również sterowanie powrotem do wcześniejszego kroku.
• ForEach: wykonuje działanie dla każdego obiektu w kolekcji.
• Jeśli: tworzy gałąź wykonywania.
• Równoległe: uruchamia wiele działań w tym samym czasie.
• Utrwalanie: jawnie żąda środowiska uruchomieniowego platformy WF, aby utrwalić przepływ pracy.
• Wybierz: umożliwia oczekiwanie na zestaw zdarzeń, a następnie wykonanie tylko działania skojarzonego z pierwszym zdarzeniem.
• ReceiveMessage: odbiera komunikat za pośrednictwem programu WCF.
• SendMessage: wysyła wiadomość za pośrednictwem usługi WCF.
• Sekwencja: grupuje zestaw działań wykonywanych sekwencyjnie. Oprócz działania jako najbardziej zewnętrznego działania przepływu pracy sekwencja jest również przydatna w przepływach pracy. Na przykład działanie While może zawierać tylko jedno inne działanie. Jeśli to działanie to Sekwencja, deweloper może wykonać dowolną liczbę działań w pętli while.
• Przełącznik: zapewnia wielokierunkową gałąź wykonywania.
• Throw: zgłasza wyjątek.
• TryCatch: umożliwia utworzenie bloku try/catch w celu obsługi wyjątków.
• Podczas wykonywania pojedynczego działania, o ile warunek jest spełniony.

Nie jest to pełna lista — WF w programie .NET Framework 4 zawiera więcej. Ponadto firma Microsoft planuje udostępnić nowe działania WF w witrynie CodePlex, swojej witrynie hostingowej dla projektów typu open source. Wkrótce po wydaniu programu .NET Framework 4 poszukaj na przykład działań, które umożliwiają przepływom pracy wystawianie zapytań i aktualizacji bazy danych, wykonywanie poleceń programu PowerShell i nie tylko.

Jak sugeruje ta lista, BAL w dużej mierze odzwierciedla funkcjonalność tradycyjnego języka programowania ogólnego przeznaczenia. Nie powinno to być zaskakujące, ponieważ WF ma być technologią ogólnego przeznaczenia. Jak opisano w tym omówieniu, podejście, które podejmuje — działania wykonywane przez środowisko uruchomieniowe platformy WF — czasami mogą poprawić życie deweloperom aplikacji.

Przepływ pracy w programie .NET Framework 4

Wersja 4 programu .NET Framework wprowadza znaczące zmiany w programie Windows Workflow Foundation. Działania w BAL zostały ponownie napisane, na przykład, a niektóre nowe zostały dodane. Daje to realne korzyści — wiele przepływów pracy działa teraz znacznie szybciej, ale oznacza to również, że przepływy pracy utworzone przy użyciu wcześniejszych wersji platformy WF nie mogą być wykonywane przez wersję środowiska uruchomieniowego WF platformy .NET 4. Te starsze przepływy pracy nadal mogą działać razem z przepływami pracy programu .NET Framework 4 bez zmian — nie trzeba ich wyrzucać. Ponadto działania utworzone przy użyciu starszych wersji platformy WF, w tym całych przepływów pracy, mogą być uruchamiane wewnątrz nowego działania międzyoperacyjnego dostępnego w programie .NET Framework 4. Dzięki temu logika ze starszych przepływów pracy będzie używana w nowych.

Wraz z lepszą wydajnością ta nowa wersja platformy WF wprowadza również inne interesujące zmiany. Na przykład wcześniejsze wersje platformy WF zawierały działanie Kodu, które może zawierać dowolny kod. Pozwoli to deweloperowi dodać do przepływu pracy prawie dowolną żądaną funkcjonalność, ale było to nieco nieległe rozwiązanie. W programie .NET Framework 4 twórcy platformy WF znacznie upraszczali pisanie działań niestandardowych, a więc działanie Code zostało usunięte. Nowe funkcje są teraz tworzone jako działanie niestandardowe.

Zmiany w wersji .NET Framework 4 są najbardziej istotne od czasu oryginalnego wyglądu platformy WF w 2006 roku. Wszystkie z nich mają jednak ten sam cel: ułatwia deweloperom tworzenie skutecznych aplikacji przy użyciu przepływów pracy.

Konkluzja

Program Windows Workflow Foundation oferuje realne korzyści dla wielu aplikacji. W pierwszych wersjach WF uderzył akord głównie z dostawcami oprogramowania. Te oryginalne wcielenia technologii były przydatne, ale nie były one naprawdę odpowiednie do głównego nurtu przedsiębiorstwa. W programie .NET Framework 4 twórcy programu WF chcą to zmienić.

Dzięki temu, że WF i WCF działają dobrze, poprawiając wydajność WF, zapewniając lepszy projektant przepływu pracy i oferując w pełni funkcjonalny proces hosta z "Dublin", firma Microsoft czyni przepływ pracy bardziej atrakcyjny dla szerszej gamy scenariuszy. Jego dni jako wyspecjalizowany gracz w dramat tworzenia aplikacji systemu Windows zbliżają się do końca. WF jest w drodze do centrum etapu.

Informacje o autorze

David Chappell jest głównym Chappell & Associates w San Francisco w Kalifornii. Dzięki swoim mówieniu, pisaniu i konsultacji pomaga ludziom na całym świecie zrozumieć, wykorzystać i podejmować lepsze decyzje dotyczące nowej technologii.