La principal novedad que incorporará Java EE 6 es la incorporación de perfiles, subconjuntos de Java EE que permitan crear una configuración adecuada para un determinado problema y no obliguen a "comerte todo el elefante". Y, sin duda, el perfil que resulta más interesante, o al menos el que potencialmente será más usado, es el perfil web.
El grupo de expertos que está definiendo Java EE 6 parece tener claro que dentro de este perfil estarán las APIs: Servlet 3.0, JSP 2.2, JSR-45, EL 1.2, JSTL 1.2, y JSR-250. Hasta aquí ningún problema, y todo bastante lógico. Sin embargo, están considerando la inclusión de EJB 3.1 " Lite", JTA 1.1, JPA 2.0, JSF 2.0 yWeb Beans 1.0. Si la inclusión de Web beans y JSF es polémica, ya que muchos desarrolladores no los consideran tecnologías ligeras, la de JTA y "EJB lite" (un subconjunto de la especificación de EJB 3.1) mucho más.
Parece que nuevamente los vendedores de servidores de aplicaciones Java EE están usando su músculo para "evitar" que una solución como Tomcat sea suficiente para crear webs (o, al menos, para hacernos creer eso). Y parece que ahora el cambio de filosofía consiste en "ya que están cansados de comerse el elefante, dejémosles ahora comer sólo un poco de cada parte del elefante".
¿Opiniones al respecto?
Etiquetas: j2ee, javaee6, ejb31
Yo lo de los perfiles no lo acabo de ver muy claro. Si ya la gente se lia con JSE, JEE, JME... venga ahora añadamos subconjuntos de JEE y asi a la hora de escoger un servidor podremos jugar a hacer casillitas de esas de "certificado para el perfil..." Ya no bastará con J2EE, JEE 4 o 5, ahora tendremos el perfil web 6 con el de JEE 4.2...
Aparte de para poder poner más etiquetas a los servidores, aun no le veo el beneficio para los demas.
Coincido con greeneyed, esta estrategia parece la clásica salida del departamento de marketing de una empresa TI, supongo que le seguirán el juego completo de certificaciones para determinado perfil y cursos de formación oficiales.
En fin que ya puestos en esto, espero que al final dejen el perfil web sin EJB, JSF, etc.. EJB 3 lite?? creo que es ya demasiado, por lo que veo serían solamente EJBs de sesión con interfaces locales.. ok o sea simples POJOs gestionados por un contenedor Lite, no veo que sentido tiene declarar algo así como "requerido" para un servidor web. JBoss Seam viene con algo parecido pero solo para hacer pruebas en Tomcat y no va muy bien que digamos. Lo de JSF es otra cosa que no entiendo, pero al menos ahí los servidores web podrían tirar de la implementación de Apache para cumplir el requisito, lo de JTA y JPA sí que suena interesante pero no creo que sea realmente necesario.
Pues yo creo que JTA es importante. Aunque solo sea para que la gente tenga en cuenta las transacciones.
OSGi VS JEE6, Yo me quedaría con la idea de OSGi ya que suena (y ya hay varias implementaciones) mas coherente, y abarca todo (o la mayor parte) lo que se pretende hacer con los "perfiles"
Saludos.
Mi opinion es la misma que nilojg,
JTA es fundamental. Aunque al tomcat tambien se lo puedes añadir.
A lo mejor pido demasiado, pero a mi me gustaría mas que las aplicacioes web fueran tan fáciles de desplegar como las aplicaciones PHP o ASP.NET: Con un simple "copy" a una carpeta, y olvidarnos de los términos deploy, deploy-descriptor, war, WEB-INF, etc. etc. etc. etc. etc. .....
Puedes desplegar aplicaciones copiando tu aplicacion a directorio del servidor de aplicaciones. Desplegar un war es basicamente deshacer un zip (eso es el war) y rearrancar un contexto. Si solo quieres subir una imagen y tres jsps, puedes copiarlos tranquilamente. Si son clases, pues ya depende de si tienes configurado el servidor para que se de cuenta de que ha cambiado una clase y lo que uses en tu aplicacion, porque si por ejemplo usas Spring y una de las clases modificadas es un bean inyectado puede que el cambio no se refleje hasta que se vuelva a inyectar rearrancando la aplicacion (lo mas probable es que con solo cambiar un class se rearranque el contexto automaticamente)
En cualquier caso, copiar los ficheros y rearrancar el servidor funcionara siempre. Aunque el war te ahorra editar los domain.xml, server.xml y similares.
Lo de olvidar el WEB-INF es mas dificil porque en algun sitio tienen que estar las clases y los jares, y es muy buena idea que esten en un directorio que el servidor web no sirve (imagina que tus .class estan en cualquier sitio, alguien se los baja y los decompila...)
Lo que si es cansino es meter un servlet, que hay que escribir unas lineas de xml... Pero tienes unos servlets mas chulos que un ocho que se compilan y despliegan solos, y que ademas puedes tener donde mas rabia te de. Solo les tienes que poner la extension jsp y te olvidas. Claro, que como se supone que solo son para presentacion, pues no se usan sus ventajas.
A lo mejor pido demasiado, pero a mi me gustaría mas que las aplicacioes web fueran tan fáciles de desplegar como las aplicaciones PHP o ASP.NET: Con un simple "copy" a una carpeta, y olvidarnos de los términos deploy, deploy-descriptor, war, WEB-INF, etc. etc. etc. etc. etc. .....
No pides demasiado... por que es posible y de hecho existe y funciona. Casi todos, por no decir todos, los contenedores web tienen un directorio, normalmente llamado webapps, donde si copias una carpeta,automaticamente te montan un contexto con el nombre de la carpeta. Y como dice nilogj, si usas JSP con eso ya esas hecho un campeon. Si luego ademas quieres usar librerias de terceros, eso ya es otra cosa, pero es que acaso en PHP puedes coger librerias .so copiarlas asi sin mas en cualquier directorio y ala, a correr? Pues eso.
Lo que pasa es que en Java se pueden hacer asi, o de muchas otras formas, y a veces el bosque no te deja ver el arbol en concreto que buscas.
Para mi gusto, lo mejor de la JVM, en combinación con un buen entorno de desarrollo, es la facilidad con la que creas visualmente una aplicación web y generas un applet.
Desgraciadamente este aspecto se descuidó en su día por los inconvenientes, que hoy no son tales.
Ahora me encuentro con que un applet, apenas tiene un montón de cálculos; aunque funciona en el entorno de desarrollo, luego no funciona en el navegador...
Lo digo aprovechando el tema... por si alguien sabe algo de a qué se debe. ;-)
Te responde el oraculus del futuro: Tu applet lee información de un archivo, cuando no lo hace, presenta los cálculos perfectamente en el navegador.
Ahora me pregunto si existe alguna manera de hacerlo... o tendré que convertirlo en los antiestéticos archivos XML. :-)
Llevo relativamente poco tiempo usando Java EE 5.0, utilizo Glassfish + EJB + JSF.
Actualmente cuando hago un cambio en un Facade o en un Controller, tengo que volver a compilar todo el proyecto (que consume 5 EJB...) lo cual me quita aproximandamente 2 minutos cada vez que le hago compile + deploy, existe alguna manera más rápida de mandar un cambio al Servidor de Aplicaciones?
Me gusta la idea de metodos asincronos de EJB 3.1.
soy nuevo en lo que es java ee, estoy tratando de aprender, pero veo q ustedes mismo se quejan de que es complicado, quisiera saber si vale la pena aprender esta tecnologia o con Visual Studio es suficiente!! respondan con sinceridad please.
Escribe tu comentario