jakie korzyści zapewnia system komponentów OSGi?
Oto całkiem spora lista:
Mniejsza złożoność - programowanie w technologii OSGi oznacza tworzenie pakietów: komponentów OSGi. Pakiety to moduły. Ukrywają swoje elementy wewnętrzne przed innymi pakietami i komunikują się poprzez dobrze zdefiniowane usługi. Ukrywanie elementów wewnętrznych oznacza większą swobodę późniejszych zmian. To nie tylko zmniejsza liczbę błędów, ale także upraszcza tworzenie pakietów, ponieważ pakiety o prawidłowych rozmiarach implementują funkcjonalność poprzez dobrze zdefiniowane interfejsy. Istnieje ciekawy blog, który opisuje, co technologia OSGi zrobiła w procesie rozwoju.
Ponowne użycie - model komponentu OSGi sprawia, że korzystanie z wielu komponentów innych firm w aplikacji jest bardzo łatwe. Coraz więcej projektów open source dostarcza gotowe pliki JAR dla OSGi. Jednak biblioteki komercyjne stają się również dostępne jako gotowe pakiety.
Prawdziwy świat -Struktura OSGi jest dynamiczna. Może aktualizować pakiety w locie, a usługi mogą przychodzić i odchodzić. Programiści, którzy używali bardziej tradycyjnej Javy, postrzegają to jako bardzo problematyczną funkcję i nie dostrzegają korzyści. Okazuje się jednak, że świat rzeczywisty jest bardzo dynamiczny, a posiadanie dynamicznych usług, które mogą przychodzić i odchodzić, sprawia, że usługi te idealnie pasują do wielu scenariuszy w świecie rzeczywistym. Na przykład usługa może modelować urządzenie w sieci. Jeśli urządzenie zostanie wykryte, usługa zostanie zarejestrowana. Jeśli urządzenie zniknie, usługa nie zostanie zarejestrowana. Istnieje zaskakująca liczba rzeczywistych scenariuszy pasujących do tego dynamicznego modelu usług. Aplikacje mogą zatem ponownie wykorzystywać potężne operacje podstawowe rejestru usług (rejestrować, uzyskiwać, wyświetlać listę z ekspresyjnym językiem filtrowania i czekać na pojawienie się i zniknięcie usług) we własnej domenie. Pozwala to nie tylko zaoszczędzić na pisaniu kodu, ale także zapewnia globalną widoczność, narzędzia do debugowania i większą funkcjonalność niż w przypadku dedykowanego rozwiązania. Pisanie kodu w tak dynamicznym środowisku brzmi jak koszmar, ale na szczęście istnieją klasy wsparcia i frameworki, które pochłaniają większość, jeśli nie całość, bólu.
Łatwe wdrożenie - technologia OSGi to nie tylko standard dla komponentów. Określa również sposób instalowania i zarządzania komponentami. Ten interfejs API był używany przez wiele pakietów w celu zapewnienia agenta zarządzania. Ten agent zarządzania może być tak prosty jak powłoka poleceń, sterownik protokołu zarządzania TR-69, sterownik protokołu OMA DM, interfejs chmury obliczeniowej dla EC2 Amazon lub system zarządzania IBM Tivoli. Ujednolicony interfejs API zarządzania ułatwia integrację technologii OSGi z istniejącymi i przyszłymi systemami.
Aktualizacje dynamiczne - model komponentu OSGi jest modelem dynamicznym. Pakiety można instalować, uruchamiać, zatrzymywać, aktualizować i odinstalowywać bez wyłączania całego systemu. Wielu programistów Java nie wierzy, że można to zrobić niezawodnie i dlatego początkowo nie używają tego w środowisku produkcyjnym. Jednak po użyciu tego przez pewien czas w rozwoju większość zaczyna zdawać sobie sprawę, że to naprawdę działa i znacznie skraca czas wdrażania.
Adaptacyjny - model komponentu OSGi został zaprojektowany od podstaw, aby umożliwić mieszanie i dopasowywanie komponentów. Wymaga to określenia zależności komponentów i wymaga, aby komponenty działały w środowisku, w którym ich opcjonalne zależności nie zawsze są dostępne. Rejestr usług OSGi jest rejestrem dynamicznym, w którym pakiety mogą rejestrować, uzyskiwać i słuchać usług. Ten dynamiczny model usług pozwala pakietom dowiedzieć się, jakie możliwości są dostępne w systemie i dostosować funkcje, które mogą zapewnić. Dzięki temu kod jest bardziej elastyczny i odporny na zmiany.
Przejrzystość - pakiety i usługi są pierwszorzędnymi obywatelami w środowisku OSGi. Interfejs API zarządzania zapewnia dostęp do wewnętrznego stanu pakietu, a także sposobu, w jaki jest on połączony z innymi pakietami. Na przykład większość platform udostępnia powłokę poleceń, która pokazuje ten stan wewnętrzny. Części aplikacji można zatrzymać w celu debugowania określonego problemu lub wprowadzić pakiety diagnostyczne. Zamiast wpatrywać się w miliony linii danych wyjściowych rejestrowania i długi czas restartu, aplikacje OSGi często można debugować za pomocą powłoki poleceń na żywo.
Wersjonowanie - technologia OSGi rozwiązuje piekło JAR. Piekło JAR to problem polegający na tym, że biblioteka A działa z biblioteką B; wersja = 2, ale biblioteka C może działać tylko z biblioteką B; wersja = 3. W standardowej Javie nie masz szczęścia. W środowisku OSGi wszystkie pakiety są starannie wersjonowane, a tylko pakiety, które mogą współpracować, są połączone razem w tej samej przestrzeni klasowej. Dzięki temu zarówno pakiet A, jak i C mogą działać z własną biblioteką. Chociaż nie zaleca się projektowania systemów z tym problemem związanym z wersjonowaniem, w niektórych przypadkach może to być ratowanie życia.
Prosty - interfejs API OSGi jest zaskakująco prosty. Podstawowym interfejsem API jest tylko jeden pakiet i mniej niż 30 klas / interfejsów. Ten podstawowy interfejs API jest wystarczający do pisania pakietów, instalowania ich, uruchamiania, zatrzymywania, aktualizowania i odinstalowywania oraz obejmuje wszystkie klasy nasłuchiwania i zabezpieczenia. Istnieje bardzo niewiele interfejsów API, które zapewniają tak wiele funkcji dla tak małego interfejsu API.
Small - OSGi Release 4 Framework może być zaimplementowany w pliku JAR o wielkości około 300 KB. Jest to niewielki narzut związany z ilością funkcji dodanych do aplikacji przez włączenie OSGi. Dlatego OSGi działa na wielu urządzeniach: od bardzo małych, przez małe, aż do komputerów mainframe. Prosi tylko o uruchomienie minimalnej maszyny wirtualnej Java i dodaje bardzo niewiele.
Szybko - Jednym z głównych obowiązków frameworka OSGi jest ładowanie klas z pakietów. W tradycyjnej Javie pliki JAR są całkowicie widoczne i umieszczane na liście liniowej. Przeszukiwanie klasy wymaga przeszukania tej listy (często bardzo długiej, 150 nie jest rzadkością). W przeciwieństwie do tego, wiązki przewodów OSGi i dla każdego pakietu dokładnie wiedzą, który pakiet zapewnia klasę. Ten brak wyszukiwania jest znaczącym czynnikiem przyspieszającym podczas uruchamiania.
Leniwy - Leniwy w oprogramowaniu jest dobry, a technologia OSGi ma wiele mechanizmów do robienia rzeczy tylko wtedy, gdy są naprawdę potrzebne. Na przykład pakiety można uruchamiać chętnie, ale można je również skonfigurować tak, aby uruchamiały się tylko wtedy, gdy inne pakiety z nich korzystają. Usługi mogą być rejestrowane, ale tworzone tylko wtedy, gdy są używane. Specyfikacje zostały kilkakrotnie zoptymalizowane, aby uwzględnić tego rodzaju leniwe scenariusze, które mogą zaoszczędzić ogromne koszty środowiska wykonawczego.
Bezpieczny - Java ma bardzo wydajny drobnoziarnisty model bezpieczeństwa na dole, ale jego konfiguracja w praktyce okazała się bardzo trudna. Powoduje to, że najbezpieczniejsze aplikacje Java działają z wyborem binarnym: brak zabezpieczeń lub bardzo ograniczone możliwości. Model bezpieczeństwa OSGi wykorzystuje drobnoziarnisty model bezpieczeństwa, ale poprawia użyteczność (a także utwardza oryginalny model), ponieważ twórca pakietu określa wymagane szczegóły bezpieczeństwa w łatwo kontrolowanej formie, podczas gdy operator środowiska pozostaje w pełni odpowiedzialny. Ogólnie rzecz biorąc, OSGi prawdopodobnie zapewnia jedno z najbezpieczniejszych środowisk aplikacji, które wciąż jest użyteczne bez platform komputerowych chronionych komputerowo.
Non Intrusive - Aplikacje (pakiety) w środowisku OSGi są pozostawione same sobie. Mogą korzystać z praktycznie dowolnego narzędzia maszyny wirtualnej bez ograniczania ich przez OSGi. Najlepszą praktyką w OSGi jest pisanie zwykłych starych obiektów Java iz tego powodu nie wymaga specjalnego interfejsu dla usług OSGi, nawet obiekt Java String może działać jako usługa OSGi. Ta strategia ułatwia przenoszenie kodu aplikacji do innego środowiska.
Działa wszędzie - to zależy. Pierwotnym celem Javy było uruchamianie w dowolnym miejscu. Oczywiście nie można uruchomić całego kodu wszędzie, ponieważ możliwości maszyn wirtualnych Java są różne. Maszyna wirtualna w telefonie komórkowym prawdopodobnie nie będzie obsługiwać tych samych bibliotek, co komputer mainframe IBM z aplikacją bankową. Do rozwiązania są dwa problemy. Po pierwsze, interfejsy API OSGi nie powinny używać klas, które nie są dostępne we wszystkich środowiskach. Po drugie, pakiet nie powinien się uruchomić, jeśli zawiera kod, który nie jest dostępny w środowisku wykonawczym. Oba te problemy zostały rozwiązane w specyfikacjach OSGi.
Źródło: www.osgi.org/Technology/WhyOSGi