Architektura usługowa (Service Oriented Architecture) [1] jest obecnie wiodącym kierunkiem rozwoju złożonych i rozproszonych systemów informacyjnych działających w środowisku biznesowym. SOA jest filozofią tworzenia, komunikacji i dzielenia funkcjonalności pomiędzy rozproszonymi systemami lub podsystemami. Podstawowym pojęciem związanym z SOA jest usługa (service) - komponent cechujący się wyspecyfikowanym zachowaniem, który można użyć, aby wykorzystać to zachowanie do własnych celów. Zachowanie usługi powinno być niezależne od implementacji, usługa powinna umożliwiać reużywalność, powinna być bezstanowa i autonomiczna. Ponadto SOA postuluje aby można było łatwo odszukiwać usługi kierując się pożądanym zachowaniem i aby wyszukane w środowisku informatycznym usługi można było łatwo komponować do postaci bardziej złożonych usług-agregatów.

Powyższa abstrakcyjna definicja usługi może być uosobiona w postaci dobrze rozwiniętej technologii usług sieciowych - Web Services. Jest to sposób udostępniania na zewnątrz funkcjonalności systemu informatycznego pod postacią wywołań i odpowiedzi (np. przez protokół HTTP) zakodowanych w języku XML. Web Service jest opisany przez dokument XML-owy WSDL (Web Service Description Language), który opisuje metody udostępniane przez Web Service, typy danych wymieniane w wywołaniach i odpowiedziach a wreszcie podstawowe protokoły komunikacyjne używane w Web Service. W dalszej części artykułu opisano w jaki sposób środowisko jPALIO umożliwia wywoływanie i udostępnianie funkcjonalności przy użyciu Web Services.

Kolejnym istotnym założeniem SOA jest umożliwienie łatwego komponowania usług do postaci bardziej złożonych. Najbardziej rozpowszechnionym narzędziem do komponowania usług opartych o Web Service jest język stworzony pod patronatem firm IBM, Microsoft i BEA - Web Services Business Process Execution Language (WS-BPEL lub BPEL). BPEL jest językiem opartym o XML. Przy użyciu instrukcji strukturalnych, sterujących i wywołujących Web Service zapewnia komponowanie usług sieciowych w postaci procesu biznesowego. Do komponowania usług środowisko jPALIO proponuje własne rozwiązanie - HETMAN, które umożliwa wyrażenie procesu biznesowego w postaci skończonej maszyny stanów. HETMAN może być wykorzystany zarówno do tworzenia usługi i udostępnienie jej w postaci Web Service jak i implementacji procesu wraz z interfacem użytkownika.

Rys. 1 Realizacja elementów architektury SOA na platformie jPALIO.

Technologie używane do wsparcia SOA mogą być zorganizowane w swego rodzaju stos. Na najniższym poziomie znajduje się warstwa transportu i formatowania, która może być implementowana przy użyciu protokołół HTTP, HTTPS, SMTP oraz przez implementację kodowania i dekodowania XML. Wszystkie te elementy są dostępne w środowisku jPALIO.
Na kolejnym poziomie znajduje się warstwa komunikacji, do której jest przyporządkowany protokół Simple Object Access Protokol (SOAP), oraz pozostałe mechanizmy WS-*1 (WSSecurity - bezpieczeństwo dostępu do Web Service, WSReliableMessaging - przekazywanie wiadomości, itp.). jPALIO zapewnia obsługę SOAP, nie ma natomiast wsparcia pozostałych elementów warstwy komunikacji.
Na trzecim poziomie znajdują się mechanizmy opisu i rozgłaszania Web Services. jPALIO zapewnia udostępnianie i korzystanie z plików opisu Web Services Web Services Description Language WSDL [7]. Szczegóły wykorzystania WSDL znajdują się w kolejnym rozdziale.  Środowisko jPALIO nie posiada natomiast żadnego wsparcia dla rozgłaszania usług przy użyciu protokołu Universal Description Discovery and Integration  UDDI.
Na kolejnym poziomie stosu technologii są elementy związane z koordynacją, kontekstem i transakcjami opartymi o Web Services. Wykorzystane są tutaj standardy WSCoordination, WSAtomicTransactions, WSBusinessActivitiy itp. jPALIO nie zapewnia żadnego wsparcia w tej warstwie.
Wreszcie na szczycie stosu są technologie komponowania usług w bardziej złożone elementy. Najbardziej rozpowszechnione są tutaj języki Business Process Execution Language BPEL oraz Web Services Choreography Description Language WSCDL. jPALIO proponuje tutaj własne rozwiązanie - język opisu procesów HETMAN, który jest opisany szerzej w dalszej części artykułu.
Na rysunku 2 przedstawiono schemat stosu technologii wspierających architekturę usługową oraz w jaki sposób środowisko jPALIO wspiera poszczególne elementy.

Rys. 2 Stos technologii wspierających SOA w realizacji jPALIO.

jPALIO zostało zintegrowane z Web Services przy użyciu biblioteki Apache CXF [4]. Integracja jest realizowana poprzez dodatkowy serwlet dołączony do serwera jPALIO. Serwlet ten jest odpowiedzialny za stworzenie usług instancji na podstawie ich konfiguracji.
Dla każdej instancji jPALIO jest możliwość skonfigurowania dowolnej liczby niezależnych usług. Usługi są definiowane w pliku konfiguracyjnym instancji jPALIO. Najprostsza konfiguracja usługi sprowadza się do podania nazwy klasy implementującej usługę. Klasa może być klasą Groovy umieszczoną w obiekcie jPALIO. Klasa ta musi zawierać odpowiednie adnotacje opisujące usługę. Za pomocą adnotacji określamy między innymi parametry usługi oraz metody jakie mają zostać udostępnione przez usługę. Na podstawie tej klasy tworzony jest automatycznie deskryptor usługi (WSDL).
Konfiguracja usługi może zostać poszerzona o parametry związane z różnymi aspektami bezpieczeństwa. Między innymi są to szyfrowanie, podpisywanie całej wiadomości lub tylko wybranej jej części. Istnieje możliwość skonfigurowania różnych sposobów autoryzacji wywołań usługi. Najprostszym sposobem jest autoryzacja typu login/hasło. Ten sposób autoryzacji został maksymalnie zintegrowany z mechanizmami bezpieczeństwa jPALIO. Użytkownikami usługi mogą być wszyscy użytkownicy systemu jPALIO przy czym można ograniczyć dostęp do usługi poprzez przypisanie usłudze wymaganego przywileju. W takim przypadku tylko użytkownicy posiadający rolę zawierającą wymagany przywilej będą mogli wywoływać usługę przy użyciu swojego loginu i hasła.
Istotną cechą implementacji Web Services w środowisku jPalio jest to, że jedynie dodanie nowej usługi do instancji lub zmiana konfiguracji istniejącej usługi wymaga restartu serwera jPALIO. W przypadku wprowadzania zmian w klasie realizującej usługę, usługa ta jest automatycznie przeładowywana.

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.