현재 새 프로젝트를 위해 JBoss 또는 Glassfish (또는 다른)를 Java EE 서버로 사용 하시겠습니까? [닫은]


136

약 1 년 안에 완료 될 새로운 Java EE 프로젝트를 오늘 시작했다면 어떤 응용 프로그램 서버를 선택하고 그 이유는 무엇입니까?

답의 일부에는 결정에 대한 주장이 포함되어야합니다. 또한 선택한 Java EE 서버와 시중의 다른 사용 가능한 서버에 대한 경험이 어느 정도입니까? 우리 모두가 당신의 대답에 넣은 조사와 생각에 대한 감각을 얻음으로써 이것들은 흥미 롭습니다.

답변:


181

지난 10 년 이상 WebLogic, WebSphere, JBoss, GlassFish, Resin, Jetty, Tomcat 등을 사용했습니다. 따라서 새로운 프로젝트를 고려하고 있다면 먼저 몇 가지 질문을하겠습니다. 더 이상 의문의 여지가없는 한 가지는 엄마를 위해 울부 짖을 때까지 고문을받지 않으면 JSP 사용을 거부 할 것입니다.

누군가의 의무 때문에 특정 제품과 호환 / 배포해야합니까? 그들을 무시하거나 다른 방법으로 설득 할 방법이 없습니까? 그렇다면 대답이 있습니다.

EJB를 사용해야합니까? 정말? 가능하면 피하십시오. 그들은 매우 큰 엔터프라이즈 급 시스템에만 필요합니다. 그것들은 단지 도구 일 뿐이고 그에 대한 큰 도구 일뿐입니다 (누구든지 "Golden Sledgehammer"라고 말할 수 있습니까?). 그것들은 지나치게 과도하게 사용되므로 실제로 필요한지 여부에 의문을 갖습니다. 필요한 경우 내가 좋아하는 Jetty를 포함한 여러 옵션을 제거합니다.

JMS, ESB 등과 같은 다른 주요 J2EE 기술을 사용해야합니까? 그렇다면 실제로는 할 수 없으면 완전한 J2EE 컨테이너로 다시 제한됩니다. 예를 들어, BPM에 투입하기 전에 신중하게 생각하고 조사하고 거의 모든 비용으로 AquaLogic BPM을 피하십시오.

본격적인 J2EE 컨테이너를 실제로 사용해야하는 경우에는 오픈 소스가 더 강력하고, 더 잘 지원되며, 비용 효율적이므로 먼저 오픈 소스를 고려하십시오. 그들은 더 큰 고객 기반과 더 많은 오픈 지원 상호 작용을 가지고 있으므로 더 나은 수정을 더 빨리 얻는 경향이 있습니다. 그러나 Resin은 미숙하고 GlassFish 또는 JBoss와 관련하여 피할 것입니다. 더 넓은 고객 기반, 성숙도 등으로 인해 JBoss를 선호합니다. GlassFish는 자동화 된 빌드 / 배치 프로세스에 통합하기가 더 어렵지만 특정 기능 (필요한 경우)에 대해서는 더 나을 수 있습니다.

Apache가 필요한 특별한 이유가 있습니까? 그런 다음 Tomcat을 기대하십시오.

서블릿으로 만 할 수 있습니까? 그런 다음 Jetty를 사용합니다. 가장 가볍고, 빠르고, 가장 쉽고, 가장 유연한 솔루션입니다. Jetty를 사용할 수없는 것에 대해 기대가된다면 그 이유에 대한 모든 가정에 의문을 갖습니다. YAGNI가 적용됩니다.

Jetty에서 StringTemplate / WebStringTemplate을 사용하는 것이 가장 좋습니다. 라이센스 비용, 견실 한 평판 및 지원 등이없는 깨끗하고 강력하며 빠르고 유지 보수가 쉬운 솔루션입니다.

대부분의 애플리케이션 / 시스템은 실제로 필요한 것은 서블릿과 적절한 아키텍처 / 디자인을 가진 JDBC이면 많은 멋진 J2EE 기능을 선택합니다. 왜 더 필요하다고 생각 하냐

본격적인 컨테이너 중에서 MAJOR 공개 웹 사이트를 지원하지 않는 한 WebLogic 및 WebSphere를 사용하지 않을 것입니다. 현재 현재 고용주의 웹 사이트가 WebLogic에 배포되어 있으며 매월 11 백만 백만 건의 방문이 발생합니다. WebLogic의 진정한 명성은 상대적으로 쉬운 클러스터링이지만, 거의 모든 비용으로 독점 벤더 잠금 기능을 피하십시오. WebSphere는 단순히 문자 그대로 모든 비용을 피하는 악몽입니다. ​​나는 과거에 부부를 한 후에 WebSphere와 관련된 프로젝트를 거부합니다. 독점 기능을 사용하는 특별한 요구가 없다면, 어느 제품도 막대한 라이센스 비용이 들지 않습니다. 많은 Fortune 500 대 기업의 수석 아키텍트 / 엔지니어로 10 년 동안 나는 아직 그러한 요구를 보지 못했습니다. 반면에

트래픽이 많고 트래픽이 많은 공개 웹 사이트의 경우에도 독점 제품은 여전히 ​​의문입니다. 차라리 간단한 확장 성 솔루션을 해결하기 위해 소수의 정말 좋은 컨설턴트가 제공하는 좋은 하드웨어 및 품질 시간에 연간 수백만 달러의 라이센스 비용을 지출하고 싶습니다. 그런 다음 연간 추가 수백만 달러를 사용하여 멋진 웹 사이트에서 판매 할 가치가있는 것을 생산할 수 있습니다.

편집 : 고려해야 할 또 다른 조각 ...

나는 최근에 테라코타를 만났다 . 모든 것을 다시 생각하고 곧 중요한 시스템에 배포하려고합니다. 특히, Terracotta는 다른 것보다 더 나은 클러스터링을 수행하므로 더 이상 클러스터링에 WebLogic을 권장하지 않습니다.


7
나중에 참조 할 수 있도록 일반적으로 Google 또는 Wikipedia 검색을 통해 두문자어에 대한 정의를 찾을 수 있습니다. YAGNI = 당신은 그것을 필요로하지 않을 것입니다 = 설계를 과도하게하지 말라 JMS = 자바 메시지 서비스 ESB = 엔터프라이즈 서비스 버스 BPM = 비즈니스 프로세스 관리
Rob Williams

21
Java EE 및 EJB에 대한 귀하의 의견은 약간 구식입니다. J2EE ?! 그것은 5 년 전과 같았습니다. Java EE 6을 살펴보고 관점을 현대화하십시오!
Brian Leathem

6
@ Brian : Brian, 특히 EJBLite에 동의합니다. 무게가 훨씬 가벼워졌습니다.
Thang Pham

7
@Brian, 게시물을보십시오- 귀하의 의견 3 년 전에 작성 되었습니다 . 그리고 Spring은 심지어 얇아진 Java EE보다 가볍습니다.
duffymo 2016 년

2
2012 년의 평결은 무엇입니까? JBoss 7 AS는 Java 6 EE 영역에서 Glassfish를 왕위에두고 있습니까? 아니면 다른 방법?
Rolando

10

"응용 프로그램 서버"라는 용어는 모호합니다. GlassFish v3을 사용하면 전통적인 웹 컨테이너로 작게 시작하고 (OSGi 및 간단한 "컨테이너 추가"기능을 사용하여) JPA, JAX-RS, EJB, JTA, JMS, ESB 등 원하는 것을 추가 할 수 있습니다. 등 ... 그러나 동일한 제품, 동일한 관리 인터페이스 등입니다. 이것이 귀하에게 응용 프로그램 서버로 인정됩니까? -알렉시스 (일)


1
불행히도 Glassfish는 더 이상 공식 제품이 아니라 참조 구현을 "단지"합니다.
Thorbjørn Ravn Andersen 2016

9

내가 일반적으로 묻는 첫 번째 질문은 "Tomcat으로이 작업을 수행 할 수 있습니까?"입니다. JMS 또는 JTA가 필요하기 때문에 대답이 '아니요'인 경우 응용 프로그램 서버를 사용합니다.

약 3 년 전에 WebLogic 8의 사용 편의성 및 라이센스 / 비용 모델에 만족 한 WebLogic 8을 사용했습니다. 하나는 웹 서비스이고 다른 하나는 포털이었습니다. 해당 프로젝트 중 하나에서 WebLogic 또는 WebLogic Portal에 문제가 발생하지 않았습니다.

지난 2 년 동안 저는 WebSphere와 협력하고있었습니다. IBM과 협상 할 때마다 항상 WebLogic에 상응하는 비용의 두 배에 달하는 비용이 들었지만 회사 정책에 따라 WebSphere를 사용해야했습니다. WebSphere의 학습 곡선이 WebLogic보다 상당히 가파른 것으로 나타 났으며 빌드 / 배포 / 테스트 수명주기는 시간이 많이 걸리므로 개발 환경에서 Tomcat을 사용했습니다. 그러나 WebSphere에서 가장 큰 문제는 web.xml을 파싱하는 새로운 문제가 발생하도록 다음 패치 릴리스로 업그레이드해야하는 버그가 발생했을 때였습니다. 모든 작업을 수행하는 데 48 시간이 걸렸습니다.

지금은 JBoss를 사용하고 있습니다. 약 3 개월 전에 Tomcat 및 Jetspeed 2로 새 프로젝트를 시작하려고했지만 Jetspeed 2가 약간 정체 된 것으로 나타 났으며 JBoss Portal 2.7.0이 JSR 286 / Portlet 2.0 지원으로 출시되었습니다. JBoss에 스핀을 제공하고 설정 및 관리가 매우 쉽다는 것을 알았습니다. 빌드 / 배포 / 테스트주기는 매우 빠르며 Spring XML 파일을 다른 곳으로 변경하지 않으면 서버를 다시 시작할 필요가 거의 없습니다.


좋은 대답입니다! Jetty를 사용해 보셨습니까? 당신이 가진 경우에 대한 당신의 의견은 무엇입니까?

7

3-4 년 동안 jBoss를 사용해 왔습니다.

jBoss의 인수 :

  1. 오픈 소스.
  2. 상업적 지원이 가능합니다.
  3. 크고 활동적인 사용자 커뮤니티.

jBoss에 대한 인수 :

  1. 일반 액세스, 지원되는 Java EE 5 컨테이너 릴리스가 없습니다.
  2. 많은 문서가 있지만 장황하다. "x를 어떻게합니까?"에 대한 답변을 찾기가 어려울 수 있습니다.
  3. 4.x의 관리 도구는 다른 상업용 제품과 비교할 때 좋지 않습니다.

"일반 액세스가 지원되지 않는 JEE 5 컨테이너 릴리스가 지원되지 않습니다." 더 이상 사실이 아닌 것 같습니다. 맞습니까?
Raedwald

@Raedwald : 예, 지금 JEE 6 시간 동안 주변되었습니다 것을 ;-)
ymajoros


3

여기서 논의되지 않은 또 다른 요점은 성능입니다. 서비스 유형 또는 사용자 수로 인해 이것이 우려되는 경우 다음이 적용됩니다.

  • Tomcat은 Glassfish보다 느린 것 같습니다
  • Glassfish는 수지보다 느린 것 같습니다
  • 수지는 G-WAN + Java보다 훨씬 느립니다.

G-WAN은 JVM에만 의존합니다. 명시 적으로 지정하지 않는 한 더 이상 컨테이너를 사용하지 않으므로 웹 응용 프로그램의 성능에 중요한 부분을 예약 할 수 있습니다.

G-WAN은 다른 언어 (C, C ++, C #, D, Objective-C)를 지원하므로 다른 작업을 위해 Java를 유지하면서 응용 프로그램의 일부를 원시 C로 처리 할 수도 있습니다.


2

선호하는 OS를 결정 기준으로 포함시킬 수 있습니다. OS 및 앱 서버에 동일한 공급 업체를 사용하는 경우보다 쉽게 ​​지원할 수 있습니다. 이미 한 공급 업체 또는 두 공급 업체와 관계가있는 경우 처리하기에 적합한 지 고려하십시오.

기술적 관점에서 GlassFish는 최신 혁신을 지원하기 때문에 선택합니다. 어쨌든 JBoss가 나쁘지 않다고 생각합니다.

내 경험의 대부분은 WebLogic에 관한 것이지만 JBoss와 GlassFish를 사용했습니다. 방금 완전한 Sun 오픈 소스 스택 (OpenSolaris, GlassFish, MySQL)에서 새 사이트를 출시했으며 약간의 좌절감만으로도 훌륭한 경험이었습니다.


매우 특정한 바이너리 의존성을 가지지 않는 한 OS는 실제로 문제가되지 않습니다 (대부분의 Java 프로젝트에는 해당되지 않아야 함). Windows, 32 및 64 비트에서 개발하고 Solaris의 Glassfish에 배포합니다. 대부분의 개발자는 실제로 알지 못하고 신경 쓸 필요가 없습니다. 사용자는 그것을 보지 못합니다 (대부분의 개발은 웹 응용 프로그램입니다).
ymajoros

2

나는 여전히 WebLogic이 시장에서 가장 좋은 Java EE 앱 서버라고 생각합니다. 라이센스 비용을 감당할 수 있다면 그만한 가치가 있다고 생각합니다.

Tomcat, OpenEJB 및 ActiveMQ를 결합하여 얼마나 멀리 갈 수 있는지 놀랐습니다. 저에게 저비용 대안이 될 것 같습니다.

Spring dm Server도 살펴 보았습니다. Tomcat을 기반으로하지만 OSGi가 추가 한 OSGi 조각은 짧은 순서로 어디에나있을 수 있다고 생각합니다. Spring 프레임 워크와 동일한 품질로 수행되면 실제로 매우 좋습니다.


2
내가 WebLogic에 가지고있는 문제는 공급 업체가 잠겨 있다는 것입니다.
Manius

1
WebLogic뿐만 아니라 내가 아는 모든 Java EE 공급 업체에서도 마찬가지입니다. 공급 업체별 기능을 사용하는 경우 잠겨 있습니다. 언젠가 코드를 작성해야합니다.
duffymo

3
WebLogic은 상업적 용도로만 사용됩니다. 일단 큰 체크를 작성하면 오픈 소스 대안을 사용하는 것보다 훨씬 더 "고정"됩니다. 플랫폼 독립성에 관심이 있다면 공급 업체별 기능을 사용하지 않을 것이므로 이것이 내가 말하는 것이 아닙니다. 실제로 한 번 읽은 설문 조사에 따르면 개발자는 피해야 할 공급 업체 잠금이 오픈 소스의 가장 큰 장점이라고 생각합니다 (비용 아님).
Manius

말도 안되는? 공급 업체와 수백만 달러 계약을 체결 해도 문제가되지 않는다고 생각하십니까? 증거가 있습니다.
duffymo 2016 년

@ymajoros "공급 업체를 잠그지 않아야 함"을 의미 했습니까? 솔직히, 나는 당신의 의견을 이해할 수 없습니다.
Patrick M

1

대안 : 응용 프로그램을 전혀 사용하지 마십시오.

체크 아웃 http://www.atomikos.com/Publications/J2eeWithoutApplicationServer .

웹 프로젝트의 경우 JSP / JSF 또는 스트럿의 복잡성을 피하기 위해 Wicket과 같은 가벼운 웹 컨테이너를 유지해야합니다.

HTH Guy


도구를 사용하여 배우고 싶지 않으면 아무 것도 사용하지 마십시오. 또는 숙련 된 전문가가되어 환경에 투자하면 보상을받을 수 있습니다. 일부 프로젝트에서는 그렇게했음을 인정해야합니다. 동일한 프로젝트는 애플리케이션 서버, Spring의 사용자 정의 클라이언트 서버, 순수 Java EE 및 Glassfish로 진화하지 않았습니다. 다시 돌아가고 싶지는 않지만 첫 번째 솔루션은 실제로 너무 복잡하여 오늘날처럼 간단합니다 (표준은 많은 변경없이 모든 Java EE 앱 서버에 배포 할 것입니다).
ymajoros

좋은 대답, 문서를 얻는 나쁜 방법
msangel
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.