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.
Odpowiedzi:
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.
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)
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.
Używam jBoss od 3-4 lat.
Argumenty za jBoss:
Argumenty przeciwko jBoss:
Zamówienie GlassFish 3.1! Zbudowana na bazie modułowego jądra GlassFish v3 opartego na Javie EE 6, wersja 3.1 zapewnia klastrowanie, scentralizowaną administrację i wysoką dostępność.
Więcej informacji można znaleźć pod adresem http://blogs.oracle.com/nazrul/entry/glassfish_3_1 .
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:
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ń.
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.
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.
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