0% encontró este documento útil (0 votos)
50 vistas23 páginas

Oposición Cuerpo Superior: Desarrollo Web

Este documento describe la evolución de la arquitectura de las aplicaciones web, desde el modelo cliente-servidor de dos niveles hasta el modelo de tres capas más actual. Explica las limitaciones del modelo de dos niveles para aplicaciones más complejas y la necesidad de añadir una tercera capa intermedia para solventar estos problemas.

Cargado por

jjig
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
50 vistas23 páginas

Oposición Cuerpo Superior: Desarrollo Web

Este documento describe la evolución de la arquitectura de las aplicaciones web, desde el modelo cliente-servidor de dos niveles hasta el modelo de tres capas más actual. Explica las limitaciones del modelo de dos niveles para aplicaciones más complejas y la necesidad de añadir una tercera capa intermedia para solventar estos problemas.

Cargado por

jjig
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

Asociación Profesional del Cuerpo Superior

de Sistemas y Tecnologías de la Información


de la Administración del Estado

Temas Específicos para la preparación de la Oposición al Cuerpo


Superior de Sistemas y Tecnologías de la Información de la
Administración del Estado.

TEMAS ESPECÍFICOS IV: Redes, Comunicaciones e Internet

Tema 114. Arquitectura de desarrollo en la WEB (I).


Integración de contenido, sonido, imagen y animación. Scripts
del cliente JAVA y Visual Basic.

AUTOR: Raquel Poncela González

Fecha: 2009
Volumen 4. Redes, Comunicaciones e Internet.

114. Arquitectura de desarrollo en la WEB (I). Integración de contenido,


sonido, imagen y animación. Scripts del cliente JAVA y Visual Basic.

Autor: Raquel Poncela González


Sumario:

114.01 Arquitectura Internet


114.01.01 Desarrollo Cliente/Servidor
114.01.02 Limitaciones de la Arquitectura en Dos Niveles
114.01.03 Añadiendo un Tercer Nivel
114.01.04 Arquitectura Internet en Tres Capas
114.01.05 Componentes Software de una Aplicación Web
114.02 Lenguajes de Scripting
114.02.01 JavaScript
114.02.02 Jscript
114.02.03 JavaScript Versus JScript
114.02.04 VBScript
114.03 Componentes de Cliente
114.03.01 Applets
114.03.02 Controles ActiveX
114.03.03 Comparación entre Java y ActiveX
114.04 Integración de Contenido, Sonido, Imagen y Animación
114.04.01 Plug-ins
114.04.02 Formatos de Imágenes Estáticas
114.04.03 Formatos de Imágenes Dinámicas
114.04.04 Audio

Bibliografía
-World Wide Web Consortium: [Link]
-Microsoft: [Link]
-Tecnología java, Sun Microsystems : [Link]
-Macromedia: [Link]
-Patrick Naughton, “The Java Handbook”. Ed. McGraw-Hill, 1996

-Stefan Koch, “Voodoo’s Introduction to JavaScript”: [Link]

_______________________________________________________________________
1
114. Desarrollo de aplicaciones en la WEB (I).
114.01. Arquitectura Internet

Las aplicaciones Web han experimentado un incremento exponencial en los últimos años, convirtiéndose
cada vez en aplicaciones más populares y requeridas. Esto hecho se debe, en parte, al rápido desarrollo de
herramientas y tecnologías para desarrollar estas aplicaciones, así como a la espectacular explosión de In-
ternet. Sin embargo, el motivo fundamental de la utilización de las aplicaciones Web ha sido el gran conjun-
to de ventajas que estas aplicaciones aportan con respecto a las aplicaciones tradicionales, ventajas que han
sido gratamente acogidas por los desarrolladores.

Analizaremos en primer lugar la evolución desde la arquitectura Cliente/Servidor hasta la recién acogida
arquitectura en tres capas, para posteriormente estudiar en detalle cada uno de los componentes participan-
tes en ellas.

A partir de ahí veremos cómo podemos desarrollar aplicaciones web, centrándonos en la parte cliente (na-
vegador del usuario) y veremos las posibilidades que las nuevas tecnologías emergentes ofrecen para la
integración de información textual con información multimedia (imagen, video, audio).

114.01.01 Desarrollo Cliente/Servidor

El paradigma Cliente/Servidor define una arquitectura que divide el proceso de la aplicación en dos procesos
diferentes, ubicando normalmente la ejecución de cada proceso en distintas máquinas. Cualquier aplicación
con acceso a datos es una aplicación Cliente/Servidor, pues gestiona el almacenamiento de datos y la peti-
ción de éstos sobre el gestor de base de datos y la interacción del usuario con dichos datos en un proceso
diferente. La idea subyacente a la arquitectura Cliente/Servidor es facilitar el acceso de diversos usuarios a
la misma información de la base de datos.

Esta arquitectura se conoce también como Arquitectura en Dos Niveles. El término “Dos-Niveles” describe la
manera en que el procesamiento de la aplicación puede dividirse en dos procesos, cliente y servidor. Ideal-
mente, esta arquitectura proporciona un nivel de presentación uniforme para todos los clientes, que acceden
a una unidad central de almacenamiento de datos.

La mayoría de las aplicaciones de Internet (email, telnet, ftp, gopher, web) son aplicaciones en dos niveles,
pues proporcionan una interfaz común para acceder a la información a través de Internet.

La siguiente figura muestra cómo acceden los clientes a los datos centralizados.

Clien- Servi-

Utilizando como ejemplo el Web: el navegador Web que reside en el cliente solicita los datos (páginas
HTML) almacenadas en el Servidor Web.

2 ___________________________________________________
VOLUMEN 04 – COMUNICACIONES, REDES E INTERNET
Volumen 4. Redes, Comunicaciones e Internet.

Internet

Clientes Servidor

114.01.02 Limitaciones de la Arquitectura en Dos Niveles

La arquitectura de un sistema depende de la aplicación. En un entorno en el que sólo se necesita mostrar


contenido estático en una página HTML, no necesitamos ningún elemento adicional a los proporcionados por
la arquitectura en dos niveles. El cliente solicita al servidor el envío de una página determinada. El servidor
recibe la petición y la procesa enviando la página al cliente. El cliente, al recibirla, la muestra por pantalla.

Existen situaciones más complejas. Supongamos que tenemos una aplicación sobre Internet que necesita
mostrar contenido dinámico en sus páginas, es decir, contenido extraído de una base de datos. Podríamos
mostrar formularios en el cliente que permitieran interactuar con los datos, y procesos en el servidor que
recibieran peticiones y las solucionaran. Para la validación de los datos podríamos utilizar algo de código en
el cliente (JavaScript, por ejemplo) que filtrara los datos antes de enviarlos al servidor. En definitiva, la ar-
quitectura para esta aplicación podría ser también una arquitectura en dos niveles. Sin embargo, nos encon-
tramos con algunos problemas. ¿Qué ocurre si las validaciones en el cliente son demasiado complejas?
Tendríamos que reescribir dichas validaciones en cada página, rediseñándolas para cada regla particular, por
lo que las páginas HTML serían mucho menos mantenibles y las funciones JavaScript mucho menos reutili-
zables. Nuestras necesidades han sobrepasado la funcionalidad que otorga la arquitectura en dos niveles.

El Problema del “Cliente Gordo”

Idealmente, la Arquitectura Cliente/Servidor tiene como objetivo permitir a cada máquina realizar el trabajo
para el que está más cualificada. Las estaciones de trabajo estaban diseñadas para ofrecer interfaz gráfica al
usuario, por lo que se especializaron en la presentación de datos, mientras que los servidores estaban dise-
ñados para gestionar datos y redes, por lo que se especializaron como almacenamiento de datos.

Sin embargo, a medida que evoluciona la informática, confluyen dos nuevas características: las máquinas
empiezan a ser muy potentes y aparecen nuevas necesidades más complejas. El primer factor influyó en la
distribución de los servidores, pues actualmente es mucho más barato comprar varios servidores medios que
un único servidor potente. El segundo factor, por su parte, favoreció la carga de responsabilidades en los
clientes, puesto que las nuevas máquinas soportaban una mayor carga de proceso.

Estos dos factores dieron lugar al llamado Problema del Cliente Gordo. En las aplicaciones en dos niveles, los
clientes son aplicaciones monolíticas poco adaptables a cambios y poco escalables a nuevas necesidades.
Aunque los clientes tienen como objetivo realizar la presentación de datos, se encargan también de tareas
complejas relativas a la gestión de la información. ¿Qué ocurriría si tuviéramos que distribuir los datos sobre
múltiples servidores de datos? ¿Qué ocurriría si cambiara parte de la lógica de negocio de la aplicación?
Tendríamos que modificar todo el programa cliente, cuya funcionalidad no tendría que estar relacionada con
los cambios a realizar.

Cuándo Utilizar una Arquitectura en Dos Niveles

Como hemos visto anteriormente, el desarrollo en dos niveles presenta algunos problemas de vital impor-
tancia para algunas aplicaciones. Sin embargo, existe otro conjunto de ellas para las que los dos niveles
_______________________________________________________________________
3
114. Desarrollo de aplicaciones en la WEB (I).
pueden ser suficientes. La pregunta es, ¿cuándo introducir un tercer nivel? Generalmente, será necesario
introducir tres niveles cuando los datos estén distribuidos, el tamaño de la base de datos se incremente
rápidamente; cuando se espere que la aplicación esté en continua evolución, cuando se espere que el núme-
ro de usuarios aumente con el tiempo... En definitiva, siempre que la aplicación no vaya a permanecer inal-
terable con el paso del tiempo, lo cual engloba la mayor parte de las aplicaciones porque, ¿qué aplicación no
cambia con el tiempo?

114.01.03 Añadiendo un Tercer Nivel

Podemos evitar los problemas vistos en los puntos anteriores extendiendo nuestra arquitectura hasta tres
niveles. Para ello, añadiremos un tercer nivel cuyas funciones serán encapsular y aislar el acceso a datos y
maximizar la reutilización de objetos. La arquitectura obtenida será la siguiente:

Internet Servidor de Servidor


Aplicaciones de Datos
Clientes

En la Arquitectura en Tres Niveles aparecen tres funciones bien diferenciadas: el almacenamiento y gestión
de los datos, el proceso de la lógica de la aplicación y la presentación de los datos e interacción con el usua-
rio.

La capa de presentación es completamente independiente de la localización, acceso y manipulación de los


datos, pues el acceso a datos corresponde a la capa de aplicación y la manipulación de los mismos es tarea
del propio sistema gestor de base de datos. Así mismo, los objetos de la aplicación son completamente in-
dependientes de la presentación que se les de, permitiendo a la vez ser mostrados por una aplicación cliente
estándar o un navegador. Este hecho favorece la reutilización de los objetos, pues su independencia de la
presentación garantiza la validez de su proceso para cualquier aplicación. Por último, pero no por ello menos
importante, ofrecemos el aislamiento de la interfaz de los datos a los objetos externos. Dichos objetos cono-
cen qué datos obtienen, pero no cómo los obtienen, pues los objetos de la capa intermedia se encargan de
ocultarlo, ofreciendo solamente la interfaz de acceso a datos.

La arquitectura ideal para las Aplicaciones Internet/Intranet es la Arquitectura en Tres Niveles, pues tiene,
como hemos visto, muchas ventajas con respecto a la Arquitectura en Dos Niveles.

114.01.04 Arquitectura Internet en Tres Capas

Vamos a ver, en una primera aproximación, los componentes que intervienen en una Aplicación Inter-
net/Intranet sobre una Arquitectura en Tres Niveles.

Clasificando los componentes según el nivel de la arquitectura al que pertenecen, tendremos:

 Nivel de Presentación
Los componentes participantes de este nivel tienen como función realizar la presentación de la
información extraída de la base de datos, interactuar con el usuario e interactuar con los objetos de
aplicación para enviar o solicitar procesos sobre los datos. Dado que estamos hablando de aplicaciones
sobre Internet, los componentes visuales de la aplicación son Páginas HTML.

4 ___________________________________________________
VOLUMEN 04 – COMUNICACIONES, REDES E INTERNET
Volumen 4. Redes, Comunicaciones e Internet.

 Nivel de Aplicación
En este nivel intervienen los Objetos de Negocio. Dichos objetos están ubicados en el Servidor de
Aplicaciones y son los encargados de procesar la lógica de la aplicación, así como de establecer el
mecanismo de comunicación entre la información almacenada en la base de datos y el usuario. De esta
manera, los componentes de las páginas HTML solicitarán cierta información a estos objetos de negocio,
que a su vez solicitarán la información a la base de datos, devolviéndola entonces al cliente
(componente de la página HTML).
 Nivel de Datos
Es el encargado del almacenamiento de los datos, y sus componentes son los Componentes de una Base
de Datos Relacional: tablas, vistas, triggers, procedimientos almacenados, etc.

114.01.05 Componentes Software de una Aplicación Web

La información que se ofrece en un sitio web está, tradicionalmente, almacenada en ficheros. El cliente soli-
cita ficheros por un nombre, y el servidor web envía por HTTP estos ficheros al cliente. Estos ficheros tienen
formato HTML y componen el contenido del sitio web.

En los orígenes de Internet, todas las aplicaciones constaban únicamente de ficheros estáticos HTML. Sin
embargo, a medida que crece y se extiende Internet, comienzan a aparecer sitios web dinámicos, es decir,
sitios web que ofrecen información no necesariamente contenida en una página HTML. Las aplicaciones web
dinámicas forman en tiempo de ejecución el contenido HTML que envían al cliente, normalmente a partir de
información almacenada en una base de datos o cualquier otro dispositivo de almacenamiento. Las páginas
HTML resultantes que se envían al cliente pueden haber sido obtenidas mediante CGI’s, Active Server Pages,
Servlets, etc.

Los sitios dinámicos ofrecen muchas ventajas a los desarrolladores. Gracias a la construcción dinámica de
páginas HTML es posible mantener coherente el contenido web con el contenido almacenado en la base de
datos. Así, el sitio web puede ser visto como un conjunto de páginas y scripts que se ejecutan en el servidor.
En este contexto un fichero puede ser tanto un fichero plano (sólo texto) como un fichero con scripts inter-
pretados por el servidor web o por otro intérprete ubicado en el servidor.

Servidor WEB Navegador

htt

referen-

procesa Filtro

Página con Scripts

Dentro de la arquitectura en tres capas definida anteriormente, los componentes software que conforman el
_______________________________________________________________________
5
114. Desarrollo de aplicaciones en la WEB (I).
Servidor de Aplicaciones son los mostrados en la siguiente figura:

Servidor HTTP/SSL

Objetos de Negocio Páginas Páginas


Servlets/Clases Java dinámicas HTML
Controles ActiveX ASP/JSP
Archivos Multimedia

JVM Intérprete Scripting Imagen, Audio, Video

Gestor de Transacciones

JDBC/ODBC

TCP/IP

 Servidor HTTP/SSL. El servidor web sirve las páginas HTML a los clientes que la solicitan. Para
ello el servidor debe disponer de una conexión a Internet.

El protocolo sobre el que se solicitan y envían las páginas HTML es el protocolo http (HyperText
Transfer Protocol). Sería suficiente que el servidor web dispusiera de este protocolo. Sin embargo,
día a día la seguridad se está convirtiendo en un factor más importante. Gracias al protocolo SSL
(Secure Sockets Layer) se puede enviar y recibir información de forma segura. Actualmente es el
protocolo más utilizado para garantizar la seguridad en la Red. Por ello, se recomienda que el servi-
dor web permita la habilitación de este protocolo.

Los servidores más utilizados en la actualidad son, por una lado, Apache Web Server, software libre
muy utilizado en la comunidad Unix; y por otra parte, Internet Information Server en el mundo NT
de Microsoft.

 Páginas HTML. Hasta ahora el componente más importante de una aplicación web era la página
HTML. Los navegadores solicitan páginas (o páginas conceptuales) a los servidores. Los servidores
distribuyen la información a los navegadores. La apariencia que ofrecen las páginas HTML confor-
man la apariencia de la aplicación, es decir, conforman la capa de presentación.

Cualquier aplicación web que se precie debe permitir al usuario, además de navegar por las páginas
del sitio web, introducir datos que personalicen la comunicación entre servidor y cliente. Los datos
que el cliente puede introducir son texto, selecciones de combos o información booleana. El meca-
nismo más común para recuperar esta información del usuario son los formularios HTML.

Un formulario HTML es una colección de campos de entrada que se ubican dentro de una página
HTML. Los elementos básicos de entrada son: caja de texto de una línea, caja de texto multilínea,
checkbox, radio button y listas de selección.

Todos los elementos de un formulario HTML se identifican con un nombre o un identificador. Cada
formulario tiene también asociada una acción, bien una página, un CGI, un Servlet… Cuando el

6 ___________________________________________________
VOLUMEN 04 – COMUNICACIONES, REDES E INTERNET
Volumen 4. Redes, Comunicaciones e Internet.

usuario pulsa el botón Enviar (subbmit) la información contenida en el formulario es enviada al ser-
vidor a la acción especificada. El resultado de esa acción (una página HTML) será enviado como res-
puesta al cliente. De esta manera el usuario ha interaccionado con el servidor, enviando información
y personificando las acciones deseadas.

 Objetos de Negocio. No toda la lógica de la aplicación debe ser implementada en los scripts de las
páginas HTML. Las grandes aplicaciones web implementan también componentes en su capa de ne-
gocio. Esta capa intermedia existe entre la interfaz de usuario (páginas HTML con scripts) y la capa
persistente (base de datos) y suele estar implementada como un conjunto de componentes que se
ejecutan en el servidor de aplicaciones. Este servidor puede estar físicamente junto con el servidor
web, pero también puede ser una máquina distinta. Una de las mayores ventajas de esta capa in-
termedia es la habilidad para compartir estos objetos de negocio entre distintas aplicaciones, ya se-
an web o no. Otra gran ventaja es la encapsulación de toda la capa de negocio y su independencia
con respecto a la presentación.

Normalmente, los scripts de servidor de las páginas HTML contienen referencias a los objetos de
negocio del servidor. Dichos scripts crean objetos y ejecutan sus métodos. Tal y como comentamos
antes, este procesamiento se realiza durante la petición de una página por parte del cliente. Una vez
que el servidor envía la página al cliente, la conexión con los objetos de negocio desaparece.

 Páginas Dinámicas. En muchas tecnologías de desarrollo web, como Java Server Pages (JSP) de
Java o las Active Server Pages (ASP) de Microsoft, las páginas son una combinación de HTML estáti-
co y scripts dinámicos. Partes del código embebido en las páginas HTML será ejecutado en el servi-
dor, y parte del código será ejecutado en el cliente.

Los scripts embebidos en estas páginas .asp o .jsp se interpretan en el servidor y el resultado de su
ejecución es enviado al cliente en forma de página HTML. Dichos scripts pueden estar escritos en
cualquier lenguaje de scripting, siendo los más conocidos JavaScript, JScript y VBScript. Dada su im-
portancia, se estudiarán con más detalle con posterioridad.

 Intérprete de Scripting. El servidor web debe disponer de un intérprete de scripting que permita
la ejecución de scripts de servidor.

Es importante resaltar que la conexión entre el cliente y el servidor solamente está activa durante el
proceso de solicitud de la página. Una vez que el servidor envía la página solicitada al cliente, la co-
nexión se rompe. Toda la actividad del servidor tiene lugar durante la solicitud de la página. La lógi-
ca de la aplicación del servidor se activa únicamente mediante la ejecución de scripts ubicados en
las páginas solicitadas por el cliente.

Dependiendo del motor de script, las páginas pueden contener variables definidas por el usuario,
funciones y procedimientos. En el caso de Java es posible también definir clases e instancias de cla-
ses.

El objetivo del procesamiento de código en el servidor es actualizar el estado de la aplicación en el


servidor y preparar y formatear la nueva página HTML, obtenida a partir de datos de la base de da-
tos.

Para poder diseñar una aplicación web es muy importante comprender el paradigma de la interac-
ción servidor-cliente. Los objetos de negocio no son siempre accesibles cuando se realizan peticio-
nes por parte del cliente, por lo que el diseño de estas aplicaciones no puede ser paralelo con res-
pecto al diseño de aplicaciones tradicionales. Hay que aprender a pensar “de forma web”.

 Java Virtual Machine (JVM). Las aplicaciones Java y los objetos utilizados desde las Java Server
Pages, necesitan la máquina virtual Java para poder ejecutarse. Si se utiliza esta tecnología, sería
necesaria la instalación del entorno de ejecución Java.

 Gestor de Transacciones. Existe la posibilidad de instalar un gestor de transacciones en el servi-


dor de aplicaciones. Este gestor se configura como contenedor del entorno de ejecución de los obje-

_______________________________________________________________________
7
114. Desarrollo de aplicaciones en la WEB (I).
tos de servidor, ofreciendo funciones adicionales. Entre estas funciones, cabe destacar la multiplexa-
ción de conexiones a la base de datos, es decir, la facilidad de utilizar la misma conexión a la base
de datos por dos objetos diferentes, minimizando así el número de conexiones abiertas. Los gesto-
res de transacciones también permiten la monitorización del sistema, así como el estudio de la “his-
toria del servidor” (mediante el almacenamiento de snapshots del estado del sistema). Una última
función a destacar es la reiniciación de objetos en caso de caída, favoreciendo la disponibilidad de
las aplicaciones.

Algunos gestores de transacciones muy utilizados en la actualidad son Tuxedo de Bea Systems y Mi-
crosoft Transaction Server (MTS).

 Drivers de conexión a bases de datos (JDBC/ODBC). El servidor de aplicaciones debe Conec-


tarse al servidor de datos y acceder a la información que controlan los gestores de bases de datos.
Hoy en día, los sistemas más utilizados son los gestores relacionales, entre los que se destacan Ora-
cle, Informix, Sybase, SQL Server... Los drivers que se utilizaban hasta el momento estaban basados
en el estándar ODBC (Open DabaBase Connectivity). Desde la aparición de Java, también se propor-
cionan drivers JDBC (Java DataBase Connectivity) para acceso a bases de datos desde aplicaciones
Java.

 Archivos Multimedia. En el servidor de aplicaciones estarán ubicados todos los ficheros de ima-
gen, audio y video que se deseen poner a disposición de los usuarios. También deberían estar ubi-
cadas las instalaciones de los plug-ins necesarios para escuchar o ver dicha información, de manera
que los usuarios puedan descargarlas (en aquellos casos en que sea necesario).

 TCP/IP. Los protocolos de nivel de transporte y red en Internet son TCP/IP (Transfer Control Pro-
tocol / Internet Protocol).

Los componentes software del Servidor de Datos son:

 Gestor de Bases de Datos


 Drivers de Acceso a Datos (JDBC/ODBC)
 TCP/IP

Los componentes software del Cliente son:

Navegador web

JVM Intérprete Scripting Plug-ins

TCP/IP

 Navegador web. Programa que permite el acceso y manejo de la información disponible en Inter-
net a través de un sistema amigable y eficaz. El primero fue Mosaic de NCSA (escrito en Lenguaje
C). Posteriormente vino Netscape Navigator (ahora llamado Communicator) y más tarde Microsoft
Internet Explorer. Hoy en día los navegadores integran muchos servicios de Internet, tales como
FTP (File Transfer Protocol), correo electrónico, news, etc.

 Java Virtual Machine. Los applets de Java necesitan la máquina virtual Java para poder ejecutar-
se. Los navegadores actuales ya permiten la ejecución de los applets sin necesidad de instalar

8 ___________________________________________________
VOLUMEN 04 – COMUNICACIONES, REDES E INTERNET
Volumen 4. Redes, Comunicaciones e Internet.

ningún plug-in adicional.

 Intérprete Scripting. El servidor no es el único que dispone la capacidad de ejecutar código, pues
los scripts también pueden ejecutarse en el cliente, una vez que éste ha recibido la página. El código
que se ejecuta en el cliente no puede acceder a los objetos de negocio, puesto que no puede llamar
a estos objetos del servidor (el código se ejecuta localmente en el cliente). Por este motivo, los
scripts de cliente no se suelen utilizar para implementar la lógica de negocio, sino para realizar vali-
daciones de datos antes de enviar éstos al servidor. Por ejemplo, comprobar el formato de una fe-
cha es una función muy común del código de cliente.

No debemos confundir los scripts de cliente con los componentes de cliente, tales como los applets
de Java o los controles ActiveX. Estos componentes están incluidos en una categoría aparte dentro
del conjunto de categorías participantes en las aplicaciones web. Los scripts de cliente a los que nos
estamos refiriendo son aquellos escritos en JavaScript o en VBScript, scripts que se encuentran em-
bebidos dentro de la página. El código de estos scripts se ejecuta como resultado de la generación
de algún evento por parte del cliente, como puede ser pulsar un botón.

Las páginas HTML pueden también contener componentes específicos que se ejecutan en el cliente.
Los componentes de este tipo más conocidos son los Applets de Java y los controles ActiveX. Ambos
se ejecutan en el navegador, aunque sólo determinados navegadores soportan estos componentes.

La seguridad se vuelve un factor muy importante en estos componentes, pues no pueden realizar
todas las operaciones que deseen en un máquina ajena al servidor. Por este motivo, las acciones
que pueden ser realizadas desde los componentes de cliente están limitadas.

Por último, destacar que estos componentes pueden ser muy útiles para dotar a la aplicación de una
apariencia imposible de ofrecer con los elementos estándar HTML.

 Plug-ins. Los plug-ins son programas que se agregan al navegador e interactúan con él, con las
páginas web y con los recursos locales y de Internet. Hoy en día, prácticamente todos los navegado-
res soportan plug-ins, que normalmente se usan para agregar soporte para nuevos formatos de ar-
chivos o bien para agregar interactividad. Tienen mucha aceptación porque ofrecen una manera fácil
de extender la funcionalidad del navegador sin necesidad de bajar un navegador nuevo. Serán estu-
diados con más detalle a lo largo del tema.

 TCP/IP. Los protocolos de nivel de transporte y red en Internet son TCP/IP (Transfer Control Pro-
tocol / Internet Protocol).

Tecnologías Existentes

Para desarrollar una aplicación web sobre una arquitectura en tres capas podemos utilizar dos tecnologías
que denominaremos “Tecnología Java” y “Tecnología Microsoft”. Ambas se definen sobre la misma
arquitectura compuesta por los elementos ya descritos: páginas HTML estáticas, páginas dinámicas, objetos
de servidor y datos. La diferencia radica en la manera en que se introduce el dinamismo a la aplicación.

En el primer caso, los objetos de servidor se implementan en Java, mientras que en el segundo caso se
implementan en Visual Basic o Visual C++ (existe la posibilidad de implementarlos en Java, aunque por su
complejidad se desaconseja). Por otro lado, las páginas dinámicas se denominan Java Server Pages, en el
caso de la tecnología Java y Active Server Pages (ASP) en el caso de la tecnología Microsoft.

_______________________________________________________________________
9
114. Desarrollo de aplicaciones en la WEB (I).
Microsoft Java
S.O. Windows NT Unix, Macintosh, NT…
Independiente
Acceso a BD ODBC JDBC
Servidor Web IIS (Internet Information Netscape Web Server
Server) Apache Web Server
Java Web Server

Lenguaje de Scripting VBScript, Jscript JavaScript
Páginas Dinámicas ASP (Active Server Pages) JSP (Java Server Pages)
Objetos de Servidor Componentes ActiveX Servlets
Clases Java
Objetos de Cliente Componentes ActiveX Applets Java
Navegador Web Internet Explorer IE, Netscape, HotJava…
Independiente

10 ___________________________________________________
VOLUMEN 04 – COMUNICACIONES, REDES E INTERNET
Volumen 4. Redes, Comunicaciones e Internet.

114.02 Lenguajes de Scripting

114.02.01 JavaScript

El lenguaje de programación JavaScript es un compacto lenguaje de creación de scripts incorporado, basado


en objetos, independiente de la plataforma y controlado por eventos. Puede usarse para desarrollar aplica-
ciones de Internet que residan en el servidor o en el cliente. Sin ninguna comunicación de red, una página
HTML con JavaScript incrustado interpreta el texto introducido en los campos del formulario y avisa al usua-
rio por medio de un diálogo si los datos introducidos son válidos (es decir, es muy útil para las validaciones
de primer nivel).

JavaScript también sirve para llevar a cabo acciones tales como reproducir un archivo de audio, ejecutar un
applet o comunicarse con un plug-in. Los scripts de cliente están restringidos, como su nombre indica, a él
mismo, y no pueden comunicarse con el servidor para intercambiar datos.

JavaScript permite elaborar scripts de eventos (por ejemplo, presionar una tecla o hacer clic con el ratón),
objetos (como elementos de formularios u hojas de estilo) y acciones, en diferentes plataformas. Además,
crea interacción entre HTML, plug-ins y Java.

Contrariamente a la creencia popular, JavaScript no es una versión reducida de Java ni reemplaza los scripts
de CGI (Common Gateway Interface). Fue desarrollado por Netscape, no por Sun (empresa desarrolladora
de Java), pero utiliza un nombre similar por razones de márketing. El nombre originario de JavaScript era
“Mocha”, que después pasó a ser “LiveScript” para finalmente terminar siendo JavaScript. El intérprete real
de JavaScript en la mayoría de los navegadores se basa en el estándar ECMAScript, que es la versión estan-
darizada de JavaScript, con soporte de la organización ECMA de Europa.

Por medio de JavaScript, hasta los desarrolladores menos experimentados pueden dirigir respuestas desde
diversos eventos, objetos y acciones. Toda persona que sepa componer HTML tiene así la capacidad de
cambiar imágenes y reproducir distintos sonidos en respuesta a eventos especificados, tales como el clic del
ratón que realiza un usuario o bien la salida y entrada en la pantalla. Este programa también ofrece a los
desarrolladores la capacidad de verificar los datos introducidos por los clientes antes de que se envíen al
servidor, lo cuál atenúa la carga y la cantidad de conexiones que deben tener lugar en la red. JavaScript
también funciona sin problemas en ordenadores muy antiguos y lentos, a diferencia de los applets de Java,
que pueden resultar demasiado lentos para ordenadores antiguos.

Ventajas de JavaScript

JavaScript presenta muchas ventajas frente a los lenguajes tradicionales de programación. Para empezar, se
integra perfectamente con el navegador web. Por otro lado, puede acceder a todos los objetos de una pági-
na web y manipularlos, a través del modelo de objetos del navegador. Por tanto, hay interacción con el
usuario sin conectarse con el servidor.

JavaScript es una extensión prácticamente universal del lenguaje HTML que mejora la experiencia del usua-
rio por medio de la gestión de eventos y la ejecución en el cliente. A la vez amplía el control que ejerce el
desarrollador web sobre el navegador del cliente. Los programas escritos en JavaScript pueden usarse para
realizar las validaciones de primer nivel. También se puede utilizar para crear contenido dinámico. Según el
tipo de navegador, JavaScript puede mostrar información en distinto formato. También se puede modificar
la imagen de la página en función de los datos introducidos por el cliente.

Según el tipo de aplicación de red y ancho de banda, es necesario evaluar la combinación de aplicaciones
para cliente y aplicaciones para servidor. JavaScript crear y lee cookies, y así es posible conservar el estado
del cliente. Una cookie es información guardada en el navegador que puede ser recuperada por el servidor
que la colocó allí y que sirve, por ejemplo, para identificar a un usuario. Utilizando JavaScript, cookies y
páginas HTML se pueden crear aplicaciones complejas sin necesidad de programar nada en el servidor.

_______________________________________________________________________
11
114. Desarrollo de aplicaciones en la WEB (I).
Problemas de JavaScript en los Navegadores

Si bien actualmente todos los grandes navegadores aceptan JavaScript, sigue existiendo un problema, ya
que la implementación difiere entre un navegador y otro, como ocurre con HTML. El resultado es que las
páginas web no se visualizan bien en ciertos navegadores y que las aplicaciones no se ejecutan correcta-
mente en la Web por utilizar un navegador que no corresponde. Ya era bastante complicado que existieran
diversas implementaciones de HTML, pero con las implementaciones divergentes de JavaScript los desarro-
lladores web se han visto aún más limitados para crear nuevos sitios, pues mantener la compatibilidad con el
amplio abanico de posibilidades no es tarea fácil. La solución pasaba por seleccionar un navegador y reco-
mendar su utilización, lo que normalmente conlleva muchas protestas por parte de los usuarios, que no
quieren verse obligados a utilizar un navegador concreto.

La otra opción, soportar todas las versiones, implica dos cosas. O bien hay que limitarse al mínimo compati-
ble con todos los navegadores, por lo cuál el sitio web será muy aburrido, o bien se puede crear scripts
múltiples para todos los navegadores, lo cuál es muy engorroso desde el punto de vista del desarrollador.

114.02.02 JScript

JScript es la implementación de Microsoft de la especificación de lenguaje ECMA 262 (ECMAScript Edition 3).
Aparte de algunas excepciones de poca importancia (para mantener la compatibilidad con versiones anterio-
res), JScript es una implementación completa del estándar ECMA...

...o al menos eso certifica Microsoft, aunque en la práctica JScript presenta incompatibilidades con dicha
especificación y con JavaScript, haciendo las sentencias escritas en JScript ilegibles para otros navegadores
distintos a Internet Explorer. Por este motivo, los scripts que deban ser ejecutados en el cliente siempre
deberían ser programados en JavaScript que funciona en todos los navegadores, y nunca en JScript. JScript
sí se integra perfectamente con el servidor web de Microsoft, por lo que es un buen lenguaje de scripting
para la parte servidora de las aplicaciones.

Siguiendo con las características técnicas, JScript es un lenguaje de secuencias de comandos interpretado y
basado en objetos. Aunque tiene menos funciones que los lenguajes orientados a objetos de altas prestacio-
nes como C++, JScript es muy eficiente para los propósitos a los que se destina.

JScript no es una versión reducida de cualquier otro lenguaje (sólo está relacionado, distante e indirecta-
mente, con Java, por ejemplo), ni es una simplificación de ningún lenguaje. Sin embargo, es un lenguaje
limitado. Por ejemplo, en JScript no se permite escribir aplicaciones independientes ni proporciona compati-
bilidad integrada para la lectura y escritura de archivos, por ejemplo. Además, las secuencias de comandos
de JScript sólo pueden ejecutarse con un intérprete o "host", como las páginas Active Server (ASP, Active
Server Pages), Internet Explorer o Windows Script Host.

JScript es un lenguaje en el que no se necesita declarar los tipos de datos. Esto significa que no es necesario
declarar explícitamente los tipos de datos de las variables. De hecho, JScript incluye una mejora en esta
característica. No se puede declarar explícitamente los tipos de datos en JScript. Además, en muchos casos
JScript realiza conversiones de forma automática cuando es necesario. Por ejemplo, si agrega un número a
un elemento que contiene texto (una cadena), el número se convierte en texto.

114.02.03 JavaScript Versus JScript

Como ya hemos dicho, JavaScript fue creado por Netscape y desde entonces es el lenguaje de creación de
scripts para cliente más elegido. Como las primeras especificaciones fueron desarrolladas solamente por
Netscape, Microsoft inventó JScript, que se asemeja en gran medida a JavaScript y supuestamente es com-
patible. No obstante, hay algunas diferencias interesantes si tenemos en cuenta que las empresas están on-
line deben tener aplicaciones compatibles con todos los navegadores.

Algunas diferencias surgen de bugs en la implementación, y otras, de la implementación en sí. En las prime-
ras versiones, cuando Netscape desarrollaba el estándar por su parte, la implementación de JavaScript iba
siempre adelantada con respecto a la de JScript.

12 ___________________________________________________
VOLUMEN 04 – COMUNICACIONES, REDES E INTERNET
Volumen 4. Redes, Comunicaciones e Internet.

La decisión de Microsoft de elaborar scripts para cliente permite al desarrollador optar entre la sintaxis al
estilo de C que tiene JavaScript de Netscape y el estilo de Visual Basic al que están acostumbrados muchos
desarrolladores de tecnologías Microsoft.

Las diferencias entre JavaScript y JScript son muy sutiles, pero son lo suficiente como para interrumpir el
código. Mientras que JavaScript no es sensible a las mayúsculas y minúsculas para los nombres de función
estándar, JScript sí lo es. Otro problema es el de la jerarquía de objetos, que dificulta el acceso a los objetos
en la página web, aunque trabajando sobre el script original se puede conseguir que funcione en ambos
navegadores.

114.02.04 VBScript

Microsoft Visual Basic Scripting Edition, el miembro más reciente de la familia de lenguajes de programación
de Visual Basic, lleva la ejecución de secuencias de comandos a una variedad de entornos, incluida la ejecu-
ción de secuencias de clientes Web en Microsoft Internet Explorer y la ejecución de secuencias de servidores
Web en Servicios de Microsoft Internet Information Server.

La apariencia y forma de programación en VBScript es muy similar al conocido lenguaje de programación de


Microsoft Visual Basic o Visual Basic para Aplicaciones.

VBScript se comunica con las aplicaciones principales mediante ActiveX Scripting. Con ActiveX Scripting, los
exploradores y otras aplicaciones principales no necesitan ningún código de integración especial para cada
componente de ejecución de secuencias de comandos. ActiveX Scripting permite a un host compilar secuen-
cias de comandos, obtener y llamar a puntos de entrada y administrar el espacio de nombres disponible
para el programador. Con ActiveX Scripting, los proveedores del lenguaje pueden crear bibliotecas de tiempo
de ejecución del lenguaje estándar para la ejecución de secuencias de comandos. Microsoft proporcionará
soporte para bibliotecas de tiempo de ejecución para VBScript. Microsoft colabora con varios grupos de In-
ternet para definir el estándar de ActiveX Scripting de manera que los motores de ejecución de secuencias
de comandos se puedan intercambiar. ActiveX Scripting se utiliza en Microsoft Internet Explorer y en Servi-
cios de Microsoft Internet Information Server.

La ventaja principal de VBScript es la integración total al sistema operativo Microsoft, gracias a la cual crea
aplicaciones web muy sofisticadas. Los bugs de estos scripts pueden eliminarse con el depurador estándar
de Microsoft, y así resulta más fácil detectarlos.

La desventaja principal de VBScript también es su integración total al sistema operativo de Microsoft, dado
que no corre sobre otros sistemas operativos ni sobre otros navegadores. Es exclusivo para usuarios de In-
ternet Explorer y Windows. Eso viola las reglas de la Web, que establecen que todo debe ser accesible para
todos.

_______________________________________________________________________
13
114. Desarrollo de aplicaciones en la WEB (I).
114.03 Componentes de Cliente

114.03.01 Applets

Un applet es un programa de Java incrustado en una página HTML. Es importante entender la diferencia
entre un applet y una aplicación. Los applets se diseñan específicamente como objetos incrustados en pági-
nas web y no se ejecutan fuera de este contexto. Se descargan como documentos HTML y se ejecutan en el
cliente.

Los applets que se cargan desde la red no pueden leer ni escribir archivos del sistema cliente. Aunque estas
características serían suficientes para proteger los ordenadores cliente, se han incorporado medidas de se-
guridad adicionales para evitar que se utilice la máquina cliente como gateway, mediante la habilitación de
conexiones de Internet únicamente a través del host de origen.

Tampoco se permite que los applets puedan iniciar aplicaciones instaladas en el ordenador cliente ni acceder
a ellas. Se prohíbe también que carguen bibliotecas o definan llamadas de métodos nativos, lo cual impide el
acceso al sistema operativo y a sus recursos.

Como se puede imaginar, estas restricciones de seguridad también limitan las posibilidades de uso de los
applets de Java. Está establecido que no se pueden imprimir ni guardar documentos. Para permitir estas
opciones, hay que pedir permiso a los clientes (deben habilitar esta posibilidad). Para poder incorporar la
capacidad de acceso a los recursos locales es necesario firmar el applet. Mediante este procedimiento se
revela la identidad del programador. Este procedimiento de firma y confirmaciones por parte de los clientes
hace que los applets de Java sean muy seguros, aunque es válido únicamente para los que se descargan de
la red, mientras que aquellos que están ubicados en el disco local tienen estas opciones habilitadas automá-
ticamente.

Etiqueta <APPLET></APPLET>

La sintaxis de la etiqueta <applet> necesaria para introducir un applet en una página HTML es la que se
muestra a continuación. Los elementos obligatorios están en negrita:

<APPLET
CODEBASE = URL
ARCHIVE = lista de archivos
CODE = fichero_applet ...o... OBJECT = applet serializado
ALT = texto alternativo
NAME = nombre de instancia del applet
WIDTH = pixels HEIGHT = pixels
ALIGN = alineación
VSPACE = pixels HSPACE = pixels
>
<PARAM NAME = Atributo1 del applet VALUE = valor>
<PARAM NAME = Atributo2 del applet VALUE = valor>
...
más HTML
</APPLET>

CODE, CODEBASE, son atributos de la etiqueta applet; ofrecen información acerca del applet. Los únicos
atributos obligatorios son CODE, WIDTH, and HEIGHT. A continuación se describe cada atributo.

 CODEBASE = URL
Este atributo, opcional, especifica la URL del applet, es decir, el directorio que contiene el código del ap-
plet. En caso de no ser especificado, se utiliza la URL del documento.
 ARCHIVE = lista de archivos
Este atributo, opcional, describe uno o más archivos que contienen las clases y otros recursos que deben
ser “precargados”. Los archivos se separan por “,”.

14 ___________________________________________________
VOLUMEN 04 – COMUNICACIONES, REDES E INTERNET
Volumen 4. Redes, Comunicaciones e Internet.

 CODE = fichero_applet
Este atributo, obligatorio, proporciona el nombre del fichero que contiene la subclase applet. Es relativo
a la URL del applet. No puede ser una dirección absoluta. Si no está presente el atributo CODE debe es-
tar presente el atributo OBJECT.
 OBJECT = applet serializado
Este atributo proporciona el nombre del fichero que contiene una representación serializada de un ap-
plet. Si no está presente el atributo CODE debe estar presente el atributo OBJECT.
 ALT = texto alternativo
Este atributo, opcional, especifica cualquier texto que debería ser mostrado si el navegador no puede
entender el applet y no puede ser ejecutado.
 NAME = nombre de instancia del applet
Este atributo, opcional, especifica un nombre para la instancia del applet, haciendo posible la comunica-
ción entre applets ubicados en la misma página.
 WIDTH = pixels HEIGHT = pixels
Estos atributos, obligatorios, proporcionan información acerca de la anchura y altura inicial de la zona
del navegador en la que el applet será mostrado.
 ALIGN = alineación
Este atributo, opcional, especifica la alineación del applet. Los valores posibles son los mismos que para
la etiqueta IMG: left, right, top, texttop, middle, absmiddle, baseline, bottom, absbottom.
 VSPACE = pixels HSPACE = pixels
Estos atributos, opcionales, especifican el número de píxeles arriba y abajo del applet ( VSPACE) y a cada
lado del applet (HSPACE).
 <PARAM NAME = Atributo1 del applet VALUE = valor>
Esta etiqueta es la única manera de especificar un atributo específico del applet.

114.03.02 Controles ActiveX

ActiveX permite que los componentes software interactúen entre sí en un entorno de red, independiente-
mente del lenguaje en el que han sido programados. Se pueden crear componentes ActiveX que proporcio-
nen características de aplicaciones comunes y funciones que puedan ser fácilmente reutilizables, tanto en un
entorno de red como en una aplicación independiente tradicional.

Los controles ActiveX son componentes (u objetos) que se pueden insertar en una página web o una aplica-
ción para proporcionar características sofisticadas y animaciones. Los controles ActiveX son pequeños y
versátiles y ofrecen una puerta abierta hacia la creación de contenido web espectacular. Pueden ser escritos
en casi todos los lenguajes de programación, incluyendo Java, C++ y Microsoft Visual Basic. Los controles
ActiveX se pueden reutilizar con facilidad en otras páginas web o aplicaciones.

La arquitectura abierta de ActiveX permite la creación de contenido web dinámico utilizando la tecnología
COM (Component Object Model), scripts y componentes software (incluyendo applets de Java). Esta arqui-
tectura permite que aplicaciones independientes interactúen entre sí, ya sean aplicaciones ejecutándose en
navegadores o aplicaciones independientes.

Etiqueta <OBJECT></OBJECT>

Para introducir un control ActiveX en una página HTML es necesario utilizar la etiqueta <object>. Un ejem-
plo es el que se muestra a continuación:

<OBJECT CLASSID="clsid:99B42120-6EC7-11CF-A6C7-00AA00A47DD2"
CODEBASE="[Link]
ID=control1
WIDTH=150
HEIGHT=90
>
<PARAM NAME="Atributo 1 del control" VALUE=valor>
</OBJECT>

_______________________________________________________________________
15
114. Desarrollo de aplicaciones en la WEB (I).
 El objeto introducido en la página HTML se identifica mediante su CLASSID. Es un identificador único
para el control, de acuerdo con el “class id” que define el modelo COM.

 El atributo ID especifica una etiqueta con un nombre único dentro de la página, con el objetivo de
facilitar el acceso a dicho control dentro de la página, ya que acceder al control mediante su
CLASSID es muy engorroso para el programador.

 El atributo CODEBASE se utiliza para proporcionar la URL desde la cual el control debe ser descarga-
do. Si el control se encuentra ya instalado en los clientes, no es necesaria la definición de esta URL,
aunque es recomendable que siempre se indique al navegador dónde buscar el control en caso de
no existir en la máquina del usuario.

 Además de estos atributos, el control puede tener definidos los suyos propios. Mediante el atributo
PARAM se puede dotar de valor a los mismos.

114.03.03 Comparación entre Java y ActiveX

Ambas tecnologías ofrecen la posibilidad de agregar funcionalidades a páginas web estáticas sin la necesi-
dad de conexiones de servidor adicionales. Al descargar un control ActiveX o un applet Java, las páginas
web pasan a ser más dinámicas e interactivas. No obstante, esta ventaja básica también traen aparejados
algunos problemas. ActiveX y Java presentan un problema de seguridad adicional para los datos del ordena-
dor del cliente. Un programa descargado puede contener resquicios incorporados con el fin de intentar ac-
ceder a los datos o bien destruirlos. Con el objetivo de que ActiveX y Java resulten de utilidad para los usua-
rios y que éstos los acepten, ambos sistemas implementan medidas para garantizar la seguridad y la priva-
cidad de los datos.

Internet Explorer, navegador de Microsoft, cuenta con soporte para ActiveX de forma nativa; Communicator
de Netscape necesita un plug-in para que los controles ActiveX puedan correr sobre él. Gracias a las configu-
raciones de seguridad, se pueden aceptar los controles ActiveX con o sin previo aviso, y también es posible
rechazarlos. Si el usuario decide aceptar los controles ActiveX, debe confiar en el uso que dicho control pue-
de realizar sobre los recursos locales del usuario.

Java restringe el acceso a los recursos locales cuando se presentan applets que no son de fiar. Todos los
programas se ejecutan de forma predeterminada dentro de la “caja de arena” ( sandbox) de Java. En tanto
no se descubra un punto débil de la “caja de arena”, el usuario podrá estar seguro de que los datos y recur-
sos de su ordenador están protegidos.

Por tanto, la principal diferencia entre un control ActiveX y un applet de Java reside en el nivel de daños que
se pueden provocar al aceptar programas desconocidos. La mayoría de los controles ActiveX y los applets de
Java son inofensivos, pero basta con un único código malicioso para destruir todos los datos del usuario.

El usuario no permite el acceso a los recursos locales por el sólo hecho de aceptar un applet de Java, pero sí
lo permite con los controles ActiveX desde el momento en que acepta la descarga. La diferencia consiste en
que, en el caso de Java, el usuario no autoriza el acceso, mientras que en ActiveX sí. Para evitar riesgos,
deberían rechazarse todos los programas que provienen de servidores de Internet desconocidos o no fiables.

16 ___________________________________________________
VOLUMEN 04 – COMUNICACIONES, REDES E INTERNET
Volumen 4. Redes, Comunicaciones e Internet.

114.04 Integración de Contenido, Sonido, Imagen y Animación

La importancia de las información multimedia en el mundo Internet viene originada por la importancia que
en el mundo real también se le está concediendo. Hoy en día las empresas basan sus negocios en el diseño
y utilizan la imagen y música como herramientas primordiales del márketing. Los sitios web que utilizan alta
resolución de imágenes y ofrecen animaciones y música mejoran la comunicación, la colaboración y el co-
mercio con sus clientes.

Para poner en marcha todo el potencial de un sitio web con gran cantidad de información multimedia, según
las necesidades business-to-business (B2B) y business-to-consumer (B2C), hay que ofrecer tecnología con
los siguientes requerimientos:

 Alta resolución de las imágenes, sin necesidad de que cliente, servidor y red utilicen más recursos
 Velocidad de descarga: los tiempos deben reducirse al mínimo y deben ser optimizados
 Formato universal: se deben utilizar estándares, evitando los plug-ins específicos (que no sean un
estándar de facto) y software adicional
 Acceso universal: los usuarios deben tener la posibilidad de recibir la información multimedia que
deseen desde cualquier lugar de origen, sin estar condicionados por su lugar de residencia
 Libre elección de navegador y de software por parte de los clientes
 Escalabilidad: las soluciones y tecnologías utilizadas deben servir para que las compañías y los
webmasters manejen una gran cantidad de información de manera rápida y eficiente
 Integración con las soluciones existentes: las nuevas tecnologías deben permitir que los usuarios in-
tegren la nueva información con la disponible con anterioridad

114.04.01 Plug-ins

Los plug-ins son programas que se agregan al navegador e interactúan con él, con las páginas web y con los
recursos locales y de Internet. Hoy en día, prácticamente todos los navegadores soportan plug-ins, que
normalmente se usan para agregar soporte para nuevos formatos de archivos o bien para agregar interacti-
vidad. Tienen mucha aceptación porque ofrecen una manera fácil de extender la funcionalidad del navega-
dor sin necesidad de bajar un navegador nuevo. En especial durante los primeros años, los plug-ins eran
muy bien recibidos. Ahora que los navegadores traen cada vez más funciones incorporadas, la importancia
de los plug-ins desaparece poco a poco, sobre todo ante la posibilidad de que el XML pase a ser la nueva
base de los documentos de Internet. Todavía faltan algunos años para que los navegadores ya no necesiten
ningún plug-in. Actualmente se tiende a dejar de lado los plug-ins para ofrecer soluciones de Java o ActiveX.

Hay ventajas que hacen de los plug-ins la mejor solución. Pueden acceder sin dificultad a recursos del sis-
tema, como una impresora, además de ser mucho más rápidos que cualquier programa Java.

Algunos de los plug-ins más extendidos por Internet son:

1. El lector Acrobat de Adobe.

El PDF (Formato de documento portátil) de Acrobat es el formato más usado en Internet además del
HTML. Se aplica asiduamente en documentos de texto que necesitan impresión de alta calidad y diseño,
puesto que el plug-in de Acrobat está disponible para todas las plataformas más importantes.

Gracias a su integración con los navegadores web, muestra documentos de PDF sin ningún tipo de alte-
ración, y la impresión de alta calidad es compatible con impresoras estándar y Postscript. Así, casi todos
los sitios web utilizan PDF para distribuir folletos en línea y documentación técnica.

2. QuickTime de Apple

QuickTime fue inventado hace unos años por Apple Computer y desde entonces pasó a ser el entorno
más usado para CD-ROM de multimedia y para producciones en Internet. Se diseñó para simplificar la
tarea de manejar e integrar el espectro más amplio posible de medios digitales, no sólo sonido y video.
De hecho, el formato QuickTime Movie es tan bueno y tan bien aceptado que se convirtió en la base del
estándar MPEG-4.
_______________________________________________________________________
17
114. Desarrollo de aplicaciones en la WEB (I).
QuickTime reproduce numerosos sonidos y formatos de película, y el plug-in se comunica con aplicacio-
nes de JavaScript y Java, e integra los formatos compatibles mejor aún a las páginas web. QuickTime
sólo está disponible para plataformas de Windows y Macintosh.

3. Cosmoplayer de Platinum

Cosmoplayer de Platinum muestra documentos en VRML (Lenguaje de Modelado de Realidad Virtual). El


VRML es un formato interactivo que tiene su propio lenguaje de creación de scripts. Las interfaces de
Java y JavaScript permiten no sólo la creación de universos 3D sino también la posibilidad de hacerlos
interactivos. Por medio de la cuarta dimensión, la del tiempo, podemos mover cosas o cambiarlas. Con
los lenguajes antes mencionados, es posible dar vida a personas virtuales en un mundo en 3D o crear
representaciones virtuales de personas que merodeen por la escena de VRML.

Cosmoplayer fue lanzado como software libre, y hay binarios disponibles para Windows y Macintosh.

Muchas empresas utilizan Cosmoplayer para mostrar sus productos en tres dimensiones en pantalla de
modo que los clientes puedan darles la vuelta y mirarlos desde todas las perspectivas.

4. Shockwave de Macromedia

Shockwave se convirtió en el plug-in estándar para multimedia en Internet. Ya viene instalado con el
Communicator de Netscape; por tanto, los usuarios de Netscape no necesitan descargarlo. El plug-in re-
produce contenidos web interactivos, como software de entretenimiento, presentaciones comerciales,
juegos y publicidades.

Los archivos de este plug-in están creados exclusivamente con Director de Macromedia, una herramien-
ta para generar aplicaciones multimedia enriquecidas. Shockwave está muy extendido en la actualidad
por Internet.

114.04.02 Formatos de Imágenes Estáticas

Los navegadores web sólo brindan soporte directo a los formatos de imagen estática. En este caso, estático
significa que la imagen en sí no cambia de colores, perspectiva ni resolución. Todos los navegadores son
compatibles con los formatos de archivo estáticos GIF, JPEG y PNG (todavía quedan algunas personas que
ponen gráficos BMP en sus páginas web y no se dan cuenta de que la mayoría de los usuarios ven tan sólo
un link desconectado).

Si observamos la participación de mercado que poseen GIF, JPEG y PNG (se pronuncia “ping”) veremos que
PNG todavía no es muy común. Pero si deseamos crear sitios web con imágenes estáticas, PNG es la mejor
solución.

¿Por qué utilizar PNG si los formatos GIF Y JPEG existen desde hace más tiempo? Los dos formatos tienen
problemas. GIF (Graphic Interchange Format) es fruto de CompuServe y tiene la mala reputación de ser el
formato preferido para las imágenes pornográficas que se intercambian en la red. El formato GIF utiliza el
algoritmo de compresión patentado LZW de Unisys, por ello todos los programas que brindan soporte a GIF
tendrían que pagar por el uso de la licencia. Este hecho nunca se ha producido, pero la introducción de las
patentes en el mundo del software podría dar lugar a dicha situación.

Por otra parte, JPEG (Joint Photographics Experts Group) es un formato de imágenes denominado “con
pérdida”. De acuerdo a la magnitud de la compresión la imagen pierde información. El algoritmo de compre-
sión intenta eliminar información que el ojo humano no puede percibir, por lo que se trata de un buen for-
mato para la visualización. Sin embargo, tan pronto intentamos modificar una imagen JPEG, veremos que la
información oculta ha desaparecido. Si lo aplicamos en fotos, puede que no nos demos cuenta, pero si lo
aplicamos en imágenes prediseñadas (clip arts), texto, etc, se ve la diferencia inmediatamente. La ventaja
de JPEG es que los archivos se comprimen en una proporción de 1 a 10 o más.

18 ___________________________________________________
VOLUMEN 04 – COMUNICACIONES, REDES E INTERNET
Volumen 4. Redes, Comunicaciones e Internet.

Cuando a finales de 1994 CompuServe anunció que el formato GIF utilizaba un algoritmo patentado, la In-
ternet Society después de semanas de acaloradas discusiones en Usenet, comenzó el desarrollo de un nuevo
formato que sería gratuito y de mejor calidad que los GIF y los JPEG juntos. El proyecto PNG es un ejemplo
perfecto de la cooperación y eficiencia en Internet. Mediante el uso de correo electrónico y los grupos de
noticias, los expertos de todo el mundo han diseñado e implementado este nuevo estándar. Los objetivos de
este nuevo formato de imágenes fueron los siguientes:

 Portabilidad: ser compatible entre plataformas, sistemas operativos e implementaciones


 Liviano para la Red: reducir el tamaño de las imágenes para descargar la red de tráfico
 Nuevo formato de gráficos: crear un nuevo formato de gráficos para reemplazar a GIF y JPEG

PNG no ofrece soporte para las animaciones. Para ello existe otra formato llamado MNG (Gráficos de Red de
Imágenes Múltiples). Este formato está basado en PNG y es aún mejor que GIF para las animaciones.

PNG está soportado de manera directa a partir de las versiones 4 del Navigator/Communicator de Netscape
y de Internet Explorer de Microsoft. Las versiones anteriores pueden adaptarse al formato PNG mediante la
descarga de un plug-in.

114.04.03 Formatos de Imágenes Dinámicas

Las imágenes estáticas proporcionan al sitio web un diseño atractivo, pero siempre hay que tender a la in-
troducción de imágenes dinámicas (animaciones), pues mejorarán la apariencia de nuestro sitio web y pro-
vocarán la atención de posibles clientes.

Existe una amplia gama de productos diferentes en el mercado. Estos formatos pueden cambiar de resolu-
ción, perspectiva, iluminación, colores, etc. Dentro del contexto de las imágenes en Internet, dinámico no
significa aplicaciones Java, películas desarrolladas con el programa Director o controles ActiveX que también
pueden ofrecer formatos de imágenes interactivas y dinámicas, ya que éstas requieren programación adicio-
nal. En cambio, los formatos dinámicos no necesitan programación, pero sí diseño. Las imágenes dinámicas
contienen metainformación acerca de la imagen en sí, lo que permite modificar su apariencia sin necesidad
de crear una nueva imagen.

La mayoría de los formatos dinámicos utiliza plug-ins para navegadores o requiere programas especiales de
visualización. Esto limita el uso de los formatos si los plug-ins no son compatibles con todas las plataformas
destino (uno de los pocos plug-ins compatibles con todas las plataformas es el de Adobe Acrobat Reader, lo
que convierte a PDF como el formato estándar de distribución de documentos por Internet). Mediante el uso
de applets de Java se puede solucionar la dependencia de las plataformas, pero requiere que se escriba una
aplicación Java. Es mejor recurrir a los plug-ins para navegador, como QuickTime de Apple, CosmoPlayer de
Platinum o RealPlayer de Real Networks. Todos ellos están ya instalados junto con la instalación de Netscape
Communicator.

FlashPix, QuickTime VR y VRML son tres tecnologías avanzadas que han sido elegidas para las imágenes en
Internet. Existen muchos otros formatos, pero estos tres se adaptan a las nuevas necesidades que surgen
con Internet.

El Formato FlashPix

FlashPix no puede compararse con ninguna otra tecnología de imágenes del mercado. La clave de FlashPix
es el formato de archivos en mosaico y de multi-resolución que permite que las imágenes se almacenen en
distintas resoluciones para distintos propósitos, como edición o impresión. Cada resolución está dividida en
bloques o mosaicos de 64x64. Dentro de un mosaico, los píxeles pueden no estar comprimidos, o pueden
estar comprimidos mediante JPEG o en un solo color.

Algunas de las funciones principales de FlashPix son:

 Sistema coordinado de resolución independiente.


 Representaciones de imágenes múltiples.
 Definición de un espacio de color estandarizado que mantiene los colores uniformes cuando se los
_______________________________________________________________________
19
114. Desarrollo de aplicaciones en la WEB (I).
visualiza a través de diferentes pantallas e impresoras.
 Posibilidad de creación de nuevas extensiones, como una extensión de sonido que posibilita adjuntar
información de audio a una imagen en un solo paquete completo.
 Escalabilidad y portabilidad.

QuickTime VR

Hace unos años Apple Computer diseño QuickTime y desde entonces es el entorno más popular para los CD-
ROM multimedia y producciones de Internet. El objetivo de QuickTime es que se pueda trabajar con los tipos
de medios digitales más variados (no sólo sonido y video) e integrarlos. El formato QuickTime Movie es tan
bueno y popular que se ha transformado en la base del estándar MPEG-4.

QuickTime VR es el componente de realidad virtual que permite la visualización de imágenes panorámicas en


360 grados. Mediante las imágenes panorámicas se puede visualizar un objeto desde un punto de vista fijo o
se puede caminar alrededor de un objeto determinado, de acuerdo a lo que se quiera mostrar.

QuickTime está formado por los siguientes elementos:

1. El formato de archivo QuickTime Movie que define:


 Sistemas de almacenamiento de composiciones de medios digitales
 Formato de almacenamiento que no sólo guarda elementos de medios sino también la descripción
de su composición
2. La capa de abstracción de los medios de QuickTime que define:
 Acceso a las herramientas de software y a aplicaciones para el servicio de soporte de los medios
 Aceleración de hardware para las secciones críticas
 Sistemas para ampliar y mejorar los servicios de los medios
3. Un variado grupo de servicios internos de medios:
 Un grupo de capacidades globales internas que sirven para reducir el tiempo de desarrollo
 Interoperabilidad entre las aplicaciones QuickTime

Apple y sus empresas suministran el software para desarrollar las imágenes QuickTime VR. A diferencia de
FlashPix, QuickTime no es un estándar abierto. La totalidad del desarrollo y la implementación está en ma-
nos de Apple. El software de cliente viene en forma de un reproductor independiente y un plug-in de nave-
gador, ambos gratuitos en la versión estándar. No hace falta la instalación adicional de ningún software por
parte del servidor web. Los archivos de QuickTime se almacenan en la ruta de los documentos del servidor
web para que después los navegadores los puedan recuperar.

VRML (Virtual Reality Model Language)

El VRML (Lenguaje de modelado de realidad virtual) es el estándar de formato de archivo para multimedia
tridimensional y mundos virtuales compartidos en Internet. Se trata de una especificación abierta para crear,
visualizar y manipular objetos y espacios tridimensionales. Del mismo modo que HTML revolucionó Internet
al crear una interfaz gráfica y al ser la base para el intercambio de información, VRML eleva la experiencia
on-line al siguiente nivel de interacción, con gráficos estructurados y dos dimensiones adicionales. La tercera
dimensión (profundidad) y la cuarta (tiempo) se agregan a los “terrenos llanos” de Internet.

Las características principales de VRML son:

 Estándar abierto: ISO e IEC (International Electrotechnical Comisión) reconocieron VRML como un
estándar internacional (ISO/IEC-14772-1:1997) en diciembre de 1997
 Multimedia tridimensional: antes de su estandarización, VRML ya era el estándar de facto para com-
partir y publicar información entre CAD, animación y programas de modelado tridimensional
 Mundos virtuales compartidos: una de las motivaciones originales de los precursores de VRML fue la
posibilidad de hablar y trabajar en un espacio virtual tridimensional compartido
 En Internet: a diferencia de las aplicaciones tridimensionales previas, la utilización de Internet para
compartir objetos y escenas tridimensionales estaba incluida desde el comienzo.

VRML es el formato más interactivo de los descritos. Debido a que posee su propio lenguaje de creación de
scripts e interfaces con Java y JavaScript se pueden crear mundos tridimensionales interactivos.

20 ___________________________________________________
VOLUMEN 04 – COMUNICACIONES, REDES E INTERNET
Volumen 4. Redes, Comunicaciones e Internet.

No es necesaria la instalación de software adicional en el servidor web, pero el cliente de Internet debe des-
cargar uno de los plug-ins de VRML.

Comparación de Tecnologías de Imágenes


En la siguiente tabla se muestran las correspondencias entre tecnologías y requerimientos:

FlashPix QuickTime VR VRML


Alta resolución Sí Sí Sí, requiere un ordenador
potente
Velocidad de descarga Rápida Lenta Rápida
Formato universal Se adapta al navegador Requiere un plug-in Requiere un plug-in
Acceso universal Sí Sí Sí
Libre elección de Sí Sí, requiere un plug-in Sí, requiere un plug-in
navegador
Escalabilidad Sí Sí Sí
Integración de Procesamiento de Multimedia CAD
software imágenes
Estándar abierto Sí No Sí
Fuente abierta No No Sí

Las tres tecnologías tienen sus ventajas y, si observamos la fila que representa la integración de software
actual, veremos el posicionamiento de las mismas. Eso no significa que las tecnologías no se puedan mezclar
o incluso elegir la tecnología de un sector para ofrecer una solución a otro.

Los estándares abiertos y las fuentes abiertas se han vuelto más importantes. Tener un estándar abierto
significa que no hace falta utilizar solamente el formato de imágenes de una compañía en especial.

114.04.04 Audio

MP3

Fue en el año 1987 cuando el Instituto Graunhofer de la Universidad Alemana de Eslangen inició la búsque-
da de un método que permitiese la trasmisión de audio en formato de comprensión digital, logrando que un
minuto de calidad similar a un fichero que ocupa en un CD unos 10 megabytes, se comprimiera con MP3 en
menos de 1 MB. El grupo MPEG (Moving Picture Expert Group) aprobaba la nueva tecnología en 1992 y
desde entonces MP3 es un modo abreviado de decir MPEG y Layer 3. Y no nos asombramos ya cuando nos
aseguran que, según consultores independientes, hoy día se realizan diecisiete millones de
descargas MP3 diarias o que su capital de recursos es prácticamente insondable.

Otros formatos

Otros formatos de audio que están perdiendo importancia frente a MP3 son WAV y MIDI.

_______________________________________________________________________
21
114. Desarrollo de aplicaciones en la WEB (I).

También podría gustarte