Zalety i wady korzystania z biblioteki współdzielonej w pełni enkapsulowanej EAR

Question

Nasz zespół buduje i obsługuje framework usług internetowych. Inne zespoły, które faktycznie budują serwisy internetowe, wykorzystują nasze ramy dla niektórych popularnych funkcji. Istnieją dwie możliwości spakowania pliku EAR. Opcja 1 polega na wbudowaniu wszystkich słoików ramowych do EAR. Opcja 2 polega na skonfigurowaniu biblioteki współużytkowanej na serwerze aplikacji i umożliwieniu wszystkim aplikacjom korzystania z biblioteki. Mamy potencjał upto 100 wdrożeń EARS, które wykorzystają te ramy. Jakie są zalety i wady tego podejścia pod względem budowy, zarządzania i rozwoju. Używamy websphere.

Answer 1

Podstawowym kompromisem jest zużycie pamięci w stosunku do zarządzania wersjami.

Jeśli pakiety zostaną umieszczone w pliku EAR, każda aplikacja utworzy własne instancje klasy, pobierając pewną ilość permgenu (lub odpowiednika), a także zajmując przestrzeń sterty dla danych statycznych.

Jeśli przechowujesz bibliotekę w katalogu lib aplikacji, wówczas będzie tylko jedna instancja każdej klasy. Oznacza to jednak, że każda aplikacja korzystająca z tej biblioteki musi korzystać z tej samej wersji i (chyba że zapewniona jest zgodność wsteczna) musi zostać uaktualniona w tym samym czasie.

Biorąc pod uwagę, że mówimy o 100 ofiarach, problem zarządzania wersjami prawdopodobnie będzie duży. Chyba, że ​​twoja biblioteka jest absolutnie ogromna (i zakładam, że korzystasz z 64-bitowego serwera z dużą ilością pamięci, więc uczyń to OGROMNIE), albo nigdy się nie zmieni (mało prawdopodobne), sugerowałbym opakowanie z EAR.

Answer 2

Proponuję również opakowanie z EAR. Ad kdgregory zwrócił uwagę na zarządzanie setkami programów, a ilość testów sugerowanych przez uaktualnienia staje się zniechęcająca; Ponadto należy użyć systemu kontroli wersji do zarządzania instancjami plików binarnych, które klienci mogą spożywać.

Answer 3

Zamiast umieszczać wspólne pliki jar w bibliotece/aplikacji, można zamiast tego korzystać z biblioteki współdzielonej WebSphere. Pozwala to na przypisanie różnych wersji tej samej biblioteki współdzielonej do różnych aplikacji, umożliwiając w ten sposób pewną elastyczność dla wersji msnsging.

Różne podejścia do udostępniania mają tendencję do komplikowania pewnych zagadnień, dlatego należy uważnie przyjrzeć się zaangażowanym modułom ładującym.

Wolałabym pozostać czysto-waniliową, pakować wszystko w EAR. To prosta, prosta Java EE. Każda aplikacja może wybrać własną stawkę przyjęcia wersji ramowej.

Zobacz artykuł Keys Botzum na opakowaniu common code.

Answer 4

Inną rzeczą, na którą należy zwrócić uwagę, jest to, że jeśli chcesz udostępnić instancje obiektów między plikami EAR, np. używając dynacache na serwerze WWW, klasy dla tych obiektów będą musiały być ładowane z bibliotek współdzielonych. (w przeciwnym razie, mimo że mogą być tą samą klasą/wersją, będą one ładowane przez różne programy ładujące klasy i niekompatybilne)

Zwykle używam zwykłej wanilii, "pakuję wszystko w EAR", ale potem robię wyjątki dla rzeczy, które należy udostępnić, i umieścić te klasy w specjalnym wspólnym JAR.

Answer 5

Zgadzam się z (prawie) wszystkim, co zostało napisane na ten temat wcześniej: chyba że masz ku temu dobry powód, śmiało pakuj wszystkie biblioteki w EAR i ciesz się korzyściami samodzielnych, samowystarczalnych raportów rocznych.

Jednak, jeśli w bibliotece trzeciej strony są używane statyczne obszary do inicjalizacji, należy spakować je w EAR. Wyraźnym przykładem jest Log4J. Log4J uruchamia się tylko raz dla każdego programu ładującego klasy. Dlatego, jeśli chcesz mieć inną konfigurację Log4J na EAR, nie masz innego wyjścia, jak umieścić plik JAR Log4J z każdą EAR. W przeciwnym razie JAR Log4J zostanie załadowany za pomocą programu ładującego klasy, który jest wspólny dla wszystkich Twoich EAR, załaduje się (i zainicjuje własne statyczne obszary) raz, a ta konfiguracja będzie obowiązywać dla wszystkich aplikacji korzystających z Log4J.