스프링 대 Jboss

Question

엔터프라이즈 웹 애플리케이션에서 Spring 대 Jboss의 장점과 단점은 무엇입니까?

Answer 1

이미 말했듯이, 요점을 다시 알려 드리겠습니다. JBoss는 애플리케이션 서버입니다. 일부 Java 응용 프로그램 서버는

• 스피어
• 글래스 피시
• 보스

스프링 프레임 워크입니다 포함되어 있습니다. 꽤 많은 것을 제공하는 다소 큰 프레임 워크이지만 나에게있어 주요 기능 중 하나는 MVC이다. MVC는 Contoller에서 모델을 뷰와 분리하는 디자인 패턴입니다. 모델은 데이터의 표현입니다. 이것은 데이터베이스 나 XML 파일과 같은 것들에 의해 뒷받침 될 수 있습니다. 뷰는 모델을 보는 데 사용되는 뷰입니다. 이것은 웹 프론트 엔드이거나 윈도우 애플리케이션 일 수 있습니다. 사용자가보기와 상호 작용합니다. 사용자는 업데이트 할 모델에 대한 열망을 표현합니다. 이것은 컨트롤러가 들어오는 곳입니다. 우리는 컨트롤러에 업데이트 할 모델을 알려줍니다. 뷰가 모델을 기반으로하므로 뷰가 업데이트됩니다. 이것은 간단하게 끝났지 만 요컨대. 당신이 볼 수있는 다른 MVC 프레임 워크는 Struts입니다. 앞서 말했듯이

봄이 좋은 질문입니다 같은

• 보안 프레임 워크 제어
• 의존성 삽입 (Dependency Injection)

Answer 2

JBoss는 컨테이너이고, 스프링은 컨테이너 내부에서 실행됩니다. 사과와 오렌지를 비교하고 있습니다.

Answer 3

여기에 제 의견입니다 :

봄은 모든 자바 EE에 좋은 대표, 제이 보스는 모든 것을 나쁜 나타내는 반면.

음 ... 그게 그렇게 잘되지 않았다. (나는 그렇게 생각하지 않았다). JBoss가 어떤 애플리케이션을 호스트하도록 결코 선택하지 않을 것이라고 말하고 있습니다. 그것은 너무 clunky와 헤비급이고, 특히 잘하지 않습니다. 나는 그것이 모 놀리 식하고 clunky 덜 느끼기 때문에 봄 좋아. 물론 Spring은 애플리케이션 컨테이너가 아니지만 애플리케이션을 호스팅하는 데 필요한 대부분의 인프라를 구축하는 데 사용할 수 있습니다. 컨테이너에 연결하기 만하면 나머지는 Spring에서 처리합니다.

Answer 4

의

반전으로 제공하는 다른 기능이 있습니다. 몇몇은 여기가 사과와 오렌지의 비교라는 Jboss가 컨테이너라는 것을 잘못 설명했다. Spring은 단순히 Struts와 같은 프레임 워크 일 뿐이다. 그러나 이것이 다소 혼란스러운 이유는 JBoss와 Spring 모두 원래의 단순한 기원으로부터 상당히 확장되어 서로를 향해 더 가까워지고 있기 때문입니다. JBoss를 이해하는 쉬운 방법 중 하나는 이름이 원래 "EJBoss"였고 오픈 소스 J2EE 어플리케이션 서버를위한 것이므로 EJB 컨테이너 역할을하는 Tomcat보다 이점이있어 WebSphere와 경쟁 할 수있었습니다 및 기타 독점적 인 응용 프로그램 서버.

그리고 Spring은 IoC 프레임 워크 (현재는 "Dependency Injection"이라고 함)입니다. 본질적으로 객체의 팩토리이므로 더 "느슨하게 결합 된"설계를 따를 수 있습니다.

그러나 인기가 높아지면서 두 제품이 모두 확장되었습니다.예를 들어, JBoss는 지금은 자신의 IoC 컨테이너의가 있습니다 제이보스 마이크로 컨테이너 : JBoss IoC

보스라는 자신의 경량 IoC 컨테이너를 제공합니다. JBoss Microcontainer는 컨트롤/종속성 주입 컨테이너의 가벼운 반전으로서 Spring과 개념이 비슷합니다. Pico Container 및 Plexus.

그리고 봄이 완벽하게 실행할 수있는 반면, 공존 (대부분) 행복하게 보스와, 그것은 본격적인 EJB 컨테이너를 필요로하지 않는다, 그것은 바람둥이에 쉽게 실행할 수 있습니다

. Spring의 전체 설계 목표는 POJO의 사용과 EJB에 매우 반대되는 중량 컨테이너를 필요로하지 않기 때문에 경량 설계와 POJO의 사용이라는 아이디어에 기반을 두었습니다.

Rod Johnson

당신이 보스에서 봄을 실행할 수없는 이유가 없다는 것을 지적했습니다

봄이 (또는 애플리케이션 서버 외부) 모든 응용 프로그램 서버에서 작동하도록 설계가; Spring을 사용한다고해서 서버가 제공 할 수도있는 것을 무시하는 것은 아닙니다. 사례가 많아서 선택의 폭이 넓어집니다.

그렇다면 두 시스템의 어떤 부분을 사용하고 어떤 Java 표준을 고수해야하는지 결정해야합니다. 이 기사에 따르면, 표준에 얼마나 잘 부합하는지 커버하는 JBoss and Spring에 따르면, 어떤 기술을 선택 하느냐에 따라, 당신은 편견을 뽑고 있습니다. 이것은 꽤 논쟁의 여지가있는 전투 인 것 같습니다. 다음에 오는 어떤

은 제이보스와 스프링 소스 툴에 통합 XML에서 모든 것을 이상 전투 결국 가상화, 자체 .... 그 건강한 경쟁,

[싹둑로, 긴장 ​​완화 아무것도하지만입니다 ]

시간 만이 말해 줄 것이다, 그러나 나는이 전투는 것을 개발자를위한 더 나은 아니라 닷넷보다 더 많은 선택, 그리고 자바의 주위에 더 혁신을 수 있다고 생각, 그것은 보스 힘든 테스트 할 수 있지만, 하나의 합니다 그들이 처리 할 수있는 실행이 완벽하다면 그렇지 않다면 스프링 소스가 지각과 실질적인 이점 사이의 쐐기를 움직여야한다. of JEE 6 ... 애플리케이션의 이식성은 늦어도 이식성이 떨어진다. 독점 모델에 대응하기 위해서는 을 시연해야한다. , 그 일이되지 않은, 다양한 자바 표준 준수에 더 최신의보기를 들어

는이 request for feedback on Spring 5 찾아 가라. Spring 디자이너가 당면한 제약에 대한 아이디어를 얻을 수 있으며, Spring 시장에서 Spring이 다양한 EE 서버를 지원하도록하는 것이 중요하다는 사실을 강조 할 수 있습니다.

EE를 부드럽게 업그레이드하려고합니다. 기준선도.우리가 효과적으로 여기에 개별 요구 사항이 있기 때문에 지금, 이것은 조금 까다 롭습니다 - 및 을 우리가 생산 환경를 기업의 채용 수준을 고려해야합니다

우리는 확실히 우리의 현재에서 (3.0 서블릿 올릴 수 있습니다 Servlet 2.5 런타임 호환성). 스프링 5 응용 프로그램을 EE 6 기준선 서버에서 계속 실행하고 싶습니다. Java EE 7의 시장 상황이 이고 서블릿 3.0 API를 기반으로하는 서버가 많기 때문에 블로그 게시물을 참조하십시오. [snip] 2002 년 JMS 1.1 API를 계속 지원해야하는 수치는 입니다. 우리는 이 JPA 2.1+ 및 Bean Validation 1.1+를 제안하지만 우리의 손은 이 될 것 같습니다 : TomEE 1.7 JBoss EAP 6.4에는 하드 JPA 2.0과 Bean Validation 1.0 API가 있고 WebLogic 12.1.3에는 JPA 2.1이 있지만 Bean Validation 1.1 API는 없습니다 (관련성 있음에도 불구하고).

Answer 5

java6 및 CDI (@inject)는 사용자의 의견이 잘못되었으므로 봄이 더 이상 유일한 것이 아닙니다. 15 년 전 EJB2 (심지어 EJB3도 포함) 이었지만 오늘날의 CDI 코드는 websphere, weblogic, jboss, glassfish ... 등 원하는대로 관리됩니다.

Answer 6

응용 프로그램은 모 놀리 식 (하나의 JVM 프로세스는 모든 것을 처리합니다)에서 수직/수평 적 클러스터를 확장해야하며, 스프링의 사용을 조정할 수있는 마이크로 서비스 아키텍처도 구현할 수 있습니다.