Mucho se ha escrito acerca de lo relativa de la respuesta a la pregunta del título. Muchos artículos han explicado extensamente las diferencias entre ambas tecnologías (yo mismo publiqué uno el año pasado). No obstante la mayor parte de los informáticos siguen preguntándose en qué difieren estas 2 propuestas, al parecer las más importantes de la presente época en lo que a desarrollo de software empresarial se refiere. ¿Se puede decir que una sea mejor que la otra en cualquier circunstancia? ¿Y si la respuesta es Depende, depende exactamente de qué?

No puedo negar que yo también he dado la típica respuesta: Depende. Depende de la experiencia que una empresa tenga y con qué tecnologías. Depende del perfil de los profesionales con que se cuente. Depende de con qué proveedor de software la empresa está acostumbrada a trabajar y con qué resultados. Depende de si se cuenta con un área de Arquitectura y los proyectos se planifican obedeciendo a lo que dicte dicha área. Depende si esa área se preocupa de impartir el conocimiento necesario a los analistas y jefes de proyectos informáticos de modo que estos sepan cómo implementar lo que Arquitectura les exige. Depende de si existe la disposición de enseñar a los proveedores externos (los que hacen la pega) el cómo hacerlo, ya que normalmente existe debilidad ahí: la compañía dicta un conjunto de normas, técnicas, tecnologías y buenas prácticas a ser utilizadas, pero los que realmente deben realizar el trabajo no tienen idea y menos la experiencia de cómo implementar lo que se les pide.

Y no menos importante que lo anterior, depende del monto que se esté dispuesto a invertir. Y si con esta última afirmación pensaste: ah claro, si se tiene dinero se invertirá en Microsoft y si no en Java; FARSO, farso, farso, farso. No es la tecnología que se opte lo que determinará los costos. En mi propio artículo de febrero del año pasado apunté a los resultados de un estudio que demostró que para un determinado proyecto, los costos de hacerlo en J2EE y Linux fueron 13 veces mayores que .NET y Windows, sin mayores diferencias en el resultado obtenido. Pero también hay otros estudios con cifras muy distintas. De modo que lo que realmente importa es la manera como se implemente un determinado proyecto.

¿Te parece que más te confundo? Bueno, trataré de darte una respuesta más concreta. Sin embargo, para comprender mejor el presente, para variar debemos conocer algo de historia:

Hace apenas algunas semanas, alguien muy importante para la comunidad informática dijo lo siguiente en una entrevista: ¡Visual Basic hizo más por la programación que los lenguajes orientados a objetos!. ¿Quién crees que dijo esas palabras? Bill Gates, se apresuró en contestar un amigo mío equivocadamente cuando se las mencioné. Pues bien, fue Linus Torvald, nadie menos que el creador del sistema operativo Linux.

Sus palabras hacen notar el fenómeno que significó Visual Basic principalmente hace unos 11 años atrás aproximadamente, en especial entre sus versiones 3 y 6. Antes de Visual Basic desarrollar software empresarial significaba manejarse con lenguajes como C o C++ para soluciones de comunicaciones, integración y middleware; DBase o Clipper para aplicaciones monolíticas con interfaz de usuario y base de datos local en sistema operativo DOS; o COBOL para sistemas de redes basados en poderosos sistemas operativos propietarios IBM, con interfaces de usuario bien rudimentarias. Windows era el sistema operativo que todos tenían y querían, las bases de datos relacionales ya existían y lo único que había para desarrollar aplicaciones con rica interfaz gráfica, comunicándose con bases de datos centralizadas en arquitecturas Cliente-Servidor, era Delphi o PowerBuilder (FoxPro para pequeños grupos de trabajo).

Todas soluciones o muy complejas para el programador promedio, o insuficientes o extremadamente costosas y difíciles de implementarlas en ambientes de desarrollo lejos de las grandes compañías.

Visual Basic le permitió a los programadores desarrollar fácilmente aplicaciones con interfaz Windows y con acceso a bases de datos remotas y centralizadas. La arquitectura Cliente-Servidor estaba al alcance de todos.

No obstante, todo este aparente poder tan al alcance de la mano hizo que miles de desarrolladores alrededor del mundo se ilusionaran con la idea de que tenían la panacea. Pero olvidaron que las interfaces de usuario con conexión a bases de datos no eran suficientes para atender todos los requerimientos corporativos: servicios transaccionales de plataforma cruzada, comunicaciones de alto rendimiento, acuerdos exigentes de nivel de servicio, integración corporativa. Muchas compañías abusaron de Visual Basic y terminaron con montones de aplicaciones cada una atendiendo a una necesidad específica de negocio, pero sin ninguna conexión entre ellas, ninguna arquitectura común, con poco o ningún software reutilizable.

Por otro lado, otra tecnología surgía en paralelo buscando satisfacer esas necesidades que no eran atendidas ni por Visual Basic ni por la mayoría de las tecnologías entonces vigentes. A fines de la década pasada J2EE surge como un framework concebido para el desarrollo de aplicaciones distribuidas y escalables. Sus diversos contenedores, como el contenedor de EJBs o el de Servlets, abstraían de manera magnífica lo que antes era terriblemente complejo de implementar desde cero.

Servicios como transacciones de plataforma cruzada, seguridad, comunicaciones remotas, pool de conexiones a bases de datos o a canales de mensajería, servicios de nombres, contexto HTTP para aplicaciones web, etc., facilitaban desarrollar servicios que se invocaban remotamente o que se comunicaban con sistemas legacy. Las aplicaciones basadas en estándares J2EE se ejecutaban realmente en capas distintas, no solamente lógicas, sino físicas. Más encima todo esto se había diseñado para ejecutarse dentro de máquinas virtuales Java, algo disponible gratuitamente para los principales sistemas operativos existentes. Independientemente de los costos elevados de los contenedores comerciales como WebSphere o WebLogic, la implementación de ambientes de desarrollo con tecnologías J2EE era posible gracias al open source.

Pero tanta maravilla no contaba ni con una arquitectura tan simple para interfaces de usuario como la que tenía Visual Basic, ni contaba con alguna herramienta tan fácil de utilizar.

De modo que llegó el nuevo siglo y contábamos entonces con 2 fuertes tecnologías: una que simplificaba como ninguna otra cosa el desarrollo de interfaces de usuario con conexiones a bases de datos y que, con mucho esfuerzo y no de manera natural, hasta permitía hacer cosas más complejas como plataformas de servicios corporativos. Y la otra que de manera nativa facilitaba mucho el desarrollo de plataformas de servicios corporativos, y que además permitía desarrollar interfaces de usuario, pero con bastante esfuerzo y no de manera natural.

Microsoft sabía que debía ofrecer algo mejor para el desarrollo corporativo y Sun una arquitectura más simple para el lado del cliente. Ni siquiera vale la pena mencionar los esfuerzos de Microsoft llamados DCOM y COM+. Nada interoperables y muy difíciles de administrar. La arquitectura JSP de Sun sí es más digna de mencionar como una solución posible para clientes web, aunque aún no se acercaba a otras alternativas como el ASP de Microsoft y ni al mismo PHP.

Pero para principios de este nuevo siglo, Microsoft sí le dio el palo al gato con toda una nueva plataforma para el desarrollo de software: .NET. Heredaba todo lo bueno que tenía el viejo Visual Basic pero también lo corregía, convirtiéndolo en un lenguaje verdaderamente orientado a objetos y además administrado. .NET además trajo al nuevo C#, lenguaje que rápidamente fue adoptado inclusive por la comunidad Linux. Pero la mayor novedad de todas en realidad venía por el lado de la integración: .NET lo apostaba casi todo a los Web Services y a estándares abiertos basados en XML.

Así que para el 2002 teníamos un panorama algo diferente: por un lado .NET con todas las facilidades para el desarrollo de aplicaciones de escritorio y web (gracias a un fantástico ASP.NET), y ahora más encima con una propuesta de integración absolutamente interoperable basada en Web Services. Y por el otro J2EE que cada vez era mejor y más maduro en lo que hacía.

Web Services en ese momento aún era mirado con ojos recelosos por muchos arquitectos de software. Aún se dudaba de su éxito. J2EE por su parte lograba la interoperabilidad con otras plataformas y tecnologías gracias a su integración con sistemas MOM (Message-Oriented Middleware) como MQSeries entre otros. No obstante estos sistemas MOM eran (y todavía son) costosos y la gente empezó a entusiasmarse con las posibilidades de los relativamente simples y baratos Web Services. De manera que estos últimos fructificaron. Todo el mundo ahora clamaba por los Web Services. Sun fue obligado a incorporarlos también en la especificación J2EE.

No obstante, Sun no implementó los Web Services de la misma manera que Microsoft. Microsoft desde el principio pensó en que estos debían ser desarrollados desde cero y proporcionó las herramientas para facilitarlo. Las tecnologías J2EE trataron de simplemente agregar la máscara de Web Service a componentes EJB ya existentes. De primera esto estuvo bien, cuando aún se desarrollaban Web Services simples, con mensajes XML planos, asegurados simplemente por canales SSL (Secure Socket Layer). Pero cuando empezó a ser evidente que la seguridad del transporte no sería suficiente sino más bien sería necesaria la seguridad a nivel de mensaje, mediante la implementación de estándares WS-S (Web Services – Security) que ya estaban siendo concebidos por OASIS o el W3C, J2EE se atrasó nuevamente respecto de .NET.

En este momento, J2EE (ahora llamado Java EE) ofrece 2 alternativas para la ejecución de aplicaciones distribuidas: RMI (Remote Method Invocation utilizado para la comunicación con y entre Enterprise Java Beans) y Web Services. Microsoft por su parte también ofrece 2 alternativas: Web Services (siempre la principal) y .NET Remoting (la evolución de COM+ pero aún sin merecer mención).

Lo que realmente marca la diferencia entre estas tecnologías de desarrollo de software empresarial actualmente son las herramientas de productividad.

Visual Studio de Microsoft sigue facilitando mejor que nadie el desarrollo de aplicaciones cliente, ya sean estas de escritorio, web o de dispositivos móviles.

En el mundo Java EE existen IDEs (Integrated Development Environment) como Eclipse o Netbeans (y otros basados en esos mismos) que también facilitan el desarrollo de aplicaciones cliente pero no tan bien como Visual Studio. Sin embargo, estos últimos sí permiten el desarrollo simple de aplicaciones distribuidas. Las últimas versiones de estos IDEs cuentan con asistentes generadores de código que crean las distintas capas de una aplicación de manera muy sencilla: crean los EJBs que se comunican con la Base de Datos o con algún canal de mensajería y luego crean la interfaz web que invoca a estos EJBs (ahora con una nueva tecnología web llamada JSF casi tan buena como ASP.NET). Y todo eso haciendo uso de Patrones de Diseño. También permiten el desarrollo de aplicaciones que se comunican via Web Services pero no de manera tan fácil como con RMI. La seguridad sigue siendo muy compleja de agregarles a sus Web Services. La interoperabilidad con Web Services seguros de otras plataformas es muy difícil aún para Java. Aunque esto también está cambiando y ya se pueden ver mejoras en Java EE 5.
Visual Studio no da ninguna facilidad para el desarrollo de aplicaciones distribuidas basadas en .NET Remoting, pero sí para Web Services. En esto último es aún inigualable. Y agregar seguridad a los Web Services de acuerdo a los últimos estándares OASIS mediante los Web Services Enhancements de Microsoft (actualmente en su versión 3) no puede ser más fácil.

Y Microsoft mostró haber tenido una muy buena visión ya que hoy vemos lo de moda que está el concepto de SOA (Service-Oriented Architecture) y de ESB (Enterprise Service Bus), conceptos basados en la implementación de Web Services.

De modo que ahora puedo darte una respuesta concreta a la vieja pregunta: Java EE o .NET. Si es que recién estás frente a la disyuntiva y tienes la opción de elegir considera lo siguiente: Si tu empresa ya posee inversión en algún sistema de mensajería, como MQSeries por ejemplo, y para ustedes sería sencillo basar su interoperabilidad en las características propias de dicho MOM, poseen buenos servidores disponibles ya sean estos Unix o Windows, cuentan con un Arquitecto de Software con experiencia y pueden capacitar a su gente, Java EE puede ser una buena decisión aunque igualmente necesitarán a .NET para ciertas necesidades de negocio puntuales.

Por otro lado, si buscan implementar SOA basándose en Web Services, están conscientes de que tendrán que implementar seguridad a nivel de mensajes, no quieren invertir o seguir invirtiendo en un costoso sistema MOM, .NET puede ser la sabia elección. Pero no cierre completamente las puertas a Java EE. Más de alguna necesidad específica de negocio, como servicios complejos que talvez deban interactuar con sistemas legacy, aún inclusive dentro de un mismo contexto transaccional, probablemente sean más fácilmente implementados dentro de una arquitectura Java EE, pero que igualmente podrán ser accedidos via Web Services por su plataforma .NET.

¿No quedó muy clara la respuesta? Lo lamento, fui lo más concreto que pude ser. Y no olvide: ambos mundos siguen evolucionando. Ya viene la nueva plataforma distribuida Windows Communication Foundation por el lado de Microsoft con la que hasta Sun quiere interoperar y tiene un proyecto para ello, Tango. Y Java EE ya tiene una propuesta interesantísima para interfaz de usuario muy similar a lo que viene con Windows Vista, también basada en XML, y se llama XUI. Peor aún, viene un tercer contendiente en camino, un tal Ruby, pero es materia para otro artículo…