Konfiguracja

Konfiguracja nie jest szczególnie skomplikowana, do uruchomienia potrzebny będzie sam JavaRebel oraz serwer aplikacji. Osobiście przetestowałem serwery aplikacjyjne JBoss 4.2.3.GA oraz Tomcat 5.5.26 deployując na nich aplikację Spring’ową.

W obu przypadkach dodajemy linię:
set JAVA_OPTS=-noverify -javaagent:javarebel.jar -Drebel.dirs= -%JAVA_OPTS%
uzupełniając “-Drebel.dirs=” o katalogi do których nasze IDE kompiluje klasy, oddzielając je przecinkami. W przypadku JBoss’a plikiem do którego dodajemy linię jest run.bat, natomiast dla Tomcat’s będzie to catalina.cmd.

Plik javarebel.jar umieszczamy w tym samym miejscu, w którym znajdował się edytowany przez nas wcześniej, czyli katalogu bin serwera.

Działanie

Teraz możemy już uruchomić serwer. Naszą aplikację deployujemy na serwerze normalnie, wrzucając w odpowiednie miejsce plik war. Aplikacja zostanie uruchomiona, a JavaRebel rozpocznie monitorowanie folderu podanego wcześniej, sprawdzając czy któraś z naszych klas nie została zmieniona. Monitorowanie zmian odbywa się na podstawie znaczników czasu w klasach. Przeładowanie klasy zachowuje wszystkie istniejące instancje.

JavaRebel pozwala nam na wykonanie szeregu operacji na naszych klasach. Możemy zarówno dodawać jak i usuwać metody, konstruktory, pola, klasy czy adnotacje. Oczywiście pozwala nam zmieniać ciała samych metod. Niestety, ograniczeniem jest brak możliwości zamiany klasy bazowej oraz dodawanie/usuwanie interfejsów. Wydaje mi się jednak, że nie są to tak częste operacje, aby mogły stanowić problem.

Spring

W ostatnim czasie pojawił się plugin do JavaRebel wspierający jego działanie ze Springiem. Wspiera on rejestrowanie nowych bean’ów, kontrolerów, zarządzanie zależnościami. Wszystkie powyższe operacje mogą być wykonywane zarówno przy użyciu konfiguracji w XML’u jak i adnotacji. Co prawda narzędzie jest udostępnione jako open source, jednak wciąż należy je traktować jako wersję beta.

Licencja

Jest chyba największą wadą tego narzędzia, nie jest ono tanie. Licencja ciągła przy zakupie poniżej dziesięciu kosztuje 249$, a licencja roczna to koszt 99$. Cena licencji spada wraz z ich ilością.

Autorzy podają, że narzędzie to jest aktualnie używane przez wszystkich developerów serwisu LinkedIn. Ponadto posiadacze brązowego pasa na www.javablackbelt.com mogą otrzymać licencję za darmo.

Wrażenia

Osobiście ten sposób wprowadzania zmian w aplikacji bardzo przypadł mi do gustu. Nie zauważyłem opóźnień związanych z przeładowywaniem klas. Zależności były zawsze na miejscu dzięki możliwości zachowania istniejących instancji bean’ów. Uważam, że jest to narzędzie warte rozważenia, szczególnie w przypadku aplikacji, których deployment zajmuje pokaźną ilość czasu. Jednak z tego co zdążyłem wyczytać na forum projektu, pojawiają się problemy z obsługą EJB i generalnie nie istnieje wsparcie dla jakichkolwiek frameworków (poza Springiem). Jednak istnieje możliwość darmowego przetestowania, czy narzędzie spełnia nasze oczekiwania.

Moim zdaniem jest to bardzo przydatne oprogramowanie przy przygotowaniu aplikacji springowych, jednak jego cena jest nieco wygórowana, biorąc pod uwagę kłopoty z EJB i brak wsparcia dla innych frameworków.

Wprowadzenie.

Na jBPM składają się:

Siłą jBPM jest właśnie jPDL który łączy pracę analityka i programisty w jednym pliku. Analityk najpierw modeluje proces (np.  sprzedaż produktu) wyszczególniając na grafie kierunkowym wszystkie istotne kroki danego procesu. Etap ten jest podobny do modelowania diagramu przepływu lub przypadków użycia znanych z UML czyli przyjazny dla analityka. Następnie programista po otrzymaniu takiego pliku zaczyna podpinać do poszczególnych węzłów grafu różne akcje i zadania (np. wywołanie zdalnego systemu, zapis do bazy danych). Użyłem słowa podpinać gdyż programista przy pomocy GPD wskazuje po prostu klasy które mają być użyte do obsługi.  Kolejną miłą właściwością jBMP jest persystencja  oparta o Hibernate co pozwala na umieszczenie tabel jBPM’a zarówno obok tabel naszej aplikacji jak i w całkowicie oddzielnej bazie danych. W bazie danych zapisywane są definicje procesów, instancje procesów oraz dane zgromadzone w zadaniach (task).

Jak to się robi.

Początek jest banalnie prosty wpisujemy  http://www.jboss.org/jbossjbpm/  pojawia nam się strona z wielkim przyciskiem DOWNLOAD  i idąc tym tropem ściągamy sobie jPDL Suite. Tak zdobytą paczkę rozpakować należy w dowolnym miejscu i przejść do katalogu “designer” z tego miejsca odpalamy anta który zainstaluje nam eclipse.  Można też po prostu ściągnąć sobie eclipse i rozpakować go do katalogu ./designer/eclipse.

Po uruchomieniu eclipse tworzymy nowy projekt JBoss jBPM/Process Project. Dajemy mu nazwę i klikamy ‘Finish’. Naszym oczom ukazuje się przykładowy projekt wraz z  jednym handlerem i JUnit testem.  Najważniejszą częścią tego przykładu jest plik procesdefinition.xml który zawiera  graf kierunkowy determinujący przebieg procesu, jest napisany w języku jPDL.

Bloki procesu (grafu) dzielą się na kilka grup. Dokładny opis wszystkich bloków był by bardzo obszerny więc przedstawię tylko podstawowe.

States służą do określenia kolejnych kroków procesu istotnych z punktu biznesowego i  wykonywanych automatycznie(bez ingerencji użytkownika) np. odpytanie o dane jakiegoś zewnętrznego systemu.

Tasks Node jest specyficznym stanem gdyż jest przeznaczony do umieszczania w nim zadań do wykonania dla człowieka. Proces przechodzi dalej w chwili zakończenia zadania przez człowieka np. następnego dnia. W czasie obsługi danego zadania w dowolnym momencie można zapisać jego aktualny stan.

Fork i Join służące do rozdzielenia procesu na kilka równolegle wykonywanych ścieżek. Istotną rzeczą jest że fork i join zawsze pracują w parach i wszystkie ścieżki wychodzące z jednego forka muszą skończyć się w jednym joinie. Proces oczekuje na bloku Join do zakończenia wszystkich ścieżek.

Transition jest to połączenie pomiędzy blokami procesu określające kierunek przejścia. Z bloku może wyjść dowolna liczba połączeń. Jeśli podczas wyjścia z bloku nie jest podana nazwa połączenia proces przechodzi po pierwszym (kolejność w xml).

Każdy blok ma możliwość podpięcia klasy obsługującej wyjątki, oraz dowolną liczbę klas obsługujących akcje, wykonywanych gdy nastąpi zdarzenie do których są przyporządkowane(np. node enter, node leave). Akcje mogą być również przyporządkowane do Transitions.

<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2" name="simple">
	<start-state name="start">
		<transition name="to_state" to="first">
			<action name="action"
				class="com.sample.action.MessageActionHandler">
				<message>Going to the first state!</message>
			</action>
		</transition>
	</start-state>
	<state name="first">
		<transition name="to_end" to="end">
			<action name="action"
				class="com.sample.action.MessageActionHandler">
				<message>About to finish!</message>
			</action>
		</transition>
	</state>
	<end-state name="end"></end-state>
</process-definition>

public class MessageActionHandler implements ActionHandler {

	String message; 

	public void execute(ExecutionContext context) throws Exception {
		context.getContextInstance().setVariable("message", message);
	}
}

Jak widać w powyższym kodzie pole message nie posiada metod get i set jego wartość jest bezpośrednio wstrzykiwana z definicji procesu. Interfejs ActionHandlera posiada tylko jedną metodę do której jako parametr przychodzi ExecutionContext zawierający definicję procesu i jego instancje(wszystkie).

W momencie wykonania kompletnej implementacji wszystkich zdarzeń oraz podpięciu interfejsu użytkownika, mieli byśmy piękną trzy etapową obsługę czegoś. Gdyby była to aplikacja wykonana tradycyjnie każda zmiana wymagała by w mniejszym lub większym stopniu dostosowania istniejących elementów. Lecz gdy mamy do czynienia z grafem możemy po postu w dowolnym miejscu dodać kolejny element. Jak widać na rysunku poniżej.

Wbrew pozorom takie rozszerzanie aplikacji zdarza się dość często szczególnie jak mamy do czynienia z procesami decyzyjnymi oraz organizacją pracy w rozwijających się przedsiębiorstwach.

Podsumowanie.

JBPM to platforma do modelowania procesów biznesowych oparta o grafowy język jPDL. Nadaje się świetnie do tworzenia systemów które mają na celu przydzielać zadania do wykonania dla poszczególnych osób w złożonym środowisku procedur i przepisów.