OSGI - co to takiego ?

Cześć,
czy może ktoś wytłumaczyć co to jest ?
Wiem, że w googlach są informacje i to nawet po polsku, ale proszę o powiedzienie o tym z punktu widzenia programisty.
Warto się z tym zapoznać ?

To jest taka platforma umożliwiająca na dynamiczną wymianę komponentów w runtime. Możesz wyłączyć jakiś moduł aplikacji, usunąć go, dodać nowy itd bez konieczności restartów. Dodatkowo pozwala na dość dobrą kontrolę nad tym co moduły współdzielą. W "zwykłej" javie wszystkie biblioteki lecą do jednego worka i jak masz np. zależność od różnych wersji tej samej biblioteki to robi się problem. Dodatkowo dodanie biblioteki dodaje "wszystko" co się w niej znajduje. OSGi pozwala ograniczyć te problemy.

Niemniej jest to mało popularna technologia i nie wiem czy jest wielki sens sie nią interesować.

W poprzedniej pracy miałem nieprzyjemność pracować z tą technologią. Jedno słowo - uciekaj!

Nie chcesz wiedziec :P

zyxist napisał(a):

OSGi wykorzystywany jest m.in. przez Eclipse. Służy on do robienia modułowych aplikacji. Moduł jest to jakiś zapakowany kawałek kodu, który realizuje określoną funkcjonalność:

• wystawia jakieś API dla innych modułów,
• posiada jakieś obiekty z cyklem życia (start/stop), które ja nazywam serwisami,
• moduły można dynamicznie dodawać i usuwać w trakcie działania aplikacji.

OSGi przetestowałem sobie krótko czysto hobbystycznie, ponieważ w praktyce nie natrafiłem na przypadek użycia, który uzasadniałby wykorzystanie OSGi do tworzenia aplikacji z modułów i spokojnie mogłem poradzić sobie z prostszymi narzędziami. U mnie, gdy już pojawiały się moduły, to głównie po to, żeby programista sobie wziął dowolną liczbę z nich i złożył aplikację, którą potrzebuje - innymi słowy, lista modułów była ustalana na sztywno w kodzie i znana w momencie startu aplikacji. Właśnie ta dynamiczna natura OSGi czyni z niego tak ciężki framework - a skoro jej nie potrzebuję, to nie potrzebuję OSGi w ogóle.

Zwłaszcza od Javy 9 można sobie łatwo poradzić kombinacją lżejszych technologii:

• aby sprawić, by moduł A nie mógł używać wewnętrznych klas modułu B (nawet jeśli te w obrębie modułu B są publiczne), do tego służy nowy system modułów Javy,
• aby fizycznie odseparować kod modułów od siebie, wystarczy sobie stworzyć podprojekty w Gradle'u czy Mavenie i budować je jako osobne JAR-ki,
• cykl życia obiektów - 2 kilobajty kodu przyjmujące listę serwisów i wywołujące najpierw metodę start() na każdym z nich, a potem metodę stop(). Dodatkowo można zaimplementować sobie algorytm sortowania topologicznego, aby zrobić zależności między serwisami (np. serwis M musi się odpalić przed serwisem N).
• luźne wiązanie - dowolny kontener IoC.

A jeśli nie potrzebujesz w ogóle dzielić aplikacji na moduły, to sytuacja się jeszcze bardziej upraszcza.

OSGi umożliwiał też update tych modułów na żywca czego nie będziesz w stanie swoim setupem zrobić, z drugiej strony łatwiej jest to opędzić na poziomie procesów niż classloaderów.

Większość już została powiedziana. Dorzucam 3 grosze, bo trochę przez przypadek (nie z własnej głupoty) pracowałem kilka lat w projektach opartych o OSGi i nie polecam.
Sama technologia jest na pozór OK i daje obietnicę rozwiązania problemów z zależnościami i wersjami w classpath (taki trochę maven do runtime) - w zamian za to - wprowadza niestety piekło classloaderów. Długo wszystko jest fajnie, ale kóregoś pięknego dnia dorzucacie do projektu jakąś bibliotekę do parsowania XML (czy tym podobne) i wszystko zaczyna się sypać. Potem się okazuje, że ktoś w tej bibliotece nie przewidział OSGI i ręcznie "łazi" po classloaderach.... niby to nie wina OSGi, a samej biblioteki. Niemniej problem pozostaje, produkcja sie sypie i trzeba użyć poteżnej magii do rozwiązania problemu.

Czyli też jestem na NIE. OSGi ciekawy eksperyment i pomysł niegłupi... ale nie sprawdza się w praniu.