sourcecode

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

copyscript 2022. 11. 7. 22:41
반응형

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

오늘 약 1년 후에 완료되는 새로운 Java EE 프로젝트를 시작했다면 어떤 애플리케이션 서버를 선택하시겠습니까? 그 이유는 무엇입니까?

답변의 일부는 결정에 대한 주장을 포함해야 합니다.또한 선택한 Java EE 서버와 시장에서 사용 가능한 다른 서버에 대한 경험이 얼마나 되는지도 확인할 수 있습니다.당신의 답변에 대한 조사와 생각을 모두 알고 있기 때문에 이러한 것들은 흥미롭습니다.

지난 10년 이상 WebLogic, WebSphere, JBoss, GlassFish, 수지, Jetty, Tomcat 등을 사용해 왔습니다.그래서 만약 제가 새로운 프로젝트를 고려한다면, 저는 제 자신에게 먼저 몇 가지 질문을 할 것입니다.내가 더 이상 의심하지 않을 한 가지는 내가 엄마를 위해 울 때까지 고문을 당하지 않는 한 JSP를 사용하는 것을 단호히 거부한다는 것이다.

다른 사람의 지시로 인해 특정 제품에 대한 호환성/도입이 필요합니까?그들을 무시하거나 달리 설득할 방법이 없나요?그렇다면, 정답이 여기 있습니다.

EJB를 사용해야 하나요?정말?가능한 한 사용하지 마십시오. 실제로 필요한 것은 매우 큰 엔터프라이즈급 시스템뿐입니다.이 툴은 단순한 툴에 불과하며, 그 점에서 큰 툴입니다(누구나 골든 슬레지 해머라고 말할 수 있습니다).그것들은 너무 많이 사용되고 있기 때문에 정말로 필요한지에 대해 의문을 제기합니다.만약 필요하다면, 내가 좋아하는 제티도 포함해서 몇 가지 선택사항이 사라집니다.

JMS, ESB 등 다른 주요 J2EE 기술을 사용해야 합니까?만약 그렇다면, 그리고 정말 없으면 안 된다면, 당신은 다시 완전한 J2EE 컨테이너에 갇히게 될 것입니다.예를 들어, BPM에 전념하기 전에 신중하게 생각하고 조사하십시오.그리고 AquaLogic BPM은 (거의) 모든 비용을 들여 피해야 합니다.극히 추악합니다.

완전한 J2EE 컨테이너를 사용해야 하는 경우에는 보다 견고하고 지원성이 뛰어나며 비용 효율이 높기 때문에 먼저 오픈 소스를 고려하십시오.고객층이 넓어지고, 보다 개방적인 서포트의 교환이 가능하기 때문에, 보다 신속한 수정이 가능하게 되는 경향이 있습니다.그러나 레진은 미숙하기 때문에 GlassFish나 JBoss에 비해 도입과 지원에 문제가 있다고 생각합니다.JBoss는 고객층이 넓거나 성숙도가 높기 때문에 저는 JBoss를 선호합니다.GlassFish는 자동화된 빌드/도입 프로세스에 통합하기가 더 어렵지만 특정 기능(필요한 경우)에 대해서는 더 좋을 수 있습니다.

Apache가 필요한 특별한 이유가 있나요?그리고 Tomcat에 기대어, 아마 뭔가 더 있을 거야.

서블릿만으로 먹고 살 수 있나요?그리고 Jetty를 사용합니다.이 솔루션은 가장 가볍고, 빠르고, 쉽고, 유연한 솔루션입니다.만약 내가 Jetty를 사용할 수 없다면, 나는 그 이유에 대한 나의 모든 추측에 의문을 제기할 것이다.YAGNI가 적용됩니다.

가장 좋은 방법은 Jetty에서 String Template/Web String Template를 사용하는 것입니다.이는 라이센스 비용, 확실한 평판 및 지원 등을 필요로 하지 않고 깨끗하고 견고하며 빠르고 유지보수가 가능한 솔루션입니다.그게 요즘 내가 시작하는 부분이야.

대부분의 애플리케이션/시스템은 서블릿과 제대로 된 아키텍처/설계를 갖춘 JDBC만 있으면 되는 경우 화려한 J2EE 기능을 많이 선택합니다.왜 더 필요하다고 생각하는지 물어보세요.

본격적인 컨테이너 중 귀하가 MAJOR 공개 웹 사이트를 지원하지 않는 한 WebLogic과 WebSphere는 사용하지 않을 것입니다(현재 고용주의 웹 사이트는 WebLogic에 구축되어 있으며 월 1,100만 이상의 조회수를 기록하고 있습니다).WebLogic의 가장 큰 장점은 클러스터링이 비교적 간단하다는 것입니다.단, 독자적인 벤더 록인 기능은 거의 모든 비용을 들여 회피할 수 있습니다.WebSphere는 말 그대로 어떤 대가를 치르더라도 피할 수 있는 악몽입니다. 과거에 WebSphere와 관련된 프로젝트는 몇 번 해본 적이 있지만 거절합니다.독자 사양의 기능을 사용하는 특별한 요구가 없는 한, 어느 제품도 고액의 라이센스 요금을 지불할 가치가 없습니다.Fortune 500대 기업의 시니어 아키텍트/엔지니어로서 10년 동안, 저는 이러한 요구를 본 적이 없습니다.한편, 그러한 독점 제품을 선택하는 것에 대해 많은 고통을 경험해 왔습니다.

매우 크고, 트래픽이 많은 공개 웹사이트에서도, 독점 제품들은 여전히 의문입니다.심플한 scalability 솔루션에 대처하기 위해서, 몇개의 뛰어난 컨설턴트가 제공하는 뛰어난 하드웨어와 귀중한 시간을 라이센스 비용으로 연간 수백만달러를 소비하고 싶다고 생각하고 있습니다.연간 수백만 달러는 그 멋진 웹사이트에서 팔 만한 것을 만드는 데 사용될 수 있다.

편집: 고려해야 할 또 다른 요소...

나는 최근에 테라코타를 만났다.모든 것을 재고하고 있으며, 조만간 중요한 시스템에 도입할 예정입니다.특히 Teracotta는 무엇보다 클러스터링을 잘하므로 더 이상 클러스터링을 위해 WebLogic을 권장하지 않습니다.

"응용 프로그램 서버"라는 용어는 모호합니다.GlassFish v3에서는 예를 들어 기존의 웹 컨테이너를 작게 시작하여 OSGi 및 간단한 "컨테이너 추가" 기능을 사용하여 JPA, JAX-RS, EJB, JTA, JMS, ESB 등 원하는 것을 추가할 수 있습니다.다만, 같은 제품, 같은 관리 인터페이스 등입니다.어플리케이션 서버로서의 자격이 있습니까? - Alexis (Sun)

첫 번째 질문은 "Tomcat으로 할 수 있나요?"입니다.JMS 또는 JTA가 필요하기 때문에 아니라고 대답할 경우 응용 프로그램서버에 의존합니다.

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

지난 2년 동안 저는 WebSphere와 함께 일했습니다.IBM과 협상할 때마다 WebLogic의 두 배에 달하는 비용이 들었지만 기업 정책에 따라 WebSphere를 사용해야 했습니다.WebSphere의 학습 곡선이 WebLogic보다 상당히 가파르고, 개발 환경에서 Tomcat을 사용할 정도로 빌드/도입/테스트 수명 주기가 매우 시간이 많이 소요되었습니다.그러나 WebSphere에서 발생한 가장 큰 문제는 다음 패치 릴리스로 업그레이드해야 하는 버그가 발견되었을 때 web.xml을 구문 분석하는 데 새로운 문제가 발생했다는 것입니다.48시간 교대 근무로 그 모든 걸 끝냈죠

At the moment though I am using JBoss. About 3 months ago I was about to embark on my new project with Tomcat and Jetspeed 2, But I noticed that Jetspeed 2 seems a bit stagnant right now and JBoss Portal 2.7.0 was just released with JSR 286/Portlet 2.0 support. I gave JBoss a spin and found it very easy to set-up and administer. The build/deploy/test cycle is very quick and I rarely have to restart the server unless I have changed a Spring XML file somewhere.

I've been using jBoss for 3-4 years.

Arguments for jBoss:

  1. Open source.
  2. Commercial support available.
  3. Large, active user community.

Arguments against jBoss:

  1. No general-access, supported Java EE 5 container release.
  2. Lots of documentation but verbose; can be hard to find the answers to "How do I do x?"
  3. Administrative tools for 4.x poor compared to other commercial offerings.

Checkout GlassFish 3.1! Built on top of the modular, Java EE 6 based GlassFish v3 kernel, version 3.1 delivers clustering, centralized administration and high availability.

Refer to http://blogs.oracle.com/nazrul/entry/glassfish_3_1 for more details.

Another point that was not discussed here is performance. If this is a concern because of the type of service or because of the number of users, then the following will be applicable:

  • Tomcat seems to be slower than Glassfish
  • Glassfish seems to be slower than Resin
  • Resin is much slower than G-WAN + Java

Note that G-WAN relies on the JVM alone: it does not use any further containers (unless specified explicitly) so you might reserve it to performance-critical portions of your web applications.

As G-WAN supports other languages (C, C++, C#, D, Objective-C), you may even process some parts of the applications in raw C while keeping Java for other tasks.

I might include your preferred OS as a decision criteria. It should make it easier to support if you are using the same vendor for OS and app server. If you already have a relationship with one or both vendors consider if they are good to deal with.

From a technical perspective I would choose GlassFish because it has support for more recent innovations. I do not think JBoss is bad in anyway it simply isn't as up-to-date.

Most of my experience is on WebLogic but I have used JBoss and GlassFish. I just released a new site on a complete Sun open source stack (OpenSolaris, GlassFish, MySQL) and it was a great experience with only minor frustrations.

I still think that WebLogic is the best Java EE app server on the market. I think it's worth it if you can afford those license fees.

I've been surprised to see how far you can go by combining Tomcat, OpenEJB, and ActiveMQ. That would seem to me to be a low-cost alternative.

I'd also look into the Spring dm Server. It's based on Tomcat, but I think the OSGi piece they've added in could be everywhere in short order. If it's done with the same quality as the Spring framework, it'll be very good indeed.

An alternative: use no appserver at all.

Check out http://www.atomikos.com/Publications/J2eeWithoutApplicationServer.

For web projects, keep a light web container if you have to, combined with something like Wicket to avoid the complexity of JSP/JSF or struts.

HTH Guy

ReferenceURL : https://stackoverflow.com/questions/277543/would-you-at-present-date-use-jboss-or-glassfish-or-another-as-java-ee-serve

반응형