domingo, mayo 24, 2015

Evolución o desajuste: un asunto crítico

De interés para usuarios de Plex; en el último tiempo, varias discusiones importantes se han desarrollado en la comunidad de usuarios en CA. Discusiones que van en dos direcciones: prometedores nuevos desarrollos, y retrasos lamentables en el soporte de nuevas tecnologías. Esta dualidad refleja probablemente la situación del producto: un gran capital en una herramienta robusta que no pierde utilidad, y una respuesta errática a los cambios tecnológicos. Puntualizo algunas de las discusiones, e invito a revisarlas, y en el caso de las ideas propuestas, a votarlas si les parecen adecuadas. Las menciono por su título:
Outlook question: la discusión abierta es acerca del soporte de WinApi, ObMapi, es decir, el sistema de mensajería, para Outlook 2013 (también se menciona Outlook 2010). El problema reside en que el API está soportado para 64 bits, pero no para 32 bits, y Plex es generado para 32 bits. Esta es la respuesta del soporte de Plex:
There is a compatibility issue between the 64-bit versions of Microsoft Outlook and other 32-bit applications. Since Plex generates 32-bit application, you will need to use the 32-bit versions of Outlook.  (remite a la explicación de Microsoft). So, if you are using the OBMAPI or WINAPI Souce Code mail APIs, then you will not be able to use the 64-bit version of Outlook 2013 with these APIs.
La solución ofrecida es usar la versión de Office de 32 bits, o usar otro código, o solicitar al equipo de desarrollo que estas APIs soporten 64 bits. El propio soporte recomienda esta última opción, que conduce a  una solicitud existente desde julio de 2014.
Sobre este asunto del atraso en el soporte de productos u opciones respecto a la evolución tecnológica actual, hay otra discusión que afecta a 2E, no Plex, pero donde valen las opiniones de los participantes, ya que podrían asociarse sin mucha dificultad también a Plex: la complejidad de plataformas y tecnologías que deberían abarcarse hace difícil mantener el paso. En el caso de Office, el problema resulta aún más claro: los cambios de arquitectura ensayados por Microsoft son capaces de hundir a cientos de proveedores de servicios que trabajan para su plataforma (partners), como sucediera con el mercado de Silverlight, y seguramente con los incipientes desarrollos orietados al cuasi difunto Metro.
Otras discusiones de importancia vienen de la sección de Ideas, por ejemplo la postulación de la generación de servicios REST sobre el System i (discusión especialmente interesante), o las dos o tres referencias a la actalización del soporte de SQL en el System i (1, 2). O incluso las postulaciones a mejoras en el soporte de RPG ILE. Todos ellos hablan de un retraso de soporte a la evolución de las distintas plataformas, que resulta prioritario resolver. Hoy la evolución tecnológica es rápida y diversa, y resulta muy difícil abarcar el espectro completo de arquitecturas, tecnologías y paradigmas. Aún para el paradigma de diseño basado en modelos, resulta difícil seguir el paso para elaborar transformaciones adecuadas a cada caso y sus interrelaciones. ¿Qué camino es más aconsejable en éste caso, el de Plex?
Desde hace años, la solución de las transformaciones para atender nuevas áreas en Plex han estado a cargo de terceros; sea socios de negocios, como en el caso de los desarrollos web, telefonía móvil, e incipientemente cloud por parte de SoftDesign (Websydian) y CM First (WebClient), o los desarrollos para XML de Simon Jasperse, o los minipatterns debidos a Peter Fabel y Luwdig Hirth, o Stella Tools de George Jeffcock. Probablemente este sea el mejor modo de poder atender, especialmente sin un elevado presupuesto de investigación, la avasalladora ola de cambios en que nos movemos.
También desde hace años, el equipo de desarrollo de Plex expone crecientemente el API que permite la interrogación y operación del modelo, sus objetos y sus métodos. Es gracias a ésto que herramientas como Stella Tools puede trabajar. Probablemente esta vía sea la mejor para el desarrollo del modelador y sus generadores. Sería muy positivo que el trabajo del laboratorio de desarrollo de Plex se concentrara en éste aspecto: los modos para extender el modelador, para extender la inclusión de nuevos generadores que puedan ser elaborados por terceros. Estos terceros podrían ser empresas interesadas en extender la generación de código final a un nuevo área, o empresas  interesadas en adecuar una extensión a sus propias necesidades. Al modo en que Xtext trabaja hoy como DSL. Creo que ésta es la salida viable de Plex en éste momento, y allí deberían centrarse los esfuerzos.


domingo, mayo 10, 2015

Java en el System i

La JVM de IBM vs el JDK clásico. Cap 13, pag 591
Continuando el comentario (y recomendación de su  lectura) del Red Book sobre modernización del System i, dos palabras sobre Java en  el i.

Siempre se discute la lentitud de Java y su manejo de espacio de memoria, pero deberíamos decir que esto depende mucho  de la implementación y del aprovechamiento de las herramientas disponibles. Particularmente, IBM ha hecho un cambio radical en la JVM: el reemplazo por la implementacion de IBM,  Por experiencia, hemos pasado por casos que comenzaron con fallos y caídas, y fueron ajustados y optimizados hasta pasar a un funcionamiento absolutamente normal. En el capítulo 13 del red book, se comenta sobre la lentitud de Java (13.3.2 Myths surrounding Java: Java is slow)
Is Java really slow? It depends on what you compare it to. (...) you must choose the correct tool for the job. If what you need is high performance, you must select a lower-level language, such as C/C++ or RPG, but if you are dealing with huge and complex applications, it might be better to use a language with more flexibility, such as Java.
The reputation for slowness that Java usually carries is related to the JVM and not the language itself. The Java language is dependent on multithreads and large amounts of memory. Many people who are accustomed to running other languages starve their Java applications, which causes terrible performance. On the IBM side, the Classic JVM was not designed for IBM POWER architectures. It was ported from the original Oracle version, which resulted in performance issues. However, IBM Technology for Java is designed for the platform and it has been highly optimized by IBM to leverage the Power architecture. With this new version of Java, you can take advantage of the multithreading nature of Java, which was not possible before. Lastly, processor technology has improved greatly over the past few years. Processors are geared toward multithreading, which is a significant boost to Java based applications.
 
Disponible desde 1998, ha pasado mucho desde su introducción en el System i, progresando hasta ser hoy una alternativa confiable. IBM comenzó ofreciendo soporte a la JVM clásica de Java, hasta que decidió atacar los problemas de adecuación a la plataforma, desarrollando su propia versión, tanto de un conjunto de clases y servicios que explotan los recursos nativos del equipo (IBM Toolbox for Java), como de una propia JVM, que ajusta la versión clásica desarrollada hoy por Oracle:
Java on IBM i can take advantage of the 64-bit architecture of the systems to provide a scalable solution from single processor machines all the way up to multiprocessor machines. The Classic JVM was unique in its implementation of asynchronous garbage collection, which allowed the JVM to continue processing application requests during the garbage collection cycle.
Nevertheless, this uniqueness of the Classic JVM became a disadvantage. For many developers and vendors, it required much work to port their applications to the IBM i, which disabled the portability features of the Java platform. This also resulted in more expenses to IBM and slower releases of the new Java versions and updates. In addition, the Classic JVM was based on porting code that was not tuned to the features built within the IBM PowerPC architecture. Starting in V5R4, IBM i started to move away from the Classic version of Java and support for Classic is now stabilized. Today, Java is delivered on IBM i only through the IBM Technology for Java version.  (...) Initially the IBM Technology for JVM was implemented only on 32-bit architecture, but since IBM i 6.1, the 64-bit version is available for use. This gives more flexibility for developers, allowing them to fit the JVM according to their needs.
Este es un aspecto importante a tener en cuenta: las nuevas ediciones del sistema operativo implementan sólo la versión de Java de IBM. Así, Java 7 es implementada solamente en la versión de IBM. Sin embargo, esto no debería alterar la ejecución de código, sino explotar la posibilidad de usar de manera nativa servicios y posibilidades del sistema operativo y de la base de datos. El "IBM Toolbox for Java" y su equivalente open source JTOpen ofrecen un excelente medio de interactuar con los recursos del sistema.

En nuestro caso, el desarrollo de aplicaciones web con Webclient, que utiliza java como capa intermedia, nos ha dado oportunidad de comprobar la posibilidad de usar java sobre el System i. Básicamente, nuestras aplicaciones se ejecutan sin diferencias (salvo extensiones que concientemente explotan facilidades del sistema) sobre servidores Websphere en System i, iSeries o como se le llame, y sobre servidores Tomcat o Jetty (en este caso sólo para pruebas). Y quisiera decir que, además, las herramientas de análisis de problemas y performance que Websphere ofrece, son superiores al momento de tener que estudiar problemas. Probablemente, la posibilidad de usar Java nativamente es una de las mejores garantías de modernización y explotación del equipo, convirtiéndose en un puente entre el mundo móvil, web y de recursos infinitos que propone IOT, y la potencia de procesamiento y de manejo de datos del i.