OSGi: Modularność bez restartów w aplikacjach JEE

Ci, którzy śledzili rozwój technologii związanych z Javą 7 z pewnością spostrzegli wszechobecność pojęcia modularności. To zagadnienie przewija się przez kilka Java Specification Requests (JSR), takich jak (aktualnie zawieszony) JSR-277, oparty na technologii OSGi JSR-291, system modułów dla Javy, który jest częścią samego języka (JSR-294) czy też projekt Jigsaw, będący Sun-owską inicjatywą w kierunku modularyzacji maszyny wirtualnej. Chociaż większość ze wspomnianych JSR-ów odkrywa nowe obszary, sam standard OSGi ugruntował już na dobre swoją pozycję w wielu licznych zastosowaniach. Stał on się standardem około roku 1999 w środowiskach systemów wbudowanych. Biorąc pod uwagę  ograniczoną pojemność takich systemów niemożliwym było uruchomienie nowej maszyny wirtualnej dla każdej aplikacji, skutkiem czego aplikacje musiały w łatwy i bezpieczny sposób współdzielić jedno środowisko uruchomieniowe. Java sama w sobie nie dostarcza wystarczającego wsparcia w tym zakresie. Z wielu powodów: liniowy classpath nie pozwala na pracę z wieloma wersjami tej samej biblioteki, nie istnieje skuteczna metoda ukrycia szczegółów implementacyjnych przed innymi aplikacjami oraz zadeklarowania zależności explicite. Ponadto, brakuje jednego standardowego mechanizmu, który zapewniałby aplikacjom jeden jasny cykl życia; nie ma także mechanizmu publikacji i odkrywania usług oferowanych przez aplikacje działające na tej samej maszynie wirtualnej. Aby umożliwić aplikacjom od różnych dostawców efektywną i wydajną pracę w obrębie jednej maszyny wirtualnej bez konieczności restartu po każdej instalacji czy aktualizacji, mówimy o wymaganiach importu.

Aby sprostać tym wymaganiom, utworzony został standard OSGi. Jest on zarządzany przez wiele organizacji tworzących konsorcjum Gosi. Istnieją liczne implementacje standardu, z których obecna wersja jest nosi numer 4.1: wersja 4.2 jest w trakcie ciągłego rozwoju i ma być opublikowana jeszcze w tym roku. Do dobrze znanych open source’owych implementacji można zaliczyć Apache Felix i Equinox. Ten ostatni jest znany zwłaszcza jako silnik, na którym zbudowany został pluginowy model popularnego Javowego IDE – Eclipse’a.

Zastosowania OSGi

Przez lata zastosowania OSGi były ograniczone do systemów wbudowanych (czyli np. tych, które firma BMW montuje w swoich samochodach) i pewnych aplikacji specjalnego przeznaczenia. Jakkolwiek w ciągu ostatnich kilku lat standard ten wzbudzał coraz większe zainteresowanie w społeczności J2EE. Wiele serwerów aplikacyjnych już używa OSGi na swoje wewnętrzne potrzeby. Poza nimi standard wykorzystywany jest przez liczne frameworki i środowiska uruchomieniowe. Pozwalają one rzeszy developerów na wygodne korzystanie z tej technologii. Istnieje również pewna liczba rozwiązań pomagających zajmować się skomplikowanymi relacjami, które obecne są w pełni dynamicznym środowisku takim jak OSGi. Przykładowo, każda usługa może być uruchomiona w dowolnym momencie, ale może także być w dowolnej chwili zatrzymana. Aplikacja wspierająca standard OSGi musi potrafić obsłużyć takie sytuacje. Na pierwszy rzut oka, wydaje się to jedynie zwiększać złożoność systemu szczególnie, jeśli odniesiemy się do tradycyjnego modelu aplikacji Enterprise Java. Po głębszej analizie okazuje się, że obsłużenie takich sytuacji jest warunkiem koniecznym budowy każdej niezawodnej aplikacji, która kontynuuje swoją pracę, także wtedy, gdy inne aplikacje bądź usługi są tymczasowo niedostępne (gdyż na przykład instalowana jest nowa wersja).

Projektem, który odgrywa tutaj ważną rolę jest Spring Dynamic Modules (Spring-DM), open source'owy szkielet aplikacji integrujący model framework'u Spring ze standardem OSGi. Efektem jest rozwiązanie, w którym OSGi otrzymuje w pełni dojrzały model komponentowy. Pionierska praca nad Spring-DM, wykonana przez ludzi z zespołu SpringSource, a wcześniej z firm BEA i Oracle, jest obecnie przedmiotem standardyzacji jako dokument RFC-124 i docelowo będzie częścią OSGi 4.2. Spring-DM 2 będzie z kolei wzorcową implementacją tego standardu.

OSGi po stronie serwera

Wszystko powyższe oznacza, iż przed standardem OSGi otwarł się zupełnie nowy obszar zastosowań - strona serwera. Możliwości oferowane przez OSGi takie jak łatwa modularyzacja aplikacji, dynamiczność, a także zorientowanie na usługi stanowią znakomitą odpowiedź na  życzenia i wymagania stawiane przed dzisiejszym serwerami aplikacyjnymi. Na przykład, zbyt często obecnie nie można pozwolić sobie na wyłączenie całej aplikacji tylko dlatego, iż jedna jej część wymaga upgrade'u, nie mówiąc już o restartowaniu serwera, na którym aplikacja jest zainstalowana. Ponadto, coraz więcej problemów pojawia się w sytuacjach, w których aplikacja wymaga wielu wersji zewnętrznych bibliotek. Wtedy jedynym rozwiązaniem jest spakować całą aplikację wraz z wszystkimi zależnościami (których rozmiar często przewyższa rozmiar samej aplikacji) do jednego dużego archiwum i mieć nadzieję, iż zależności te będą wzajemnie kompatybilne. Jednakże inna wersja aplikacji znajdująca się wyżej w hierarchii classloaderów nie może mieć dostępu do tych zależności bez specjalnych zabiegów w trybach delegacji classloadera.

W przypadku współdzielenia standardowej funkcjonalności pomiędzy aplikacjami praktycznie jedyną realną opcją jest wykorzystanie rozwiązań zdalnych, albowiem brakuje konstrukcji pozwalającej współdzielić między aplikacjami lokalnie oferowane dynamiczne usługi. Zespół Enterprise OSGi Expert Group pracuje obecnie nad zbieraniem wymagań, które dotyczą zastosowania OSGi w środowisku biznesowym oraz nad ustandaryzowaniem niektórych rozwiązań w tej dziedzinie.

Aktualne zastosowania standardu OSGi w serwerach aplikacyjnych ograniczają się wyłącznie do ich środka. Produkty takie jak WebSphere Application Server czy też ostatnia wersja Sun-owskiego Glassfisha w dużym stopniu wykorzystują OSGi wewnętrznie, jednakże w żadnym przypadku nie obejmuje to twórców aplikacji. Muszą oni budować swoje systemy w tradycyjny sposób określony technologią J2E, w której ogromne monolityczne aplikacje osadzane na serwerze bez większej interaktywności czy modularności. Rynek jednak się zmienia. Rozwijanych jest wiele produktów, których głównym celem jest udostępnienie OSGi po stronie serwera, np. Infiniflow tworzony przez firmę Paremus. Produkty te pozwalają ich użytkownikom rozwijać aplikacje biznesowe, które w pełni wykorzystują funkcjonalności oferowane przez standard OSGi. Wymagają one jednak sposobu pracy innego niż ten, do którego przywykła większość twórców aplikacji. Jeden z powodów, dla których większość serwerów aplikacyjnych nie udostępnia programistom standardu OSGi jest obok oczywistych benefitów płynących z jego zastosowania, pewna liczba właściwych tylko dla OSGi problemów. Większość z tych problemów jest spowodowana faktem, iż wiele istniejących bibliotek i frameworków zawiera kod niekompatybilny z modelem OSGi wymuszającym bardzo ścisłe reguły widoczności. Na przykład, domyślnie biblioteka "nie widzi" kodu aplikacji, która ją wykorzystuje, podczas gdy działanie wielu nowoczesnych bibliotek jest oparte właśnie na takim założeniu. Znaczy to, że przykładowo biblioteki nie mogą dynamicznie generować kodu opartego na kodzie aplikacji: w modelu OSGi jest to niemożliwe bez dodatkowej konfiguracji, ponieważ biblioteki te nie deklarują wyraźnie zależności od kodu aplikacji.

The SpringSource dm Server

Innym rozwiązaniem w tym obszarze jest The SpringSource dm Server. Jest to serwer aplikacyjny, który jest oparty na Apache Tomcat, Equinox oraz Spring-DM. Celem jego jest umożliwienie programistom wykorzystania OSGi w ich aplikacjach webowych i korporacyjnych, jednocześnie pozwalając na użycie istniejących bibliotek i frameworków takich jak Spring czy Hibernate. Wielką różnicą w porównaniu z innymi serwerami aplikacji jest to, iż OSGi nie jest skryte gdzieś "pod maską", ale dostępne dla twórców aplikacji, którzy mają możliwość samodzielnego używania i uruchamiania modułów OSGi (nazywanych także bundle'ami bądź pakunkami), co z kolei pozwala na zmodularyzowanie wielkich aplikacji, które komunikują się ze sobą poprzez architekturę zorientowaną na usługi.

Nie jest to SOA tracyjnie pojęta, pojedyncze moduły wciąż działają na tym samym serwerze, ale ich zależności zostały zadeklarowane explicite oraz usługi są w znacznie mniejszym stopniu od siebie zależne. Ma to wiele zalet. Jedna z nich to większy znacznie większy potencjał  reużywalności - wiele aplikacji może używać ten sam kod, a nawet korzystać z tych samych usług. Przy wielu aplikacjach działających na tym samym serwerze aplikacyjnym oznacza to mniejsze zużycie pamięci, ponieważ biblioteki muszą być załadowane tylko raz razem ze startem serwera, a nie za każdym razem, gdy startuje aplikacja. Serwer sam w sobie jest również zbudowany z modułów, tak więc nieużywane funkcjonalności mogą być łatwo wyłączone. Oznacza to szybszy czas startu i mniejsze wykorzystanie zasobów. Na przykład serwer Tomcat może być całkowicie wyłączony, jeśli nie ma aplikacji, które potrzebują interfejsu webowego.

Aby móc skorzystać z tych wszystkich zalet, wymagane jest, aby wszystkie potrzebne biblioteki były dostępne jako pakunki OSGi z odpowiednimi metadanymi. Dla wielu popularnych open source'owych bibliotek nie stanowi to problemu. Aby sprostać wymaganiom wobec zmieniających się wersji pakunków zewnętrznych bibliotek, SpringSource zainicjował osobny projekt: Enterprise Bundle Repository, dostępny pod adresem http://www.springsource.com/repository. Na stronie tej można znaleźć setki bibliotek Javowych w formie pakunków OSGi. Można je ściągnąć zupełnie za darmo i używać z dowolną implementacją standardu, nie tylko z dm Serverem.

Istotną funkcjonalnością dodawaną przez dm Server do czystego standardu OSGi jest koncepcja aplikacji składającej się z wielu pakunków, tzw. Platform Archive czy plik PAR. Poprzez spakowanie pakunków jako aplikację, otrzymuje się jedną zarządzalną jednostkę, dla której podstawowe czynności administracyjne takie jak deployment czy monitoring stają się łatwiejsze niż w przypadku pojedynczych pakunków. Pomysł ten pozwala także na pewien rodzaj 'scopingu', w którym typy i usługi wewnątrz jednej aplikacji nie są widoczne dla innych aplikacji. Jedną z zalet tak sformułowanej enkapsulacji jest to, iż różne wersje jednej aplikacji mogą działać na tym samym serwerze bez powodowania konfliktów. Kod, który ma być współdzielony jest oczywiście nadal dostępny, ale nie jest spakowany jako część aplikacji.

Co więcej, dm Server dostarcza rozwiązań do pracy z bibliotekami, które używają technik nie działających wewnątrz standardowego środowiska OSGi, takich jak dynamiczna generacja kodu lub tzw. "wplatanie" kodu, a które to techniki wykorzystywane są przez wiele implementacji JPA. Sewer ten dostarcza także całe zaplecze dla aplikacji webowych, dla których OSGi posiadał jedynie ograniczone wsparcie.

Konkluzje

Jest jasnym, iż OSGi jest wschodzącą gwiazdą w świecie Enterprise Java. Zalety pracy w prawdziwie zmodularyzowanym środowisku przyciąga wielu programistów. Wiele serwerów aplikacji już używa OSGi a wraz z innowacyjnymi produktami takimi jak Paremus Infiniflow czy też SpringSource dm Server użycie standardu OSGi staje się łatwe także dla twórców aplikacji. Potrwa jeszcze trochę zanim OSGi stanie się mainstreamową technologią po stronie serwera, ale bezsprzecznie OSGi w zastosowaniach korporacyjnych to przedsięwzięcie, o którym będzie głośno w nadchodzących latach.

Wydrukuj