Mostrando entradas con la etiqueta JEE. Mostrar todas las entradas
Mostrando entradas con la etiqueta JEE. Mostrar todas las entradas

sábado, 28 de noviembre de 2015

JavaOne 2015 - A sus 20 años -

En mi asistencia a Oracle Open World decidí incluir también al JavaOne.
Primero, era interesante volver a las acostumbradas platicas y segundo por que a los 20 años de cumpleaños de Java era atractivo ver como estaba la comunidad.


Arrancando el lunes y a diferencia del evento hermano, solo asignaron 2 hoteles. Un evento que llegó en el año 2000 a llenar los dos Moscone y con una comunidad internacional, ahora estaba reducido a una exposición con una sala menor a cualquiera del Oracle Open World y no mas de 20 salones de pláticas.

Mi primera pregunta, donde está la comunidad Java!!

Note que parte de esa comunidad estaba ya en el otro evento, y quizá ya no tanto como desarrolladores sino contro rol. De igual manera, aunque gran parte de la plataforma que se tenía en Oracle Open World al final se ejecuta sobre JVM pero ya es otro el giro.

Donde quedo la emoción de cuando se anunciaban mas APIs. Recuerdo en 1999 cuando llenamos la sala y oimos sobre EJB 1.1 o JMS 1.0 o JINI y probabamos de manera inmediata la tecnología.

Viejos tiempos dije y de ahi me di cuenta de otro hecho, la comunidad ya no es joven, ya no eramos esos programadores entre 20 y 30 años. Poca sangre joven note.  Y donde están esos programadores Java, se supone que hay bastante comunidad.

La respuesta está en una comunidad que por rollos legales y comerciales, para ORACLE es más innombrable que Voldermot

Si, Android, y muchos lectores me van a matar, pero si Java se sigue aprendiendo es por que la anti tesis de ORACLE le ha renovado vida.  
En el evento de JavaOne 2015 cero mención a Android. ORACLE aún sigue hablando de Java Micro Edition pero pues creo que nadie me discute que el tiempo ya dio su respuesta sobre lo que resulto con la idea de dispositivos moviles habilitados con Java. No fue ORACLE el ganador...

Que hay de Java 8? Bueno, ya saben, el intento de incorporar algunos elementos de progamación funcional al lenguaje, las tan citadas Lambda. Este ejemplo era muy tipico de ver ...


Si fuera el único mundo de programación Java quizá muchos dirian, que bien, pero esto ya tienen bastante tiempo con lenguajes como Ruby y como siempre he criticado en Java, siempre se ha temido dar ciudadania a expresiones que requiere el lenguaje. Expresiones regulares resulta demasiado complejo frente a lenguajes que si le dieron esa capacidad de ser ciudadanos de primer mundo en la sintáxis tales como Perl, Python, Ruby. Ahora pasa lo mismo con las lambdas. 

Después de 20 años, por fin se admite que el manejo de las rutas de clases o CLASSPATH necesita ser organizado. Era una crítica que hacian los detractores de la platforma. JDK 1.8 nos ofrece una herramienta llamada jdeps para amaestrar el mundo de los cientos de JAR y no vivir la pesadilla de ClassNotFoundException o peores. 

JavaFX, prefiero mejor no hacer comentarios en un mundo donde HTML5 ya resolvió muchos problemas de Interfaz de usuario.

JavaScript es soportado con el motor de ORACLE llamado Nashorn , no es impresionante si ya se conocia Mozilla Rhino. Pero espero que esto permita ver hacia un posible enfoque políglota del ambiente.

¿Que hay de JEE 7? Bueno,  está llegando un poco tarde a una película que ya lleva un tiempo avanzando. Mientras otras plataformas de programación están en busca de ambientes ligeros (ejemplo Sinatra con Ruby o Flask con Python) nuestro viejo conocido framework aun se niega a seguir dieta.  
Si, ya se tiene inyección de la dependencia, JPA ya converge con Hibernate. Aún siguen las discusiones para que usar Spring si ya JEE 7 cubre todo.  Ya se habla de generar microservicios (aunque aun falta mucho por entender de este estilo ). Pero aquí es donde empezaron mis dudas sobre Java hace años, la sobre especificación y la verdad atado a modelos de hace ya una decada que han demostrado no ser tan efectivos. No quiero un Node.js o Ruby ligero, pero creo que la comunidad de desarrollo ya sabe lo que implica programar aplicaciones en el backend y Java EE 7 aún necesita hacer algo para simplificar el tema.

JSF aún sigue seriamente considerado en la ruta de tecnología de JEE y veo de la comunidad ortodoxa aún el alejamiento hacia Javascript.  No quiero ser pesimista pero JSF temo que sufrirá el destino que Java FX a menos que se replantee. O qué sensación tienen al ver este diagrama de JSF 2.0 para entenderlo a fondo.



Nube, nube por doquier pero ... Les comparto esta presentación  y ésta del evento y ustedes juzgen sobre el tema. 
Su servidor no encontró respuestas sobre cual es la manera de diseñar aplicaciones Java para la nube y tenemos que agregar un poco la manera como ORACLE está enfocado el tema de nube y muchas veces no queda clara su estrategia en términos de PaaS  

Hubo temas donde se toco Scala como lenguaje funcional.

Una plática muy interesante desde la perspectiva de ingeniería donde se hizo una consola de juegos de los años 90 usando Raspberry Pi, impresion 3D y mucha electrónica y superando muchos obstaculos.  Estuvo Stephen Chin, quien es ORACLE Java Community Manager.

Internet of Things estuvo presente, pero aún me pregunto por que no han desenterrado el último regalo de ingeniería que nos dejo Biil Joy, JXTA.

El cierre del Vava one fue entretenido. Salvo que al inicio y mas con la cultura de EUA, nos cerrraron las puertas a los que llegamos un par de minutos tarde por falta de espacio.  Ya que pudimos pasar y con una cervez en mano por su error, pude ver un show preparado por la comunidad Java, la guio Stephen Chin, recorriendo en el tiempo estos 20 años con un Tardis tipo Dr. Who y con la aparición de James Gosgling y recuperando la tradición de aventar las playeras. Algunas bromas donde veo como la comunidad aun cree en ciertos principios como verdad única (JSF, JEE, un solo lenguaje, sintáxis cada vez complicada) 

Les comparto el video del Keynote del cierre. Aun me pregunto por que Brasil se nos adelanto como comunidad Java ... Creo que no nos enfocamos a unir la comunidad mexicana, que vaya que si sabemos del lenguaje pero cada uno en nuestro mundo. Se habló de Java para 2035 (y me quede pensando si yo estaría ahí a mis 63 años o si realmenta existiría un Java One 2035)  y ya saben, los niños, el futuro. Pense, quiero que las nuevas generaciones aprendan Java? 

En resumen, JavaOne 2015 fue una experiencia muy interesante, y más que fui en otra óptica, ya no quiero programar todo en Java y se que ese no es el camino. Extrañe a la comunidad joven (ahora en el mundo del desarrollo móvil o aplicaciones Web con Jscript) y también tuve nostalgia por aquellos tiempos donde el mercado Java daba para cientos de empresas que te mostraban tecnología.

Así que no es lo mismo los tres mosqueteros que 20 años después.  

Deseo que el lenguaje continue pero necesita evolucionar ya, necesita morir y renacer, como el ave fénix. A esto escribire otro articulo que se me ocurrió en el mismo evento.



domingo, 20 de septiembre de 2015

Computo en la nube o de como empieza el reinado de los servicios

Hace más de dos decadas, el autor de este artículo, Gustavo De la Cruz, estudiaba y devoraba la arquitectura de CORBA y marcos de objetos distribuidos similares (COM, SOM y otras decenas de tecnologías similares) con el fin de lograr un esquema de aplicaciones integradas a través de objetos. En esos tiempos los lenguajes Orientados a objetos eran C++, Objective C, Smalltalk, Eiffel y todos prometian una pronta integración entre ellos.  SUN Microsystems tenía un proyecto muy fuerte entre manos para revolucionar el computo distribuido. Estoy hablando de inicios de la decada de los 90.

La arquitectura se basaba en servicios comunes para lograr la persistencia, ciclo de vida, concurrencia, seguridad, eventos, transacciones y un sin fin de servicios que parecía el paraíso de los programadores para hacer aplicaciones distribuidas basadas en objetos. El protocolo unificador era IIOP y parecia que nadie iba a poder igualar esta labor, ni Microsoft con su COM.

En esos tiempos este era mi libro de referencia y lo leía casi todos los días



Y llego Java, y los jovenes proyectos acabaron devorando a los viejos proyectos de CORBA. Aunque al principio Java fue un lenguaje excelente para implementar CORBA, en ese momento también el uso del protocolo HTTP como el gran transportador de mensajes síncronos entre aplicaciones y elevando el nivel de estandarización y la capacidad de exponer objetos no solo en redes privadas, sino via la naciente Internet. Así se unió al modelo multicapa, una capa adicional, de 3 a 4 capas, la capa de Web.

Muchos saben ya la historia, salió J2EE (hoy JEE) y muchos servicios de CORBA vieron su simil, Transacciones y ciclo de vida se volvieron EJBs, Persistencia EJB de entidad, Naming a JNDI y con eso se elevó el nivel de reuso de servicios. Y si, los programadores ya teniamos las herramientas para hacer la magia que tanto soñabamos con objetos. Llegó la epoca del servidor de aplicaciones. Decenas de compañías te ofrecían en el JavaONE su producto, empresas que ya no figuran. Podría decir que los únicos sobrevivientes de esos tiempos que ahora veo con una particular nostalgia de mi epoca de juventud adulta, son WebLogic, Websphere y JBoss, TomCat (es un appserver ??)  donde se pueden edificar arquitecturas de despliegue que pueden usar procesamiento de manera escalable y formando clusters.

En esos tiempos, los que eramos arquitectos de software, con un pequeño nivel de soberbia, no pensabamos tanto en el hardware. Al final, la magia de la portabilidad permitia que el diseño pudiera ejecutarse en cualquier tipo de computadora que soportara la JVM y podiamos confiar que la ingeniería del JIT se podía encargar de ejecutar de manera optima el código...

Esta arquitectura aun es la reina en muchos ambientes de aplicaciones empresariales. Hemos educado a las nuevas generaciones a confiar sin cuestionar la magia de los servidores de aplicaciones. De igual manera, el mundo  Microsoft .NET hizo lo similar y aprovechó las lecciones dolorsamente aprendidas en temas de desempeño para simplificar el modelo de aplicaciones con objetos distribuidos.

Llegó la revolución de la simplificación, 2003, cuando Rod Johnson y varios más cuestionaron el enfoque de utilizar/desperdiciar recursos de computo y volvieron a los Plain Old Java Objects.  Se dieron arquitecturas livianas, corriendo con TomCat y rompiendo la ortodoxia de que todo era un EJB.

Los clusters de Weblogic o Websphere seguían teniendo sentido para aplicaciones que necesitaban de escalabilidad y de manera mágica se hacia la migración y manejo de las fallas, así como unir al cluster una JVM más. Así es el estado de los actuales servidores de aplicaciones y se han optimizado con esquemas de base de datos en memoria o caché (Terracota, Coherence)

La última complicación del lado del mundo Java fueron sus JSF, con el intento de hacer componentes web reutilizables, pero con demasiado énfasis en que todo lo resuelve el servidor.

Y el resurgimiento de Javascript, dado que el navegador ya no es una pieza tonta de software que solo desplegaba HTML e imágenes, sino toda una gama de componentes para visualizar, almacenar, comunicar que ahora es HTML5, CSS3 y Javascript y donde el procesamiento se puede hacer en la computadora cliente que ya tiene capacidades respetables.

Agregado a la aparición de aplicaciones móviles que muchas veces tienen que trabajar fuera de línea; todo ha llevado que los servicios distribuidos tienen una clara definición de que es lo que deben de hacer y estandarizados a través de modelos basados en REST o intercambio con JSON.

Esto ha llevado a una nueva variante de implantar los servicios. Muchos usando software abierto. Modelos de base de datos donde ya no solo es SQL la única opción, distribución de la carga de trabajo usando esquemas de mensajes asíncronos y capacidades para analizar grandes volumenes de datos usando procesamiento distribuido.

El hardware se ha vuelto un "commodity" y los procesadores, almacenamiento y redes se pueden manejar por decenas y abaratando los modelos de computo distribuido e implantar masivamente servicios de software que están reemplazando al modelo de servidores de aplicaciones pero usando directamente las capacidades del hardware "virtualizado".

Como dije, hace un par de decadas no era el hardware el modelo primordial al diseñar la arquitectura, hoy en día es fundamental y la escalabilidad y tolerancia a fallas ya no es tanto de un sistema operativo o de un middleware, sino de mecanismos que permiten replicar imagenes virtuales sobre múltiples procesadores y almacenamiento y con la capacidad de resistir a fallas. Ya nadie queda impactado si un nodo de computo tiene un problema, puede ser reemplazado por uno similar y  en cuestión de segundos o minutos.

Todo esto es lo que se llama computo en la nube. Al final es lo que narro, muchos servicios disponibles con un pool de recursos casi infinito de procesadores, almacenamiento y redes y disponible de manera ubicua a través de Internet.

Nunca he comprobado esta teoria, pero presiento que la manera como se están solucionando los diversos temas relacionados con ofrecer un servicio de la nube viene desde lo aprendido por muchos en sus clases de sistemas operativos o  ambientes distribuidos, de un sistema operativo llamado Amoeba, que nacio de la escuela de Andrew Tanenbaum. El siguiente diagrama muestra la arquitectura y vean que el pool de procesadores es lo que ahora se llama computo elástico. Los invito a leer los libros de Tanenabaum en esta materia y se van a ver sorprendidos que hace 20 años ya las ideas actuales estaban definidas


A lo que voy de toda esta historia es que el momento que estamos viviendo de computo en la nube es el momento de madurez de un tipo de computo que fue concebido como objetos y que se transformo a servicios que son ubicuos, portables, interoperables y con la capacidad de explotar hasta el "tuetano" las capacidades de virtualización de hardware.

Hoy mucha gente está preocupada sobre la nube, que implica.  Puesto de manera simplificada es poner en Internet tus aplicaciones. Ese puede ser el primer foco de usar una nube pero no es el mejor en términos de arquitectura por que es llevarse todo lo que tienes bien y mal en los sistemas empresariales y no usar el total potencial de la tecnología de la nube. Muchos aún se preocupan por subir el servidor de aplicaciones, clusters, la complejidad de un RDBMS en la nube. Como primer paso quizá está bien pero ...

Es importante que los especialistas de TI se abran y entiendan el estado actual del arte de la tecnología. Ya  no hay un solo lenguaje de progamación, ya no hay una plataforma que predomine, la guerra de CPUs (CISC vs RISC) o de sistemas operativos (Windows vs UNIX-Linux)  se acabó y hubo ganadores que ni siquiera pueden ya cantar victoria. 

Lo que se debe aprovechar es la riqueza y variedad potencial de los servicios distribuidos que se ofrecen y usarlos por sus caracteristicas (disponibilidad, confiabilidad, capacidad, seguridad, portabilidad e interoperabilidad) y ya no ponerse en modo ortodoxo si es de un fabricante o una tecnología en particular. En este momento, la visión inicial de los objetos distribuidos como componentes reutilizables (o de re uso) ya es un hecho pero no es el resultado del esfuerzo de un fabricante o grupo (como era DCE o CORBA) sino de la apertura del software abierto y que ha sido adoptado por cuestiones técnicas y no comerciales y se han vuelto estándares de facto.

Asi que si en el servicio existe una arquitectura MEAN o JEE o .NET, o con servicios NoSQL o Hadoop o Spark o RabbitMQ o AMQ, con Windows o Linux; no es preocupante la variedad tecnológica, es bueno dejar la libertad y creatividad a los arquitectos y programadores del software y garantizando los requerimientos técnicos y el nivel de calidad de servicio; y controlar (gobernar) a través de buenas definiciones de arquitectura empresarial y estándares la enorme variedad de tecnologías. 

Pensar entonces como servicios de plataforma es el enfoque, o lo que se conoce como Platform as a Service (PaaS)  es lo que permite explotar el modelo de encapsular la complejidad. 

La siguiente presentació de Slideshare, Pizza as a Service,  ayuda a entender el modelo de la nube. Muchos de los lectores ya usan SaaS, dado que tienen una dirección de correo electrónico personal basada en algun servicio (Gmail, Outlook, Yahoo?) 

Empezando a pensar en el futuro. Hoy grandes empresas ofrecen las nubes. Tiene buenos puntos por que podemos delegar la pizza y administrar a través de niveles de servicios. Pero la contraparte es que se sigue concentrando el procesamiento en grandes cúmulos controlados por grandes empresas, lo cual es contrario a la filosofia de Internet.

Voy a repetir (en español) lo que un articulo de SUN sobre JXTA dice al respecto:

"The Internet was founded on a simple vision: to build a highly decentralized and resilient worldwide network infrastructure that would scale and that could resist any denial-of-service attacks" 

"Internet fue creado con una visión simple: constituir una infraestructura de red  de alcance mundial y que es altamente descentralizada y resilente  que puede escalar y resistir cualquier denegación del servicio"

JXTA, que es una tecnología que siento aún no se comprendió, y la última obra de Bill Joy en SUN, tuvo la visión de tomar P2P como el siguiente paso. Yo identifico que en la epoca del IoT, JXTA tiene mucho por decir.

Analizando la arquitectura de JXTA, nos lleva a un nivel adicional de procesamiento. Se construyen redes virtuales de peers encima de la infraestructura estática de la actual Internet. 


Pienso entonces, algún dia también las nubes se van a volver "commodity" y tendremos la libertad de usar nubes públicas abiertas (open cloud computing?) para constituir nuestros servicios personalizados o de una empresa. La nube se va convertir en una red de Peers y que de manera dinámica se van a enlazar. Espero en unos años leer esta entrada y ver que tanto atine a predecir sobre este tema.

Por mientras, si es importante considera el computo en la nube, identificar su beneficio a nivel de negocio, el cual siempre es hacia la agilidad de tener soluciones tecnológicas para lograr innovación y realización de la estrategia. Quien no tome esta oportunidad, va a quedar muy rezagado para el siguiente paso. No teman en cambiar los viejos paradigmas de procesamiento. No mas servidores de aplicaciones, no más grandes clusters, los servicios de la nube ya tienen la capacidad para dar el modelo equivalente.

Quien tenga el valor de hacer este cambio, ya está adelantando buenos pasos. Diria, está innovando ...

Esperando comentarios ...