OSGi w infrastrukturze rozproszonej

Question

Pracujemy nad infrastrukturą opartą na OSGi do przetwarzania strumieni danych na podstawie strumienia. Określone zadania przetwarzania są wykonywane przez poszczególne komponenty OSGi. Teraz potrzebujemy możliwości dystrybucji tych komponentów na różne maszyny, co oznacza, że ​​potrzebujemy jakiegoś mechanizmu komunikacji między komponentami/kontenerami OSGi.

Podczas moich badań natrafiłem na różne potencjalne rozwiązania: R-OSGi, Apache CXF dla Distributed OSGi, Eclipse Communication Framework.

ECF wydaje się szczególnie interesujący, ponieważ obsługuje różne formaty transportu i zapewnia obsługę takich rzeczy, jak wykrywanie usług.

Moi centralne pytania:

• czy są jakieś szczegółowe tutoriale/walk-through dla utworzenia infrastruktury ECF w Felix? (z moich badań wynika, że ​​ostatnio dodano obsługę Felix)
• Czy są jakieś rozwiązania poza trzema wymienionymi powyżej, które mogłem pominąć?
• Czy istnieje powód do wzięcia Apache CXF zamiast ECF?

Answer 1

Pierwsze pytanie - czy istnieje szczegółowe przejście do utworzenia ECF z Feliksem - nie znam odpowiedzi, choć można użyć wyszukiwarki, aby znaleźć kombinacje tych terminów .

Problem polega na tym, że ECF wykorzystuje infrastrukturę Equinox, i czasami nieumyślnie polegał na pakietach, które nie są publiczne z powodu zależności przechodnich (w szczególności Runtime API, który używa Equinox do niepublicznego debugowania). To z kolei oznacza, że ​​ECF opiera się na całym szeregu innych składników, które są dostępne i jest to zestaw, który zazwyczaj nie jest dobrze zdefiniowany w środowisku wykonawczym Felix.

Zmarnowałeś materiał serwisowy Paremusa, który jest komercyjnym rozwiązaniem w chmurze OSGi. Nie jestem pewien, czy koncentrowałeś się na open-source, czy nie; ale jeśli włączasz licencje komercyjne, to mają bardzo solidną architekturę dla usług zdalnych.

Wreszcie pytanie Apache CXF o ECF - jeśli używasz Felixa, argumentowałbym, że przejście z Apache CXF jest prawdopodobnie łatwiejsze niż przejście z ECF. Wynika to głównie z tego, że zestaw zależności jest uzależniony od tego, czy działa on w połączeniu z faktem, że ECF może nie być testowany na Felixie, a zatem może on przybierać określone aspekty środowiska wykonawczego Equinox (które obejmuje na przykład delegowanie rodzica klasy runtime do pobrania rzeczy w boot classpath). Nie jest to w istocie wina ECF per se, ale raczej artefakt funkcjonowania ekosystemu Eclipse.

Jeśli chcesz komunikować się z środowiskami wykonawczymi spoza OSGi, w Apache CXF istnieje przewaga polegająca na tym, że mogą generować WDSL do interakcji z innymi językami. Wierzę, że możesz zrobić to samo w ECF z nieco większą ilością pracy. Rozwiązanie CXF może być bardziej szczegółowe niż odpowiadające mu ECF (WSDL zawsze jest), ale jeśli nie korzystasz z dużej liczby żądań, nie ma to większego znaczenia.