Tendencias

Tecnologías y Herramientas para el desarrollo de aplicaciones en Internet

Internet

Noviembre/2000

Marino Posadas es MVP en .NET Framework, Microsoft Certified Solution Developer (MCSD), MCAD (Microsoft Certified Application Developer en .NET), MCT(Microsoft Certified Trainer) y autor de numerosos artículos para revistas especializadas, así como de varias obras editadas por Editorial Ra-Ma en solitario y junto a Grupo EIDOS.

La rápida evolución de Internet está forzando literalmente a tomar posiciones activas a muchas empresas, por un lado, para evitar la obsolescencia, y por otro, para aprovechar las posibilidades de negocio.

El segundo objetivo es, por fuerza mucho más prosaico, y también mucho más rentable. Las noticias económicas nos abruman respecto a negocios fabulosos realizados por Internet: hay grandes empresas que compran empresas pequeñas por cantidades espectaculares por el sólo valor añadido de que la empresa pequeña ha desarrollado una tecnología útil para Internet; de la noche a la mañana surgen portales que se convierten en referente obligado de sus usuarios, y la opinión de un juez a quien no hemos visto jamás provoca subidas y bajadas espectaculares de la bolsa, que repercuten incluso en el pequeño inversor que vive a 7000 Km. de distancia. Quizá sean exageraciones propias de una situación tan novedosa que no tiene referente.

Todas estas promesas y realidades, se basan, desde luego, en un conjunto de tecnologías. Para algunos quizá demasiadas, pero esa es la situación que el mercado impone. En lo que los americanos llaman "el nuevo paradigma", destacan, no obstante, ciertos nombres. Nombres de empresas y nombres de productos. También algunos nombres propios, como los de Tim Berners-Lee (el "inventor" de Internet) o Vinton Cerf. Pero, sean quienes sean las empresas, los hombres y los productos, lo que hace posible el funcionamiento de Internet es la tecnología y esa tecnología se basa en los estándares.

Internet utiliza estándares para gestionar las comunicaciones entre servidores (proveedores de servicios) y consumidores: HTTP, FTP, SMTP, etc. Existe un lenguaje universal (estándar) para la construcción de páginas web: HTML. Existen dos estándares para la construcción de componentes (ActiveX y CORBA). Existe un lenguaje (Java) propuesto como estándar por una empresa particular (Sun Microsystems), que permite la independencia de la plataforma. E incluso las nuevas propuestas para mejorar el funcionamiento y las prestaciones de Internet se basan en nuevos estándares (XHTML, XML, etc).

No parece, pues que lo importante sea una herramienta dada, sino que la herramienta sea estándar. Que quienes construyen soluciones lo hagan de forma estándar, para maximizar su vigencia y su alcance.

Por otro lado, no todos los estándares son nuevos. De lado de la balanza donde se sitúan los proveedores de servicios, los servidores de datos siguen siendo las piezas clave del almacenamiento de la información que la Web va a proporcionar. Eso lo han entendido perfectamente los creadores de Sistemas de Gestión de Bases de Datos, que se afanan permanentemente en actualizar: Microsoft, Oracle e IBM juegan un papel importantísimo y todos ellos disponen de buenos servidores de datos, de sistemas de proveedores de servicios de Internet y de productos para la construcción y gestión de sitios web, y, además, se ven forzados a colaborar entre ellos, -a pesar de sus luchas comerciales- por que el cliente es cada vez más libre de elegir soluciones mixtas, que impliquen la presencia de productos de varias compañías.

De esta forma, surgen soluciones comerciales, que pretenden convertirse en estándares "de facto" sin conseguirlo: Internet Information Server de Microsoft, Oracle Web Server y Apache para Linux, son buenos ejemplos de ello. La decisión la toma el cliente, y muchas veces, depende del escenario. No cabe decir que una solución es mejor que otra. Las circunstancias mandan, la decisión depende de ellas, y un conocimiento de lo que cada uno proporciona es vital para que la solución adoptada suponga un éxito. Por ello, vamos a recorrer ese estado de las tecnologías, con el objetivo de aclarar algo la espesura de conceptos coincidentes y herramientas paralelas, y explicar, siquiera brevemente, la maraña de siglas (estándares o no) envueltas en las soluciones que se ofrecen al directivo que tiene que tomar una decisión al respecto.

Entendemos por tal aquellos aspectos del funcionamiento de Internet que están modificando las relaciones sociales tradicionales, tanto en lo económico como en otros ámbitos de la actividad humana.

De esta forma, aparecen servicios sobre los servicios, y lo virtual se presenta como la nueva forma de hacer cosas que antes hacíamos de forma real. El comercio electrónico es sólo un aspecto, pero no podemos olvidar otros igualmente importantes. Por un lado, la Teleconferencia, un sistema que está permitiendo que se establezcan "reuniones virtuales". El mecanismo es sencillo. Un sitio Web gestiona la conexión de varios usuarios, recibiendo sus diálogos y emitiéndolos al resto de participantes. Se crea de esta forma el concepto de "lugar virtual", que –además- puede llevar a cabo las labores de notaría y almacenamiento de conversaciones. En sus versiones más avanzadas, los sitios virtuales asignan a cada participante una imagen que lo representa (se denominan avatares), de manera que la comunicación no sea tan impersonal, o incluso, si disponemos de cámaras preparadas al efecto, (webcams) podremos ver realmente a nuestros interlocutores (ver figura adjunta).

Las consecuencias de esto son importantes. Un usuario con un teléfono móvil y un portátil, puede asistir a una Teleconferencia o Videoconferencia aunque esté en una playa de moda, o en la montaña, con tal de que tenga cobertura telefónica. En esa situación, el usuario del portátil, se convierte en canalizador de la información, ya que toda la información que reciba de la red, puede redirigirla hacia su propia empresa, a través de algún mecanismo de transferencia de ficheros, como FTP, o adjuntándola a un mensaje de correo electrónico.

Y existen un número creciente de servicios en los que tradicionalmente la presencia humana era imprescindible, en los que se está utilizando cada vez más la virtualidad. Uno de ellos es la enseñanza a distancia. Existen aplicaciones para Internet, como Almagesto, del Grupo EIDOS (http://almagesto.com), que permiten la realización de cursos de todo tipo con control de profesorado, asistencia personalizada al alumno, realización de exámenes, base de datos de conocimiento, etc., que pueden personalizarse para que una corporación los utilice en su propia formación interna, o bien ofrezca cursos propios sobre cualquier materia.

Finalmente, hay que reseñar en esta introducción el uso de Internet en escenarios tradicionales –para los que ya existe una solución bien conocida-, pero en los que Internet ofrece un modo alternativo: este es el caso de la telefonía, la radio y la televisión (Web-TV). Son situaciones a las que Internet aporta beneficios de tipo económico, generalmente. La comunicación telefónica, por ejemplo, es siempre local (a nuestro proveedor de servicios Internet), aunque estemos hablando con Kuala Lumpur. La radio por Internet, permite el acceso desde escenarios no-estándar, como puede ser el ordenador de la oficina, o también el acceso a fuentes no accesibles de otro modo (uno puede escuchar el programa de Dixieland de los miércoles en Radio New Orleans, sin mayores problemas). Y lo mismo sucede con la televisión, aunque en este caso, el ancho de banda se convierte en un problema importante. Otro tema distinto es ver Internet a través de la Televisión. Ofertas muy recientes permiten hacer eso ya en nuestro país.

El futuro de Internet pasa por ser más grande y con velocidades exponencialmente mayores. La comercialización de Internet es un tema candente hoy día, donde se promete cualquier tipo de comercialización salvaje de la información. El gobierno federal, agradecido por este éxito inesperado, aún tiene mucho que decir en esto. La NREN (National Research and Educational Network -Red Nacional de Educación e Investigación), fue aprobada en el otoño de 1991 como un proyecto a cinco años y con un presupuesto de dos billones de dólares para que la red troncal de Internet fuera actualizada. Ya es una realidad y su nombre clave Internet-2. Es cerca de 100 veces más rápida que la red más rápida de hoy día permitiendo la transferencia de la Enciclopedia Británica en un segundo. Permite gráficos animados en 3-D, enlaces de radio y teléfonos móviles a ordenadores portátiles, fax, voz y televisión de alta definición.

El modelo de programación actual ha variado. Hasta aquí hay una cierta unanimidad. Lo que no parece tan claro, es el modo en que lo ha hecho. Aquellos, que como en mi caso, hemos vivido la evolución informática de los mainframes de los años 70 hasta la actualidad, hemos tenido ocasión de comprobar cómo la separación entre el mundo serio de la informática corporativa (mucho tiempo liderada por IBM) y la informática de juguete, encabezada por Microsoft han confluido de tal forma que no está bien clara la diferencia entre ambos.

En lo que casi todos parecen estar de acuerdo, es en la división de roles que se ha producido en el concepto de aplicación. Si observamos con atención, todo indica que los avances que se producen en las tecnologías de la información parecen basarse siempre en una misma forma de proceder: sacar factor común. Los sistemas operativos gráficos hacen eso cuando separan un conjunto de funciones en ficheros DLL que son compartidos por la mayoría de las aplicaciones; las API de ODBC y OLE-DB son una forma común de acceder a datos cuyos orígenes y formatos son bien diversos, pero que son vistos por el programador a través de una misma jerarquía de objetos (DAO, RDO ó ADO), independientemente del sistema de soporte; las máquinas virtuales de Java no pretenden otra cosa que permitir que código escrito en un mismo lenguaje pueda ser interpretado en diferentes plataformas, cuya estructura es bien distinta; VBA y los modelos de objetos posibilitan la programación de macros en herramientas tan diversas como Autocad 14 ó Microsoft Office mediante el mismo lenguaje. Incluso ActiveX y la tecnología en 3 capas, de la que hablaremos a continuación, no hace sino extraer aquella parte de los programas que puede residir en una máquina distinta y -dotándole de una estructura estándar- permitir que se exponga como objeto programable por otras herramientas.

Dentro de esta maraña de siglas, estándares, herramientas, tecnologías y demás acrósticos de 3 letras que nos invaden diariamente, caben destacar, por su implantación un conjunto que hemos pretendido esquematizar en la figura adjunta y que pasaremos a comentar con más detalle a continuación:

Consecuentemente con esta filosofía, el modelo actual de las aplicaciones, divide éstas en 3 capas bien diferenciadas, que pueden ser desarrolladas de forma totalmente independiente, y que –gracias al concurso de los estándares- pueden incluso ser reutilizadas en más de un contexto:

Resumiéndolo en pocas palabras, aquello que afecta al proceso de comunicación en cuanto al modo en que lo percibe el usuario, es lo que, genéricamente, entendemos por interfaz de usuario. La interfaz de usuario habla con nosotros, nos presenta contenidos, espera una respuesta o una solicitud de nuestra parte y actúa en consecuencia. Hasta el momento, esa interfaz de usuario se compone, el 99% de los casos, de un conjunto de ventanas sembradas de lo que llamamos controles, esto es, botones, cajas de texto, menús desplegables, cajas de diálogo, etc. Y la situación no varía excesivamente al utilizar páginas web como interfaz: las páginas reproducen esa situación familiar, aunque no estén –estrictamente hablando- formadas por controles.

En la actualidad podemos distinguir 3 formas de interfaz de usuario: La interfaz clásica de ventanas, la interfaz integrada en programas de gestión (también a base de ventanas, pero participando de los servicios que da el programa de gestión), y los navegadores.

En el primer caso, estamos hablando de los programas clásicos a los que estamos acostumbrados en su 90%. Una ventana principal y un menú van ofreciendo posibilidades al usuario que selecciona, e introduce la información a procesar. Se construyen con las herramientas de desarrollo tradicionales: Visual Basic, Visual C++, Java, etc.

En el segundo, la aplicación es ejecutada por otra aplicación que el usuario ya tiene instalada en su equipo: Por ejemplo, cualquier aplicación de la suite de Office, permite que un programador almacene código fuente y todos los elementos adicionales necesarios para construir una aplicación en un documento de Office (documentos de Word, hojas de cálculo Excel, diapositivas PowerPoint, etc.). Cuando el usuario quiere trabajar con la aplicación, simplemente abre el documento, y toda la maquinaria se pone en marcha igual que si estuviéramos en un entorno tradicional. La diferencia es que estarán presentes los elementos de la aplicación servidora si no se han desahabilitado: los menús de Word, las cajas de diálogo, etc. Tiene la ventaja de que no requiere de instalación, ya que la aplicación que lo maneja se encuentra ya instalada en el equipo del usuario.

El tercer tipo de interfaz es el propio navegador. En este caso, no existe una interfaz de usuario "ad-hoc", sino que es el propio navegador el que permite el desplazamiento por las páginas que constituyen la aplicación. Se trata desde luego, del sistema más fácil de instalar, ya que –literalmente- no requiere instalación. Las páginas son descargadas de un sitio Web y en ellas se encuentra el sistema de navegación.

Tiene varios inconvenientes, no obstante. En primer lugar, la velocidad está determinada por el ancho de banda y la concurrencia –el número de usuarios simultáneos-, aunque esto mejorará con el tiempo. Peor aún, no resuelve el problema de la información múltiple. Las páginas no pueden visualizarse simultáneamente (no podemos tener abierta la página de clientes, y a la vez la de proveedores, para comprobar datos, por ejemplo), ya que los navegadores (a excepción de alguno de pago, como Opera), no permiten más que la visualización de una página a la vez. Y si además añadimos componentes escritos en Java, la lentitud será inevitable comparada con cualquier otro sistema tradicional.

Como hemos apuntado antes, los lenguajes típicamente implicados en la construcción de las interfaces tradicionales, son Visual Basic, Visual C++, Java. (si bien existen otros que no mencionamos aquí por no hacer la lista demasiado extensa). El más popular –con diferencia- es Visual Basic, con más de 3 millones de programadores registrados en el mundo (quizás 4 en total), con un lenguaje sencillo de aprender, pero potente, gracias a sus componentes predefinidos, a su integración con el sistema operativo Windows (con Windows 2000 incluso, no se requieren más librerías de instalación que las que la aplicación use específicamente) y en parte a la cantidad de ayuda y recursos disponibles: una comunidad tan grande de desarrolladores es una garantía.

Microsoft Visual C++, o C++ Builder de Inprise (hay muchos otros, de menor implantación en el mercado), basados en lenguaje C++, son quizá los más potentes de todos los lenguajes existentes, pero, al manejar recursos de más bajo nivel, -más próximos a la máquina- requieren mucho más esfuerzo de programación. Casi todo el mundo está de acuerdo en que hacer aplicaciones exclusivamente en C++ es un trabajo ímprobo. Dentro del mundo del desarrollo de aplicaciones de gestión, se suelen usar para la construcción de componentes.

Respecto a Java, se trata de una herramienta pensada por y para Internet. Tiene la gran ventaja de la independencia de plataforma. Un programa desarrollado en Java debe de funcionar en cualquier otra plataforma (Unix, VMS, OS/2, MacIntosh, etc.) gracias a una maquina virtual que se encarga de interpretar las instrucciones Java al código propio de esa plataforma. Es un sistema ya bastante maduro, aunque sigue en evolución, (sobre todo las herramientas de desarrollo).

También sirve para la construcción de componentes (llamados applets y también java beans). Su principal inconveniente actual es su lentitud. El trabajo extra que deben de realizar las máquinas virtuales antes citadas, enlentece los procesos –a veces de forma exasperante- en porcentajes que pueden oscilar entre el 25% y el 200% dependiendo de lo que estemos haciendo y los equipos de que dispongamos. La situación está mejorando, no obstante, a medida que se optimizan las máquinas virtuales y se multiplica la potencia de los procesadores.

Los tres lenguajes mencionados, tienen, además la capacidad de permitir la construcción de componentes, con lo cual son válidos tanto para la creación de la interfaz de usuario, como para la elaboración de los componentes que intervendrán en la capa de reglas de negocio.

Aparte del ya citado Java, los lenguajes que intervienen en la construcción de sitios web, son mucho más estándares que estos que hemos visto. De hecho existe una entidad de normalización (el World Wide Web Consortium ó W3C), que se encarga de publicarlos oficialmente, para que los constructores de herramientas se atengan a ellos.

Genéricamente se les denomina "lenguajes de marcas", ya que consisten en marcar los datos que se incluyen en las páginas de forma que estos sean interpretados por los navegadores de igual manera (con independencia de la plataforma). Se escriben en texto sin formato, lo que garantiza independencia sin necesidad de máquina virtual alguna.

Sin embargo, debe quedar claro que su papel no es equiparable al de los componentes (sean éstos Java, ActiveX o CORBA), ya que mientras éstos ejecutan instrucciones, los lenguajes de marcas se limitan a indicar cómo debe de ser mostrada la información, y en sus versiones más modernas (con XML), incluso en qué orden, o qué filtros aplicar, o cómo navegar por ellos.

Para permitir la ejecución de instrucciones de programación, los lenguajes de marcas permiten la inclusión dentro de su código de unas marcas especiales que admiten código fuente escrito en lenguajes especiales que no son compilados, sino interpretados: los lenguajes de Script. Existen varios de ellos, JavaScript, VBScript, PerlScript, Pyton, etc. Pero, sin duda, JavaScript es el más popular pues funciona en cualquier navegador. No es Java, pero está inspirado en la sintaxis de ese lenguaje.

Cuando un navegador encuentra un fragmento de código JavaScript, invoca a un intérprete que ejecuta estas instrucciones, dotando de funcionalidad programable a las páginas Web. Además, como no se trata de componentes, no hay máquinas virtuales especiales, ni dependencia funcional de la CPU. Respecto a la posición estratégica de JavaScript respecto de sus competidores, la ventaja es que podemos asumir que funciona correctamente en un 95%. (por razones que, de momento, siguen escapando a mi comprensión, aunque las especificaciones oficiales publicadas por la W3C son firmadas por representantes de las más importantes compañías productoras de navegadores, luego, en su implementación no cumplen al 100% dicha normativa...).

Podríamos hacer dos divisiones principales: Lenguajes de marcas clásicos y de nueva generación. Entre los primeros hay que destacar a HTML y DHTML. Entre los segundos, XML y sus derivados.

Se conviene en denominar de esa forma a los componentes de capa intermedia que intervienen en la construcción de una aplicación.

¿Qué entendemos por componentes de capa intermedia? ¿Y qué es una capa intermedia?. Respondamos en sentido inverso. Hablando genéricamente, podemos decir que una capa intermedia es un elemento funcional de un programa que se ejecuta separadamente del resto de la aplicación, si bien conectando con el resto de elementos de ésta mediante algún sistema de comunicación entre aplicaciones (Típicamente, RPC).

Por ejecución separada del resto, entendemos que ocupa su propio espacio de direcciones en memoria, o bien, que reside separadamente de la aplicación que lo utiliza (por ejemplo en otra máquina que hace las veces de servidor de componentes). ¿Qué beneficios se obtienen mediante ésta separación? Dependen de la arquitectura de la aplicación.

En el primer caso, un componente es un fragmento de código compilado, que reside en un fichero separado, y que se registra en la máquina que va a utilizarlo. Una vez registrado, el componente puede ser utilizado por cualquier aplicación, y no sólo por aquella para la que ha sido pensada originalmente. Eso supone que si creamos un componente para devolver el conjunto de clientes que pertenecen a una ciudad concreta, también podría ser usado por personal administrativo desde una herramienta como Office, para crear listados de clientes para los representantes (por ejemplo). El que esto sea posible depende de cómo haya sido construido el componente.

Y nuevamente, volvemos a la importancia de los estándares. Los componentes a los que me refería antes eran componentes ActiveX. Se llaman así a aquellos que están construidos utilizando la especificación DCOM (una tecnología abierta, pero inventada por Microsoft). Las ventajas son enormes. Podemos crear componentes polivalentes, que pueden ser utilizados en diferentes contextos, haciendo que sea la lógica del negocio la que importe, y no la lógica de las aplicaciones individuales. Podemos pensar más en conceptos como Clientes, Proveedores, Productos, Servicios, etc, y menos en las características propias de un programa. Una vez registrado, un componente se convierte en un servicio del sistema operativo.

Además se pueden tener componentes DCOM en diferentes plataformas, gracias a su carácter estándar. De esa forma, una aplicación Windows, puede llamar a componentes DCOM que residan en una máquina Sun-Solaris, sin problema. Y no sólo es posible esa arquitectura: Muchas aplicaciones corporativas de gran volumen, como SAP, poseen componentes COM conectores para permitir que otras aplicaciones utilizando programas de gestión clásicos, o suites como Office, puedan manipular los datos producidos por ellas. Incluso puede accederse a la base de datos SAP R/3 desde estas plataformas para soluciones Internet.

Y ahí no termina la lista de ventajas. Un componente puede ser incluido en una página web, y cuando un lector solicita la página, el componente se descarga junto con el resto de la información. Una vez descargado se solicita permiso al usuario para la instalación en su máquina, y –caso de obtenerlo- se registra quedando a disposición de los programas que lo soliciten.

Otra posibilidad: existen servicios del sistema operativo (Windows NT/2000), que permiten que un servidor se comporte como distribuidor de componentes. En concreto me refiero a Microsoft Transaction Server (MTS, que más correctamente, debiera de llamarse Component Server). La idea es que cualquier aplicación que invoque el uso de uno de estos componentes puede hacerlo igual sobre una máquina remota que sobre una local. Bajo este escenario, MTS permanece a la escucha de las peticiones de componentes que las máquinas cliente puedan realizar. Cuando una máquina solicita un componente registrado por MTS, éste crea un copia del componente y lo envía al usuario. Pero, (y aquí esta el quid de la cuestión) cuando otro usuario solicita el mismo componente, MTS no vuelve a instanciarlo nuevamente, sino que utiliza y gestiona el que ya tiene cargado, permitiendo que múltiples usuarios utilicen un único componente, y esto con unas buenas prestaciones de velocidad.

¿Virtudes? Dos, principalmente. Por un lado, la centralización de la gestión de componentes, permite que los cambios no afecten a las instalaciones cliente. Si queremos cambiar algo en un componente, lo hacemos, volvemos a registrarlo en MTS y está listo para todas las aplicaciones que lo soliciten. Por el otro, lo que se ha dado en llamar la reducción del TOC (Total Cost of Ownership, o Coste Total de Propiedad), ya que, cuando los componentes acceden a bases de datos (lo que es la situación más natural), un solo componente da servicio a múltiples usuarios, pero sólo utiliza una licencia del servidor.

Mediante la herramienta de administración, se puede saber en todo momento qué componentes están en funcionamiento, y cuántas instancias de ellos están dando servicio en un momento dado. En la figura adjunta puede observarse la monitorización de componentes en funcionamiento mediante la consola de administración de MTS. :

Las herramientas que se utilizan en la construcción de estos componentes son las mismas que se usan para la construcción de la interfaz de usuario: Visual Basic, Visual C++, etc.

Existen otros dos modos de construcción de componentes basados en sendas especificaciones. El más conocido, después de ActiveX, es CORBA. Se utiliza preferentemente en entornos Unix/Linux, y se construyen mediante compiladores como C++ (cualquier versión actualizada permite hacerlo).

El tercer caso se refiere a componentes creados en Java. Se denominan applets o java beans, y también están pensados para ser utilizados como componentes de capa intermedia, o para ser incluidos dentro de una página Web, mediante un proceso similar al comentado anteriormente. El homólogo de MTS dentro de este escenario es RMI que permite una especie de gestión centralizada de los componentes Java que se le soliciten, aunque no incluye las mismas prestaciones que aquél.

El camino de la evolución parece que se dirige hacia la multifunción y multiplataforma usando los denominados componentes ligeros (thin components). Por multifunción entendemos la extensión natural de lo que los componentes ya son capaces de realizar, permitiendo que se puedan construir con cualquier herramienta y puedan servir para cualquier propósito: Transacciones, seguridad, enrutamiento de procesos, multiplicidad de escenarios de ejecución.

Además, la construcción de componentes de este tipo permite que los desarrollos se basen, no sólo en componentes propios, sino en otros construidos por terceras compañías de los cuales hay literalmente, miles en el mercado. (y un buen número de ellos, gratuitos). Esto posibilita el abordaje de aplicaciones para las cuales no se conoce toda la tecnología, siempre y cuando localicemos el componente que nos resuelve los pormenores de ese fragmento de la aplicación. Basta con registrarlo y usarlo como si fuera propio.

Respecto a los componentes ligeros, se trata solo de una denominación para referirse a un tipo de componentes que eliminan toda posible "carga extra", con el objeto de que su descarga a través de Internet, sea fácil y no presuponga un problema asociado con el ancho de banda.

Toda la filosofía de Microsoft Windows Distributed interNet Applications (Windows DNA), se basa en éstas capacidades.

Respecto a los mecanismos de acceso a los datos, el nivel de estandarización también es notable en la actualidad. Antaño, el acceso a un servidor, requería el conocimiento puntual de librerías específicas de cada servidor, lo que originaba que una aplicación realizada para uno de ellos, fuera perfectamente inútil si se cambiaban los datos de servidor.

El primer intento de unificación en este sentido fue ODBC (Open DataBase Connectivity). Se trata de un estándar que permite que los programadores se independicen del servidor. El único requisito es que se cree un driver específico para la base de datos a manejar en el servidor adecuado. A partir de ahí, el programador utiliza una librería de objetos, como RDO ó DAO para el acceso, de forma que todos los objetos de la base de datos aparecen ante él como objetos programables dentro de esa jerarquía.

Si la necesidad empresarial supone un cambio de servidor con un traslado de los datos, la aplicación permanece intacta. Solo hay que cambiar el driver, y todo puede seguir funcionando como estaba.

No obstante, esta visión tenía aún algunos inconvenientes. La irrupción de Internet, ha puesto en el candelero formatos de datos que se han convertido en auténticos estándares en poco tiempo, y para los que se precisaba un mecanismo homogéneo de acceso (ficheros de correo electrónico, documentos de todo tipo, etc).

Dicho mecanismo, según la propuesta Microsoft, aceptada por muchos fabricantes, es la estrategia UDA (Universal Data Access), que se basa en una extensión de OLE, denominada OLE-DB. Mediante OLE-DB, se puede acceder a datos de formatos heterogéneos sin que eso suponga un problema de modificación de las formas de acceso. Se puede abrir un correo electrónico, o un documento de Word, una hoja de cálculo Excel o incluso crear una tabla con el contenido de los ficheros existentes en un directorio. Lógicamente, habrá un traductor, igual que sucedía con ODBC. Ese traductor que permite el acceso es el Proveedor OLE-DB, de los que existen ya un buen número, entre los que se cuenta un Proveedor OLE-DB para ODBC, en el caso de que el servidor de datos al que pretendemos acceder no tenga todavía disponible el proveedor OLE-DB nativo.

Con esta filosofía podemos poner en marcha la programación mediante la librería ADO (ActiveX Data Objects), que para facilitar las cosas, se incluye de forma predeterminada en el sistema operativo Windows 2000.

Para el caso de Java, también existe un estándar de acceso a los datos, denominado JDBC (Java DataBase Connectivity), que se comporta de forma similar a como lo hacen los drivers ODBC para cualquier otro lenguaje.

Si bien es cierto que el número de servidores de datos disponibles es alto, no lo es menos que el número de los más populares o que tienen una mayor penetración en el mercado, se ha reducido a unos pocos, generalmente asociados con las compañías de software de mayor envergadura.

Dentro del mundo Microsoft, hay que destacar SQL-Server 7.0, su última versión. Se trata de un servidor escalable, de excelentes prestaciones y muy buen precio. Permite la gestión integrada de toda la información, un mantenimiento muy avanzado, y una programación de bases de datos que comprende la optimización de índices, la ejecución de procedimientos almacenados (con posibilidad de depuración), diseño visual de bases de datos, agentes y asistentes para todas las tareas, documentación en castellano muy exhaustiva, y una integración total con el sistema operativo, del que se convierte en un servicio más. Algunas bases de datos de enorme tamaño, están siendo gestionadas mediante SQL-Server 7, como la que sirve de almacenamiento a la web www.terraserver.com, con un TeraByte de almacenamiento en disco y datos de imágenes de todo el planeta a distintos niveles de profundidad.

Dentro de esta filosofía, hay que destacar, no obstante, la próxima versión, que aparecerá en verano de este año (SQL-Server 2000). Se integrará perfectamente con la cuarta versión de Windows 2000 (DataCenter), para ofrecer altísimas prestaciones, especialmente de cara a servicios Internet de alto nivel de concurrencia. Según parece, las últimas pruebas de rendimiento realizadas por empresas independientes, han ofrecido resultados espectaculares, por encima de los obtenidos por servidores de gama alta de la competencia (Sun Solaris, IBM-DB2, etc.). Habrá que esperar un poco para probarlo. Además incluye la posibilidad de devolver la información en formato XML, e incluso de realizar consultas al servidor de datos utilizando el navegador como herramienta.

Los otros grandes protagonistas en el mercado de servidores, siguen siendo –indiscutiblemente- Oracle e IBM. El primero, siempre ha mantenido un nivel de prestaciones y calidad excelente, y se trata, sin duda alguna, de una las mejores opciones existentes en el mercado. Dispone adicionalmente, de herramientas para la construcción de aplicaciones, que abarcan desde la fase de diseño a las de implementación, depuración e instalación, bien integradas con los servicios de datos. Se complementa, además, con un servidor de Internet muy completo. El inconveniente, para algunos, es su alto precio y en ciertas facetas, la documentación y servicios de mantenimiento, aunque esa situación parece ser común a otros competidores, como el último de la terna mencionada aquí: IBM.

El gigante azul ha sufrido una profunda reconversión en los últimos años tendente a romper ese aislamiento tradicional y permitir una convivencia con los demás sistemas y tecnologías. Su base de datos DB2 es un clásico, y la seguridad que ofrece, proverbial. La otra cara de la moneda, parece ser siempre la misma: documentación exclusivamente en inglés, en la mayoría de los casos, servicios de mantenimiento a precios altos, y en éste caso concreto, un hardware nativo (no vale el hardware estándar), del orden de docenas de veces más caro que su equivalente estándar.

Existen, ciertamente otros productos servidores de datos de cierta implantación, como Informix, Sybase, ADABAS, Watcom, Gupta, etc., pero no tienen el nivel de implantación que tienen los anteriormente citados.

Las soluciones y servicios que hemos visto hasta ahora, se integran de alguna forma o de varias, dentro de las soluciones Internet, pero lo cierto es que los sitios Web tienen su propio conjunto de tecnologías, y que éstas también pueden combinarse, agruparse por empresas distribuidoras, etc.

No obstante, y si uno analiza siquiera por encima las estadísticas, se observan dos tendencias claramente diferenciadas: las soluciones basadas en productos Microsoft, y las apadrinadas por una serie de empresas de la competencia. (No olvidemos que en una solución de éste tipo, el sistema operativo es fundamental).

La estrategia de Microsoft de cara a la Web, se basa en un conjunto de tecnologías bien definidas, que parten de la base del sistema operativo: Windows NT ó 2000, como aglutinante del resto de servicios. Asumido esto, y sobre ese sistema operativo, la construcción de webs se basa en los siguientes servicios y lenguajes:

En realidad podemos esquematizar el proceso con algo más de detalle, desde la petición inicial de una página por parte del cliente, hasta la recepción de los distintos servicios, tal y como se aprecia en la figura siguiente:

Se trata de una solución de gran implantación en el mercado, especialmente en el servidor, debido a la popularidad del servidor de páginas Apache para Unix/Linux. Se trata de un servidor al estilo de IIS, pero con un alto nivel de integración con los sistemas UNIX/Linux.

Típicamente, utiliza componentes de servidor escritos en la especificación CORBA, normalmente, mediante compiladores de C++ para UNIX y, en general, requiere mayores conocimientos para su instalación y puesta en funcionamiento, en comparación con las soluciones Windows.

Las páginas de respuesta pueden estar programadas en distintas especificaciones, como CGI (que se está abandonando, ya que requiere lenguaje C++), Perl, que está viviendo una resurrección gracias al fenómeno de Internet, o JSP, que es el equivalente de ASP para JAVA.

Respecto a las prestaciones son tantos los elementos a tener presentes, que no es posible decir que una solución es mejor que otra. Por si la plétora de posibilidades fuera poca, gracias a los componentes y la integración de aplicaciones, es posible construir casi cualquier combinación que funcione satisfactoriamente, en la que se mezclen ambas soluciones tanto en servidores como en clientes, en las que una aplicación puede contener tantas capas como sean necesarias, permitiendo la convivencia de servidores UNIX con clientes Windows, dentro de una arquitectura como la que se muestra en la figura adjunta:

La decisión será cuestión de cada solución en particular, y no sólo intervendrán cuestiones de tipo empresarial, de marketing o de preferencias personales, sino también de recursos humanos, en el sentido de la facilidad de aprendizaje, las características del plantel de programadores disponible, planificación y facilidad de puesta a punto, soporte, etc.

Aparentemente, con el tiempo parece existir un mayor respeto por los estándares a la hora de la construcción de herramientas. Eso es bueno, ya que nos ofrece unas líneas guía, y nos garantiza que la inversión realizada en formación no se va al traste por el hecho de que una compañía tenga más o menos predominancia en el mercado.

Todo parece indicar que lo apuntado aquí, respecto a programación en 3 capas, importancia de servidores, utilización de lenguajes estándar e independencia de la plataforma, son las líneas de desarrollo por venir. Sin embargo, ya que hablamos de Internet, es ineludible hacer referencia a un nuevo estándar del que se está hablando con profusión últimamente, y que según parece ha conseguido el consenso de casi todos los fabricantes: XML.

Se define el estándar XML como: El formato universal para documentos y datos estructurados en Internet. XML es un conjunto de reglas, normas y convenciones para diseñar formatos de texto para tipos de datos heterogéneos (desde las hojas de cálculo, o las libretas de direcciones de Internet, hasta parámetros de configuración, transacciones financieras o dibujos técnicos) sin que su naturaleza suponga un inconveniente en su manipulación. Además XML no requiere licencias, es independiente de la plataforma, y tiene un amplio soporte.

Al tratarse de una tecnología y no de una herramienta, XML se convertirá en protagonista de escenarios muy diferentes: Visual Basic (la versión 7.0, anunciada para Nov/2000) se basará totalmente en ella y en el nuevo Microsoft Forms+), la programación Web (donde junto al nuevo ASP+ permitirá construir soluciones Internet en las que el código de servidor sea binario –compilado- y el mecanismo de transporte de datos, XML), programación de soluciones ofimáticas (responde a un modelo de objetos programable utilizando el lenguaje VBA), utilización como formato de intercambio (los ficheros se escriben en texto plano y pueden ser leídos en cualquier plataforma (Windows, UNIX/LINUX, McIntosh, OS/2, VMS, etc.).

Los principios que han animado la creación del estándar XML se basan en separar dos partes que hasta ahora estaban indisolublemente unidas en un documento HTML: la presentación y los datos que son presentados. Es cierto que existe un paso previo en este proceso de desligamiento: las hojas de estilo en cascada ó CSS (Cascade Style Sheets); pero éstas solamente permiten definir patrones de presentación independientes que son aplicados mediante etiquetas HTML a un documento. Se trata de una separación conceptual, que no factual: los datos siguen estando ligados a una página HTML.

Con XML la separación es total. Podemos crear un conjunto de hojas de presentación (ficheros XSL, un derivado del estándar) y aplicarles en diferentes contextos el mismo documento XML que contiene los datos: obtendremos tantas presentaciones de éstos como ficheros XSL utilicemos. Además, el estándar XSL es más potente que las hojas de estilo en cascada, pues permite delimitar qué conjuntos de información deseamos y hasta el orden en que queremos que aparezcan, y esto sin realizar más peticiones al servidor.

Este lenguaje de presentaciones (denominado XSL o Extensible StyleSheet Language), utiliza una sintaxis XML, -por razones de coherencia- y está definido como estándar por la W3C, igual que todos los lenguajes asociados a XML que hemos estado analizando. Si el lector está interesado en revisar la especificación completa del estándar, podrá encontrarla en la dirección Internet: http://www.w3.org/TR/WD-xsl/

Este estándar permitirá una mejora considerable de las búsquedas en Internet, ya que al almacenar los documentos con un formato estándar y autodefinido en su cabecera, bastará leer ésta para saber si la aparición de una cierta palabra en el texto tiene sentido en el contexto de la búsqueda.

Por si esto fuera poco, su formato (texto plano) permite su transporte y lectura bajo cualquier plataforma o herramienta y le da un valor de universalidad que no se puede conseguir con ningún formato nativo, por mucha aceptación que tenga.