Jak świadczenie usług OSGi na kliencie

Question

Rozwijamy web-aplikacji (pozwala nazwać to bank zdjęć), dla których mamy zidentyfikowane następujące potrzeby:

• Aplikacja zaspokaja klientów, które składają się z zestawu użytkowników.
• Nowy klient mogą być tworzone dynamicznie, a klient udaje to użytkownicy
• klienci mają różne zestawy funkcji, które mogą być dynamicznie zmieniane
• klienci mogą rozwijać swoje własne cechy i ich rozmieszczenia.
• Aplikacja jest jednorodna i ma aktualną wersję, ale wersja do podnoszenia klientów może być nadal obsługiwana indywidualnie.
• Aplikacja powinna być zarządzana w całości, a klienci dzielą zasoby, które powinny być łatwe do skalowania.

Pytanie: powinniśmy budować to na standardowej ramy OSGi lub bylibyśmy lepiej z użyciem jednego z powstających struktur aplikacyjnych (Panna, Baran lub zbliżający standardowych OSGi)?

Więcej tło i kilka początkowych myśli:

Budujemy aplikację internetową, która Widzimy wkrótce setki klientów (firm) z setkami użytkowników każdy (pracowników), w przeciwnym razie po co;). Chcemy, aby był modułowy, a więc OSGi. W przyszłości sami klienci mogą opracowywać i wtłaczać komponenty do swoich aplikacji, więc potrzebujemy izolacji klienta. Możemy również chcieć różnych klientów, aby uzyskać różne zestawy funkcji.

Jaki jest "prawidłowy" sposób dostarczania różnych implementacji usług różnym klientom aplikacji, gdy różni klienci dzielą te same pakiety?

Moglibyśmy skorzystać z metody App-Server (patrzyliśmy na Virgo) i ładować każdy pakiet raz dla każdego klienta w jego "aplikacji". Jednak nie ma ochoty na objęcie OSGi. Nie hostujemy wielu aplikacji, 99% usług będzie miało tę samą implikację. dla wszystkich klientów. Chcemy również zarządzać (konfigurować, monitorować itd.) Aplikację jako jedną.

Każda usługa może być zarejestrowana (poprawnie skonfigurowana) raz dla każdego klienta wraz z pewną właściwością "klient-token". Trochę bałaganu i trzeba się z tym uporać z rozbudowanym wzorcem lub może ManagedServiceFactory? Również przed zarejestrowaniem usługi dla klienta A trzeba będzie nabyć wersję A każdej z jego zależności.

"Obecny" klient będzie znany w każdym żądaniu i może być związany z wątkiem. Trochę bałaganu, który musi dostarczyć żeton klienta za każdym razem, gdy szukasz usługi. Utrudnia to korzystanie ze struktur komponentów, takich jak blueprint. Aby obejść ten problem, możemy użyć haków serwisowych do proxy każdego zarejestrowanego typu usługi i pozwolić na wysłanie proxy do właściwej instancji zgodnie z bieżącym klientem (wątek).

Rozpoczęcie naszego całego doświadczenia z OSGi poprzez zastosowanie obejścia (hack?) Powyżej naprawdę wydaje się wskazówką, że jesteśmy na niewłaściwej ścieżce. Więc co powinniśmy zrobić? Wróć do Virgo? Spróbuj czegoś podobnego do tego, co zostało opisane powyżej? Coś zupełnie innego ?!

ps. Dziękuję za przeczytanie tutaj!;)

Answer 1

Istnieje kilka aspektów, do roztworu:

Przede wszystkim, trzeba znaleźć sposób, aby skonfigurować różne klientów masz. Budowanie rozwiązania na podstawie programu ConfigurationAdmin ma sens, ponieważ wtedy możesz maksymalnie wykorzystać istniejący standard OSGi. Powodem, dla którego warto zbudować coś na wierzchu, jest to, że ConfigurationAdmin umożliwia konfigurowanie każdej pojedynczej usługi, ale możesz dodać warstwę na wierzchu, dzięki czemu możesz wygodniej skonfigurować całą aplikację (zestaw pakietów) za jednym razem. Taką konfigurację można następnie przetłumaczyć na poszczególne konfiguracje usług.

Dodawanie nieruchomości do usług, które mają konkretne wdrożenia dla klientów, ma wiele sensu. Można je ustawić za pomocą ManagedServiceFactory, a właściwość ułatwia wyszukiwanie usługi dla właściwego klienta za pomocą filtra. Możesz nawet zdefiniować scenariusz awaryjny, w którym szukasz usługi specyficznej dla klienta lub ogólnej (ponieważ nie wszystkie usługi będą prawdopodobnie specyficzne dla klienta). Ponieważ musisz jawnie dodawać takie filtry do swoich zależności, polecam wzięcie istniejącego rozwiązania do zarządzania zależnościami i rozszerzenie go o konkretny przypadek użycia, aby zależności automatycznie dodawały właściwe filtry specyficzne dla klienta bez konieczności ręcznego określania tych filtrów. Zdaję sobie sprawę, że będę musiał zagłębić się w szczegóły, daj mi znać ...

Następne pytanie brzmi: jak śledzić "kontekst" klienta w aplikacji. Tradycyjnie jest tu tylko kilka opcji, z których najczęściej używa się lokalnego kontekstu wątku. Powiązanie wątków z klientami zwykle ogranicza Twoje możliwości implementacji, ponieważ prawdopodobnie oznacza to, że musisz zabronić programistom tworzenia samych wątków i ciężko jest oddzielić niektóre zadania od pul wątków roboczych. Jest jeszcze gorzej, jeśli kiedykolwiek zdecydujesz się na korzystanie z usług zdalnych, ponieważ oznacza to całkowitą utratę kontekstu.

więc do przejścia na identyfikacji klienta z jednego elementu na drugi, ja osobiście wolę rozwiązania gdzie:

1. Jak tylko nadejdzie żądanie (na przykład w swojej serwletu HTTP) jakoś określić klientowi ID.
2. Jawnie przekazuj identyfikator w łańcuch zależności usług.
3. Używaj tylko takich rozwiązań, jak używanie lokacji wątku w granicach pojedynczego pakietu, jeśli na przykład używasz w pakiecie biblioteki innej firmy, która potrzebuje tego do śledzenia klienta.

Answer 2

Już od jakiegoś czasu zastanawiam się nad tą samą kwestią i chciałabym poznać wasze opinie na temat następującej analogii.

Rozważ serię aplikacji internetowych, w których zapewniasz kontrolę dostępu za pomocą infrastruktury jednokrotnego logowania (SSO). Użytkownik uwierzytelnia się jednokrotnie przy użyciu serwera SSO, a kiedy żądanie przychodzi, docelowa aplikacja sieciowa pyta serwer SSO, czy użytkownik jest (nadal) uwierzytelniony i sam określa, czy użytkownik jest uprawniony. Informacje autoryzacyjne mogą być również dostarczane przez serwer jednokrotnego logowania.

Teraz pomyśl o pakietach aplikacji jako miniaplikacjach. Mimo że nie są to aplikacje internetowe, czy nadal nie ma sensu posiadanie pakietu SSO z wykorzystaniem technik SSO do uwierzytelniania i podawania informacji autoryzacyjnych? Każdy pakiet aplikacji musiałby zostać opracowany lub skonfigurowany do używania pakietu SSO do sprawdzania autentyczności uwierzytelnienia (token SSO) i sprawdzania autoryzacji przez żądanie pakietu SSO, jeśli użytkownik ma dostęp do tego pakietu aplikacji.

Pakiet SSO utrzymuje pewne repozytorium sesji, a także udostępnia właściwości użytkownika, np. informacje umożliwiające identyfikację repozytorium danych tego rodzaju. W ten sposób nie przeszedłbyś również przez (znaczący) "token obsługi klienta", ale raczej tajemniczy token SSO, który jest dostarczany i zarządzany przez pakiet SSO.

Answer 3

Nie należy uważać, że Panna jest kontenerem OSGi opartym na systemie Equinox, więc jeśli nie chcesz używać niektórych funkcji specyficznych dla Panny, nie musisz tego robić. Dostaniesz jednak dużo benefits, jeśli użyjesz Virgo, nawet dla podstawowej aplikacji OSGi. Wygląda jednak na to, że potrzebujesz wsparcia w Internecie, które wychodzi z pudełka z serwerem Virgo i pozwoli zaoszczędzić sobie trudu samodzielnego zebrania go razem.

Pełne ujawnienie: Prowadzę projekt Virgo.