2012-06-11 10 views
10

Pracuję teraz nad usługą OSGi i mam pytanie dotyczące korzystania z usług w OSGi. Istnieje kilka różnych sposobów rejestracji usługi użytkownika. Czy ktoś może wyjaśnić różnicę między śledzeniem usług OSGi a usługami deklarującymi? Który jest lepszy?Co różni usługa śledzenia usług OSGi od usług deklaratywnych

+0

Dziękuję wszystkim. Cała twoja odpowiedź jest przydatna. Ale mogę wybrać tylko jedną: –

Odpowiedz

14

W OSGi The ServiceTracker to programowy sposób na uzyskanie odniesienia do usługi. np. piszesz kod ServiceTracker, który "śledzi" odniesienie do innej usługi i wykorzystajmy go, gdy stanie się dostępny.

W przeciwieństwie do usług deklaratywnych (DS), można zadeklarować zależności, które są wstrzykiwane do komponentu. DS jest, jako taka, formą zastrzyku zależności. Wykres zależnoś ci mię dzy usługami wraz z ich poleceniem startowym okreś la moment rozpoczę cia Twojej usługi. Właściwość cardinality w definicji DS pozwala zadeklarować, czy relacja jest obowiązkowa (1..1), wielokrotność z co najmniej jedną (1..n), opcjonalną (0..1) lub wielokrotną opcjonalną (0..n). Gdy deklarujesz obowiązkowe relacje, twoja usługa nie rozpocznie się, dopóki wszystkie zależności nie zostaną spełnione. Po zadeklarowaniu opcjonalnego związku usługa zostanie uruchomiona niezależnie od stanu zależności, ale należy zachować ostrożność w kodzie, że odwołanie do usługi może mieć wartość null.

Z praktycznego punktu widzenia ServiceTracker to dużo kodu do pisania i utrzymywania. Biorąc pod uwagę dynamiczny charakter usług OSGi, specyfikacja OSGi wymaga wielu stanów, które należy wziąć pod uwagę. DS zapewnia czysty sposób deklarowania i utrzymywania zależności. Dobrze zdefiniowane zależności pomogą ci zachować spójność twojego środowiska uruchomieniowego.

+1

DS - Deklaratywne usługi – Robin

+0

@Robin Zawsze mieszam ten akronim w mojej głowie - poprawiony. – maasg

3

Usługa Śledzenie usług OSGi pozwala zarejestrować odbiorców dla określonych usług, aby móc zareagować, gdy usługa stanie się dostępna.

Z drugiej strony usługi deklaracyjne domyślnie wykorzystują moduł śledzenia usług do opóźnienia wykonania kodu aktywacyjnego pakunku, dopóki nie zostaną rozwiązane zależności usługi.

4

Usługi deklaracyjne (DS) są dość łatwe w użyciu, a unikniesz niektórych kodów związanych z korzystaniem z ServiceTrackera. Jeśli przejdziesz do zwykłego OSGI, używając tylko ServiceTracker, musisz zająć się niektórymi aspektami dynamicznej natury usług OSGI. Usługi mogą przychodzić i odchodzić, a twój komponent musi sobie z tym poradzić. Jeśli używasz DS, większość tej pracy jest już wykonana. Wystarczy zdefiniować odniesienia do innych usług, a DS wstawi te odniesienia, gdy staną się dostępne. DS aktywuje Twój komponent po spełnieniu wymagań komponentu.

Jeśli używasz adnotacji Apache Felix SCR lub adnotacji dostarczonych przez bndlib, możesz także uniknąć zapisywania xml wymaganych przez usługi deklaracyjne. Niedawno grupa OSGI opublikowała także swoje adnotacje. Myślę, że te dostarczone przez bndlib i te z OSGI są bardzo podobne i jestem prawie pewien, że narzędzie bnd może przetwarzać oba.

Użyłem adnotacji Apache SCR jakiś czas temu, ale teraz wolę używać bndlib, ponieważ zawiera adnotacje dla Metatype i niektórych klas, które znacznie ułatwiają implementację usługi zarządzanej. Metatype to specyfikacja związana z usługami zarządzanymi. Zasadniczo zapewnia metadane, które mogą być używane przez implementacje Admin Config, aby zapewnić bardziej przyjazny dla użytkownika interfejs do konfiguracji komponentu.

Znam dwie inne możliwości: iPojo i Blueprint.

iPojo jest dość potężny i bogaty w funkcje. Zawiera większość elementów OSGI i zawiera kilka ciekawych funkcji, takich jak obsługa EventAdmin i obsługa ConfigAdmin.

Użyłem Blueprint trochę, ale z powodu nadmiernego użycia xml nie lubię tego tak bardzo. Myślę, że możesz powiedzieć, że Blueprint jest jak Wiosna dla OSGI.