Standardy workflow przy budowie systemu informatycznego

Transkrypt

1 mgr inż. Rafał Renk mgr inż. Rafał Knapik prof. dr hab. inż. Witold Hołubowicz Uniwersytet im. Adama Mickiewicza, UAM Poznań Instytut Technik Telekomunikacyjnych i Informatycznych, ITTI Poznań Standardy workflow przy budowie systemu informatycznego Obecnie na rynku istnieje wiele grup standardów, obejmujących różne funkcjonalności oraz różne poziomy implementacji systemów workflow. Standardy te cały czas ewoluują, łączą się ze sobą, powstają nowe wersje. Na bazie doświadczeń uzyskanych w trakcie realizacji projektu IST VISP (Virtual ISP) w ramach 6 Programu Ramowego w artykule przedstawiona została analiza obecnej sytuacji dotyczącej organizacji i standardów workflow. Artykuł przedstawia napotkane problemy i trudności, jak również podejście do oceny oraz wyniki oceny stosowalności poszczególnych standardów z punktu widzenia tworzonej w ramach projektu platformy VISP. 1 Wprowadzenie Zagadnieniami związanymi z systemami workflow zajmuje się wiele organizacji na całym świecie. Każda z organizacji promuje swoje własne rozwiązania w tym zakresie oraz wykorzystywane terminy i pojęcia związane z tego rodzaju systemami. Sytuacja w tej dziedzinie cały czas ewoluuje. Organizacje i wspierane przez te organizacje standardy łączą się. Nie istnieje jeden powszechnie przyjęty i dojrzały standard realizacji workflow. Dodatkowo sytuację związaną ze standardami workflow komplikuje wielowarstwowość tego rodzaju standardów. W praktycznych zastosowaniach konieczne jest określenie zestawu standardów odpowiedzialnych za różne funkcje realizacji workflow od modelowania choreografii procesów przez wykonywalne definicje workflow do standardów wspierających operacje administracyjne i przesyłanie komunikatów. Elementem, jaki należy wziąć pod uwagę przy tworzeniu rozwiązań workflow, jest dostępność narzędzi wspierających tworzenie workflow oraz kompatybilność i współdziałanie różnych standardów na różnych warstwach tworzenie workflow. Rozdział 2 niniejszego artykułu przedstawia ogólny opis platformy informatycznej ułatwiającej współpracę wielu dostawców usług internetowych. W rozdziale 3 przedstawiono podstawowe pojęcia i ich definicje związane z systemami workflow wykorzystywane w niniejszym artykule. Kolejny rozdział (rozdział 4) przedstawia krótki opis organizacji zajmujących się standardami związanymi z workflow oraz standardy workflow. Rozdział 5 opisuje główne wymagania przyjęte do realizacji platformy VISP i metodykę oceny stosowalności poszczególnych standardów do realizacji tej platformy. W rozdziale 6 przedstawione są wyniki przeprowadzonej analizy i zestaw rekomendowanych standardów do realizacji platformy VISP. Rozdział 7 przestawia krótkie podsumowanie artykułu oraz wnioski. 2 Platforma programistyczna dla ISP - projekt VISP Projekt VISP jest projektem realizowanym w ramach 6 Programu Ramowego. Projekt ten jest projektem typu STREP, a jego całkowity budżet wynosi ok. 3,5 mln euro. Czas realizacji projektu to: 32 miesiące. Projekt rozpoczął się w listopadzie 2005 roku, a koniec projektu przewidziany jest na czerwiec W skład konsorcjum wchodzi 11 partnerów z takich krajów jak: Belgia, Szwajcaria. Luksemburg, Francja, Polska, Grecja, Niemcy, Włochy, Rumunia, Bułgaria. Partnerzy reprezentują ośrodki uczelniane, małe i średnie przedsiębiorstwa (ISP) oraz duże firmy komercyjne.

2 Głównym celem projektu VISP jest opracowanie platformy programowej dla małych i średnich przedsiębiorstw (MŚP) z sektora ISP (dostawców usług internetowych). Opracowana platforma ma umożliwiać współpracę i wspólne działanie różnych dostawców usług internetowych w celu oferowania kompleksowych usług uwzględniających potrzeby biznesowe klientów. Współpracujące firmy ISP określane są jako klaster VISP (ang. VISP cluster), a platforma programowa jako platforma VISP (ang. VISP platform). Platforma VISP ma wspomóc dostawców usług internetowych poprzez m.in.: zwiększenie satysfakcji klientów, którzy będą mieli do dyspozycji większą liczbę oferowanych usług i będą mieli większą kontrola nad subskrybowanymi usługami, udostępnienie możliwości definiowania nowych usług poprzez łączenie przygotowanych komponentów usługowych, szersze otwarcie rynku lokalnego (zwiększenie jego konkurencyjności), Rysunek 1 przedstawia schemat modelu referencyjnego platformy VISP, gdzie przedstawiona jest współpraca różnych podmiotów powiązanych ze sobą hierarchicznie (poziomy np. P1.1 i P1.2 oraz wewnętrzne podmioty np. I2.2.1) na platformie VISP. VISP Level 3 P1.2 P1.1 Level 2 P3 P2.1 P5 P4 Level 1 C3 C4 C1 C2 Level 1 P2.3 Level P2.2 3 I I P - Partner I - Internal entity C - Customer Rysunek 1 Schemat modelu referencyjnego platformy VISP [VISP_AnnexI] Strzałki na przedstawionym powyżej rysunku reprezentują przepływ procesów biznesowych pomiędzy partnerami klastra, a także wewnątrz organizacji. Zautomatyzowanie tych procesów to podstawowy cel platformy realizowanej w ramach projektu VISP. Z tego też względu jednym z najbardziej istotnych zagadnień przy jej projektowaniu jest właściwy dobór standardów workflow. 3 Podstawowe pojęcia związane z systemami workflow Przed opisem kryteriów doboru standardów workflow warto ustalić podstawowe pojęcia z tego obszaru oraz relacje między nimi. Rysunek 2 przedstawia model opracowany przez jedną z podstawowych organizacji standaryzacyjnych - The Workflow Management Coalition (WfMC), wykorzystywany w niniejszym artykule.

3 jest zdefiniowany za pomocą Proces biznesowy (np. co ma się zdarzyć w trakcie procesu) jest zarządzany przez Podproces Definicja procesu (zapis tego co ma się zdarzyć w trakcie procesu) składa się z Czynność realizowana ręcznie (nie będąca częścią systemu przepływu pracy) używany do tworzenia poprzez i zarządzania Instancja procesu Czynność (zapis tego co się rzeczywiście która może być dzieje) lub reprezentowana w trakcie realizacji przepływu pracy przez Czynność realizowana automatycznie System zarządzania przepływem pracy (sterowanie zautomatyzowaną częścią procesu biznesowego) Instancja czynności i/lub złożoną z jednej lub wielu która zawiera Element pracy (zadanie przydzielone uczestnikowi przepływu pracy) Wywoływane aplikacje (narzędzia informatyczne umożliwiające wykonanie czynności) Rysunek 2 Zależności pomiędzy podstawowymi pojęciami [WfMC_Glos: 1999] Przedstawione poniżej definicje i objaśnienia poszczególnych pojęć oparte są o definicje zaproponowane w [WfMC_Glos: 1999]. Proces biznesowy jest to jedna lub wiele powiązanych procedur lub czynności, które wspólnie służą realizacji celu biznesowego, zwykle wykonywanych w ramach struktury organizacyjnej określającej role uczestników procesu i powiązania pomiędzy rolami. Definicja procesu jest to taka forma prezentacji procesu biznesowego, która umożliwia zautomatyzowane przetwarzanie, takie jak modelowanie czy wykonywanie procesu przez system zarządzania przepływem pracy. Definicja procesu składa się z sieci czynności i powiązań pomiędzy nimi, kryteriów rozpoczęcia oraz zakończenia procesu i informacji na temat poszczególnych czynności, takich jak wykonawcy czynności czy powiązane z czynnościami aplikacje i dane. Instancja procesu to reprezentacja pojedynczego uruchomienia procesu lub czynności należącej do procesu wraz z przekazaniem powiązanych z tym danych. Każda instancja jest obrazem oddzielnego wątku wykonywania procesu lub czynności, który może być sterowany niezależnie. Dla każdej instancji przypisany jest wewnętrzny stan i widziany z zewnątrz identyfikator, dzięki któremu można na przykład odczytywać dane umożliwiające obserwacje przebiegu procesu. Workflow (w języku polskim określany jako przepływ pracy) jest to zautomatyzowany w całości lub w części proces biznesowy, w trakcie którego dokumenty, informacje i zadania są przekazywane pomiędzy uczestnikami procesu w celu umożliwienia wykonania czynności w sposób zgodny ze zdefiniowanymi regułami. System workflow (w języku polskim określany jako system zarządzania przepływem pracy) jest to system umożliwiający za pomocą oprogramowania tworzenie definicji procesów oraz zarządzanie wykonywaniem instancji procesów uruchomionych na jednym lub wielu silnikach przepływu pracy, który potrafi interpretować definicje procesów, komunikować się z uczestnikami przepływu pracy oraz, tam gdzie jest to wymagane, wywoływać inne aplikacje. Czynność wykorzystywana w powyższych definicjach to opis części pracy, którą można przedstawić jako logiczny krok w trakcie procesu. Czynność może być wykonywana ręcznie, nie jest wtedy zautomatyzowana, lub automatycznie. Tam gdzie wymagane są zasoby ludzkie, czynność przydzielana jest uczestnikowi przepływu pracy. Uczestnik przepływu pracy to zasób wykonujący część pracy odpowiadający czynności.

4 4 Organizacje i standardy związane z przepływem pracy Istnieje wiele organizacji standaryzacyjnych, których prace związane są w większym lub mniejszym stopniu z workflow. Do głównych z nich zaliczamy: OASIS (ang. Organization for the Advancement of Structured Information Standards), BPMI (ang. Business Process Management Initiative), OMG (ang. Object Management Group), W3C (ang. World Wide Web Consortium), WfMC (Workflow Management Coalition), RosettaNet, OAGi (ang. Open Applications Group). Rysunek 3 przedstawia powiązanie pomiędzy poszczególnymi wymienionymi powyżej organizacjami standaryzacyjnymi związanymi z systemami workflow, a listą wspieranych przez te organizacje standardów workflow (oznaczonych odpowiednimi kolorami). Standardy workflow przedstawione są na różnych warstwach 1. Warstwy te związane są z różnymi etapami i poziomem szczegółowości tworzenia specyfikacji workflow. Poszczególne warstwy tworzenia workflow odpowiadają za: modelowanie procesów - standardy definiujące sposób, w jaki poszczególne pojęcia związane z procesami biznesowymi powinny być reprezentowane na diagramach, choreografia - definiuje sposób, w jaki niezależne, organizacje uczestniczące w procesie biznesowym komunikują się ze sobą w trakcie wspólnego dążenia do osiągnięcia celu biznesowego, orkiestracja definiuje czynności i działania realizowane w trakcie procesu przez organizację, administracja workflow - wywoływanie i monitorowanie stopnia wykonania czynności i działań oraz utrzymywanie definicji procesów, rozszerzenia - głównie umożliwiające definiowanie transakcji w ramach procesów, modele referencyjne - gotowe definicje procesów biznesowych możliwe do wykorzystania w trakcie integracji procesów biznesowych różnych partnerów, opis usług - opis funkcji realizowanych przez usługi sieciowe oraz sposobu dostępu do tych funkcji, komunikacja - wymiana komunikatów za pomocą języka XML, sposób konstrukcji komunikatów oraz zarządzania komunikacją. Activities Process Modelling UMM UML MDA / BPDM BPMN BPSM Process Choreography BPSS WSBPEL (abstract) WS-CDL WSCI WSCL Process Orchestration WSBPEL (executable) ebxml CPPA BPML XPDL Workflow Adminstration BPQL WfXML Workflow Extensions BPXL BTP Information Models UBL OAGIS RosettaNet PIP Service Descriptions WSDL Communication s SOAP ASAP Standards Bodies OASIS ebxml OMG BPMI W3C WfMC OAGi RosettaNet Rysunek 3 Organizacje standaryzacyjne promujące standardy związane z workflow [VISP_D21] 1 Na rysunku 2 oznaczone jako Activities.

5 Przedstawione warstwy oraz rozmieszczenie standardów na poszczególnych warstwach jest rozmieszczeniem przykładowym nie jest to stos protokołów. Rysunek 4 prezentuje określone relacje i powiązania pomiędzy poszczególnymi standardami. Podwójne linie ze strzałkami reprezentują ewolucję standardów poprzez ich łączenie się, pojedyncza linia ciągła oznacza możliwość pełnego mapowania funkcjonalności pomiędzy standardami a pojedyncza linia przerywana oznacza możliwość mapowania wybranych funkcjonalności pomiędzy standardami. Standardy te stanowią wstępną listę standardów, które w dalszych etapach realizacji projektu poddane zostały ocenie wg wcześniej przygotowanych kryteriów. UMM Modelling methodologies Graphical notation BPMN UML BPSS WS-CDL Choreography (non executable) WSCI WSCL Orchestration (executable) Administration & monitoring BPML BPEL BPEL4WS XPDL BPSS+ CPP/CPA BPELJ JSR207 jpdl BPQL WSFL XLANG Abstract Programming language based Wf-XML BPSM RosettaNet Interfaces UBL OAGIS interfaces Information models [] SOAP ASAP Wf-XML Extension layers (communication protocols, etc) Rysunek 4 Wybrane powiązania pomiędzy głównymi standardami workflow [VISP_AnnexI] Szersza charakterystyka poszczególnych standardów przedstawionych na powyższym rysunku zawarte jest w p. 6 niniejszego artykułu. 5 Kryteria porównania standardów workflow Rysunek 5 przedstawia etapy wyboru zestawu standardów dla platformy VISP. Jako dane wejściowe w realizowanej metodyce wyboru standardów posłużyły: wymagania dla platformy VISP (p. 5.1) oraz zdefiniowany zbiór standardów workflow (p. 4). W oparciu o wymagania platformy VISP określono zestaw kryteriów technicznych (p. 5.2) i rynkowych (p. 5.3) dla poszczególnych grup standardów. Na bazie opracowanych kryteriów dokonano analizy standardów (p. 6.1 i p. 6.2) oraz zdefiniowano rekomendowany zestaw standardów dla platformy VISP (p. 6.3).

6 Wybrane do analizy standardy workflow Wymagania dla platformy VISP Kryteria techniczne Kryteria rynkowe Analiza standardów Rekomendowany zestaw standardów dla platformy VISP Rysunek 5 Etapy wyboru zestawu standardów dla platformy VISP W ramach pracy przyjęto jako kryteria opisujące cechy charakterystyczne standardów następujące grupy wymagań: wymagania stawiane przez platformę VISP (w oparciu o [VISP_AnnexI]), kryteria techniczne, kryteria rynkowe. 5.1 Wymagania stawiane przez platformę VISP W celu możliwości praktycznej implementacji platformy programowej VISP wybrane do jej implementacji standardy muszą spełniać szereg wymagań. Poniżej przedstawiona jest, krótka charakterystyka podstawowych wymagań dla platformy VISP [VISP_AnnexI, VISP_D11]. Wybrane dla platformy VISP standardy powinny zapewniać możliwość współpracy wielu podmiotów w klastrze VISP w dwóch różnych trybach: tryb Wirtualnego Przedsiębiorstwa, w którym klaster VISP widziany jest z zewnątrz jako jedna organizacja, zachowując wewnętrznie własną odrębność, tryb Społeczności, w którym z zewnątrz nie widać klastra, a tylko poszczególnych partnerów korzystających z własnych zasobów. Ponadto platforma VISP i wykorzystane standardy powinny zapewniać możliwość współpracy z innymi systemami np. ERP, wsparcia różnego rodzaju modeli biznesowych wykorzystywanych przez poszczególnych partnerów, wsparcia różnego rodzaju modeli ekonomicznych (rozliczeń wewnątrz i na zewnątrz klastra VISP), wsparcie procesów realizacji usług dla klienta oraz procesów związanych z działaniem klastra VISP (np. dodawanie/usuwanie partnera z klastra). Z punktu widzenia usługowego standardy workflow powinny umożliwiać wsparcie m.in.: wykorzystania dekompozycji usług oferowanych przez różnych ISP na bloki funkcjonalne w celu budowy nowych usług, możliwość przekazywania informacji o rezerwacji zasobów, parametrów SLA wewnątrz klastra VISP i dla klienta zewnętrznego, monitorowanie aktualnie realizowanych usług. W ramach tworzenia platformy VISP należy również uwzględnić m.in. takie elementy jak: wspólna baza wiedzy o oferowanych usługach dla całego klastra VISP czy to, że podmiot może być jednocześnie partnerem w kliku klastrach VISP. 5.2 Kryteria techniczne Przed dokonaniem oceny standardów określono kryteria tej oceny charakteryzujące poszczególne standardy. Zdefiniowano następujące kryteria wspólne dla orkiestracji i choreografii [VISP_D21]:

7 możliwość zdefiniowania mechanizmów kontroli przepływu pracy/ monitorowanie przepływu komunikatów przepływ sterowania może być zdefiniowany i możliwe jest monitorowanie wymiany informacji pomiędzy uczestnikami, w tym możliwa jest: specyfikacja elementów kontroli (pętle, decyzje itp.) typowe, znane z języków programowania mechanizmy sterowania są dostępne, specyfikacja sekwencyjnych przepływów sekwencyjny przepływ czynności może być zdefiniowany, specyfikacja podstruktur, takich jak moduły, podprocesy możliwość zdefiniowania modułów możliwych do ponownego wykorzystania, podprocesy standard pozwala na zdefiniowanie podprocesów, możliwość zdefiniowania złożonych struktur przepływu złożone struktury danych oraz wzorce przepływu pracy mogą zostać zdefiniowane, możliwość zdefiniowania przepływu danych przepływ danych pomiędzy uczestnikami procesu może zostać zdefiniowany, kompatybilność ze standardem WSDL i BPMN standard jest kompatybilny ze standardem WSDL, możliwość obsługi błędów i kompensacji zachowanie procesu w przypadku błędnych sytuacji może być określone, specyfikacja wiązań możliwy jest dostęp do protokołów na niższych warstwach, możliwość definicji transakcji transakcyjna komunikacja może być zdefiniowana, możliwość określenia ról i interakcji z uczestnikami procesu oprócz określenia dostępu do usług standard umożliwia definiowanie interakcji z uczestnikami procesu, Wykonywalność specyfikacja jest wykonywalna, rozszerzalność specyfikacja pozwala na dodawanie nowych, niestandardowych elementów. Jako kryteria charakterystyczne dla choreografii zdefiniowano: możliwość określenia przepływów typu end-to-end możliwość definicji procesów, w których udział bierze więcej niż 2 uczestników, możliwość modelowania opartego na zdarzeniach w języku możliwe jest modelowanie wg schematu w przypadku zdarzenia wykonaj czynność, łatwość nauki czas jaki jest wymagany do nauki sprawnego posługiwania się standardem. Specyficznymi kryteriami dla orkiestracji były: niezależność od platformy sprzętowej Standard nie jest przeznaczony dla żadnej platformy sprzętowej lub programistycznej, możliwość zdefiniowania jakości usługi czynnościom procesom mogą być przypisane priorytety. 5.3 Kryteria rynkowe Oprócz względów technicznych o ocenie przydatności danego standardu do budowy systemu decydowały także względy rynkowe. Kryteriami były tutaj [VISP_D21]: dostępność stabilnej wersji specyfikacji wersja specyfikacji jest zaakceptowana przez organizację standaryzującą, dostępność otwartych lub komercyjnych narzędzi stworzono narzędzia wykorzystujące specyfikację, czy specyfikacja została zastąpiona standard został zastąpiony przez inny, czy specyfikacja jest przestarzała specyfikacja prawdopodobnie zostanie zastąpiona przez nowszą wersję lub inny standard, otwartość standard jest dostępny i może być używany za darmo, doświadczenie wewnątrz konsorcjum członkowie konsorcjum VISP znają i używają ten standard.

8 6 Rezultaty analizy standardów workflow Wyniki oceny standardów zostały przedstawione poniżej w postaci tabel. Dla każdego z kryteriów określono, czy poszczególne standardy spełniają to kryterium. Dla określenia zgodności z kryterium użyto następujących symboli: + standard spełnia kryterium, - standard nie spełnia kryterium, 0 standard spełnia kryterium częściowo, na kryterium nie dotyczy standardu. Każda z tabel została krótko skomentowana. W każdym z tych komentarzy zwrócono uwagę głównie na problemy związane z przedstawianymi standardami. 6.1 Aspekty techniczne W ramach prac przeanalizowało aspekty techniczne dotyczące standardów dotyczących choreografii i orkiestracji procesów biznesowych Choreografia Wyniki analizy aspektów technicznych dotyczących choreografii przedstawia Tab. 1. Tab. 1 Wyniki oceny standardów dotyczących choreografii Kryterium Możliwość zdefiniowania mechanizmów kontroli przepływu pracy/ monitorowanie przepływu komunikatów Możliwość określenia przepływów typu endto-end BPMN UML 2.0 UMM WSCL WSCI WS-CDL ebxml BPSS Możliwość zdefiniowania złożonych struktur Możliwość zdefiniowania przepływu danych Kompatybilność ze standardem WSDL na na na (2.0) 0 Kompatybilność ze standardem BPMN na na na Możliwość obsługi błędów/kompensacji/transakcji Specyfikacja wiązań Wykonywalność Rozszerzalność Łatwość nauki Do danych przedstawionych w powyższej tabeli można dodać, że standard UMM uważany jest za język bardzo skomplikowany, a jego wykorzystywanie wymaga dużej wiedzy i doświadczenia. Przeciwko standardom WSCL, WSCI, WS-CDL, ebxml BPSS przemawiają głównie aspekty rynkowe, omówione w rozdziale

9 6.1.2 Orkiestracja Wyniki analizy aspektów technicznych dotyczących choreografii przedstawia Tab. 2. Tab. 2 Wyniki oceny standardów dotyczących orkiestracji Kryterium BPEL4WS 1.1 WSBPEL 2.0 XPDL 1.0 XPDL 2.0 WSFL BPELJ PD4J jpdl JBI CPPA WWF Specyfikacja elementów kontroli przepływu (pętle, warunki) na 0 + Podprocesy na - - Możliwość zdefiniowania złożonych struktur Możliwość zdefiniowania przepływu danych Kompatybilność ze standardem BPMN na na Specyfikacja wiązań Możliwość obsługi błędów i kompensacji Możliwość definicji transakcji Możliwość określenia ról i interakcji z uczestnikami procesu na + + Wykonywalność na + - Rozszerzalność Niezależność od platformy sprzętowej Możliwość zdefiniowania jakości usługi na + - Najbardziej obiecującymi z punktu widzenia zastosowania do budowy platformy VISP są standardy BPEL i XPDL. Obydwa standardy nie są pozbawione jednak wad. Głównie dotyczą one relacji ze standardami modelowania choreografii i modelowania graficznego orkiestracji. Problemy głównie dotyczą tu mapowania pomiędzy językiem BPMN, podstawowym językiem w dziedzinie choreografii, a tymi standardami. Podstawowy standard diagramów procesów to BPMN. Pełne mapowanie z tego języka możliwe jest tylko do wersji 2.0 standardu XPDL. Wersja 1.0 standardu XPDL zawiera tylko część elementów wymaganych do realizacji takiego mapowania. Problemem wersji 2.0 standardu XPDL jest za to brak dostępnych na rynku narzędzi ze względu na to, że ostateczna wersja tego standardu opublikowana została dopiero w październiku 2005 roku. Dla standardu BPEL z kolei nie opracowano sposobu mapowania BPMN dla żadnej z obecnie istniejących wersji. Ponadto nowa wersja standardu (WS-BPEL 2.0) nie jest kompatybilna z poprzednią wersją tego standardu tj. standardem BPEL4WS Kryteria rynkowe Aby stwierdzić, które standardy mogą zostać wykorzystane w trakcie dalszych prac nad systemem, przeanalizowano także kryteria rynkowe.

10 6.2.1 Choreografia Wyniki analizy kryteriów rynkowych standardów dotyczących choreografii przedstawia Tab. 3. Tab. 3 Wyniki oceny kryteriów rynkowych standardów dotyczących choreografii Kryterium BPMN Dostępność stabilnej wersji specyfikacji Dostępność otwartych lub komercyjnych narzędzi UML UMM WSCI WS-CDL ebxml BPSS WSCL / + - / - + / - + / + - / - Czy specyfikacja została zastąpiona Czy specyfikacja jest przestarzała Otwartość Doświadczenie wewnątrz konsorcjum W tej dziedzinie głównym problemem jest dojrzałość standardów oraz stopień ich komplikacji, czego skutkiem jest brak narzędzi wykorzystujących te standardy. Języki WSCI i WSCL nigdy nie osiągnęły statusu standardu dojrzałego. WS-CDL jest bardzo rozbudowanym standardem, ale nie został jeszcze ukończony, poza tym istnieje niewiele narzędzi umożliwiających posługiwanie się standardem WS-CDL. Standard BPSS należy do rodziny standardów ebxml i może być używany łącznie z innymi standardami w ramach ebxml. Niestety, pozycja rynkowa standardu ebxml w ostatnich latach jest coraz słabsza i jest to jeden z powodów, dla którego budowa platformy VISP opartej na tym standardzie jest ryzykowna. Kryteria rynkowe eliminują także standard UMM. Standard ten jest mało rozpowszechniony, istnieje niewiele narzędzi wspierających i trudno znaleźć ekspertów znających ten standard Orkiestracja Wyniki analizy kryteriów rynkowych.standardów orkiestracyjnych przedstawia Tab. 4. Tab. 4 Wyniki oceny aspektów rynkowych standardów dotyczących orkiestracji Kryterium BPEL4WS 1.1 WSBPEL 2.0 XPDL 1.0 XPDL 2.0 WSFL BPELJ PD4J jpdl JBI CPPA WWF Dostępność stabilnej wersji specyfikacji Dostępność otwartych lub komercyjnych narzędzi /+ -/- +/+ -/0 -/+ +/+ -/- +/- +/+ +/+ -/+ Czy specyfikacja została zastąpiona Czy specyfikacja jest przestarzała Otwartość Doświadczenie wewnątrz konsorcjum

11 Najbardziej obiecującym z tej grupy standardów (poza BPEL oraz XPDL) jest standard CPPA. Jednak podobnie jak w przypadku standardu BPSS problemem w tym przypadku był jego związek z innymi językami z rodziny ebxml i coraz słabsza ich pozycja na rynku. 6.3 Przyjęta struktura standardów na potrzeby platformy programowej VISP Wynikiem przeprowadzonej analizy jest zestaw standardów rekomendowanych do wykorzystania w trakcie dalszych prac w ramach projektu VISP. Standardy te wraz z dziedzinami standaryzacji, których dotyczą, przedstawia Rysunek 6. W obszarach ściśle związanych z systemami workflow, czyli choreografii i orkiestracji, wybrano odpowiednio standardy BPMN i UML oraz XPDL i BPEL. Oprócz tych standardów zarekomendowano też języki ze zbliżonych dziedzin. Ponieważ zdecydowano, że system oparty będzie na web services, oczywistymi wyborami były język WSDL jako język komunikacji z usługami internetowymi, SOAP i ASAP jako protokoły komunikacji na niższych warstwach. W przypadku ewentualnych koniecznych automatycznych tłumaczeń pomiędzy językami zarekomendowano BPDM jako język pośredni oraz metodykę MDA. Standardy i repozytoria przedstawione na najniższej warstwie zostały przyjęte jako potencjalne źródła gotowych procesów już dostępnych w ustandaryzowanej formie. Modelling methodology Standardized mappings between standards BPDM/ MDA BPMN WSBPEL UML activities XPDL Choreography Orchestration Deployment, administration, monitoring WSDL Service ASAP Modelling notation Uniform notation for VISP entities SOAP ASAP Communication protocols (Wf-XML) XML UBL (OAGIS interfaces) (RosettaNet Interfaces) Information Rysunek 6 Rekomendowany zestaw standardów do budowy platformy VISP [VISP_D21] Poza wyborem zestawu standardów przedstawionym na powyższym rysunku, koniecznym okazało się opracowanie sposobu realizacji opisów workflow przy ich wykorzystaniu. Przykładowy sposób wykorzystania rekomendowanego zestawu standardów do tworzenia workflow pokazuje Rysunek 7. Przedstawiono na nim ścieżkę prowadzącą od nieformalnego opisu procesu stworzonego przez Inżyniera Produktu do wykonywalnych plików z zapisem procesu.

12 Clarification of Details Clarification of Details Clarification of Details Product Engineer Process Architect Mapping Expert Orchestration Expert uses creates uses creates generate uses creates creates Informal Description of the required workflow Initial BPMN choreography Refined BPMN choreography BPEL4WS workflow skeleton Complete, executable BPEL4WS workflow Rysunek 7 Sposób wykorzystania standardów workflow [VISP_D32] Nieformalny opis procesu wykorzystywany jest przez Architekta Procesów do stworzenia wstępnego diagramu choreografii w języku BPMN. Diagram ten jest następnie uzupełniany przez Eksperta Mapowania o informacje niezbędne do tłumaczenia diagramu na język orkiestracyjny. Następnie, na podstawie uzupełnionego diagramu BPMN, generowane są szkielety plików w języku BPEL. Każdy z tych szkieletów staje się bazą, na podstawie której Ekspert Orkiestracji tworzy kompletny, wykonywalny plik BPEL. 7 Podsumowanie Zagadnieniami związanymi z systemami workflow zajmuje się wiele organizacji na całym świecie. Nie istnieje jeden powszechnie przyjęty i dojrzały standard realizacji workflow. Od kilku lat obserwuje się tendencję zmierzającą do łączenia poszczególnych organizacji oraz wspieranych przez nie standardów w celu wypracowania dla danego rozwiązania silniejszej pozycji na rynku. Proces konsolidacji cały czas jest w toku i promowane standardy oraz organizacje zajmujące się tymi standardami cały czas ewoluują. Pierwsza fala tego rodzaju konsolidacji miała miejsce kilka lat temu kiedy technologie firmowe zostały łączone w rozwiązania, które następnie przedstawiono jako kandydata do standaryzacji. Przykładem tego rodzaju konsolidacji było połączenie rozwiązań XSFL oraz XLANG promowanych przez firmy IBM i Microsoft. Druga fala konsolidacji rozpoczęła się niedawno i dotyczy łączenia prac się organizacji standaryzacyjnych związanych przepływem pracy. Przykładem takiej konsolidacji może być połączenie w 2005 roku prac organizacji BPMI i OMG związanych z procesami biznesowymi i przepływem pracy. Najbardziej obiecujący jest język BPMN jako język modelowania dla analityków biznesowych i UML jako język modelowania dla projektantów technicznych. Oba podejścia umożliwiają specyfikację choreografii pomiędzy wieloma partnerami i procesami biznesowymi. Poza wielością dostępnych standardów workflow dodatkowym problemem związanym ze standardami workflow jest ich wielowarstwowość. W praktycznych zastosowaniach konieczne jest określenie zestawu standardów odpowiedzialnych za różne funkcje realizacji workflow od modelowania choreografii procesów przez wykonywalne definicje workflow do standardów wspierających operacje administracyjne i przesyłania komunikatów. Elementem jaki należy wziąć pod uwagę przy tworzeniu rozwiązań workflow jest dostępność narzędzi wspierających tworzenie workflow, dojrzałość i stabilność standardu oraz aktualna pozycja na rynku. Uwzględnienie tych aspektów jest równie ważne jak stopień spełnienia wymagań funkcjonalnych, gdyż zwiększa szanse na stworzenie stabilnego systemu i ułatwia jego późniejsze

13 utrzymanie i rozbudowę. Przy wyborze konkretnych standardów należy też zwrócić uwagę na kompatybilność i współdziałanie różnych standardów na różnych warstwach tworzenia workflow, tak aby nakład pracy prowadzącej od stworzenia biznesowego opisu procesu do jego wykonywalnej wersji był jak najmniejszy. Literatura 1. [WfMC_Glos: 1999] Workflow Management Coalition, Terminology & Glossary, Document Number WFMC-TC-1011, Issue 3.0, February 1999, dostępny pod adresem 2. [VISP_AnnexI] Description of work, Annex I. 3. [VISP_D11] D1.1 VISP Business Models Analysis and Requirements, editors: Philippe Chaudron, Eric Mannie-Corbisier. 4. [VISP_D21] D2.1 VISP Workflow Technologies Functional Analysis and Comparison, editor: Jane Hall. 5. [VISP_D32] D3.2 Workflow Modelling and Specification Platform Functional Architecture, editor: Jane Hall. 6. [BPEL4WS11] T. Andrews et al., Business Process Execution Language for Web Services, Version 1.1, 5 May 2003, dostępny pod adresem ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf. 7. [BPELJ] BEA and IBM, BPELJ: BPEL for Java, March 2004, dostępny pod adresem ftp://www6.software.ibm.com/software/developer/library/ws-bpelj.pdf. 8. [BPEL_oasis] D. König, Web Services Business Process Execution Language (WS- BPEL), 2005, dostępny pod adresem 9. [BPML] Business Process Management Initiative, Business Process Modeling Language, November [BPMN] Business Process Management Initiative, Business Process Modelling Notation (BPMN). Version 1.0, May 2004, dostępny pod adresem [BTP_2004] OASIS, Business Transaction Protocol, version 1.1, Working Draft 05, November 2004, dostępny pod adresem [SOAP12] W3C, SOAP Version 1.2, June 2003, dostępny pod adresem [UML20_DI] OMG, Unified Modeling Language: Diagram Interchange, version 2.0, OMG Document ptc/ , June 2005, dostępny pod adresem UN/CEFACT, UN/CEFACT s Modelling Methodology, Draft, CEFACT/TMWG/N090R10, November 2001, dostępny pod adresem [WSDL20] W3C, Web Services Description, Language (WSDL) Version 2.0, January 2006, dostępny pod adresem [WSFL] IBM, Web Services Flow Language (WSFL 1.0), May 2001, dostępny pod adresem [XLANG] Microsoft, XLANG, Web Services for Business Process Design, 2001, dostępny pod adresem [XPDL1.0] Workflow Management Coalition, XML Process Definition Language (XPDL), Document Number WFMC-TC-1025, Version 1.0, October 2002, dostępny pod adresem [XPDL2.0] Workflow Management Coalition, Workflow Management Coalition Workflow Standard, Document Number WFMC-TC-1025, Version 2.00, October 2005, dostępny pod adresem