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

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

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



답변

지난 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을 권장하지 않습니다.


답변

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


답변

내가 일반적으로 묻는 첫 번째 질문은 “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 파일을 다른 곳으로 변경하지 않으면 서버를 다시 시작할 필요가 거의 없습니다.


답변

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

jBoss의 인수 :

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

jBoss에 대한 인수 :

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

답변

Checkout GlassFish 3.1! 모듈 식 Java EE 6 기반 GlassFish v3 커널 위에 구축 된 버전 3.1은 클러스터링, 중앙 집중식 관리 및 고 가용성을 제공합니다.

자세한 내용은 http://blogs.oracle.com/nazrul/entry/glassfish_3_1 을 참조하십시오.


답변

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

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

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

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


답변

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

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

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