Spring vs Jboss

Question

¿Cuáles son las ventajas y desventajas de Spring vs. Jboss para una aplicación web empresarial.

Answer 1

Como ya he dicho, permítanme repetir el punto. JBoss es un servidor de aplicaciones. Algunos servidores de aplicaciones Java incluyen

• Websphere
• Glassfish
• JBoss

Spring es una infraestructura. Un marco bastante grande que ofrece bastante, pero para mí una de las principales características es MVC. MVC es un patrón de diseño donde usted separa su Modelo de la Vista de su Contoller. El modelo es la representación de los datos. Esto puede ser respaldado por cosas como bases de datos o archivos XML. La vista es lo que se usa para ver el modelo. Esto puede ser una interfaz web o una aplicación de Windows. El usuario interactuará con la vista. El usuario expresará su deseo de que el modelo se actualice. Aquí es donde entra el controlador. Usamos el controlador para decirle al modelo que se actualice. Y debido a que la vista se basa en el modelo, la vista también se actualiza. Esto es simplificador, pero en pocas palabras. Otro framework de MVC que puedes mirar es Struts.

Como he dicho anteriormente, hay otras características que ofrece, tales como la primavera

• marco de seguridad
• Inversión de Control
• inyección de dependencias

Answer 2

JBoss es un contenedor, el resorte es lo que se ejecuta dentro del contenedor. Estas comparando manzanas con naranjas.

Answer 3

Aquí es mi opinión:

primavera representa todo lo que es bueno en Java EE, mientras que JBoss representa todo lo que es malo.

Bueno ... eso no fue tan bien (no es que pensara que lo haría). Solo digo que nunca elegiría JBoss para alojar cualquier aplicación. Es tan torpe y pesado, y no hace nada particularmente bien. Me gusta Spring porque se siente menos monolítico y torpe. De acuerdo, Spring no es un contenedor de aplicaciones, pero se puede usar para construir la mayor parte de la infraestructura que necesita para alojar una aplicación; solo tiene que enchufarlo en un contenedor y Spring se encarga del resto.

Answer 4

Esta es una buena pregunta. Algunos han indicado incorrectamente que esta es una comparación de manzanas a naranjas, es decir, Jboss es un contenedor, y Spring es simplemente un marco, como Struts. Sin embargo, la razón por la que esto es un poco confuso es que tanto JBoss como Spring se han expandido considerablemente desde sus orígenes originales y simples, y por lo tanto se están acercando uno al otro. Una manera fácil de entender JBoss es que el nombre era "EJBoss" original, y se pretendía que fuera un servidor de aplicaciones J2EE de código abierto, por lo que tenía la ventaja sobre el servidor sobre servir como un contenedor EJB, y así competir con WebSphere y otros servidores de aplicaciones propietarios.

Y Spring era un framework IoC (ahora denominado "Dependency Injection"), esencialmente una fábrica de objetos para que pueda seguir un diseño más "flojo".

Sin embargo, con su popularidad, ambos productos se expandieron.Por ejemplo, JBoss ahora tiene su propio contenedor IoC: JBoss IoC

JBoss proporciona su propio contenedor ligero COI solicitada: JBoss microcontenedor. JBoss microcontenedor es un peso ligero, Inversión de Control de /Dependencia contenedor de inyección similar en concepto a la primavera, Pico de contenedores, y el plexo.

Y aunque Spring puede funcionar perfectamente bien, coexistiendo (la mayoría) felizmente con JBoss, no necesita un contenedor EJB completo, puede ejecutarse fácilmente en tomcat. El objetivo de diseño de toda la primavera se basa en la idea de diseño ligero, y el uso de POJOs, y la falta de necesidad de un contenedor de gran peso, que era muy contrario a los EJB, y por lo tanto parece reñido con JBoss.

Rod Johnson ha señalado que no hay ninguna razón usted no puede funcionar en la primavera de JBoss:

primavera está diseñado para trabajar en cualquier servidor de aplicaciones (o fuera de un servidor de aplicaciones ); Usar Spring no significa ignorar lo que el servidor puede ofrecer. Simplemente proporciona una mayor selección en muchos casos .

Entonces, lo que tiene que decidir es qué partes de los dos sistemas desea usar y qué estándares Java desea cumplir. De acuerdo con este artículo, en JBoss and Spring, que cubre lo bien que se adhieren a las normas, parece, dependiendo de la tecnología que elija, usted va a recoger un lado, ya que esto parece ser una batalla muy polémico.

Lo que viene a continuación es otra cosa que la distensión, como JBoss y primavera Fuente batalla sobre todo de XML para la integración de herramientas para finalmente virtualización, sí .... es una competencia sana,

[tijeretazo ]

Sólo el tiempo lo dirá, pero creo que esta batalla sólo hace cosas mejor para los desarrolladores, más opciones en lugar de .Net, y más innovación en torno a Java, que será una dura prueba para JBoss, pero una que pueden manejar si la ejecución es impecable, de lo contrario, busque primavera Fuente de abrir una brecha entre la percepción y reales ventajas de JEE 6 ..., más temprano que tarde, la portabilidad de las aplicaciones será tendrá que ser demostrado con el fin de contrarrestar los modelos propietarios , y que no ha sucedido,

para una mirada más puesta al día en el cumplimiento de las diversas normas de Java, miren la request for feedback on Spring 5. Puede hacerse una idea de las limitaciones que enfrentan los diseñadores de la primavera, mientras que también destaca el hecho de que, para el mercado de la primavera, es importante asegurarse de primavera es compatible con los distintos servidores de EE:

tenemos la intención de actualizar suavemente los EE.UU. línea de base también.Ahora, esto es un poco complicado ya que efectivamente tenemos necesidades individuales aquí - y debemos tener en cuenta los niveles de adopción de la empresa en la producción entornos:

Sin duda nos elevamos a Servlet 3.0 o superior (de nuestro presente Servlet 2.5 compatibilidad de tiempo de ejecución), pero no más, ya que nos gustaría que las aplicaciones Spring 5 se ejecuten en los servidores con línea de base EE 6 todavía. Vea mi publicación de blog anterior para una discusión sobre por qué esto es inevitable, dada la situación del mercado con Java EE 7 y la multitud de servidores que es todavía basado en la API de Servlet 3.0. [snip] Es una pena que tengamos que seguir apoyando la API JMS 1.1 de la era 2002 ... Nos gustaría elevarnos a JPA 2.1+ y Bean Validation 1.1+, pero nuestras manos parecen vinculadas: TomEE 1.7 y JBoss EAP 6.4 tienen JPA 2.0 duro y Bean Validación 1.0 API en ellos, y WebLogic 12.1.3 tiene JPA 2.1 pero no Bean Validation 1.1 API (a pesar de estar relacionados).

Answer 5

Desde java6 y CDI (ver @Inject) su opinión es falsa, primavera no es el único que nunca más. Era cierto hace 15 años con EJB2 (e incluso EJB3) pero hoy el código CDI se gestiona en websphere, weblogic, jboss, glassfish, ... el servidor de aplicaciones que desee.

Answer 6

Las aplicaciones se ejecutan en JBoss como monolítico (un proceso JVM lo hace todo) donde necesitará un clúster vertical/horizontal para escalar, donde como el uso del resorte se puede ajustar también implemente la arquitectura de microservicios.