Coraz bardziej urzeczony OSGi - nowe artykuły na JavaLobby

Pojawiły się kolejne mini-artykuły dotyczące OSGi z serii Getting started with OSGi. Coraz bardziej urzekają mnie powody stworzenia OSGi oraz możliwości płynące z wykorzystania platformy w modularnych aplikacjach. Po kilku dniach lektury dokumentacji i przeglądania różnych serwisów internetowych dotykających tematu OSGi, pokuszę się na przybliżenie (i możliwe zainteresowanie) tą technologią.

OSGi jest platformą komponentów nazywanych pakietami OSGi (ang. OSGi bundle - tłumaczenie zapożyczone ze Słownika informatycznego angielsko-polskiego IDG.pl). Idea polega na stworzeniu platformy, w której pakiety podlegają pewnym transformacjom, w sensie rozwoju. Wyróżnione są stadia (stany) rozwojowe w cyklu życiowym komponentu (org.osgi.framework.Bundle):

• UNINSTALLED
• INSTALLED
• RESOLVED
• STARTING
• STOPPING
• ACTIVE

Wydaje się, że takich podobnie funkcjonujących szkieletów jest kilka (PicoContainer, HiveMind, Spring Framework, Apache XBean, NanoContainer, Plexus, jądra serwerów aplikacyjnych, Apache Maven 2 z mechanizmem wtyczek, czy wręcz EJB 3.0 i JSF 1.2). Możnaby tak wymieniać, ale przy OSGi na uwagę zasługują następujące fakty:

• OSGi jest standardem OSGi Alliance założonej w 1999 r. przez Sun, IBM i Ericsson et al (za Wikipedią). Obecnie w skład ciała standaryzującego wchodzą również Nokia, Motorola, Philips, Siemens, BMW, Deutsche Telekom i in. (widać znaczący udział rynku telekomunikacyjnego, gdzie "uzbrajanie się" central w odpowiednie usługi powinno odbywać się dynamicznie, na żądanie)
  
• Wykorzystanie standardu OSGi do stworzenia mechanizmu wtyczek w Eclipse IDE (http://www.eclipse.org/osgi oraz projekt Equinox)
• IBM WebSphere Application Server 6.1 oparty jest o zestaw pakietów, co umożliwia dynamiczne rozbudowywanie (na pewno teoretycznie) - artykuł WebSphere Application Server V6.1: What's new in Version 6.1? oraz niesamowita prezentacja IBM WebSphere Application Server V6.1: Componentization Overview.
• Utworzenie projektu Spring-OSGi, którego celem jest umożliwienie tworzenia aplikacji Spring, które będą jednocześnie mogły być uruchamiane w środowisku OSGi i korzystać z usług obu środowisk.
• BEA microService Architecture (mSA) korzystająca z OSGi (kilka informacji o BEA, OSGi i jej planach w artykule ComputerWorld BEA zapuszcza korzenie).
  
• JSR 291: Dynamic Component Support for Java^TM SE - tworzący się standard dotyczący Java SE i opierający się na OSGi
• JSR 277: Java^TM Module System - tworzący się standard dystrybucji modułów Java. Bardzo zbliżony do OSGi i tym samym kontrowersyjny (w klimacie podobnym do debaty wokół stworzenia nowego rozwiązania java.util.logging vs log4j).
  

Poza stadiami wyróżnia się również sposób zarządzania zależnościami (brzmi jakby znajomo z Apache Maven 2, nieprawdaż?). Innymi słowy, podobnie jak w Maven 2 czy w kontenerach IoC - Spring Framework, na przykład - możemy deklarować zależności, które są rozwiązywane przez platformę OSGi. Co więcej, jak przeczytałem w Getting Started with OSGi: Registering a Service, w przeciwieństwie do wymienionych rozwiązań, OSGi pozwala na, tzw. dynamiczne IoC, tj. zależności (pakiety OSGi) można dynamicznie podmieniać (ang. hot-swap). Raz uaktywniony pakiet można dostarczyć pakietom zależnym, a po chwili podmienić jego implementację (!)

Z mojej perspektywy wydaje się, że rozwiązania modularne promowane przez otwarte projekty są bardziej znane niż implementacje OSGi. Kto słyszał o OSGi? Może jakieś wzmianki, ale korzystać z tego? Nie sądzę.

Dostępnych, darmowych implementacji OSGi R4 jest kilka:

• Eclipse Equinox
• Apache Felix
• Knopflerfish
  

Seria mini-artykułów, a właściwie mini-przepisów, Getting started with OSGi przyjemnie wprowadza w temat. Może kogoś jeszcze zainteresuje?!