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ć ?
Java 
- Rejestracja:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
0
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ć.
- Rejestracja:ponad 7 lat
- Ostatnio:około 6 lat
- Postów:101
1
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.
0
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.
Świetny Kot -> wiem, i to jest klucz całego mojego wpisu. Skoro moje przypadki użycia nie wymagają dynamicznej zmiany modułów, to można sobie poradzić kombinacją prostszych narzędzi.
- Rejestracja:ponad 8 lat
- Ostatnio:około 2 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
0
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.
edytowany 2x, ostatnio: jarekr000000
Pipes