Transcript The World Wide Web Caso de Estudio de Interoperabilidad

The World Wide Web
Caso de Estudio de Interoperabilidad
Integrantes:
Ricardo Macedo
Renato Paz
Carolina Vigil
Relaciones para el Ciclo de
Arquitectura del Negocio

La propuesta original de la Web vino de Tim Berners-Lee, investigador del Laboratorio Europeo
de Física de Partículas (CERN), quienes observaron que los varios miles de investigadores en el
CERN formó una red humana en evolución. La gente iba y venía, desarrollado nuevas
asociaciones de investigación, y perdiendo las antiguas, para compartir documentos, charlaba en
los pasillos, y así sucesivamente, y Berners-Lee quería apoyar esta red informal con una red similar
pero de información electrónica. En 1989, creó y distribuyó en todo el CERN un documento
titulado Gestión de la Información: una propuesta. En octubre de 1990 una versión reformulada
de la propuesta de proyecto fue aprobado por la dirección, el nombre World Wide Web fue
elegido, y comenzó el desarrollo.

La figura muestra los elementos de la ABC en cuanto se aplicaban a la propuesta inicial aprobada
por la dirección del CERN. El sistema se concibió para promover la interacción entre los
investigadores del CERN (el usuario final) dentro de las limitaciones de un entorno informático
heterogéneo. Los clientes eran la administración del CERN, la organización y desarrollo fue un
solitario investigador del CERN. El caso de negocios realizados por Berners-Lee fue que el
sistema propuesto aumentaría la comunicación entre el personal del CERN. Ésta era una
propuesta muy limitada, con muy limitados (y especulativos) objetivos. No había manera de saber
si ese sistema, de hecho, incrementaría la comunicación. Por otra parte, la inversión requerida por
el CERN para generar y probar el sistema era también muy limitado.
Relaciones para el Ciclo de
Arquitectura del Negocio

El entorno técnico era familiar a los de la comunidad de investigación, por lo
que la Internet ha sido un pilar desde su introducción a principios de 1970. La
red tenía nociones débiles de control central (comités de voluntarios cuyas
responsabilidades fueron para establecer protocolos para la comunicación
entre los diferentes nodos en Internet y alquilar nuevos grupos de noticias) y
no reglamentada, principalmente a través de grupos de noticias especializados.

Los Sistemas de hipertexto habían tenido una larga historia, comenzando con
la visión de Vannevar Bush en la década de 1940. la visión de Bush había sido
explorado a lo largo de los años 1960 y 1970 y en la década de 1980. Sin
embargo, la visión de Bush no se había logrado en gran escala por la década
de 1980: Los usos del hipertexto se limitaban principalmente a los sistemas de
documentación en pequeña escala.
Relaciones para el Ciclo de
Arquitectura del Negocio

La gestión CERN aprobó la propuesta de Berners-Lee en octubre de 1990. En
noviembre había desarrollado el primer programa de Web en la plataforma NeXT, lo
que significaba que claramente había comenzado a trabajar sobre la aplicación antes de
recibir la aprobación formal de gestión. Esta articulación flexible entre la aprobación
de la gestión y actividades de los investigadores es muy común en las organizaciones
de investigación en el que pequeñas inversiones iniciales son obligatorias. Por su
naturaleza, las organizaciones de investigación tienden a generar proyectos de abajo
hacia arriba más a menudo que las organizaciones comerciales, porque ellos dependen
de la originalidad de los investigadores y la creatividad y tienen mas libertad que en una
organización comercial.

La aplicación inicial de un sistema Web tenía muchas características que faltan en los
navegadores Web más recientes. Por ejemplo, se permitía a los usuarios crear enlaces
desde dentro del navegador, y permitía a los autores y lectores anotar la información.
Berners-Lee inicialmente pensó que ningún usuario desearía escribir HyperText
Markup Language (HTML) o hacer frente a los localizadores de recurso uniforme
(URL).
Relaciones para el Ciclo de
Arquitectura del Negocio
Requerimientos y Cualidades

La World Wide Web, tal como es concebido y aplicado inicialmente en el
CERN, tenía varias cualidades deseables. Fue portátil, capaz de interoperar
con otros tipos de equipos que ejecutan el mismo software, y fue escalable y
extensible. Los objetivos de negocio de promover la interacción y permitir
computación heterogénea, condujo a los objetivos de calidad de acceso, de
interoperabilidad, extensibilidad y escalabilidad, lo que a su vez llevó a
LibWWW, la biblioteca de software original que ha apoyado el desarrollo
basado en Web y una arquitectura distribuida de cliente-servidor . La
realización de estas propiedades en la arquitectura de software original creó
una infraestructura que realmente apoyó un enorme crecimiento de la Web.

LibWWW funciona en prácticamente cualquier hardware y acepta con
facilidad los nuevos protocolos, formatos de datos nuevos, y nuevas
aplicaciones. Debido a que no tiene ningún control centralizado, la web
parece ser capaz de crecer sin límites.
Requerimientos Originales









Acceso remoto a través de redes. Toda la información tenía que ser accesible desde cualquier
máquina de una red CERN.
Heterogeneidad. El sistema no puede limitarse a ejecutar en cualquier hardware específico o
plataforma de software.
Descentralización. En el espíritu de una red humana y de la Internet, no puede haber una única
fuente de datos o servicios. Este requisito fue en previsión de que la web crecería. La operación
de vincular a un documento, en particular, tuvo que ser descentralizado.
Acceso a datos existentes. bases de datos existentes debían ser accesibles.
Posibilidad para los usuarios agregar datos. Los usuarios deben ser capaces de "publicar" sus
propios datos en la Web, utilizando la misma interfaz que utiliza para leer datos de los demás.
Enlaces privados. Enlaces y nodos tiene que ser capaz de ser privada.
Bells and whistles. La única forma de visualización de datos inicialmente prevista era de mostrar
en un 24 x 80 caracteres terminal ASCII. Los gráficos fueron consideradas opcinales.
Análisis de datos. Los usuarios deben ser capaces de buscar en varias bases de datos y buscar
anomalías, regularidades, irregularidades, etc. Berners-Lee dio, como ejemplo, la capacidad de
buscar software no documentado y organizaciones sin personas.
Enlaces en vivo. Dado que la información cambia todo el tiempo, debe haber alguna manera de
actualizar. Esto podría ser simplemente la recuperación de la información cada vez que el enlace
se accede o (en una forma más sofisticada) por notificar a un usuario de un vínculo cada vez que
la información ha cambiado.
Requerimientos Originales

Además de estos requisitos, hay una serie de nonrequirements identificados. Por
ejemplo, los derechos de autor de ejecución y seguridad de los datos se mencionan
explícitamente como requisitos que el proyecto original no se ocuparía. La Web, en su
concepción inicial, iba a ser un medio público. Además, la propuesta original
explícitamente indica que los usuarios no deberían tener que utilizar cualquier formato
de marcado particular.
Otros criterios y características que eran comunes en las propuestas de sistemas de
hipertexto en el momento pero que no figuraban en la propuesta de la Web son los
siguientes:

El control de topología

Definición de las técnicas de navegación y los requisitos de la interfaz de usuario, incluyendo
mantener un historial visual

Tener diferentes tipos de enlaces para expresar diferentes relaciones entre los nodos
Los primeros requisitos: LibWWW

Las utilidades genéricas proporcionan una capa de portabilidad en el que el resto del
sistema descansa.

Esta capa incluye los elementos básicos para el sistema, tales como gestión de redes,
tipos de datos tales como clases de contenedores, y las utilidades de manipulación de
cadenas.

A través de los servicios prestados por esta capa, todos los niveles superiores se puede
hacer independiente de la plataforma, y la tarea de migración a un nuevo hardware o
software de plataforma puede ser casi totalmente contenida dentro de la conservación
de la capa de servicios públicos, que hay que hacer sólo una vez por plataforma.
Los primeros requisitos:
LibWWW

La capa de la base del esqueleto contiene la funcionalidad de una aplicación Web Acceso a la red,
gestión de datos y el análisis, registro, etc. Por sí mismo, esta capa no hace nada. Por el contrario,
proporciona una interfaz estándar para una aplicación web que deben desarrollarse, con la funcionalidad
reales proporcionados por plug-in de módulos y funciones de llamadas que son registradas por una
aplicación.

Plug-ins son registrados en tiempo y hacer el trabajo real de la capa de la base. De envío y manipulación
de datos. Por lo general compatible con los protocolos, la manija de transporte de bajo nivel, y entender
los formatos de datos.

Plug-ins se puede cambiar de forma dinámica, lo que es fácil de añadir nuevas funcionalidades o incluso
a cambiar la naturaleza misma de la aplicación web.
Una Temprana Arquitectura
Cliente-servidor Usando
LibWWW

Funciones de llamada de espera ofrecen otra forma de solicitudes para
ampliar la funcionalidad proporcionada en la capa central. Son arbitrarios
funciones específicas de la aplicación que se puede llamar antes o después de
las
solicitudes
de
módulos
de
protocolo.
¿Cuál es la relación entre las utilidades genéricas y el núcleo? Las utilidades
genéricas proporcionan funciones de plataforma independiente, pero pueden
ser utilizados para construir cualquier aplicación en red. La capa de la base,
por otra parte, proporciona las abstracciones específicas para la construcción
de
una
aplicación
Web.
La capa de flujo proporciona la abstracción de una secuencia de datos
utilizada por todos los datos transportados entre la aplicación y la red.
Una Temprana Arquitectura
Cliente-servidor Usando
LibWWW

La capa superior, que consiste en los módulos de aplicación Web, no
es una aplicación real, sino más bien un conjunto de funcionalidades
útiles para escribir aplicaciones. Incluye módulos para funciones
comunes, tales como el almacenamiento en caché, la tala, y el registro
de servidores proxy (para la traducción de protocolo) y puertas de
enlace (para tratar con los cortafuegos de seguridad, por ejemplo),
conservación
de
la
historia,
y
así
sucesivamente.
Lecciones De LibWWW.

Formalizado interfaces de programación de aplicaciones (API) son obligatorios. Estas son las interfaces que presentan la
funcionalidad de LibWWW de los programas construidos en la parte superior de la misma. Por esta razón, las API
deben especificarse de forma independiente del lenguaje, porque LibWWW está concebido para apoyar el desarrollo de
aplicaciones en una amplia variedad de plataformas y en muchos idiomas.

La funcionalidad y la API se debe presentar en capas. Diferentes aplicaciones tendrán acceso a los diferentes niveles de
abstracción de servicio, que son más natural proporcionado por capas.

La biblioteca debe ser compatible con una dinámica, de composición abierta establecido de características. Todas estas
características deben ser sustituibles, y debe ser posible hacer sustituciones en tiempo de ejecución.

Procesos construido sobre el software deben ser flujos seguros. aplicaciones basadas en Web debe ser compatible con la
capacidad de realizar varias funciones al mismo tiempo, sobre todo porque las operaciones como la descarga de archivos
de gran tamaño sobre un enlace de comunicación lento puede tomar una cantidad considerable de tiempo real. Esto
requiere el uso de varios hilos simultáneos de control.
Lecciones De LibWWW.

Resulta que LibWWW no es compatible con todos estos objetivos, así como podría
hacerlo. Por ejemplo, el núcleo LibWWW hace algunas suposiciones acerca de los
servicios esenciales, así que no todas las funciones pueden ser dinámicamente
reemplazados. Por otra parte, es LibWWW destinados a ejecutarse en diferentes
plataformas, por lo que no puede depender de un modelo de un solo hilo. Así, se ha
implementado pseudothreads, que proporcionan alguna, pero no toda, de la
funcionalidad requerida. Por último, las aplicaciones Web más actuales no admiten
configuración de la característica dinámica, que requiere reiniciar el sistema antes de los
nuevos
servicios
se
pueden
registrar.
Una Temprana Arquitectura Clienteservidor Usando LibWWW
Una Temprana Arquitectura Clienteservidor Usando LibWWW

La interfaz de usuario (UI) El Director se encarga de la apariencia y sensación del
interfaz de usuario del cliente. Sin embargo, dada la composición abierta conjunto de
recursos que un sistema de WWW puede manejar, otro elemento, el gestor de
presentaciones, puede delegar mostrar la información a los programas externos
(espectadores) para ver los recursos conocidos por el sistema, sino que el gestor de la
interfaz de usuario no soporta directamente .Por ejemplo, la mayoría de los
espectadores del sitio Web utiliza un programa externo para visualizar archivos
PostScript o archivos. Pdf. Esta delegación es un compromiso entre los deseos
contrapuestos de la integración de interfaces de usuario (que prevé una constante
mirada y sentir y por lo tanto, un mejor uso) y extensibilidad.
Una Temprana Arquitectura Clienteservidor Usando LibWWW

El administrador de la interfaz de usuario captura petición de un usuario para la recuperación de información en
forma de una dirección URL y pasa la información a la gestión de acceso.

El gerente de acceso determina si la URL solicitada existe en la memoria caché de navegación y también
interpreta la historia-basada (por ejemplo, "atrás"). Si el archivo se almacena en caché, que se recupera del administrador
de la caché y se comunicará al gestor de presentaciones para su visualización ya sea a la interfaz de usuario o un visor
externo. Si no se almacena en caché, el administrador de protocolo determina el tipo de solicitud e invoca el conjunto de
protocolos necesarios para que le de servicio.

El administrador de flujo de cliente utiliza este protocolo para comunicar la solicitud al servidor. Una vez que
reciba una respuesta del servidor en forma de un documento, esta información se pasa al gestor de presentaciones para
su visualización adecuada.

El gestor de presentaciones consulta a un control estático ver el archivo de configuración (mimerc, mailcap, etc) para
ayudar a que el mapa tipos de documentos a los espectadores externos.
Una Temprana Arquitectura
Cliente-servidor Usando
LibWWW

El servidor HTTP garantiza un acceso transparente al sistema de archivos La fuente de los documentos que la
web existe para la transferencia. Para ello, ya sea por el manejo del acceso directo (por tipos de recursos se conoce) o a
través de un proxy conocido como Common Gateway Interface (CGI).

Cuando una solicitud es recibida por el administrador de servidor de flujo, se determina su tipo y la ruta de la
URL que se resuelva a través de la resolución de camino. El servidor HTTP consulta una lista de acceso para determinar
si el cliente solicitante está autorizado para el acceso. Puede iniciar una sesión de autenticación de contraseña con el
cliente para permitir el acceso a los datos protegidos.
Interfaz de entrada común (CGI)

La mayoría de la información devuelta por un servidor es estática, cambia sólo si se modifica en
su sistema de archivos de origen. scripts CGI, por otro lado, permitir que la información
dinámica, petición específica a ser devuelto. CGI ha sido históricamente usado para aumentar
funcionalidad de servidor: para la entrada de información, para las búsquedas, para obtener
imágenes puede hacer clic.

El uso más común de CGI, sin embargo, es la creación de documentos virtuales
Documentos que se sintetiza de forma dinámica en respuesta a una solicitud del usuario. Por
ejemplo, cuando un usuario busca algo en Internet, el buscador crea una respuesta a la solicitud
de búsqueda del usuario, un script CGI se crea un nuevo documento HTML de la respuesta y lo
devuelve
al
usuario.
Interfaz de entrada común (CGI)

Probablemente la característica adicional muy importante que CGI se señalan a la arquitectura Web es
que permite a los usuarios "put" de la información en la web, en contraste con el "get" operación que
normalmente proporcionan los servidores. Aunque el requisito de crear la información figuraba en el
original de las necesidades mundiales del proyecto Wide Web, no se ha logrado plenamente. CGI
permite a los usuarios mostrar información sólo en formas específicas de la aplicación, como agregarlo a
una
base
de
datos
rellenando
un
formulario.
Deficiencias El problema de seguridad fue una y otra fue la portabilidad. CGI scripts escritos en
VisualBasic, AppleScript, y C el trabajo de Shell en Windows, Macintosh y UNIX,
respectivamente. Estas secuencias de comandos no puede ser (fácilmente) pasados de una plataforma a
otra.
Ciclo a través de la ABC: La Evolución de la Web
basada en el comercio electrónico Arquitecturas

El increíble éxito de la Web se ha traducido en un interés sin precedentes de los negocios y por lo tanto, la presión sin
precedentes sobre la arquitectura, a través de la ABC. Los requisitos empresariales han comenzado a dominar la
arquitectura Web. Business-to-business y las empresas con los consumidores a sitios Web han impulsado la mayoría de
la

innovación
en
software
basado
en
Web.
La concepción original de la Web fue como una red de documentos, de acuerdo con sus raíces en el hipertexto. El
comercio electrónico, sin embargo, considera que la Web como una red de datos, y estos puntos de vista diferentes han
llevado a algunas tensiones. Por ejemplo, "empujar" los datos a un usuario es difícil, la técnica más común para la
actualización de datos es la recarga en períodos específicos en lugar de basarse en la modificación de los datos para
forzar una actualización de pantalla. Otro es el botón Atrás de un navegador, que en determinadas circunstancias puede
resultar
en
datos
obsoletos
que
se
muestra
en
una
pantalla.
Ciclo a través de la ABC: La Evolución de la Web
basada en el comercio electrónico Arquitecturas

Los nuevos requisitos del comercio electrónico :

Alto rendimiento. Un popular sitio web suele tener decenas de millones de "hits" por día, y los
usuarios esperan de baja latencia de la misma. Los clientes no toleran el sitio simplemente se niega
a sus peticiones.

Alta disponibilidad. sitios de comercio electrónico se espera que esté disponible "24 / 7."Ellos
nunca cierran, por lo que debe tener mínimo tiempo de inactividad? Tal vez unos pocos minutos al
año.
Escalabilidad. Como sitios Web creciendo en popularidad, su capacidad de transformación deberá
ser capaz de crecer de manera similar, tanto a ampliar la cantidad de datos que puede administrar y
mantener niveles aceptables de servicio al cliente.


De Seguridad. Los usuarios deben estar seguros de que ninguna información confidencial que
envían a través de la web está a salvo de espionaje. Los operadores de sitios Web debe estar seguro
de que su sistema sea seguro contra ataques (robando o modificar datos, dar a dichos datos
inutilizables inundándolo con peticiones, que se caiga, etc.)
Ciclo a través de la ABC: La Evolución de la
Web basada en el comercio electrónico
Arquitecturas

Modificación: El comercio electrónico sitios web cambian con frecuencia, en
muchos casos a diario, por lo que su contenido debe ser muy sencillo de cambiar.

La solución arquitectónica de estos requisitos es más sobre la arquitectura del
sistema de arquitectura de software sencilla. Los componentes que pueblan el
sistema provienen del mercado comercial: los servidores Web y clientes Web,
por supuesto, pero también bases de datos, servidores de seguridad,
servidores de aplicaciones, servidores proxy, servidores de transacciones, etc.
Ciclo a través de la ABC: La Evolución de la Web
basada en el comercio electrónico Arquitecturas

Una implementación típica de una arquitectura
del sistema de comercio electrónico consiste en
un número de niveles, cada uno formado por
una agrupación coherente de software (por lo
general a medida componentes comerciales) y el
hardware.
Arquitectura de soluciones

El enfoque arquitectónico básico que se utiliza para
la Web, en primer lugar en el CERN y más tarde en
la World Wide Web Consortium (W3C), se basó en
los
clientes
y
servidores,
y
una
biblioteca
(LibWWW) que oculta todo el hardware, sistema
operativo, y las dependencias de protocolo.
Arquitectura de soluciones

Los productores de contenidos y los consumidores interactúan a través de sus
respectivos servidores y clientes.

El productor que se describe el contenido en HTML en un servidor.

El servidor se comunica con un cliente que utiliza el Protocolo de Transferencia de
Hipertexto (HTTP).

El software en el servidor y el cliente se basa en LibWWW, así que los detalles del
protocolo y de las dependencias en las plataformas están enmascarados de ella.

Uno de los elementos del lado del cliente es un navegador que sabe cómo mostrar
HTML para que el consumidor el contenido se presente en una imagen comprensible.
Los primeros requisitos:
LibWWW

LibWWW es una biblioteca de software para crear aplicaciones que se
ejecutan en el cliente o el servidor. Proporciona la funcionalidad
genérica que es compartida por la mayoría de aplicaciones: la capacidad
de conectarse con máquinas remotas, la capacidad de entender los
flujos
de
datos
HTML,
etc.
LibWWW es una biblioteca compacta y portátil que se puede construir
sobre la creación de aplicaciones basadas en Web, tales como clientes,
servidores, bases de datos, Web y arañas.
Los primeros requisitos:
LibWWW

Las utilidades genéricas proporcionan una capa de portabilidad en el que el resto del
sistema descansa.

Esta capa incluye los elementos básicos para el sistema, tales como gestión de redes,
tipos de datos tales como clases de contenedores, y las utilidades de manipulación de
cadenas.

A través de los servicios prestados por esta capa, todos los niveles superiores se puede
hacer independiente de la plataforma, y la tarea de migración a un nuevo hardware o
software de plataforma puede ser casi totalmente contenida dentro de la conservación
de la capa de servicios públicos, que hay que hacer sólo una vez por plataforma.
Los primeros requisitos:
LibWWW

La capa de la base del esqueleto contiene la funcionalidad de una aplicación Web Acceso a la red,
gestión de datos y el análisis, registro, etc. Por sí mismo, esta capa no hace nada. Por el contrario,
proporciona una interfaz estándar para una aplicación web que deben desarrollarse, con la funcionalidad
reales proporcionados por plug-in de módulos y funciones de llamadas que son registradas por una
aplicación.

Plug-ins son registrados en tiempo y hacer el trabajo real de la capa de la base. De envío y manipulación
de datos. Por lo general compatible con los protocolos, la manija de transporte de bajo nivel, y entender
los formatos de datos.

Plug-ins se puede cambiar de forma dinámica, lo que es fácil de añadir nuevas funcionalidades o incluso
a cambiar la naturaleza misma de la aplicación web.

Funciones de llamada de espera ofrecen otra forma de solicitudes para
ampliar la funcionalidad proporcionada en la capa central. Son arbitrarios
funciones específicas de la aplicación que se puede llamar antes o después de
las
solicitudes
de
módulos
de
protocolo.
¿Cuál es la relación entre las utilidades genéricas y el núcleo? Las utilidades
genéricas proporcionan funciones de plataforma independiente, pero pueden
ser utilizados para construir cualquier aplicación en red. La capa de la base,
por otra parte, proporciona las abstracciones específicas para la construcción
de
una
aplicación
Web.
La capa de flujo proporciona la abstracción de una secuencia de datos
utilizada por todos los datos transportados entre la aplicación y la red.

La capa superior, que consiste en los módulos de aplicación Web, no es una
aplicación real, sino más bien un conjunto de funcionalidades útiles para
escribir aplicaciones. Incluye módulos para funciones comunes, tales como el
almacenamiento en caché, la tala, y el registro de servidores proxy (para la
traducción de protocolo) y puertas de enlace (para tratar con los cortafuegos
de seguridad, por ejemplo), conservación de la historia, y así sucesivamente.
Lecciones De LibWWW.

Formalizado interfaces de programación de aplicaciones (API) son obligatorios. Estas son las interfaces que presentan la
funcionalidad de LibWWW de los programas construidos en la parte superior de la misma. Por esta razón, las API
deben especificarse de forma independiente del lenguaje, porque LibWWW está concebido para apoyar el desarrollo de
aplicaciones en una amplia variedad de plataformas y en muchos idiomas.

La funcionalidad y la API se debe presentar en capas. Diferentes aplicaciones tendrán acceso a los diferentes niveles de
abstracción de servicio, que son más natural proporcionado por capas.

La biblioteca debe ser compatible con una dinámica, de composición abierta establecido de características. Todas estas
características deben ser sustituibles, y debe ser posible hacer sustituciones en tiempo de ejecución.

Procesos construido sobre el software deben ser flujos seguros. aplicaciones basadas en Web debe ser compatible con la
capacidad de realizar varias funciones al mismo tiempo, sobre todo porque las operaciones como la descarga de archivos
de gran tamaño sobre un enlace de comunicación lento puede tomar una cantidad considerable de tiempo real. Esto
requiere el uso de varios hilos simultáneos de control.
Lecciones De LibWWW.

Resulta que LibWWW no es compatible con todos estos objetivos, así como podría
hacerlo. Por ejemplo, el núcleo LibWWW hace algunas suposiciones acerca de los
servicios esenciales, así que no todas las funciones pueden ser dinámicamente
reemplazados. Por otra parte, es LibWWW destinados a ejecutarse en diferentes
plataformas, por lo que no puede depender de un modelo de un solo hilo. Así, se ha
implementado pseudothreads, que proporcionan alguna, pero no toda, de la
funcionalidad requerida. Por último, las aplicaciones Web más actuales no admiten
configuración de la característica dinámica, que requiere reiniciar el sistema antes de los
nuevos
servicios
se
pueden
registrar.
Una Temprana Arquitectura Clienteservidor Usando LibWWW
Una Temprana Arquitectura Clienteservidor Usando LibWWW

La interfaz de usuario (UI) El Director se encarga de la apariencia y sensación del
interfaz de usuario del cliente. Sin embargo, dada la composición abierta conjunto de
recursos que un sistema de WWW puede manejar, otro elemento, el gestor de
presentaciones, puede delegar mostrar la información a los programas externos
(espectadores) para ver los recursos conocidos por el sistema, sino que el gestor de la
interfaz de usuario no soporta directamente .Por ejemplo, la mayoría de los
espectadores del sitio Web utiliza un programa externo para visualizar archivos
PostScript o archivos. Pdf. Esta delegación es un compromiso entre los deseos
contrapuestos de la integración de interfaces de usuario (que prevé una constante
mirada y sentir y por lo tanto, un mejor uso) y extensibilidad.
Una Temprana Arquitectura Clienteservidor Usando LibWWW

El administrador de la interfaz de usuario captura petición de un usuario para la recuperación de información en
forma de una dirección URL y pasa la información a la gestión de acceso.

El gerente de acceso determina si la URL solicitada existe en la memoria caché de navegación y también
interpreta la historia-basada (por ejemplo, "atrás"). Si el archivo se almacena en caché, que se recupera del administrador
de la caché y se comunicará al gestor de presentaciones para su visualización ya sea a la interfaz de usuario o un visor
externo. Si no se almacena en caché, el administrador de protocolo determina el tipo de solicitud e invoca el conjunto de
protocolos necesarios para que le de servicio.

El administrador de flujo de cliente utiliza este protocolo para comunicar la solicitud al servidor. Una vez que
reciba una respuesta del servidor en forma de un documento, esta información se pasa al gestor de presentaciones para
su visualización adecuada.

El gestor de presentaciones consulta a un control estático ver el archivo de configuración (mimerc, mailcap, etc) para
ayudar a que el mapa tipos de documentos a los espectadores externos.

El servidor HTTP garantiza un acceso transparente al sistema de archivos La fuente de los documentos que la
web existe para la transferencia. Para ello, ya sea por el manejo del acceso directo (por tipos de recursos se conoce) o a
través de un proxy conocido como Common Gateway Interface (CGI).

Cuando una solicitud es recibida por el administrador de servidor de flujo, se determina su tipo y la ruta de la
URL que se resuelva a través de la resolución de camino. El servidor HTTP consulta una lista de acceso para determinar
si el cliente solicitante está autorizado para el acceso. Puede iniciar una sesión de autenticación de contraseña con el
cliente para permitir el acceso a los datos protegidos.
Interfaz de entrada común (CGI)

La mayoría de la información devuelta por un servidor es estática, cambia sólo si se modifica en
su sistema de archivos de origen. scripts CGI, por otro lado, permitir que la información
dinámica, petición específica a ser devuelto. CGI ha sido históricamente usado para aumentar
funcionalidad de servidor: para la entrada de información, para las búsquedas, para obtener
imágenes puede hacer clic.

El uso más común de CGI, sin embargo, es la creación de documentos virtuales
Documentos que se sintetiza de forma dinámica en respuesta a una solicitud del usuario. Por
ejemplo, cuando un usuario busca algo en Internet, el buscador crea una respuesta a la solicitud
de búsqueda del usuario, un script CGI se crea un nuevo documento HTML de la respuesta y lo
devuelve
al
usuario.
Interfaz de entrada común (CGI)

Probablemente la característica adicional muy importante que CGI se señalan a la arquitectura Web es
que permite a los usuarios "put" de la información en la web, en contraste con el "get" operación que
normalmente proporcionan los servidores. Aunque el requisito de crear la información figuraba en el
original de las necesidades mundiales del proyecto Wide Web, no se ha logrado plenamente. CGI
permite a los usuarios mostrar información sólo en formas específicas de la aplicación, como agregarlo a
una
base
de
datos
rellenando
un
formulario.
Deficiencias El problema de seguridad fue una y otra fue la portabilidad. CGI scripts escritos en
VisualBasic, AppleScript, y C el trabajo de Shell en Windows, Macintosh y UNIX,
respectivamente. Estas secuencias de comandos no puede ser (fácilmente) pasados de una plataforma a
otra.
Ciclo a través de la ABC: La Evolución de la
Web basada en el comercio electrónico
Arquitecturas

El increíble éxito de la Web se ha traducido en un interés sin precedentes de los negocios y por lo tanto, la presión sin
precedentes sobre la arquitectura, a través de la ABC. Los requisitos empresariales han comenzado a dominar la
arquitectura Web. Business-to-business y las empresas con los consumidores a sitios Web han impulsado la mayoría de
la

innovación
en
software
basado
en
Web.
La concepción original de la Web fue como una red de documentos, de acuerdo con sus raíces en el hipertexto. El
comercio electrónico, sin embargo, considera que la Web como una red de datos, y estos puntos de vista diferentes han
llevado a algunas tensiones. Por ejemplo, "empujar" los datos a un usuario es difícil, la técnica más común para la
actualización de datos es la recarga en períodos específicos en lugar de basarse en la modificación de los datos para
forzar una actualización de pantalla. Otro es el botón Atrás de un navegador, que en determinadas circunstancias puede
resultar
en
datos
obsoletos
que
se
muestra
en
una
pantalla.
Ciclo a través de la ABC: La Evolución de la
Web basada en el comercio electrónico
Arquitecturas

Los nuevos requisitos del comercio electrónico :

Alto rendimiento. Un popular sitio web suele tener decenas de millones de "hits" por día, y los
usuarios esperan de baja latencia de la misma. Los clientes no toleran el sitio simplemente se niega
a sus peticiones.

Alta disponibilidad. sitios de comercio electrónico se espera que esté disponible "24 / 7."Ellos
nunca cierran, por lo que debe tener mínimo tiempo de inactividad? Tal vez unos pocos minutos al
año.
Escalabilidad. Como sitios Web creciendo en popularidad, su capacidad de transformación deberá
ser capaz de crecer de manera similar, tanto a ampliar la cantidad de datos que puede administrar y
mantener niveles aceptables de servicio al cliente.


De Seguridad. Los usuarios deben estar seguros de que ninguna información confidencial que
envían a través de la web está a salvo de espionaje. Los operadores de sitios Web debe estar seguro
de que su sistema sea seguro contra ataques (robando o modificar datos, dar a dichos datos
inutilizables inundándolo con peticiones, que se caiga, etc.)
Ciclo a través de la ABC: La Evolución de la
Web basada en el comercio electrónico
Arquitecturas

Modificación: El comercio electrónico sitios web cambian con frecuencia,
en muchos casos a diario, por lo que su contenido debe ser muy sencillo
de cambiar.

La solución arquitectónica de estos requisitos es más sobre la
arquitectura del sistema de arquitectura de software sencilla. Los
componentes que pueblan el sistema provienen del mercado comercial:
los servidores Web y clientes Web, por supuesto, pero también bases
de datos, servidores de seguridad, servidores de aplicaciones,
servidores proxy, servidores de transacciones, etc.
Ciclo a través de la ABC: La Evolución de la
Web basada en el comercio electrónico
Arquitecturas

Una implementación típica de una arquitectura del
sistema de comercio electrónico consiste en un
número de niveles, cada uno formado por una
agrupación coherente de software (por lo general a
medida componentes comerciales) y el hardware.
modificacion de navegadores web


El usuario final normalmente inicia una solicitud de
información al interactuar con un navegador Web.
Los navegadores Web de soporte técnico de usuario
modificacan la interfaz en una amplia variedad de
formas, la más obvia que no ha cambiado desde la
creación de la Web: La interfaz de usuario en que el
navegador no es compatible con cableado sino se
especifica a través de HTML.

Hoy en día hay muchas otras tecnologías para
crear interfaces de usuario sofisticadas. XML,
Flash, ActiveX y subprogramas Java
HTTPS PARA LA SEGURIDAD



Una vez que el usuario ha presentado una solicitud, debe ser
transmitida a un sitio web de destino.
Esta transmisión puede ser a través de HTTP o, para
información confidencial, como tarjetas de crédito o números de
identificación, HTTPS (HTTP segura). HTTPS utiliza el sistema
Secure Sockets Layer de Netscape como subprotocol debajo de
HTTP.
Se utiliza un puerto diferente (443 en vez del puerto estándar de
80 que utiliza HTTP) para solicitar los servicios TCP / IP de
forma encriptada.
Servidores proxy de rendimiento


Las solicitudes de los navegadores individuales
primero puede llegar a un servidor proxy que
existe para mejorar el rendimiento del sistema
basado en Web.
Estos servidores caché de acceso frecuente a
páginas Web para que los usuarios pueden
recuperarlas sin tener que acceder al sitio Web.

Los servidores proxy también son utilizados por
empresas que quieren restringir el acceso de sus
empleados a ciertos sitios Web. En este caso el
servidor proxy actúa un poco como un servidor
de seguridad.
Routers y firewalls para la seguridad

Las solicitudes presentadas por el navegador (o un
servidor proxy) para luego llegar a un router, que se
encuentra en la red del proveedor de comercio
electrónico, el que puede incluir un cortafuegos para la
seguridad. (O bien el router puede pasar las peticiones
HTTP a un servidor de seguridad por separado.) El
router puede llevar a cabo la traducción de direcciones
de red (NAT), que traduce una dirección IP visible
externamente en una dirección IP interna.
Equilibrio de carga de material de rendimiento, escalabilidad y
disponibilidad


El trabajo del equilibrador de carga para distribuir la carga
(peticiones HTTP y HTTPS) Entre un grupo de equipos que
ejecutan los servidores Web.
El equilibrador de carga puede simplemente redirigir la solicitud
a otro equipo, o puede responder a la Web del cliente y se le
instruye para redirigir la solicitud a un servidor diferente. Aunque
esta redirección es transparente para el usuario final, el resultado
es un ida y vuelta adicional de comunicación.
SERVIDORES WEB DE RENDIMIENTO


Los primeros servidores Web, eran típicamente de un
solo subproceso. Las versiones modernas son
multiproceso, utilizando un conjunto de hilos, cada uno
de los cuales pueden ser enviados para manejar una
solicitud entrante.
Un servidor multiproceso es menos susceptible a
cuellos de botella cuando un número de grandes
solicitudes HTTP o HTTPS (tales como validaciones
de tarjeta de crédito) llegan por otros hilos están todavía
disponibles para atender peticiones entrantes.
Solicitud para servidores modificabilidad,
rendimiento y escalabilidad


el servidor Web traslada la solicitud a un servidor de
aplicaciones. "Servidor de aplicaciones".
Estos servidores aplican la lógica empresarial y la conectividad,
que determinan cómo interactúan los clientes y servidores. La
tendencia hacia los servidores de aplicaciones ha permitido que
una parte significativa de la funcionalidad interactúe con los
clientes en el nivel medio. Además, han permitido a las bases de
datos concentrarse en el almacenamiento, recuperación y análisis
de datos sin tener que preocuparse sobre la forma precisa que los
datos serán utilizados.
Bases de datos para rendimiento, escalabilidad y
disponibilidad

la solicitud de servicio llega a la base de datos, donde se
convierte en una instrucción para agregar, modificar o
recuperar información.