2009-08-20 13 views
44

Jestem długoletnim programistą Java w JBoss (i Tomcat). W zeszłym roku musiałem rozwinąć WebLogic i muszę powiedzieć - naprawdę tęsknię za JBoss.Weblogic lub JBoss?

Ponieważ moje doświadczenie z WebLogic jest dość płytkie, proszę o bardziej doświadczonych facetów: Czy istnieje powód do wydawania pieniędzy na WebLogic? Czy JBoss nie oferuje wszystkiego, czego potrzebujesz?

+1

Co "potrzebujesz"? –

+1

Po co marnować pieniądze na WebLogic, gdy jakikolwiek inny pakiet serwera aplikacji może być łatwo zastąpiony - np. JBoss, Tomcat, Glassfish plus dodatki itp. –

+0

, jeśli chcę wdrożyć prostą aplikację na serwerze weblogic, a następnie zapłacić za prawo licencji. –

Odpowiedz

34

Podejrzewam, że powodem, dla którego Weblogic został wybrany, jest miła osoba handlowa, która przychodzi odwiedzić menedżera z pieniędzmi do wydania, daje mu pole sprzedaży i hej-presto, firma korzysta z Weblogic. Nie wiem, czy kontrakt na wsparcie JBoss pochodzi z działem sprzedaży, ale byłby zaskoczony, gdyby tak się stało i że pole gry jest wyrównane pod tym względem.

Z mojego doświadczenia wynika, oprócz ładnego konsoli można uzyskać z WebLogic (co nie jest warte rozwidlone opłaty licencyjne) nie ma wiele między 2. Podejrzewam te dni JBoss posiada udział w rynku (tylko zgadywać, że) , która w mojej książce przekłada się na większą pomoc dostępną online, itp., gdy utkniesz na czymś.

Warto również wziąć pod uwagę, że licencje Weblogic (ostatnio je widziałem), w których zwykle używane są warunki po stronie serwera - na procesor, na skrzynkę itd. Ogranicza to użytkownika pod względem skalowalności, ponieważ dzięki JBoss można zachować dodawanie sprzętu bez ponoszenia dodatkowych kosztów, podczas gdy Weblogic twoje licencje będą również wymagały aktualizacji.

Bez względu na to, który z nich wybierzesz, będziesz w stanie zbudować swój system bez większych problemów, ale moją preferencją będzie JBoss.

1

JBoss (Red Hat) nie opublikował jeszcze komercyjnie obsługiwanego kontenera zgodnego w 100% z technologią Java EE 5 *. Jest wersja beta JBoss 5. Mam nadzieję, że nie będzie to 3 lata opóźnienia dla Java EE 6. JBoss jest bardziej zainteresowany mikrokontrakterem niż Java EE x, ponieważ właśnie tak ich klienci są bardziej zainteresowani. Nigdy nie spotkałem żadnego z tych klientów. Ale to oznacza, że ​​Java EE jest obywatelem drugiej kategorii w swoim świecie. Dowodem na to, że ich kontenery nie są wysyłane w trybie zgodnym z przepisami; musisz zmodyfikować niektóre pliki konfiguracyjne, aby były zgodne ze specyfikacją.

Gdyby Słońce nie miało pochłonąć czarnej dziury, którą jest Oracle, poleciłbym Glassfish.

  • Red Hat ma obsługiwany komercyjnie 90% pojemnik zgodny z Java EE 5. JBoss 4.3 jest ich "odskocznią" do wersji Java EE 5.
+0

Robert, jBoss ma stabilną 5.x out, czyli [certyfikat Java EE 5] (http://java.sun.com/javaee/overview/compatibility.jsp) –

1

Cóż, polecam użycie Spring + Tomcat i wprowadzę pełny serwer aplikacji JavaEE tylko wtedy, gdy będę musiał.
dotyczące Weblogic i JBoss, wolałbym JBoss, ponieważ Weblogic jest bardziej złożony.

+3

I nie zakochaj się w "Potrzebujemy ESB, bo tak to się robi ". Najpierw wypróbuj proste rozwiązanie. –

+0

Zgadzam się z "bez ESB" i najprostszym. – duffymo

23

I naprawdę jak WebLogic. W tej chwili zawieszę koszt licencji i powiem, że w czasach swojej świetności byli najlepszym serwerem aplikacji Java EE na rynku, bez rąk do pracy. BEA miał wielu niezwykle utalentowanych ludzi rozwijających swój kod i to pokazało. Jeśli pieniądze nie były częścią równania, a ja miałem pracodawcę, który nalegał na wydawanie pieniędzy, które nie były moje, nadal wybrałbym WebLogic zamiast WebSphere, JBOSS, Glassfish lub cokolwiek innego na rynku.

Jestem zasmucony zakupem Oracle. Myślę, że talent zniknął, a Oracle nie ma jasnego pojęcia, co chce zrobić z WebLogic. Utknęli na wersji 10.1 od kilku lat.

<prejudice-ahead> 
Glassfish sounds like it's a much better effort from Sun, but their history says they write great standards and lousy implementations. I don't consider Glassfish to be a viable alternative. 
    </prejudice-ahead> 

WebSphere to typowy projekt IBM: dwukrotnie koszt, pół funkcjonalność, słaba dokumentacja, i trzeba kupić wszystkie swoje bzdury (np Eclipse IDE oparte), aby go używać.

JBOSS nie jest zły, ale tylko dlatego, że różnica w cenie jest tak silna na jego korzyść.

Wolałbym polecić Spring, Tomcat i ActiveMQ jako doskonałą alternatywę. Jeśli EJB są absolutnie wymagane, dodaj OpenEJB do tego miksu.

2018 update: Moje przywiązanie do Java EE jako standardu i jego implementacje serwerów aplikacji ostygły w ciągu ostatnich dziewięciu lat. Myślę, że lepszą odpowiedzią jest Spring Boot. Wdróż plik wykonywalny JAR i nie martw się ponownie o serwer aplikacji Java EE.

+3

Glassfish jest doskonała. Działa bardzo dobrze, stabilnie, szybko, bardzo łatwa w użyciu po wyjęciu z pudełka, dobrze udokumentowana. W szczególności v2.1, v3 jest nadal w fazie rozwoju. –

+1

Historia firmy Sun jest nadal aktualna. Fakt, że Glassfish jest open source uwalnia go od pytań związanych z planami WebLogic i Oracle, ale dopiero okaże się, jaki będzie wskaźnik popularności firm. Podejrzewam, że zobaczysz zwykły wzór: zostanie on przyjęty przez małe firmy, które nie mogą sobie pozwolić na opłaty licencyjne i są pogardzane przez firmy z listy Fortune 500, które wciąż są nieufne z otwartego źródła. – duffymo

3

Osobiście wybrałbym JBoss (wersję społecznościową) na Weblogic (serwer), ponieważ jest bezpłatny (jak na wolności). Ale to nie jest odpowiedź na pytanie, więc ...

widzę dwa główne powody wyboru WebLogic:

  1. WebLogic jest dobrze zintegrowana z jednego mechanizmu konfiguracji/pliku (* Aby łatwiej konfiguruj i utrzymuj).
  2. Integracja z Tuxedo.

*) Termin łatwiejszy jest subiektywny. Większość rzeczy jest łatwa, kiedy wiesz, jak to zrobić.

0

To zależy.

Czy zdarza się, że jesteś w firmie, która lubi kupować wsparcie od innych firm, takich jak "Oracle", i nie dbają o wydatki na pieniądze, o ile są one objęte przez producenta (tak, wiem, że Redhat sprzedaje wsparcie też, ale niektóre firmy nie lubią z nich kupować)

W każdym razie jest to raczej subiektywne pytanie, nie sądzę, że byłaby to poprawna odpowiedź.

6

Jestem zasmucony zakupem Oracle. I Myślę, że talent zniknął, , a Oracle nie ma jasnego pojęcia, co chce zrobić z WebLogic. Oni mają utknęli w wersji 10.1 dla kilku lat.

Jest kilka problemów z powyższym komentarzem. Po pierwsze, Oracle kupił tylko BEA 1,5 roku temu, a nawet wtedy nie była to transakcja zatwierdzona przez DOJ. Ostateczna sprzedaż nie została zatwierdzona przed około 12 miesięcyami.

Po drugie, Oracle dokonało trzech wydań WebLogic od czasu przejęcia. Są teraz w wersji 10.3.1 (lub "11g").

Wreszcie, myślę, że Oracle jest - zaskoczona, że ​​jestem - porusza się w jasnym kierunku. Wraz z niedawnym przejęciem firmy Sun, Oracle jest obecnie głównym dostawcą technologii Java i ma wielu uważanych za wiodący serwer aplikacji Java. Nie zainwestowaliby w te firmy i technologie bez jasnego planu zdominowania rynku. Myślę, że ostatnie ruchy Oracle w środowiskach Java EE 6, WebLogic i JDeveloper pokazują, że bardzo mocno naciskają, aby zostać liderem Java.

Wciąż wolałbym JBoss; to proste i po prostu działa. Mam mnóstwo problemów z konwersją aplikacji Seam 2.x z JBoss na Weblogic, ale mam nadzieję, że w pewnym momencie się uda.

-5

IBM wydało wersję beta Java EE 6 na wersję BETA. Tak więc w przypadku Java EE 6 myślę, że IBM będzie liderem. Również JBoss jest dobrym serwerem, ale pod dużym obciążeniem moje doświadczenie pokazuje, że nie jest on w pełni niezawodny w porównaniu do WebLogic i WebSphere.

3

Pracowałem nad jboss przez rok, a na blogu od ponad roku, moje doświadczenie z logiką sieciową jest dobre w porównaniu do jboss, ponieważ weblogic jest bardziej stabilny i solidny, może obsłużyć ponad 3000 równoczesnych żądań bez rzucając jeden wyjątek tam, gdzie jboss tego nie zrobił, a konsola administratora dla weblogic jest znakomita, ale myślę, że weblogic jest bardziej skomplikowany niż jboss. Jeśli chodzi o inwestowanie pieniędzy na serwerze aplikacji, moim wyborem będzie na pewno weblogic.

1

Opracowałem aplikację Java dla JBoss 4.x i 5.x na dwa lata. Potem musiałem pracować z Weblogic 11. Nie było łatwo zmienić zdanie, ale teraz myślę, że WL znacznie lepiej. Bardziej stabilny, szybszy i Konsola administracyjna ... jak marzenie. Bardzo łatwe do zrobienia ustawienia i monitorowanie.

Mój wybór brzmi Weblogic.

1

Myślę, że powinniście rozważyć TC Server, który jest wariantem Tomcata od Vmware. Może być dobry w środowisku korporacyjnym, ponieważ większość z nich powinna być w stanie to wypracować, jako część ofert wirtualizacji.

http://www.vmware.com/products/vfabric-tcserver/

PS - I stosuje WLS w szerokim zakresie. Dla niektórych aplikacji może być dobry. Dla niektórych naprawdę tego nie potrzebujesz. Tak więc jest on bardzo napędzany przez przypadek użycia, skalę itp.

3

Zrobiłem 3 oceny WebLogic, JBoss i WebSphere. WebLogic wygrał każdy z nich, z rękami w dół. Powiedziawszy to, moje uproszczone wskazówki są następujące: użyj JBoss, jeśli nie martwisz się skalowaniem kilku tysięcy równoczesnych użytkowników. Jeśli jednak zamierzasz skalowad dalej, będziesz potrzebował czegoś o sprawdzonej mocy i solidności - to WebLogic.

Uwaga: dostawcy serwerów aplikacji zwykle poświęcają funkcje techniczne pod kątem stabilności. Innymi słowy, wytrzymałość jest w dynamicznym napięciu z cechami technicznymi. Jeśli chcesz nowe funkcje, wraz z nim otrzymasz więcej błędów. Zaskakuje mnie, jak wielu techników tego nie rozumie. Ale jeśli zastanowisz się, dlaczego nie rzucasz się i kupujesz pierwszą, nową wersję systemu operacyjnego Windows, zrozumiesz, dlaczego tak się dzieje.

HTH

1

Trzeba rozważyć TCO całkowity koszt posiadania

trzeba wziąć pod uwagę tych kosztów przy użyciu JBoss:

  • roczne subskrypcje wsparcia
  • Wyższe bieżące koszty zarządzania i administracji
  • Wpływ przerw na koszty
  • Wpływ wydajności produktu na koszt
  • Wyższy koszt testów interoperacyjności i integracji odmiennego OSS projektów
  • złożoność i koszt wspieranie zintegrowanego rozwiązania OSS
  • Polisa ubezpieczeniowa o ochronę od odpowiedzialności cywilnej
  • Koszt wspieranie i utrzymanie zmodyfikowany kod
  • Dodatkowy czas i trud pracy z wieloma licencjami open source