JEE vs. .NET, La batalla de las plataformas está en marcha

Hay quien asegura que el debate JEE contra .NET, representa un hito en la historia de las tecnologías de la información. Otras posturas sugieren, que apasionarse con este debate no debe acaparar la completa preocupación del medio, pues los ciclos tecnológicos irremediablemente proponen nuevos paradigmas, dejando obsoletas las herramientas que hoy parecen útiles y novedosas. La intención de este enfrentamiento, es poner sobre el ring cuestiones como portabilidad, compatibilidad, desempeño, soporte, diversidad e incluso la historia personal de los fabricantes; para así, conocer mejor ambas plataformas y formular un juicio.

Presentando a los Contrincantes

JEE es la edición empresarial de la plataforma Java. Aprovecha las fortalezas de la edición estándar de Java (J2SE), complementándolas con especificaciones, funcionalidades y lineamientos orientados al desarrollo de aplicaciones empresariales. El nombre original de JEE era Java 2 Enterprise Edition (J2EE) – y es como la mayoría del mundo lo sigue llamando –, sin embargo, a partir de la edición 5, que es la más reciente, se cambió el nombre oficial a Java EE, o JEE, así que, esa es la nomenclatura que utilizaremos durante este artículo.

El framework .NET es una plataforma creada por Microsoft, para el desarrollo y ejecución de aplicaciones modernas. La primera versión de .NET se lanzó en el 2002, en gran parte como respuesta al éxito de J2EE. Actualmente, .NET se encuentra en su versión 2.0.

1er. Round: Ejecución de Aplicaciones

Visión de JEE. El código fuente de Java se compila en un byte-code, que es independiente de sistema operativo y arquitectura de procesador. Dicho bytecode se ejecuta por una máquina virtual de Java (JVM). En las primeras versiones de Java, los JVM sólo eran capaces de interpretar código y generar las llamadas correspondientes al procesador (en lugar de generar código nativo), afectando seriamente su desempeño. Sin embargo, todos los JVM modernos tienen la capacidad de hacer compilación Just-In-Time (JIT) para generar código nativo, con lo cual se obtiene un mejor desempeño y se puede aprovechar las características especiales de cada arquitectura de procesador.

Visión de .NET. De forma similar que en JEE, en .NET, el código fuente se traduce a un lenguaje intermedio, llamado MSIL (Microsoft Intermediate Language). Esta tecnología proporciona servicios como verificación de código, manejo de memoria, colección de basura y seguridad. El MSIL se ejecuta por un componente denominado CLR (Common Language Runtime), el cual hace compilación JIT. El código traducido es cacheado de tal forma, que la siguiente vez puede ejecutarse directamente.

2do Round: Arquitectura y Portabilidad

Visión JEE. JEE está basado en una arquitectura del lado del servidor (Served-based). Este tipo de arquitectura, concentra la mayoría de los procesos de la aplicación en el servidor, o en un pedazo de éste. Otorgando dos ventajas críticas:

• Múltiples Clientes: una arquitectura basada en el servidor, requiere una clara separación entre la capa cliente (interfaz) y la capa servidor, en la cual se realizan los procesos de la aplicación. Esto permite que una simple aplicación soporte simultáneamente, clientes con distintos tipos de interfaces.
• Operaciones robustas: una arquitectura basada en el servidor soporta escalabilidad, confiabilidad, disponibilidad y recuperabilidad. Aplicaciones basadas en el servidor, pueden ser divididas y distribuidas en múltiples procesadores. Componentes de la aplicación, pueden replicarse, para dar soporte a caídas instantáneamente.

La plataforma JEE se define por medio de una especificación, desarrollada a través del Java Community Process. Aunque no es un estándar formal, avalado por una organización como ISO o ECMA, JEE es informalmente considerado un estándar, ya que cualquier proveedor puede desarrollar servidores de aplicación, y ambientes de ejecución para cualquier plataforma, siempre y cuando cumplan los requerimientos establecidos en la especificación, los cuales son verificados a través de un conjunto de pruebas. El hecho de que Java corra sobre un ambiente de ejecución intermedio, como lo es el JVM, más la disponibilidad de JVMs para prácticamente cualquier plataforma, le da a Java su capacidad multiplataforma, expresada en la frase, Write Once, Run Anywhere (escribe una vez, ejecuta en cualquier lado).

Visión .NET. Está diseñado principalmente para el sistema operativo Windows. Lo que tiene ciertas ventajas, por ejemplo, el manejo de ventanas para aplicaciones de escritorio es muy bueno. Sin embargo, el principal inconveniente, está en la portabilidad de las aplicaciones. Una alternativa para mitigar esta limitante, es recurrir a Mono, una implementación multiplataforma y open source del ambiente de ejecución de .NET. Pero, hay que tener en cuenta que Mono no implementa todos los detalles de la plataforma .NET, así que si no estamos al pendiente, podemos terminar con aplicaciones que funcionen sobre el CLR de Microsoft, pero no sobre Mono.

3er. Round: Lenguajes Soportados

Visión .NET. La plataforma .NET es una plataforma de desarrollo de software, con especial énfasis en la independencia de lenguaje, y la transparencia a través de redes. Tal vez los dos lenguajes más representativos de esta plataforma son: C#, y Visual Basic .NET. No obstante, también es posible generar aplicaciones para .NET en Cobol, C++, y Fortran, entre otros. La filosofía en es permitir que los desarrolladores utilicen el lenguaje(s) de su preferencia, pero aprovechando los servicios y beneficios de la plataforma.

Visión JEE. En este caso, el único lenguaje soportado es Java, y es el que se debe utilizar para el desarrollo de todos los componentes. Existen sólo dos formas oficiales para acceder a la plataforma JEE con otros lenguajes, la primera es a través de JNI (Java Native Interface) y la segunda, es a través de la interoperabilidad que ofrece CORBA.

4to. Round: Capacidades Empresariales

Las tareas más comunes en cómputo empresarial son: transacciones, distribución de objetos remotos y soporte de servicios Web XML. Veamos cómo las manejan ambas plataformas.

Transacciones
El objetivo de las transacciones, es mantener los datos del sistema coherentes, cuando las cosas no marchan bien. Típicamente recurrimos al acrónimo ACID, para recordar las propiedades que debe tener una transacción: atomicidad, consistencia, aislamiento y durabilidad. Por ejemplo, cuando un cajero automático te entrega una cantidad en efectivo, al mismo tiempo la deduce de la cuenta. Ningún tipo de fallo o imprevisto, debería provocar que el cajero realice una operación, sin realizar la otra. Es decir, todas las partes de la transacción deben aplicarse, o ninguna; y sin importar lo que pase, el sistema se deja en un estado consistente.

• JEE: los desarrolladores pueden codificar la gestión de transacciones de forma explícita (manual), o especificar el desempeño requerido y dejar que el contenedor se encargue (modo automático). En la mayoría de los casos, los desarrolladores intentan delegar el manejo transaccional al contenedor EJB. Manejar manualmente las transacciones, puede introducir errores sutiles en la aplicación; de hecho, el contenedor ha probado ser más eficiente que los desarrolladores.
• .NET: el CLR soporta tanto transacciones manuales, como automáticas. Con las primeras, los desarrolladores inician la transacción, enlistan otros en la transacción, aplican o abortan, y finalizan la transacción. Con las segundas, los desarrolladores definen un comportamiento transaccional de objeto, ajustando un valor de atributo transaccional en la página ASP.NET, un método de servicio Web XML, o una clase. Cuando un objeto se marca para participar en una transacción, automáticamente se ejecutará dentro del alcance de la transacción.

Llamando objetos remotos
Tanto en .NET como JEE, la lógica de negocios puede encapsularse en componentes que existan de manera local (en memoria), o fuera del proceso; en una máquina remota. Como sea, ambas arquitecturas siguen diferentes guías sobre cómo lograr la distribución.

• JEE: la transparencia de localidades es un atributo base de JEE. JNDI encuentra componentes del lado del servidor, tales como JMS Queues o EJBs, los cuales, si se ejecutan en un ambiente con clusters, pueden o no, residir en la misma máquina virtual. Por lo general, todos los accesos a un EJB deben ir a través de interfaces, que permiten al servidor de aplicaciones, implementar su propio balanceo de carga, a través de múltiples nodos para optimizar los tiempos de respuesta y el tráfico. En términos prácticos, la mayoría de los servidores de aplicación, intentan comunicar ejes en la misma VM para minimizar el tráfico de red, y la sobrecarga asociada. Los desarrolladores pueden forzar la ejecución en una misma VM con interfaces locales.
• .NET: con .NET remoting, los desarrolladores pueden llamar objetos remotos distribuidos, a través de dominios de aplicación, procesos y agrupaciones de máquinas. .NET remoting oculta los desagradables detalles del llamado remoto, formatea los mensajes y provee los mecanismos de transporte entre capas. El punto importante es, cómo decidir cuándo usar o no remotos. En .NET no se decide automáticamente distribuir los objetos como en JEE, debido al precio de permanencia en la red. Claro, se debe entender qué se recibe a cambio. En el mundo .NET, los desarrolladores emplean remotos para incrementar la seguridad y facilitar el mantenimiento, pero no para incrementar la escalabilidad; eso se logra de manera simple: ampliando el número de servidores Web.

Servicios Web XML

• JEE: provee soporte para la creación de servicios Web, donde cada EJB de servicio Web puede ser consumidor, y un bean de sesión sin estado, puede proveer un servicio Web. Además, especificaciones como JSR 67, 93, 101 y 10,9, enfatizan el soporte de servicios Web de la plataforma Java, incorporando respectivamente funciones de nomenclatura (naming), búsqueda (lookup), invocación (invocation) y uso (usage).
• .NET: Microsoft colocó los servicios Web como parte del núcleo de .NET. Este contiene los estándares más recientes de servicios XML aceptados, tales como el estándar XML Schema.

Otras Variables a Considerar

Todo ejecutivo que se precie de ser prudente, deberá basar sus decisiones tecnológicas, en una evaluación profunda de las variables del entorno de su propio negocio, en lugar de seguir ciegamente cierta recomendación o dictamen emitido por un tercero. A continuación, enlistamos las variables que la mayoría de los expertos proponen como vitales, para tomar una decisión de esta índole.

Escalabilidad. Debemos reconocer que el futuro no tiene palabra de honor, y las relaciones y dependencias de la empresa con su entorno, pueden cambiar fácilmente. La infraestructura tecnológica debe, entonces, ser capaz de brindar servicio a plataformas heterogéneas, provenientes de nuevos clientes, o de fusiones a nivel empresarial. Si se prevé un alto nivel de heterogeneidad, en las “relaciones tecnológicas” de la empresa, sin duda JEE será la opción más inteligente. De otra forma, la elección queda sujeta a otras variantes.

Integración de sistemas legados. La línea del tiempo, también debe verse en perspectiva con el pasado de la empresa. La integración de sistemas antiguos y de tecnologías en desuso, con los nuevos esquemas, debe planificarse cuidadosamente. Tanto JEE como .NET, proveen herramientas específicas de integración de sistemas legados, dirigidas a segmentos de mercado específicos.

Independencia del proveedor. Hay empresas que consideran vital, no depender exclusivamente de un proveedor final de tecnología, sino beneficiarse de la competencia que existe entre diversas empresas proveedoras. Por otro lado, hay quienes se sienten más seguros al trabajar con un conjunto de herramientas coherentes entre sí, y con un robusto esquema de soporte, debido a que provienen de un sólo proveedor.

Costos de Desarrollo y Mantenimiento. Un cambio o introducción de tecnología, sin una profunda justificación acorde a las políticas del negocio, es decir, dictada por las tendencias del mercado u otros criterios superficiales, puede resultar, en primera instancia, mucho más caro de lo que aparenta. Se deben considerar aspectos de fondo tales como, las capacidades del personal actual, los costos de entrenamiento y transferencia del conocimiento, el soporte existente en el medio, etcétera.

Robustez y/o ligereza. Debemos considerar el tipo de desarrollos que necesita, soporta o provee nuestra empresa. Podemos optar por las herramientas de desarrollo rápido, que una u otra tecnología ofrecen; o probablemente, preferimos una estrategia probada y con un amplio universo de empresas que la soporten. Esto depende de parámetros tales como, la criticidad de los sistemas, y el tiempo deseado de entrega. También es importante decir que, empleando las herramientas apropiadas, un desarrollo robusto no necesariamente requiere un ciclo de producción largo.

Soporte a tecnologías emergentes. Otro punto a considerar, puede ser el de innovación vs. estabilidad. En este sentido, .NET tiende a ser más innovador; incorporando y proponiendo nuevas capacidades. Por otro lado, JEE es más conservador en su adopción de tecnologías, esperando que algo se pruebe bien, y no haya duda de que se mantendrá en el mercado por un buen tiempo, para entonces adoptarlo. Un ejemplo claro de esto, es el soporte a Web Services, donde .NET tomó la batuta, aun corriendo el riesgo de soportar tecnologías antes de que estuvieran estandarizadas; mientras que JEE esperó, antes de entrarle de lleno.

Popularidad de lenguajes. Otro factor que se puede tener en cuenta, es la popularidad de los lenguajes de programación. Esto nos sirve para descubrir la cantidad de personal capacitado en cierto lenguaje, y hacia donde van las tendencias. El índice TIOBE (www.tiobe.com/tpci.htm) es una buena guía para este propósito. A continuación presentamos los resultados más recientesque corresponden al mes de agosto 2006. (Ver tabla 1).

La Decisión Final

Emitir una conclusión del tipo “y el ganador es...”, sería injusto para ambas plataformas. JEE es más maduro, y por lo tanto, es más común encontrarlo en aplicaciones de misión crítica. Por otro lado, al ser más reciente .NET ha aprendido tanto de los aciertos como de los errores de JEE y esto le da cierta ventaja.

En cuanto a la portabilidad, aún domina JEE. Aunque MONO es hoy en día una realidad, el hecho de que sea un producto sin respaldo de Microsoft y que dependa de una comunidad de código abierto, afectan la confiabilidad.

Un aspecto sin discusión, es la diversidad de los lenguajes de programación. .NET ofrece soporte para un extenso número de lenguajes, mientras que JEE únicamente soporta Java. Para una compañía que cuenta con programadores que dominan distintos lenguajes, la elección más cómoda y común, será la plataforma que ofrece soporte para múltiples lenguajes. El hecho de que el lenguaje Java sea hoy en día el más usado en el mundo, puede quizá, atenuar esta diferencia.
Finalmente, concluimos que todo ejecutivo y desarrollador, debe evaluar diversos aspectos, antes de decidirse por una de las plataformas que exploramos. Dicha evaluación, será la que le proporcione un criterio de decisión; ya que el beneficio obtenido por el uso de una plataforma en particular, será dado por el desempeño final de la aplicación, y el costo necesario para implementarla y mantenerla.