Kiedy należy używać EAR i kiedy aplikacje powinny być w WAR?

Question

Mamy wiele wiosennych aplikacji internetowych do zrobienia na serwerze WebLogic i jesteśmy ciekawi, kiedy WAR powinny wejść w EAR i kiedy powinny istnieć jako WAR. Czasami WAR będą musiały uzyskać dostęp do wspólnych logicznych JAR-ów, ale nie rozumiem, dlaczego musiałyby one trafić w EAR, gdyby mogły zostać po prostu spakowane w WAR.

Z tego co rozumiem, jeśli w EAR znajduje się kilka WAR i musisz zmodyfikować jedną z tych wojen, musisz ponownie wdrożyć całą wersję EAR, aby zaktualizować serwer. Spowoduje to odbicie wszystkich WAR. Gdyby jednak nie było ich w EAR, mógłbym tylko zaktualizować jedną WOJNĘ i to byłby jedyny, który odskoczyłby.

Co jest nie tak z posiadaniem 100 różnych plików WAR samodzielnych i przy użyciu pakietów JAR i bibliotek współdzielonych (przy użyciu WebLogic)?

Dziękujemy za wgląd!

Answer 1

Jeśli wszystko, co masz, to pliki WAR, to EAR ma ograniczoną przydatność, służy tylko jako pojemnik do rozmieszczenia dla twoich wojen. Możesz zaoszczędzić trochę nadmuchu, dzieląc JAR-y pomiędzy WAR-ami w ten sposób, ale to samo w sobie nie jest szczególnie istotne.

EAR są niezbędne, gdy mamy do czynienia z pełnymi aplikacjami JavaEE/J2EE, które wykorzystują WAR, EJB, JMS, zasoby JCA itp. Interakcje i zależności pomiędzy komponentami tego typu aplikacji są znacznie łatwiejsze do zarządzania w ucho.

Ale jeśli używasz tylko Weblogic to kontener WAR, to równie dobrze możesz użyć kontenera serwletów waniliowych, takiego jak Tomcat lub Jetty, do wszystkich funkcjonalnych zastosowań, które możesz uzyskać z Weblogic.

Answer 2

Zgadzam się z prawie wszystkimi komentarzami ze strony skaffmana (zazwyczaj).

Jeśli używasz sprężyny bez EJB, możesz oczywiście trzymać plik WAR. Nie potrzebuję EAR, które mogę zobaczyć.

Jeśli jednak Twoja aplikacja Spring używa komunikatów POJO sterowanych komunikatami, widzę, gdzie nadal można wdrożyć plik WAR w WebLogic, aby skorzystać z JMS.

EAR może być konieczne, jeśli masz EJB lub JCA, ale nie powiedziałbym, że JMS nakazuje EAR. Użyłem JMS i zainstalowałem plik WAR na WebLogic i działało dobrze.

Jeśli zdecydujesz się na Tomcat i wdrożysz tam WAR, nadal możesz zachować funkcjonalność JMS, jeśli używasz ActiveMQ.

Answer 3

Argument, aby spakować wiele WAR do EAR, może być przekonujący, jeśli napotkasz sytuację, którą zrobił mój ostatni pracodawca, gdzie masz wspólny zestaw JARów biblioteki używanych przez wiele WO i rozmiar tej kolekcji JARs jest znaczny. W naszej szczególnej sytuacji, łączny rozmiar 3 WAR z typowymi JAR-ami spakowanymi do każdej wojny wyniósł 124 MB. Lokalizując pliki JAR w zawierającej EAR i konfigurując ścieżkę klas każdej WAR, aby użyć tych JARów, ślad EAR zawierający 3 WAR został zredukowany do 40 MB. Uważam to za nieodparty powód.

Answer 4

Posiadanie wielu bibliotek współdzielonych raczej nie powinno być powodem, dla którego warto wybrać EAR, ponieważ JAR (lub zestaw JARów) zawsze może być wdrożony jako "biblioteka" w blogu, który może być udostępniony wszystkim WOJNY. Czy to prawda?

Answer 5

Nic nie jest nie tak z rozmieszczaniem wojen, programiści są zainteresowani jak najszybszym wykonywaniem zadań. Oznacza to, że często będą zaciągać dług techniczny, a jeśli znajdą się w szacownym zespole, wyczyszczą ten dług.

Jest to jednak problem, co się dzieje, gdy unikasz złożoności plików EAR i udostępniasz jar, dodając go do serwera aplikacji? O wiele bardziej powszechne w zespole tylko wojennym jest odciążenie wszelkiego rodzaju złożoności aplikacji na serwer aplikacji. Po prostu dlatego, że łatwiej było wprowadzić je w swój często nadpisywany harmonogram. Nie winię ich za to wcale, jednak teraz mamy nowy problem. Nie można użyć standardowego serwera aplikacji, należy dokonać dostosowań po stronie systemu. Skutecznie aplikacja internetowa krwawi w całym systemie. Osoba, która utrzymuje serwer aplikacji, teraz MUSI również znać szczegóły dotyczące aplikacji ... w środowisku korporacyjnym, stanowi to bardzo wyraźny problem.

Deweloperzy mogą wtedy wziąć na siebie odpowiedzialność za system, ale nadal muszą dotrzymywać terminów. Nieuchronnie krwawią również na całym systemie operacyjnym, i nagle programiści są jedynymi możliwymi administratorami. Jeśli administrator nie wie, co aplikacja używa po stronie systemu, może bardzo spowodować poważne problemy. Te niejasne linie zawsze kończą się palcami wskazującymi w obu kierunkach, nieznanymi stanami systemu i izolacją zespołu.

Czy muszą wtedy używać EAR? Nie, jestem inżynierem systemów, więc zawsze mówię, że mogą wdrożyć własny serwer aplikacji, tak jak inne komercyjne aplikacje. Wewnątrz RPM, jeśli wdrażanie WAR jest podobne do innych obsługiwanych serwerów aplikacji, wówczas otrzymują potok wdrażania WAR. Jeśli nie, to RPM wszystko w jednym ... Nie pozwalając zespołowi na eksternalizację swoich kosztów, wtedy EAR stają się WSPANIAŁYM pomysłem.