2008-12-19 165 views
7

Ambos servidores de aplicaciones están basados ​​al menos en parte en OSGI. Uno (Glassfish) es obviamente Java EE mientras que el otro no. Ahora estoy en la etapa de elegir una plataforma para un nuevo proyecto y la elección natural es Glassfish v3 Prelude. Esto plantea el problema de que quizás deberíamos usar S2AP en su lugar.Ventajas/desventajas de Glassfish v3 Prelude vs Springsource dm server for Web applications?

La pregunta es: ¿el servidor springsource dm ofrece alguna razón convincente para usar Glassfish? Y viceversa.

Respuesta

4

Los servidores de aplicaciones Java EE tienen administradores de transacciones distribuidos. Si eso es en absoluto importante, entonces puede querer ver si SpringSource dm incluye tal.

Es posible hacer XA TX con Spring-Framework, es solo que se lo deja solo para ubicar un administrador de XA adecuado e integrarlo.

El curso XA TX ha caído en gran descrédito. La mayoría de la gente trata de evitarlos como la peste. Amazon.com, por ejemplo, no los usa.

Actualmente usamos Spring-Framework y Tomcat en combinación. Hacemos toda nuestra propia integración. Mucha gente ha hecho una elección de pila de nivel medio similar. Nos relacionamos con las API de Spring-Framework, al igual que las personas de Java EE se vinculan con Java EE/EJB. No dejes que la retórica de Spring te engañe sobre eso. Sin embargo, continúa siendo de código abierto accesible para la comunidad de usuarios.

Una vez que vaya a Java EE, quedará vinculado a un proveedor de Java EE en particular, ya que es difícil pasar de una implementación a otra. Se supone que EJB3 facilitará esto, pero apostaría que seguirá siendo una empresa importante cambiar los servidores de la aplicación Java EE.

Frankly Spring-Framework proporciona más API útiles que el estándar Java EE/EJB y está innovando a un ritmo más rápido.

+0

He usado entidades EJB3 y beans de sesión sin estado y en realidad es solo una nnotation ahora comparado con el desastre que EJB 2.0/2.1. Es realmente bastante agradable ahora. – cletus

+0

Es una respuesta muy antigua, pero para las personas que aún leen algunos matices aquí: cambiamos entre los vendedores de Java EE un par de veces y no es * tan * difícil. Un par de 100k aplicación de loc se movió en gran medida dentro de un par de días cada vez. Sí, hay * diferencias *, pero es mucho menos trabajo que tener que portar su aplicación de decir WebObjects a .NET, porque WebObjects ya no se continúa. Con Java EE, la posibilidad de que la plataforma como un todo ya no continúe es mucho más pequeña que la de un proyecto individual que no continúa. –

+1

También, una vez más darse cuenta de que esta es una respuesta antigua, pero el interés de esta respuesta resuena fuertemente con el viejo pensamiento de que Java EE es más o menos igual a EJB y XA TX. No fue realmente cierto en el 2008 y ciertamente no es cierto ahora. Hay mucho más en Java EE, como JSF, CDI, JPA, Validación de Bean, Batching, JMS, etc. Con el tiempo, EJB se ha convertido en una pequeña parte de la especificación general. –

1

No he utilizado el servidor de SpringSource dm, pero creo que es mejor esperar un poco antes de probarlo en producción. La razón tiene que ver con que es una tecnología bastante nueva. Además, la forma en que el esquema de licencia funciona con SpingSource (GPL) no ayuda mucho, ya que prácticamente significa que dependerá solo de SpringSource por ahora y para el futuro. Si necesita soporte para el servidor, entonces su única opción es ir con SpringSource.

+0

Su punto es bueno, pero creo que hay factores atenuantes que reducen la dependencia del servidor de Spring Source. Primero, está basado en Tomcat, apenas nuevo. En segundo lugar, OSGi no es un estándar de primavera. Creo que todos los servidores de aplicaciones Java EE adoptarán OSGi o JSR 277 cuando se finalicen. – duffymo

2

Creo que el acquisition de Covalent Technologies de SpringSource los coloca en una mejor posición para ayudar a cualquiera que use la pila Spring/Tomcat. Las optimizaciones de Tomcat que acompañan a Spring dm Server pueden valer tanto o más que las características de OSGi.

2

El uso de OSGi en Glassfish es engañoso. Glassfish está utilizando OSGi internamente para el servidor; OSGi no está disponible para las aplicaciones implementadas en Glassfish.

Con el servidor Spring dm, las aplicaciones se pueden escribir para usar OSGi.

¿Es OSGi una consideración importante para usted? El único otro servidor de aplicaciones OSGi real es Paremus 'Infiniflow. Todos los demás servidores de aplicaciones ahora están hablando de OSGi, pero es un detalle de implementación interna; no es para las aplicaciones desplegadas.

1

SpringSource dm Server admite aplicaciones modulares: puede dividir su aplicación en paquetes OSGi y compartir cualquier servicio de infraestructura que desee proporcionar entre las aplicaciones. Esto lo aleja de las estructuras monolíticas como las WAR definidas por Java EE. Normalmente, esto significa que obtiene un ciclo de edición/guardado/redistribución muy rápido durante el desarrollo.OSGi luego le permite módulos de versión y los paquetes que exportan, así como también módulos de actualización dinámica sin tener que reiniciar todo el servidor.

El servidor de SpringSource dm se construyó desde cero como paquetes OSGi. Entonces puede configurar qué subsistemas de dm Server están cargados si no desea el conjunto estándar.

3

Se trata de un viejo hilo, pero pensé que sería útil para la gente que viene a través de este (como yo) para compartir las recientes mejoras OSGi GlassFish, principalmente en el área de OSGi Empresa RFC: http://wiki.glassfish.java.net/Wiki.jsp?page=OsgiDashboard

Por supuesto también está la inyección @ basada en recursos de OSGi Declarative Services que ha estado allí desde v3 en diciembre '09.

Cuestiones relacionadas