Komponowanie usług przy użyciu silnika HETMAN

HETMAN jest modułem jPALIO wspomagającym tworzenie oraz implementację wszelkiego rodzaju procesów sprzedaży, obiegu dokumentów, wizardów (tzw workflow). Został on zaprojektowany tak aby, przy użyciu standardowych komponentów jPALIO, można było w prosty sposób stworzyć definicję procesu oraz jego implementację.
Dla każdej instancji jPALIO istnieje możliwość zdefiniowania dowolnej liczby procesów. Definicja procesu jest tworzona w formacie XML i przechowywana w obiekcie jPALIO. W momencie pierwszego odwołania się do danego procesu, definicja wczytywana jest do pamięci. W ramach definiowania procesu tworzone są stany procesu i przejścia pomiędzy tymi stanami. Dodatkowo można zdefiniować uprawnienia dla danych przejść oraz parametry stanów i przejść.
Każdy proces musi mieć zdefiniowaną klasę, która pełni rolę menadżera procesu. Menadżer procesu musi implementować dwie podstawowe funkcjonalności: odczytanie stanu oraz zmianę stanu. Dzięki takiemu rozwiązaniu HETMAN nie narzuca architektury systemu. Programista decyduje w jaki sposób przechowywany jest stan procesowanej instancji/obiektu. Najczęstszym rozwiązaniem jest odczytywanie i zapisywanie stanu w bazie danych, aczkolwiek nic nie stoi na przeszkodzie aby odczytywać i zapisywać stan np. w pamięci lub w pliku.
Implementacja procesu (przejść, warunków) przy użyciu HETMANa odbywa się w myśl zasady CoC (Convention Over Configuration). Dzięki narzuconej konwencji, znacznie przyśpieszamy implementację a jednocześnie unikamy bardzo skomplikowanej konfiguracji oraz zapewniamy czytelność i łatwość utrzymania kodu. Konwencja sprowadza się do odpowiedniego nadawania kodów obiektom jPALIO odpowiadającym za implementację procesu. Obiekty te wywoływane są w odpowiedniej sekwencji przez silnik HETMANa. Oczywiście jest możliwość odbiegania od konwencji, ale jest to powiązane z koniecznością dodania nowych wpisów do konfiguracji procesu.
HETMAN posiada także wsparcie dla warstwy prezentacji. W przypadku wykorzystania HETMANa przez aplikację webową wykorzystywana jest tzw. „strona widoku”. Strona ta tworzona jest przez programistę. Jej zadaniem jest prezentacja bieżącego stanu procesowanej instancji/obiektu wraz z formularzami niezbędnymi do wprowadzania danych wymaganych przez przejścia możliwe do wykonania z danego stanu. Formularze związane z poszczególnymi przejściami są tworzone w oddzielnych obiektach jPALIO i są one automatycznie dołączane do „strony widoku” przez silnik HETMANa (przy założeniu, że zalogowany użytkownik ma wystarczające uprawnienia oraz spełnione są wszystkie warunki na wykonanie danego przejścia). Błędy, które mogą wystąpić podczas wykonywania procesu, obsługiwane są poprzez tzw. „stronę błędu”. Sposób w jaki ma zostać obsłużony dany błąd jest zależny od programisty.
Istotnym faktem jest to, że dodawanie nowych procesów oraz wszelkie zmiany w definicji oraz implementacji istniejących procesów, nie wymaga restartu serwera jPALIO.
Częścią modułu HETMAN jest edytor graficzny (dostępny przez interface WWW), za pomocą którego można zapisywać model proces biznesowego. Użytkownik może zaprojektować proces w postaci stanów i tranzycji pomiędzy stanami. Edytor graficzny definiuje też role związane z tranzycjami, co wyraża podział obsługi procesu pomiędzy różnymi kompetencjami. Po  utworzeniu diagramu procesu edytor zapisuje proces w postaci XML i tworzy zrąb (stub) obiektów jPALIO do obsługi procesu zgodnie z przyjętą konwencją.  Edytor graficzny HETMAN'a jest zaprezentowany na rysunku 3.

Rys. 3 Edytor graficzny procesów HETMAN

Procesy HETMAN mogą być tworzone nie tylko w edytorze graficznym ale także na drodze konwersji z diagramów aktywności UML [5]. W ramach modułu HETMAN istnieje narzędzie, które transformuje diagram aktywności UML zapisany w formacie XMI do  postaci kodu procesu HETMANA. W planach rozwojowych jPALIO jest możliwość importowania procesów biznesowych zapisanych w języku BPEL i konwersja na zapis w języku HETMAN.
W kontraście do języka BPEL, język HETMAN'a jest oparty na modelu automatu skończonego, gdzie czynności biznesowe odpowiadają tranzycjom między stanami, a stany automatu wyrażają stany procesu biznesowego. Podczas gdy BPEL przypomina bardziej strukturalne języki programowania. Z tego względu BPEL jest łatwiejszy do użycia przez osoby z działów technicznych, dla których jest to naturalny sposób postrzegania problemów. Natomiast maszyna stanowa jest łatwiejsza do interpretacji przez pracowników postrzegających działanie firmy przez pryzmat procesów biznesowych. Z drugiej strony BPEL ma większą moc wyrażania, ponieważ można w zapisie procesu uwzględniać instrukcje warunkowe a nawet same warunki wykonania instrukcji. W języku HETMAN nie jest to możliwe - warunki przejść muszą być zapisane w postaci kodu jPALIO, który może być tworzony dopiero po wykreowaniu szkieletu procesu.
Przewagą języka BPEL nad HETMAN'em, w kontekście architektury usługowej jest to, że ma on wbudowany mechanizm do wywoływania usług Web Services. Wystarczy zaimportować plik WSDL do pliku procesu BPEL i zdefiniować partner linki (czyli połączenia do zewnętrznych usług) związane z tymi plikami.  Po tych krokach można odwoływać się do metod i typów danych zdefiniowanych w pliku WSDL wewnątrz procesu. Takiej możliwości nie posiada HETMAN i należy uwzględnić ten brak przy dalszym rozwoju języka.