Punkt progu rentowności OSGi

Question

Wygląda na to, że OSGi to obecnie gorący termin. Wiele benefits są wywoływane:

• Zmniejszone Complexity
• Reuse
• Łatwe wdrażanie
• wersjonowanie

(etc)

Pytam o bardzo konkretnym przypadku użycia - małych i średnich aplikacji internetowych. Jakie korzyści przyniosłoby im to OSGi? Czy to naprawdę jest tego warte?

Answer 1

Będę ryzykować NIE, mimo że jestem wielkim fanem OSGi. Chyba, że ​​pracujesz z innymi pakietami OSGi lub masz specyficzny problem, którego nie możesz łatwo rozwiązać bez tego młota.

Korzyścią jest elegancka separacja classpath (IMHO). Jeśli potrzebujesz różnych wersji tego samego JAR/klasy, powiedzmy, że aktualizujesz niektóre części aplikacji w trakcie jej działania lub łączysz wiele modułów zewnętrznych, to OSGi jest świetne.

Nie jest to łatwe, a OSGi nie jest łatwe. Jest czysty, ale kosztem innej warstwy w stosie środowiska. I dużo pracy do nauki i utrzymania.

Nie wspominając już o tym, że dokumentacja nie jest szczególnie przyjazna dla początkujących.

Sugeruję, aby dowiedzieć się o tym - tworzenie wtyczek Eclipse to bardzo dobry sposób - ale nie budowanie go do planu deweloperów, dopóki nie poznasz go dobrze.

Answer 2

Powiedziałbym, jak zawsze "to zależy".

Twoje środowisko

Rozważmy istniejący zespół bez doświadczenia OSGI (który dumnie uważają się za doświadczonych programistów, którzy „get things done”. Jest szansa, że ​​będą one wystąpić poważny ból lub powolny początek .

wiele (więcej niż myślisz) deweloperzy nie są zaznajomieni z narzędzi budowania takich jak Ant lub Maven, a gdy są one jedynie ograniczone możliwości korzystania z tych narzędzi budowania.

Tworzenie Pakiety OSGI najlepiej jest wykonać przy użyciu skryptu lub ręcznie napisanego manifestu dla archiwum słoików.

Małe aplikacje

Dla małych aplikacji, OSGI wprowadza niepotrzebną złożoność natomiast można użyć dynamicznych języków takich jak Jython itp lub ramy plugin taki jak JPF lub SPI. Możesz również przejść bezpośrednio z refleksją i prostym niestandardowym programem ładującym klasy.

Wielkie aplikacji

Duże aplikacje mogą korzystać z OSGi, zwłaszcza gdy są one napisane od podstaw. IMHO integrujące OSGI w istniejącej aplikacji przypomina raczej wprowadzenie łaty zapewniającej architekturę modułową.

Z mojego doświadczenia wynika, że ​​po przepisaniu wielu aplikacji lepiej jest pomyśleć o modularności na początku projektu.

Inne problemy

wdrażania: Tak samo jest w każdej aplikacji. Jeśli jesteś przyzwyczajony do wdrażania aplikacji Java Web Start, wdrożenie nie jest problemem. Jeśli jesteś przyzwyczajony do OSGI, wdrożenie nie powinno stanowić problemu.

Od czasu do czasu pojawiają się zawsze problemy związane z wdrożeniem w produkcji, co jest naturalne.

Wersja: Istnieje wiele sposobów na zapewnienie wersjonowania w aplikacji. Ale jeśli używasz wersjonowania tylko jako "informacji" vs jako narzędzia (zarządzanie wymaganiami zależności), wersjonowanie nie jest problemem.

Ponowne użycie: Podczas korzystania z OSGI zazwyczaj piszesz kod do ponownego użycia, ale każdy dobrze napisany API został zaprojektowany z myślą o ponownym użyciu kodu.

Eclipse to numer jeden udanej dużej aplikacji napisanej z OSGI. Istnieją inne duże/ładne narzędzia, które nie korzystają z OSGI i są modułowe.

Wnioski

W wielu ram modułowych, trudno obsłużyć zależności, stop/start/odinstalować/zainstalować funkcje w czasie wykonywania, bez konieczności ponownego uruchamiania aplikacji. Grasz z niestandardowym ładowaniem klasy, wyłączaniem i uruchamianiem haków itp.

OSGI zapewnia taką elastyczność przy niewielkim koszcie IMHO.