400410304. El camino al futuro

Para ejecutarse, las aplicaciones han de presentarse al ordenador como instrucciones para máquinas específicas de código binario a un modelo dado -o familia- de CPU. No obstante, los programadores tienen un número de opciones de lenguaje para generar esas instrucciones para máquinas. Quizá lo que más nos concierne aquí es el grado de abstracción que ofrece un lenguaje. Más abstracciones significan menos operaciones a dirigir por los desarrolladores.

Los lenguajes de máquinas son lenguajes nativos de ordenadores, los únicos lenguajes entendidos directamente por las CPU. Con la excepción del micro código programable, los lenguajes de máquinas son el nivel más bajo de los lenguajes de programación. Como tales, no ofrecen absolutamente ningún tipo de abstracción. Al consistir totalmente en números, los lenguajes de máquinas se usan muy rara vez para escribir programas porque los desarrolladores han de codificar manualmente –en código numérico– todas y cada una de las instrucciones asociadas con la lógica comercial de la aplicación, además de sus servicios subyacentes, tales como los sockets, registros, direcciones de memoria y pilas de invocación.

Teniendo en cuenta el trabajo asociado con los lenguajes de máquinas, los desarrolladores que desean un control total sobre todos los aspectos de las prestaciones de la aplicación normalmente usan lenguaje de ensamblaje. Los lenguajes de máquinas y los lenguajes de ensamblaje contienen las mismas instrucciones, convirtiéndolos esencialmente en lo mismo. La ventaja de los lenguajes de ensamblaje es la fina capa de abstracción que crean, al presentar instrucciones en forma de nombres. Estas instrucciones nemónicas hacen que sea más fácil escribir programas, que son después transformados en lenguaje de máquinas por los ensambladores.

((Los lenguajes de máquinas son lenguajes nativos de ordenadores, los únicos lenguajes entendidos directamente por las CPU))

Los lenguajes de programación de nivel medio ofrecen el siguiente nivel de abstracción, a la vez que permiten que los programadores mantengan un alto grado de control general. Tipificados por C, los lenguajes de nivel medio ofrecen acceso de nivel bajo a la memoria y nos exigen que codifiquemos de forma explícita la mayor parte de los servicios subyacentes de la aplicación. Y aún así, estos lenguajes pueden también aliviarnos de otras obligaciones, como codificar funciones, variables y evaluación de expresiones.

Tal vez una de las ventajas más significativas de la mayoría de los lenguajes de nivel medio es la portabilidad, que permite el codificado independiente de máquina. Pero a diferencia de los lenguajes de nivel alto, la portabilidad permitida por los lenguajes de nivel medio no está basada en una máquina virtual o un entorno corriente e independiente de máquina. Más bien, se compila la aplicación para distintas plataformas de ordenador y sistemas operativos con cambio mínimo en su código fuente.

Los lenguajes de programación de nivel alto permiten incluso un mayor grado de abstracción, por lo que podemos centrar nuestra atención más completamente en la lógica comercial de la aplicación, en lugar de en los servicios que se necesitan para soportar la CPU.

Los lenguajes de alto nivel a menudo controlan la gestión de los hilos, garbage collection, API, y otros servicios de forma nativa. Java, por ejemplo, depende de una máquina virtual que abstrae todas las funciones del sistema operativo para ofrecer su famosa capacidad “escribe una vez, ejecuta en cualquier parte”. Otros lenguajes de alto nivel incluyen una variedad de lenguajes interpretados y compilados, entre los que se incluyen Basic, C++, C#, Cobal, Perl, PHP, y Python.

Por último, los lenguajes naturales merecen una mención. Dicho simple y llanamente, los lenguajes naturales abruman la interfaz humano/máquina. Unos vocabularios enormes y en constante expansión con significados cambiantes y una gramática bizantina que se emplea de forma inconsistente, hacen que los lenguajes naturales no sean adecuados para los ordenadores.

Los lenguajes de nivel alto simplifican la programación compleja mientras que los lenguajes de nivel bajo tienden a producir un código más eficiente. Al usar lenguajes de nivel alto, podemos desglosar una aplicación compleja en componentes más pequeños, aunque el precio a pagar por la conveniencia es, con mucha frecuencia, la eficiencia del código. Por lo tanto, cuando las aplicaciones tienen que cumplir con ciertos niveles de prestaciones, los desarrolladores pueden renunciar a la sencillez de codificar en lenguajes de nivel alto y decantarse por lenguajes de nivel bajo.

El continuo de la arquitectura de la computación

Desde la computación con grandes ordenadores mainframe a la de rejilla o grid, cada arquitectura de computación se ha desarrollado en respuesta a las demandas que las empresas hacen a sus departamentos de TI. Similar a la gama de opciones de lenguaje de programación, cada arquitectura de computación presenta un entorno único.

Los ordenadores grandes o mainframe usan una arquitectura de anfitrión/terminal, mediante la cual todo el procesado de la aplicación se ejecuta en el anfitrión del mainframe. Los usuarios múltiples pueden acceder al mainframe de forma simultánea mediante terminales “dumb” (en inglés “tonto” o “corto de mente”,) locales o remotas –o software de emulación de terminales–, que simplemente muestran las consultas y los resultados. Introducidos en la década de los 1950, los mainframes siguen siendo populares en las organizaciones grandes que necesitan fiabilidad, disponibilidad y servicialidad extremas.

Los mainframe son ideales para aplicaciones de misión crítica que procesan cantidades de datos como el procesado de tarjetas de crédito, administración de cuentas bancarias, operaciones de mercado y PRE. Las aplicaciones que requieren de una gran seguridad es otro de los puntos fuertes de los mainframe. En la actualidad, los grandes distribuidores de mainframe incluyen a IBM, Hewlett-Packard y Unysis.

((Los lenguajes naturales merecen una mención. Dicho simple y llanamente, los lenguajes naturales abruman la interfaz humano/máquina. Unos vocabularios enormes y en constante expansión con significados cambiantes))

Los mini computadores emplean la misma arquitectura de anfitrión/terminal que los computadores grandes pero sirven normalmente a una población de usuarios menor. Lanzado en 1959, la era del mini-ordenador fue iniciada por Digital Equipment Corporation con la introducción de su PDP-1. A un precio sorprendentemente bajo de 120.000 $, el PDP-1 extendió el alcance de la computación a un público más amplio.

Con el tiempo, los mini-ordenadores se transformaron básicamente en sistemas y servidores de medio alcance, pero sus funciones siguen siendo las mismas – el procesado de aplicaciones para múltiples usuarios. En las pequeñas y medianas empresas, los sistemas de medio alcance normalmente ejecutan aplicaciones comerciales de carácter general. Las empresas grandes normalmente las utilizan para operaciones a nivel de departamento. Entre los distribuidores, se incluyen IBM, Hewlett-Packard, and Sun Microsystems
Alejándose del modelo de alojamiento, la arquitectura de cliente/servidor reparte la carga del procesado de la aplicación entre uno o más servidores y el ordenador cliente del usuario.Cliente/servidor fomenta el que los departamentos de informática seleccionen las plataformas adecuadas de hardware y software para las funciones de cliente y servidor.

Por ejemplo, los servidores de sistemas de gestión de bases de datos con frecuencia funcionan en plataformas especialmente diseñadas y configuradas para realizar consultas, mientras que los servidores de ficheros normalmente funcionan en plataformas con elementos especiales para administrar ficheros.

Cliente/servidor fue una respuesta a las aplicaciones monolíticas y aisladas que funcionaban en los mini-ordenadores y en los ordenadores grandes. Buscando aplicaciones integradas, sensibles y globales, las empresas se dirigieron a la arquitectura de cliente/servidor para dar soporte a una gama completa de procesos comerciales – desde centros de llamadas a CRM y más allá. Entre los distribuidores de cliente/servidor están Oracle y PowerSoft.

El modelo de computación de Internet definido por la World Wide Web introdujo un nuevo giro al modelo de procesamiento distribuido de cliente/servidor. Mientras que el cliente/servidor dependía de software dedicado al lado del cliente para ejecutar las aplicaciones, la computación de Internet depende de una aplicación cliente –el navegador de web– para presentar las GUI de incontables aplicaciones mientras que los servidores back-end procesan la masa interior de la aplicación.

El cambio del “cliente gordo” del cliente/servidor al “cliente delgado” de Internet nos brinda enormes ventajas. Las actualizaciones de software se hacen solamente en el servidor y no incluyen ya un componente de lado del cliente que tenga que ser distribuido a la base del usuario.

Mientras tanto, las aplicaciones tanto de dentro como de fuera del cortafuegos dan a los usuarios autorizados acceso disponible para cualquier aplicación capacitada por web, desde boletines informativos de empresa y ventajas de RRHH al comercio electrónico o los servicios financieros. Entre los distribuidores importantes de Internet están Sun y BEA.

La arquitectura de computación de rejilla está emergiendo para permitir que las compañías alisen la arquitectura dominante de Internet de tres categorías (en inglés, tier). En la actualidad, el back-end de la aplicación web estándar es procesado por un servidor web low-end , un servidor de aplicación high-end y un servidor de bases de datos high-end o algún otro almacén de datos. Las Rejillas pueden fusionar el servidor web y las categorías de servidores de aplicación en una sola categoría de servidores de consumo paralelos, que se ejecutan en Linux.

Una aplicación web desplegada en una arquitectura de rejilla ofrece un ahorro significativo de dinero frente a la misma aplicación que se ejecuta en tres categorías. En distintas configuraciones de hardware, la computación de rejilla se está usando con éxito en una variedad de aplicaciones, desde el modelado de mercados financieros y la simulación de terremotos hasta el servicio de millones de páginas web al día. En el terreno de las rejillas, las tecnologías líderes son Linux y ordenadores basados en x86.

Progresión del lenguaje de programación

Conforme cambian las plataformas de computación los lenguajes elegidos cambian también. Mientras que Cobol dominó en la época de los ordenadores grandes y de los mini-ordenadores, puede que la era del cliente/servidor haya presentado a los desarrolladores con el mayor número de opciones de lenguaje.

Los desarrolladores podían elegir de entre un número de lenguajes populares que incluyen Visual Basic de Microsoft, Delphi de Borland, PowerScript de PowerSoft. Estos lenguajes eran todos lenguajes esencialmente con alguna forma de tipos (en inglés, “somewhat typed”), y seudo-interpretados. Y todos ellos fueron reemplazados por Java, un lenguaje de tipos fuertes (“strong typed”), seudo-interpretados y con Visual basic.NET , un lenguaje con alguna forma de tipos y pseudo-interpretado.

Durante la era de Internet, las organizaciones ejecutaban una variedad de sistemas operativos de servidor, en la categoría media, entre los que se incluyen Solaris, AIX, HP-UX, Irix, y Windows NT En muchas empresas, uno de los requisitos más importantes era que las aplicaciones fueran portátiles entre dos o más plataformas, para evitar ser condicionado por un solo distribuidor.

((La arquitectura de computación de rejilla está emergiendo para permitir que las compañías alisen la arquitectura dominante de Internet de tres categorías))

Si las aplicaciones de una organización sólo funcionaban en una plataforma, la organización perdía gran parte de su potencial de negociación y el distribuidor podía sacarle más precio en el siguiente ciclo de actualizaciones.

Java fue originalmente diseñado para ejecutarse en clientes colocados arriba y después en clientes de PC, así que el lenguaje y su tiempo de ejecución se diseñaron para ser portátiles, objetivo que desde luego cumplió. Al usar servidores de NetDynamics y KIVA, algunas empresas han empezado ya a ejecutar Java en el servidor.

Además, Java ofrecía algunas de las ventajas que los desarrolladores disfrutaban en lenguajes de la época del cliente/servidor, tales como garbage collection y niveles superiores de API para características de sistemas operativos que abstraían la complejidad.

Java pronto consiguió una masa crítica de distribuidores que soportaban la plataforma. Todo lo que existía bajo el cielo pronto tuvo una API Java, incluidos Oracle, SAP, Tibco, CICS, MQSeries, etc. En un par de años, estas aplicaciones y servicios eran ya accesibles a través de las API estandarizadas que se tornaron en J2EE, lo que continuó hasta dominar el entorno ce la computación corporativa de la era de Internet.

Lo que Java no co consiguió ofrecer fueron las herramientas tipo 4GL. No obstante, ningún otro lenguaje tenía herramientas tipo 4GL para aplicaciones web, así que su ausencia no fue una sorpresa. Por desgracia, los años han pasado, y la inmensa mayoría de aplicaciones J2EE se siguen compilando a mano.

Una lección que Microsoft ha aprendido es que para que las API puedan tener herramientas, tienen que ser desarrolladas de forma concurrente con la herramienta. Lo que es más, tanto las API como las herramientas deberían depender de meta-datos fácilmente externalizados. Las API de Java siempre se escribieron en base a los méritos de las mismas API y las herramientas posteriores eran predominantemente generadores de código evitados por los programadores.

Las API de Java se fueron convirtiendo en un cenagal de incomprensibles e inconsistentes API. La programación de incluso la aplicación más sencilla demostró ser complicada. Según Gartner, más del 80 por ciento de los despliegues de J2EE son aplicaciones servlet/JSP-a-JDBC. Es decir, la inmensa mayoría de esas aplicaciones son básicamente front-ends de HTML a bases de datos relacionales.

Resulta irónico que gran parte de lo que hace que Java sea complicado es la miríada de extensiones de ayuda de banda, como los genéricos y las plantillas JSP, que se añadieron para simplificar el desarrollo de ese tipo de aplicaciones básicas.

A pesar de todo ello, Java y J2EE han llegado a dominar totalmente la era Internet de la computación corporativa. Estas tecnologías seguirán dominando hasta que las empresas inicien su migración a las arquitecturas de rejilla de próxima generación y sus lenguajes relacionados.

El surgimiento de la Rejilla

La computación en rejilla se aprovecha de los ordenadores en red, creando un entorno virtual que distribuye el procesado de aplicaciones a través de una infraestructura paralela. Las rejillas pueden utilizar un número de modelos computacionales para lograr su objetivo de alto rendimiento.

La computación heterogénea en rejilla depende de una mezcla de ordenadores distintos y distribuidos en distintas zonas geográficas para resolver masivos problemas computacionales tales como la simulación de terremotos. Ordenadores grandes en California o Massachussets pueden estar trabajando con grupos de sistemas de medio alcance en China y cientos de PC en Europa para resolver un único problema.

El impulso hacia la computación heterogénea de rejilla surgió de la pura frustración. Con un acceso limitado a recursos escasos y caros como las súper-computadoras, los usuarios vieron que los problemas que requerían de un extensivo uso de la computación podían ser partidos en trozos y distribuidos entre múltiples máquinas de coste más bajo y que estaban ya disponibles. Normalmente, los cálculos resultantes podían ser entregados de forma más rápida y económica.

Con las ventajas de la computación en rejilla, la aparición de las rejillas homogéneas sencillamente refleja el hecho de que los grupos de PC de bajo coste y homogéneos que se ejecutan en Linux pueden representar una auténtica alternativa a las arquitecturas de computadores de mayor coste. Numerosas empresas de Wall Street ejecutan ahora simulaciones financieras complejas, como los cálculos de Monte Carlo, en grandes grupos de máquinas Linux.

((Con las ventajas de la computación en rejilla, la aparición de las rejillas homogéneas refleja que los grupos de PC de bajo coste que se ejecutan en Linux pueden representar una alternativa))

En la web, el resultado masivo ofrecido por la computación de rejilla toma un significado distinto. En vez de centrarse en solucionar un solo problema –como la secuenciación del genoma humano, por ejemplo– una rejilla puede concentrarse en ejecutar una única tarea, como la de dar servicio a páginas web. Portales web como Google, Yahoo y Amazon han demostrado todos la eficacia de la ejecución de miles de máquinas Linux básicas como servidores de Web.

Evidentemente, la arquitectura en rejilla funciona para muchas y conocidas empresas de Internet. Y ahora, los usuarios están empezando a mudar aplicaciones de transacciones a la arquitectura de rejilla.

La naturaleza de todo o nada que tienen las aplicaciones de transacciones puede hacer que el traslado a la computación de rejilla como base sea un tema delicado para empresas que están acostumbradas a ejecutar estas aplicaciones en arquitecturas de gama alta, que se consideran más sólidas y fiables. Por otro lado, las ventajas de la rejilla pueden demostrar ser un atractivo irresistible.

Lenguajes de rejilla

Independientemente de cuándo concluyan en última instancia las aplicaciones de transacciones en una rejilla, las TI se están ya metiendo en un sutil cambio de paradigmas, alejándose de las cajas SMP más grandes, que ejecutan sabores propietarios de UNIX y acercándose a rejillas grandes de máquinas de uno a dos procesadores x86 que se ejecutan en LINUX. Estas máquinas dominan ya el mercado de servidores web de front-tier.

Ahora están empezando a aparecer en el back-end con productos como Oracle RAC, la versión de Oracle capacitada para rejillas. El tránsito a rejilla afectará pronto a la categoría media, pero está retrasada por las implementaciones J2EE. Estas aplicaciones se compilaron para funcionar en pequeños grupos de máquinas con procesadores múltiples, en lugar de en grandes grupos de máquinas con un solo procesador.

A diferencia de arquitecturas anteriores, la rejilla no tiene el urgente requisito de la portabilidad. Las empresas ya no están atadas a un distribuidor cuando ejecutan Linux en cajas blancas x86. En consecuencia, no tienen ningún problema con las aplicaciones que sólo funcionan en Linux/x86.

El pie de página a esta regla de la portabilidad afecta a las empresas que necesitan que las aplicaciones se desarrollen en máquinas basadas en Windows. Para estas empresas, el único requisito de portabilidad es la capacidad de desarrollar en Windows y desplegar en Linux.

Básicamente, todas las aplicaciones empresariales actuales producen texto, bien sea HTML para los navegadores web o XML para otras aplicaciones. Con el asalto a los servicios web, todos los recursos back-end estarán pronto ofreciendo XML en lugar de datos binarios. La aplicación corporativa media va a ser una gran bomba de texto, tomando XML del back-end, transformándolo de alguna forma y produciendo bien HTML o XML.

Con esto en mente, surgen obvios requisitos para un lenguaje de programación lo mejor adecuado para soportar aplicaciones corporativas en un entorno de rejilla.
– Control rápido de XML (datos dinámicos con tipos fluctuando)- Procesamiento rápido de texto en objetos y fuera de objetos.
– Gestión óptima del flujo de control, que es la mayor parte de de la lógica limitada de la mayoría de las aplicaciones.
– Mínima portabilidad (Linux/x86 y Windows/x86)- Mínima abstracción (una fina lámina sobre el sistema operativo para servicios del sistema).
– Sintonización específica para máquinas de uno o dos procesadores x86.

Teniendo en cuenta estos requisitos, a Java no le va bien: – Java es un lenguaje de tipo fuerte que no controla datos XML con facilidad, lo que es inherentemente no estructurado.
– Java es penosamente lento en procesar texto porque no puede manipular cadenas directamente.
– Java es estupendo para aplicaciones complicadas pero no es el más adecuado para especificar el flujo del control.
– Java ofrece la máxima portabilidad, lo que un exceso para las aplicaciones de rejilla.
– Java ofrece la máxima abstracción con una enorme máquina virtual que se asienta entre la aplicación y el sistema operativo y es un exceso para las aplicaciones de rejilla.
– La mayoría de las implementaciones J2EE están afinadas para cajas SMP de 4-16 procesadores.

Para las aplicaciones que se despliegan en arquitecturas de rejilla, Java no basta. Lo que necesitan los desarrolladores es un lenguaje scripting de “tipo suelto” (loosely typed) para facilitar la encapsulación a XML y que pueda procesar texto de forma eficiente. El lenguaje debería estar muy bien adecuado para especificar flujo de control: Debería ser una fina lámina sobre el sistema operativo.

La mayoría de las distribuciones Linux ya empaquetan tres lenguajes así: PHB, Python y Perl. PHB es con mucho el más popular. A Python se le considera el más elegante, si no extraño. Perl es el seguro y fiel caballo de tiro. Los tres lenguajes son open source y gratis. El uso de PHP se ha disparado en los últimos años.

Elementos que conciernen a la rejilla

Como todas las arquitecturas y lenguajes de computación que vinieron antes que ella, la rejilla viene con su propio conjunto de retos y puntos a compensar. Por ejemplo, hay distintas semánticas adicionales y modos de fallo asociados con el modelo de programación asincrónico de la rejilla, especialmente en las aplicaciones distribuidas de gran escala.

Quizá la mayor diferencia está en que el software tiene que dar por sentado que las máquinas van a fallar, y a fallar con regularidad. Ello implica que hay que incorporar la redundancia a la capa del software. Al invocar a la lógica, los programadores no deberían estar pensando en invocar a una máquina específica, que es el modelo sincrónico tradicional RPC.

En vez de eso, los programadores deberían pensar en invocar a un servicio. En el momento de ejecución, el servicio podría de hecho estar ejecutándose en la misma máquina o en distintas máquinas.

La mayor abstracción conceptual que los programadores necesitan entender es que las aplicaciones tienen que evolucionar a un conjunto de servicios de manera que puedan ser repartidos por toda la rejilla. Tener un bucle de evento principal y ejecutar lógica secuencial puede desplegar a una rejilla, pero este tipo de modelo asciende de forma vertical en el hardware, no de forma horizontal.

((Para las aplicaciones en arquitecturas de rejilla, Java no basta. Lo que necesitan los desarrolladores es un lenguaje scripting de “tipo suelto” (loosely typed) para facilitar la encapsulación a XML y que pueda procesar texto de forma eficiente))

Obviamente, los sitios web enormemente escalables que hay hoy en uso representan el primer uso a gran escala de este tipo de arquitectura. Las interacciones de web son inherentemente atómicas.

Por ejemplo, el carro de la compra del usuario A no tiene nada que ver con el carro de la compra del usuario B. La tarjeta de crédito del usuario A puede ser procesada independientemente de la tarjeta de crédito del usuario B. En un sitio de comercio electrónico, el único recurso que tienen que compartir realmente estos usuarios es el sistema de inventario y el servicio de rastreo del remitente externo.

La rejilla ha evolucionado desde la computación numérica –en la que cosas como simulaciones de airbag se distribuirían entre numerosas máquinas– a servir a multitudes de usuarios web. El nivel siguiente superior es dar servicio a las solicitudes sobre datos compartidos; por ejemplo buscando mediante el buscador de Google y navegando redes sociales.

Google lo tiene un poco más fácil porque a ellos no les importa realmente si una búsqueda es ligeramente diferente cada vez que realizamos una, así que pueden actualizar gradualmente los índices a través de los grupos. Ese problema es un poco más confuso y los usuarios no lo notan.

Las redes sociales son algo diferentes y han tenido muchos problemas de escalabilidad. Esencialmente, todo el gráfico de objetos de las relaciones sociales tiene que ser accesible en tiempo real para todos los usuarios web independientes. Friendster (www.friendster.com/ ) resolvió este problema al usar PHP para dar servicio a las solicitudes de web y usar un servicio back-end que tenía el gráfico del objeto en la memoria. En este modelo híbrido, al constructor de la red social se le considera esencialmente un servicio de back-end, como el sistema de inventario.

Una última consideración tiene que ver con el mantenimiento. Estos sistemas son tremendamente difíciles de depurar. Ha habido muchas herramientas caseras para hacer esto, pero es una solución emergente.

Desde una perspectiva de control, administración y análisis, todos los principales distribuidores de sistemas de gestión tienen soluciones para gestionar grandes grupos de máquinas base ya hace años. Van mejorando, pero hay muchas opciones.

El futuro del scripting

PHP, Python, y Perl siguen siendo algo inmaduros en términos de sus bibliotecas de empresa, y sus capacidades de servicios web están en pañales. A pesar de ello, tienen los ingredientes necesarios para cumplir los requisitos de la siguiente fase de computación corporativa de las aplicaciones de “bombeo de texto”
Además de ser gratis y open source, estos lenguajes son fáciles de aprender y usar. PHP, Python y Perl están preparados para seguir el rastro blasonado por Linux y Apache y penetrar profundamente en el mercado corporativo. La versión más reciente de PHP no se distingue virtualmente de la de Java, hasta el punto de que tiene casi la misma sintaxis y claves.

Fuera del campo de los open-source, Microsoft ha creado Zen, anteriormente denominado “X#” ( http://research.microsoft.com/~emeijer/Papers/XML2003/xml2003.html->http://research.microsoft.com/~emeijer/Papers/XML2003/xml2003.html->http://research.microsoft.com/~emeijer/Papers/XML2003/xml2003.html) ), un lenguaje nativo de XML para su “Common language runtime” (CLR). Visual Basic es discutiblemente el lenguaje scripting más popular del mundo, y Windows está bien afinado para las máquinas de uno a dos procesadores.

Mientras Microsoft siga en escena, con toda probabilidad los desarrolladores podrán elegir entre .NET, Java, y PHP/Python/Perl. Sin embargo, cuando la aplicación esté en una arquitectura de rejilla, los lenguajes de scripting open source dominarán. DDJ