SG #11

Anti-patrones: la mejor forma de hacer un pésimo sistema de software.

Anonymous — Mon, 17 Sep 2007 19:34:19 +0000

Anti-patrones: la mejor forma de hacer un pésimo sistema de software.

Anonymous Mon, 09/17/2007 - 14:34

Publicado en

SG #11

Prácticas

Autor

Javier González Sánchez

Los anti-patrones, también llamados trampas, son ejemplos bien documentados de malas soluciones para problemas. Se estudian a fin de poderlos evitar en el futuro, y en su caso, para que su presencia pueda ser reconocida fácilmente al investigar sistemas disfuncionales durante una auditoria.

El término anti-patrón se origina como una contra parte al término patrón, acuñado en arquitectura de software, para definir las buenas prácticas de programación, diseño o gestión de sistemas. De tal manera podríamos hablar de que un sistema “bien hecho” está lleno de patrones, y debería carecer de anti-patrones; al menos ese sería un sistema ideal.

Si aplicamos una analogía social, podríamos decir que si a tú, amigo lector, no caes en el anti-patrón (nombrémosle estereotipos) de criminal, terrorista, pervertido, drogadicto, brujo, dictador, y similares, entonces podríamos afirmar que no eres una mala persona. Lo cual no implica, que seas buena; para serlo deberías, no sólo no encajar en los anti-patrones mencionados, sino además, cumplir con uno o más patrones (llamémosle cualidades): honesto, trabajador, buen hijo y/o buen padre, etcétera.

Los anti-patrones en arquitectura de software, son similares a sus análogos sociales, soluciones negativas, acciones que presentan mayores problemas que soluciones. Sin embargo, representan un camino fácil y rápido. Pero continuando con la analogía, podríamos pensar que si necesitas dinero, tienes dos opciones: el patrón (buen comportamiento) trabajar arduamente o el anti-patrón (rápido y con consecuencias a largo plazo) robar un banco.

El mismo concepto se aplica fácilmente en ingeniería, y en otras actividades donde esté presente el esfuerzo humano. Así, anti-patrones como reinventar la rueda, la cosa, el programa Dios, casarse con el diablo, la tubería de la estufa, corn cob (juntos pero no revueltos), etcétera. Dejan la enseñanza de cuál es la mejor forma de no hacer sistemas de cómputo.

En la elaboración de un sistema, intervienen al menos, diversos actores: arquitectos de software, administradores de proyecto y desarrolladores. Para cada uno de ellos, existen anti-patrones que describen comportamientos y soluciones incorrectas Los anti-patrones (una vez conocidos) constituyen para cada uno de los actores involucrados, descripciones de problemas recurrentes en la construcción de software, les proporcionan un vocabulario común para identificar problemas y discutir posibles soluciones y les sugieren pasos para la re-ingeniería, y re-organización estructural de un sistema.

Anti-patrones de Codificación

Revisemos algunas técnicas para codificación incorrecta de software.

1. Lava Flow. Algo así como “programar al estilo volcán”. Es construir grandes cantidades de código de manera desordenada, con poca documentación y poca claridad de su función en el sistema. Conforme el sistema avanza en su desarrollo, y crece, se dice que estos flujos de lava se solidifican, es decir, se vuelve mucho más complicado corregir los problemas que originan, y el desorden va creciendo geométricamente. Esto se hace patente cuando: 1. Se declaran variables no justificadas. 2. Se construyen clases o bloques de código muy grandes y complejas sin documentar, o que no se relacionan claramente con la arquitectura. 3. Usando un inconsistente y difuso estilo de evolución de una arquitectura. 4. Cuando en el sistema existen muchas áreas con código por terminar o reemplazar. 5. Y claro, cuando dejamos código sin uso abandonado; interfaces o componentes obsoletos en el cuerpo del sistema. Los resultados son predecibles: conforme los flujos se endurecen y solidifican (se escribe código y pasa el tiempo), rápidamente se vuelve imposible documentar el código o entender su arquitectura lo suficientemente bien como para hacer mejoras.

2. The God.- Un programa omnipresente y desconocido. Aquel sistema donde una sola clase ó modulo (la función main o equivalente) hace todo. Así que el programa es un solitario y único archivo de muchísimas líneas. En consecuencia, tenemos un código desorganizado y fuertemente interdependendiente.

3. Golden Hammer.- También conocida como la técnica de la barita mágica. Es un vicio relacionado con aferrarse a un paradigma, para solucionar todos los problemas que se nos presenten al desarrollar sistemas, como por ejemplo, siempre querer usar el mismo lenguaje de programación para todos los desarrollos, sea o no conveniente. Es el caso de enamorarnos de .Net, de Java, de PHP. Es importante comprender que cada uno tiene capacidades y limitaciones en aplicaciones particulares. En consecuencia se trata de, uno, el uso obsesivo de una herramienta, y dos, una terquedad de los desarrolladores para usar un paradigma de solución en todos los programas. Lo cual conlleva ocasionalmente a consumir mucho más esfuerzo para resolver un problema.

4. Spaghetti Code.- Se dice de una pieza de código fuente no documentado, donde cualquier pequeño movimiento convulsiona la estructura completa del sistema. En expresión coloquial: codificar con las... los “pies”. A diferencia del estilo volcán, donde la crítica es a la forma en que el sistema crece (se anexan módulos), aquí la crítica es a la forma en que se escribe cada una de las líneas, desde la indentación hasta el lenguaje o lenguajes utilizados y su interacción. Ya en el contexto spaghetti, si mezclamos más de un lenguaje de programación en el mismo archivo, el spaghetti es más sabroso. La receta clásica con lenguajes scripts del tipo PHP con HTML y sazonado con JavaScript, ¡es delicioso! (entiéndase un enorme problema). El origen del spaghetti es regularmente un programa creado para hacer una pequeña demostración, que termina, en un dos por tres, trabajando como producto final. Donde está el problema, bien podemos citar lo siguiente como ejemplos: 1. 50% del tiempo de mantenimiento se invierte en entender al sistema original. 2. El spaghetti es causa directa del síndrome del programador desesperado: ¡mejor reescribimos todo el programa! 3. Y obviamente el reuso es imposible. Pero si para colmo, tenemos sólo un chef, o en el contexto un “Programador Solitario”. ¿Quién era ese hombre tras el monitor? Que no está disponible para explicarnos su receta. Simplemente se tienen problemas, muchos problemas.

5. Fantasmas.- Demasiadas clases en un programa o tablas en una base de datos. Varias clases o tablas con mínimas responsabilidades. Muchas veces se utiliza para disfrazar la presencia del anti-patrón The God. Se colocan clases inútiles, que disfrazan el hecho que todo el sistema se encuentra construido en uno, o unos cuantos archivos, módulos o clases. Este anti-patrón sugiere un modelo de análisis y/o diseño inestable: el diseño no coincide con la implementación, y por ello es imposible hacer extensiones al sistema, porque entre tanto “fantasma”, encontrar los elementos relevantes es imposible.

Anti-patrones de Arquitectura

Ahora consideremos las malas técnicas para definir componentes y relaciones en el sistema, es decir, su arquitectura. Si los desarrolladores tienen una colección de malas costumbres de codificación (anti-patrones) a su alcance, los arquitectos no nos quedamos atrás. Veamos:

6. Reinventar la rueda.- Se refiere a reimplementar componentes que se pueden conseguir prefabricados de antemano, y hacer poco reuso en el código. En breves palabras: querer hacer todo uno mismo. Y hablaríamos de: 1. Poco nivel de reuso en el código, reuso de un proyecto a otro, con lo cual cada proyecto está comenzando desde cero. 2. Constantemente se reescriben fragmentos de código con la misma funcionalidad. 3. Con el consecuente gasto inútil de mano de obra y tiempo en reimplementar cosas, que ya estaban hechas. 4. El software se vuelve innecesariamente más denso.

Lo anterior, por lo regular, a causa de poco conocimiento del trabajo ya existente por parte del arquitecto, lo que conlleva a buscar soluciones para problemas ya solucionados.

7. Casarse con el diablo.- Crear una dependencia hacia un fabricante que nos provee de alguna solución (componentes). El problema es inminente: 1. Se depende completamente de lo que el vendedor haga. 2. La calidad de los productos del proveedor nos comprometen. 3. El vendedor nos tiene agarrados. Cito como ejemplo, el caso de una de las universidades más importantes del país, cuyo desarrollo casi completo del sistema de administración escolar, está realizado sobre PL/SQL en Oracle. Ellos necesitan seguir pagando las licencias de Oracle para mantenerse operando. Aún cuando los nuevos desarrollos los estén elaborando ya en otras plataformas Java y PhP, entre otras. Tienen cinco años de desarrollos en PL/SQL, que no los dejan dejar de pagar licencias. No es que Oracle sea malo. Sin embargo, puede ser caro en extremo para una universidad pública.

8. Stovepipe.- Cocinado en “caliente”. Es la forma breve de referirse a la creación de islas automatizadas dentro de la misma empresa (cada departamento crea su propio subdepartamento de sistemas). “Islas” independientes, y en conflicto unas con otras. Cada isla desarrolla la parte del sistema que necesita para satisfacer sus requerimientos, sin preocuparse por el resto (no existe un plan o eje guía), el escenario resultante implica una pobre o nula interoperabilidad, obviamente, no existe el reuso y, consecuentemente se incrementan costos. Contrario a lo que se podría suponer, cada vez es más común este tipo de acciones, dada la premura de departamentos específicos dentro de una macro-empresa, por contar con acceso a Tecnologías de Información.

Hablamos de un escenario donde prevalece: 1. Una falta de estrategia tecnológica de la empresa. 2. Falta de estándares. 3. Falta de perfil de sistema. 4. Falta de incentivos para la cooperación en el desarrollo de sistemas. 5. Falta de comunicación. 6. Falta de conocimiento sobre los estándares tecnológicos. 7. Falta de interfaces para la integración de sistemas.

Anti-patrones de Administración de Proyecto

Finalmente, los administradores tampoco están exentos de seguir ciertos anti-patrones:

9. The Mythical Month Man.- Mejor conocido como en el entorno como el “súper equipo de programadores”. Consiste en la creencia de que asignar más personal a un proyecto, acotará el tiempo de entrega. Regularmente como una forma desesperada de intentar corregir retraso del proyecto. Llega un punto donde entre más personal se asigne, más se retrasa el proyecto.

10. Project Miss-management.- La jefa o el jefe que no saben coordinar. El proyecto se descuida y no se monitorea de manera adecuada, es muy difícil de detectar en etapas iniciales, pero repentinamente emerge de golpe y suele voltear de cabeza la situación del proyecto. Se manifiesta con retrasos en las fechas de entrega y/o áreas incompletas.

11. Corncob.- Los empleados se obstaculizan unos a otros. Personas conflictivas o difíciles de tratar que forman parte del equipo de desarrollo, desvían u obstaculizan el proceso de producción, porque transfieren sus problemas personales o diferencias, con otros miembros del equipo al proyecto. Bajo esta circunstancia, el proyecto no se desarrolla correctamente aunque el personal es bueno.

Conclusión

El listado de anti-patrones es muy amplio, casi tanto como el de patrones. Recomiendo a lector la consulta adicional de los siguientes: La técnica POCP (programación orientada a cut & paste). La técnica CTE (cubre tus errores). La técnica de morir planeando, la de la navaja suiza; la técnica del viejo y poderoso Duke de York, la técnica de la esponja, el supervisor paranoico, y la técnica de la pelea.

Algunos de estos patrones, son incluso irrisorios, errores tan comunes que se supondría nadie podría cometerlos, y sin embargo, reflexionemos, cuántos de nosotros, estudiantes, profesionistas, es la primera opción a la que recurrimos. He deseado sólo comentarlos, no obstante, para cada uno de estos, existe un análisis profundo y minucioso de sus causas, síntomas, consecuencias y tratamiento. Conocer los anti-patrones es útil para refabricar, migrar, actualizar o realizar reingeniería.

Con el avance tan vertiginoso de la tecnología informática, resulta interesante comentar que las mejores prácticas de una época, pueden evolucionar y convertirse en anti-patrones en el lustro siguiente. Hoy día, podemos citar, por ejemplo, la programación estructurada va en camino de serlo en cierto contexto: “solución sencilla y rápida con consecuencias negativas a largo plazo”.

Referencias

J2EE AntiPatterns. Bill Dudney, Stephen Asbury, Joseph Krozak, and Kevin Wittkopf. Ed. John Wiley & Sons, 2003. ISBN: 0471146153.
Antipatterns: Refactoring Software, Architectures, and Projects in Crisis. William J. Brown. Ed. John Wiley & Sons, 1998. ISBN: 0471197130.
Antipatterns in Project Management. William J. Brown. Ed. John Wiley & Sons, 2000. ISBN: 0471363669

Bio

Javier González Sánchez es profesor de tiempo completo del Tecnológico de Monterrey campus Guadalajara y consultor independiente en arquitectura de software. Cuenta con una maestría por el CINVESTAV. http://javiergs.com

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

Anonymous — Mon, 17 Sep 2007 18:59:21 +0000

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

Anonymous Mon, 09/17/2007 - 13:59

Publicado en

SG #11

Autor

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.

Bio

Esmeralda Pita, Alberto González, Enlai Pensado, Yuri Kotsarenko, Luis Riojas.