Czy w chwili obecnej używałbyś JBoss lub Glassfish (lub innego) jako serwera Java EE dla nowego projektu? [Zamknięte]

136

Gdybyś zaczął dzisiaj nowy projekt Java EE, który ma zostać ukończony za około rok, który serwer aplikacji byś wybrał i dlaczego?

Część Twojej odpowiedzi powinna zawierać argumenty przemawiające za Twoją decyzją. A także ile masz doświadczenia z wybranym serwerem Java EE i innymi dostępnymi serwerami na rynku. Są one interesujące, ponieważ wszyscy mamy sens śledztwa i myśleliśmy, że zostało to zawarte w twojej odpowiedzi.

user14070
źródło

Odpowiedzi:

181

Używałem WebLogic, WebSphere, JBoss, GlassFish, Resin, Jetty, Tomcat i kilku innych w ciągu ostatnich ponad 10 lat. Tak więc, gdybym rozważał nowy projekt, zadałbym sobie najpierw kilka pytań. Jedną rzeczą, której już nie kwestionowałbym, jest to, że płasko odmówiłbym używania JSP, chyba że byłbym torturowany, dopóki nie zapłakałem za mamą.

Czy muszę być zgodny / wdrożyć w konkretnym produkcie z powodu czyjegoś mandatu? Czy nie ma sposobu, aby ich zignorować lub przekonać, że jest inaczej? Jeśli tak, oto twoja odpowiedź.

Czy muszę używać EJB? Naprawdę? Unikaj ich, jeśli to w ogóle możliwe - są naprawdę potrzebne tylko w bardzo dużych systemach klasy korporacyjnej. Pamiętaj, że to tylko narzędzia i to duże (czy ktoś może powiedzieć „Złoty młot”?). Są mocno nadużywane, więc naprawdę pytaj, czy ich potrzebujesz. Jeśli ich potrzebujesz, usuwa to kilka opcji, w tym mój ulubiony Jetty.

Czy musisz używać innych głównych technologii J2EE, takich jak JMS, ESB itp.? Jeśli tak, i naprawdę nie możesz się bez niego obejść, to znowu jesteś ograniczony do pełnego kontenera J2EE. Na przykład dokładnie przemyśl i zbadaj sprawę, zanim zdecydujesz się na BPM, i unikaj AquaLogic BPM za (prawie) wszelką cenę - jest to wyjątkowo brzydkie.

Jeśli naprawdę musisz używać pełnowartościowego kontenera J2EE, rozważ najpierw open-source, ponieważ jest on bardziej niezawodny, lepiej obsługiwany i tańszy. Mają większe bazy klientów i bardziej otwartą interakcję z pomocą techniczną, więc szybciej otrzymują lepsze poprawki. Jednak Resin jest niedojrzały i unikałbym go w stosunku do GlassFish czy JBoss - uważałem, że jest to problematyczne we wdrażaniu i wspieraniu. Wolałbym JBoss ze względu na szerszą bazę klientów, dojrzałość itp. GlassFish jest trudniejszy do włączenia do zautomatyzowanego procesu budowania / wdrażania, ale może być lepszy w przypadku niektórych jego specyficznych funkcji (jeśli ich potrzebujesz).

Czy mam szczególny powód, aby potrzebować Apache? Następnie pochyl się w stronę Tomcata, może plus coś.

Czy mogę zadowolić się tylko serwletami? Wtedy użyłbym Jetty - jest to najlżejsze, najszybsze, najłatwiejsze, najbardziej elastyczne rozwiązanie. Jeśli opieram się przeciwko możliwości korzystania z Jetty, kwestionowałbym wszystkie moje założenia, dlaczego. YAGNI ma zastosowanie.

Najlepiej jest używać StringTemplate / WebStringTemplate na Jetty: czyste, solidne, szybkie, łatwe w utrzymaniu rozwiązanie bez opłat licencyjnych, solidnej reputacji i wsparcia itp. Od tego zaczynam dzisiaj.

Większość aplikacji / systemów wybiera wiele wymyślnych funkcji J2EE, podczas gdy wszystko, czego naprawdę potrzebują, to serwlety i JDBC z przyzwoitą architekturą / projektem. Zapytaj, dlaczego uważasz, że potrzebujesz więcej.

Spośród pełnowartościowych kontenerów unikałbym WebLogic i WebSphere, chyba że wspierasz główną publiczną witrynę internetową (witryna mojego obecnego pracodawcy jest wdrażana w WebLogic i uzyskuje ponad 11 milionów odsłon miesięcznie, inne były porównywalne). Prawdziwym powodem do sławy WebLogic jest ich stosunkowo łatwe łączenie w klastry, ale unikanie ich zastrzeżonych funkcji blokowania dostawcy za (prawie) wszelką cenę. WebSphere to po prostu koszmar, którego uniknąłbym dosłownie za wszelką cenę - odmawiam realizacji projektów związanych z WebSphere po tym, jak zrobiłem kilka w przeszłości. Żaden z produktów nie jest wart ogromnych opłat licencyjnych, chyba że naprawdę masz specjalną potrzebę, która motywuje do korzystania z zastrzeżonej funkcji. W ciągu dziesięciu lat pracy jako starszy architekt / inżynier w wielu firmach z listy Fortune 500 nie widziałem jeszcze takiej potrzeby. Z drugiej strony,

Nawet w przypadku naprawdę dużych, publicznych witryn internetowych o dużym natężeniu ruchu, zastrzeżone produkty są nadal wątpliwe. Wolałbym raczej wydawać te wielomilionowe opłaty licencyjne rocznie na dobry sprzęt i trochę czasu spędzonego przez garstkę naprawdę dobrych konsultantów, aby zająć się prostym rozwiązaniem skalowalnym. Dodatkowe miliony rocznie można by następnie wykorzystać do wyprodukowania czegoś wartego sprzedaży na tej ładnej stronie internetowej ...

EDYCJA: kolejny element do rozważenia ...

Niedawno spotkałem Terracotta . Przemyślam wszystko i zamierzam wkrótce wdrożyć to w znaczącym systemie. W szczególności Terracotta radzi sobie lepiej z klastrowaniem niż cokolwiek innego, więc JUŻ NIE polecałbym WebLogic do tworzenia klastrów.

Rob Williams
źródło
7
W przyszłości definicje akronimów można zwykle znaleźć za pośrednictwem wyszukiwarki Google lub Wikipedii. YAGNI = Nie będziesz tego potrzebować = nie przesadzaj z projektem JMS = Java Message Service ESB = Enterprise Service Bus BPM = Business Process Management
Rob Williams
21
Twoje komentarze na temat Java EE i EJB są trochę nieaktualne. J2EE ?! To było jak 5 lat temu. Przyjrzyj się Java EE 6 i zmodernizuj swoją perspektywę!
Brian Leathem
6
@Brian: Zgadzam się z Brianem, zwłaszcza z EJBLite, stało się dużo lżejsze.
Thang Pham
7
@Brian, spójrz na post - został napisany trzy lata przed Twoim komentarzem. I nadal powiedziałbym, że Spring jest lżejszy niż nawet odchudzona Java EE.
duffymo
2
Jaki jest teraz werdykt w 2012 roku? Czy JBoss 7 AS jest królem Glassfish w dziedzinie Java 6 EE? Albo na odwrót?
Rolando,
10

Termin „serwer aplikacji” jest niejednoznaczny. Dzięki GlassFish v3 możesz zacząć od małego, powiedzmy, tradycyjnego kontenera internetowego i ewoluować (używając OSGi i prostej funkcji „dodaj kontener”), aby dodać wszystko, co chcesz: JPA, JAX-RS, EJB, JTA, JMS, ESB , etc ... Jednak to ten sam produkt, ten sam interfejs administratora itp. Czy to kwalifikuje się jako serwer aplikacji dla Ciebie? -Alexis (słońce)

Alexis MP
źródło
1
Niestety Glassfish nie jest już oficjalnym produktem, a „tylko” wdrożeniem referencyjnym.
Thorbjørn Ravn Andersen
9

Pierwsze pytanie, które zwykle sobie zadaję, brzmi: „Czy mogę to zrobić z Tomcat?”. Jeśli odpowiedź brzmi nie, ponieważ potrzebuję JMS lub JTA, korzystam z serwera aplikacji.

Korzystałem z WebLogic 8 około 3 lata temu, zadowolony z łatwości użytkowania WebLogic i modelu licencjonowania / kosztów. Użyliśmy go w dwóch projektach, jeden był usługą internetową, a drugi portalem. W żadnym z tych projektów nie napotkaliśmy żadnych problemów z WebLogic lub WebLogic Portal.

Przez ostatnie dwa lata pracowałem z WebSphere. Za każdym razem, gdy negocjowałem z IBM, kosztowało to dwa razy więcej niż odpowiednik WebLogic, ale trzeba było stosować WebSphere zgodnie z polityką korporacyjną. Zauważyłem, że krzywa uczenia się w WebSphere jest znacznie bardziej stroma niż w WebLogic, a nasz cykl życia budowania / wdrażania / testowania był tak czasochłonny, że użyliśmy Tomcat w środowisku programistycznym. Jednak największym problemem związanym z WebSphere było to, że napotkaliśmy błąd, który zmusił nas do uaktualnienia do następnej wersji poprawki tylko po to, aby napotkać nowy problem podczas analizowania pliku web.xml. Przejście przez to wszystko zajęło 48 godzin.

W tej chwili jednak używam JBoss. Jakieś 3 miesiące temu miałem rozpocząć nowy projekt z Tomcat i Jetspeed 2, ale zauważyłem, że Jetspeed 2 wydaje się być teraz trochę w stagnacji, a JBoss Portal 2.7.0 został właśnie wydany z obsługą JSR 286 / Portlet 2.0. Przekręciłem JBossa i stwierdziłem, że jest bardzo łatwy w konfiguracji i zarządzaniu. Cykl budowania / wdrażania / testowania jest bardzo szybki i rzadko muszę ponownie uruchamiać serwer, chyba że gdzieś zmieniłem plik Spring XML.

bmatthews68
źródło
Niezła odpowiedź! Czy próbowałeś Jetty? A co o tym sądzisz, jeśli tak jest?
7

Używam jBoss od 3-4 lat.

Argumenty za jBoss:

  1. Otwarte źródło.
  2. Dostępne wsparcie komercyjne.
  3. Duża, aktywna społeczność użytkowników.

Argumenty przeciwko jBoss:

  1. Brak ogólnie dostępnej, obsługiwanej wersji kontenera Java EE 5.
  2. Dużo dokumentacji, ale szczegółowe; może być trudno znaleźć odpowiedzi na pytanie „Jak zrobić x?”
  3. Narzędzia administracyjne dla 4.x są słabe w porównaniu z innymi ofertami komercyjnymi.
johnstok
źródło
„Brak ogólnego dostępu, obsługiwane wydanie kontenera JEE 5”. Myślę, że tak już nie jest, prawda?
Raedwald,
@Raedwald: tak, teraz, gdy JEE 6 istnieje już od jakiegoś czasu ;-)
ymajoros
3

Kolejną kwestią, która nie została tutaj omówiona, jest wydajność. Jeśli jest to problem ze względu na rodzaj usługi lub liczbę użytkowników, zastosowanie będą miały następujące zasady:

  • Tomcat wydaje się być wolniejszy niż Glassfish
  • Glassfish wydaje się być wolniejszy niż Resin
  • Żywica jest znacznie wolniejsza niż G-WAN + Java

Zwróć uwagę, że G-WAN opiera się wyłącznie na JVM: nie używa żadnych dalszych kontenerów (chyba że wyraźnie określono), więc możesz zarezerwować ją dla krytycznych dla wydajności części aplikacji internetowych.

Ponieważ G-WAN obsługuje inne języki (C, C ++, C #, D, Objective-C), możesz nawet przetwarzać niektóre części aplikacji w surowym C, zachowując Javę do innych zadań.

gert
źródło
2

Mogę uwzględnić preferowany system operacyjny jako kryterium decyzji. Powinno to ułatwić obsługę, jeśli używasz tego samego dostawcy dla systemu operacyjnego i serwera aplikacji. Jeśli masz już relacje z jednym lub oboma dostawcami, zastanów się, czy dobrze jest sobie z nimi radzić.

Z technicznego punktu widzenia wybrałbym GlassFish, ponieważ ma wsparcie dla nowszych innowacji. Nie sądzę, żeby JBoss był zły w tym sensie, że po prostu nie jest tak aktualny.

Większość mojego doświadczenia dotyczyła WebLogic, ale korzystałem z JBoss i GlassFish. Właśnie opublikowałem nową witrynę na kompletnym stosie Open Source firmy Sun (OpenSolaris, GlassFish, MySQL) i było to wspaniałe doświadczenie z niewielkimi tylko frustracjami.

Ed.T
źródło
System operacyjny nie jest tak naprawdę problemem, chyba że masz bardzo specyficzne zależności binarne (co nie powinno mieć miejsca w przypadku większości projektów Java). Tworzymy na Windows, 32 i 64 bity i wdrażamy na Glassfish na Solarisie. Większość programistów tak naprawdę nie wie i nie musi się tym przejmować. Użytkownicy go nie widzą (większość naszych rozwiązań to aplikacje internetowe).
ymajoros,
2

Nadal uważam, że WebLogic jest najlepszym serwerem aplikacji Java EE na rynku. Myślę, że warto, jeśli stać cię na te opłaty licencyjne.

Zaskoczyło mnie, jak daleko można się posunąć, łącząc Tomcat, OpenEJB i ActiveMQ. Wydaje mi się, że to niedroga alternatywa.

Zajrzałbym również do Spring dm Server. Jest oparty na Tomcat, ale myślę, że element OSGi, który dodali, może być wszędzie w krótkim czasie. Jeśli zostanie zrobiony z taką samą jakością jak framework Spring, będzie naprawdę bardzo dobry.

duffymo
źródło
2
Problem, który mam z WebLogic polega na tym, że sprzedawca jest zablokowany, to paskudna pigułka do przełknięcia, gdy naprawdę nie musisz!
Manius
1
Dotyczy to wszystkich znanych mi dostawców Java EE, nie tylko WebLogic. Jeśli korzystasz z funkcji specyficznych dla dostawcy, jesteś zablokowany. Musisz kiedyś napisać kod.
duffymo
3
Usługa WebLogic jest przeznaczona wyłącznie do celów komercyjnych - właśnie o to mi chodzi - po wypisaniu dużego czeku jesteś „zablokowany” w większym stopniu niż w przypadku alternatywy typu open source. Oczywiście, jeśli zależy Ci na niezależności platformy, nie używałbyś funkcji specyficznych dla dostawców, więc nie o to mi chodzi. W rzeczywistości ankieta, którą przeczytałem kiedyś, powiedziała, że ​​deweloperzy uważają, że unikanie blokady dostawcy jest najważniejszą zaletą oprogramowania typu open source (a nie kosztem).
Manius
Kompletne bzdury? Czy uważasz, że podpisanie wielomilionowego kontraktu z dostawcą nie blokuje Cię? Masz dowód.
duffymo
@ymajoros Czy chodziło Ci o to, że „nie powinien” mieć blokady dostawcy? Szczerze mówiąc, nie rozumiem twojego komentarza.
Patrick M,
1

Alternatywa: w ogóle nie używaj serwera aplikacji.

Sprawdzić http://www.atomikos.com/Publications/J2eeWithoutApplicationServer .

W przypadku projektów internetowych zachowaj lekki kontener WWW, jeśli musisz, w połączeniu z czymś takim jak Wicket, aby uniknąć złożoności JSP / JSF lub Struts.

HTH Guy

Guy Pardon
źródło
Jeśli nie chcesz uczyć się używania narzędzi, nie używaj żadnych. Lub spróbuj zostać wykwalifikowanym specjalistą i zainwestuj w swoje środowisko, a zostaniesz nagrodzony. Muszę przyznać, że zrobiłem to dla niektórych projektów. Te same projekty ewoluowały bez serwera aplikacji, do niestandardowego serwera klienta w Spring, do czystego języka Java EE i Glassfish. Nie chciałbym nigdy wracać, pierwsze rozwiązanie było w rzeczywistości zbyt złożone, jest tak proste, jak może być dzisiaj (a standardowo można je wdrożyć na dowolnym serwerze aplikacji Java EE bez większych zmian).
ymajoros,
dobra odpowiedź, zły sposób na zdobycie dokumentu
msangel