Unidad 1 - Contexto de La Programacion Cliente-Servidor

INSTITUTO TECNOLOGICO DE ORIZABA
INSTITUTO TECNOLGICO DE ORIZABA

ING. INFORMTICA
PROGRAMACION EN AMBIENTE CLIENTE-SERVIDOR
INVESTIGACION UNIDAD 1
Contexto de la programacin cliente-servidor
Hora: 13 a 14
PRESENTA:
ALDANA FERNANDEZ ISMAEL
No. DE CONTROL:
11010383
PROFESOR:
PELAEZ CAMARENA SILVESTRE GUSTAVO
ISMAEL ALDANA FERNANDEZ
Contenido
Introduccin........................................................................................................ 3
Desarrollo............................................................................................................ 3
1.1. Arquitectura cliente/servidor........................................................................3
Elementos de la arquitectura cliente/servidor.................................................4
El servidor..................................................................................................... 5
El cliente....................................................................................................... 5
El Middleware............................................................................................... 5
El funcionamiento bsico................................................................................. 6
1.2 Modelos de dos y tres capas.........................................................................7
Arquitectura en 2 niveles................................................................................. 7
Arquitectura en 3 niveles................................................................................. 7
Comparacin entre ambos tipos de arquitecturas...........................................8
1.3 Usos y Aplicaciones....................................................................................... 8
1.4 Comunicacin entre programas....................................................................9
1.5. Modelos de computacin distribuida..........................................................11
1.5.1. RMI.......................................................................................................... 11
La arquitectura RMI puede verse como un modelo de cuatro capas..............12
Primera capa............................................................................................... 12
Segunda capa............................................................................................. 12
Tercera capa............................................................................................... 12
Cuarta Capa................................................................................................ 12
1.5.2. COM/DCOM............................................................................................. 13
La arquitectura DCOM.................................................................................... 13
1.5.3. Servicios Web.......................................................................................... 14
La interoperabilidad puede ser de 3 tipos:....................................................15
1.5.4. Otros....................................................................................................... 16
Conclusin........................................................................................................ 17
Referencias....................................................................................................... 17
Introduccin
La arquitectura cliente-servidor define una relacin entre el usuario de una
estacin de trabajo (el cliente frontal) y un servidor posterior de archivos,
impresin, comunicaciones o fax, u otro tipo de sistema proveedor de servicios.
El cliente debe ser un sistema inteligente con su propia capacidad de
procesamiento para descargar en parte al sistema posterior (sta es la base del
modelo cliente-servidor). Esta relacin consiste en una secuencia de llamadas
seguidas de respuestas. Situar servicios de archivos (u otro tipo de servicios) en
sistemas posteriores dedicados tiene muchas ventajas. Es ms sencillo realizar el
mantenimiento y la seguridad de unos servidores situados en un mismo lugar, y
ms simple el proceso de realizacin de copias de seguridad, siempre que los
datos se encuentren en una nica ubicacin y una misma autoridad los gestione.
Desarrollo
1.1. Arquitectura cliente/servidor
La arquitectura cliente/servidor persigue el objetivo de procesar la informacin
de un modo distribuido. De esta forma, los usuarios finales pueden estar
dispersos en un rea geogrfica ms o menos extensa (un edificio, una
localidad, un pas,) y acceder a un conjunto comn de recursos compartidos.
Adems, el acceso debe ser transparente (el cliente puede desconocer la
ubicacin fsica del recurso que pretende utilizar) y, preferiblemente,
multiplataforma, es decir, independiente del sistema operativo, del software de
aplicacin e incluso del hardware.
En definitiva, cuando hablamos de la implantacin de una arquitectura
cliente/servidor, nos referimos a un sistema de informacin distribuido.
Adems de la transparencia y la independencia del hardware y del software,

una implantacin cliente/servidor debe tener las siguientes caractersticas:
o
Debe utilizar protocolos asimtricos, donde el servidor se limita a

escuchar, en espera de que un cliente inicie una solicitud.
El servidor ofrecer recursos, tanto lgicos como fsicos a una cantidad

variable y diversa de clientes (por ejemplo, espacio de almacenamiento,
bases de datos, impresoras, etc.)
El servidor ofrecer tambin una serie de servicios, que sern usados

por los clientes. Estos servicios estarn encapsulados, para ocultar a los
clientes los detalles de su implementacin (por ejemplo, aceptar el
requerimiento de un cliente sobre una base de datos o formatear los
datos obtenidos antes de transmitirlos al cliente).
Se facilitar la integridad y el mantenimiento tanto de los datos como de

los programas debido a que se encuentran centralizados en el servidor o
servidores.
Los sistemas estarn dbilmente

mediante el envo de mensajes.
Se facilitar la escalabilidad, de manera que sea fcil aadir nuevos

clientes a la infraestructura (escalabilidad horizontal) o aumentar la
potencia del servidor o servidores, aumentando su nmero o su
capacidad de clculo (escalabilidad vertical)
acoplados,
ya
que
interactan
Elementos de la arquitectura cliente/servidor.
De lo dicho hasta ahora, podemos deducir que los principales elementos que
conforman la arquitectura cliente/servidor son los siguientes:
El servidor
Cuando hablamos de una forma genrica, si mencionamos a un servidor, nos
referimos a un ordenador, normalmente con prestaciones elevadas, que
ejecuta servicios para atender las demandas de diferentes clientes.
Sin embargo, bajo el punto de vista de la arquitectura cliente/servidor, un
servidor es un proceso que ofrece el recurso (o recursos) que administra a los
clientes que lo solicitan (consultar la definicin de cliente ms abajo).
Es muy frecuente que, para referirse a un proceso servidor, se utilice el
trmino back-end.
Segn el tipo de servidor implantado, tendremos un tipo de arquitectura
cliente/servidor diferente.
Por ltimo, mencionar que en algunas ocasiones, un servidor puede actuar, a
su vez, como cliente de otro servidor.
El cliente
Igual que antes, al hablar de forma genrica sobre un cliente, nos referimos a
un ordenador, normalmente con prestaciones ajustadas, que requiere los
servicios de un equipo servidor.
Sin embargo, bajo el punto de vista de la arquitectura cliente/servidor, un
cliente es un proceso que solicita los servicios de otro, normalmente a peticin
de un usuario.
En entornos cliente/servidor, suele utilizarse el trmino front-end para referirse
a un proceso cliente.
Normalmente, un proceso cliente se encarga de interactuar con el usuario, por
lo que estar construido con alguna herramienta que permita implementar
interfaces grficas (GUI). Adems, se encargar de formular las solicitudes al
servidor y recibir su respuesta, por lo que deber encargarse de una parte de
la lgica de la aplicacin y de realizar algunas validaciones de forma local.
El Middleware
Es la parte del software del sistema que se encarga del transporte de los
mensajes entre el cliente y el servidor, por lo que se ejecuta en ambos lados de
la estructura.
El middleware permite independizar a los clientes y a los servidores, sobre
todo, gracias a los sistemas abiertos, que eliminan la necesidad de supeditarse
a tecnologas propietarias.
Por lo tanto, el middleware facilita el desarrollo de aplicaciones, porque

resuelve la parte del transporte de mensajes y facilita la interconexin de
sistemas heterogneos sin utilizar tecnologas propietarias.
Adems, ofrece ms control sobre el negocio, debido a que permite obtener
informacin desde diferentes orgenes (uniendo tecnologas y arquitecturas
distintas) y ofrecerla de manera conjunta.
Podemos estructurar el middleware en tres niveles:
o
El protocolo de transporte, que ser comn para otras aplicaciones del

sistema.
El sistema operativo de red
El protocolo del servicio, que ser especfico del tipo de sistema

cliente/servidor que estemos considerando.
El funcionamiento bsico
Aunque es probable que a estas alturas ya te hagas una idea sobre el
funcionamiento general del modelo cliente/servidor, vamos a concretarlo a
continuacin:
1. Lo primero que debe ocurrir es que se inicie el servidor. Esto ocurrir
durante el arranque del sistema operativo o con la intervencin posterior
del administrador del sistema. Cuando termine de iniciarse, esperar de
forma pasiva las solicitudes de los clientes.
2. En algn momento, uno de los clientes conectados al sistema realizar
una solicitud al servidor.
3. El servidor recibe la solicitud del cliente, realiza cualquier verificacin
necesaria y, si todo es correcto, la procesa.
4. Cuando el servidor disponga del resultado solicitado, lo enva al cliente.
5. Finalmente, el cliente recibe el resultado que solicit. A continuacin
realiza las comprobaciones oportunas (si son necesarias) y, si era ese el
objetivo final, se lo muestra al usuario.
Si descomponemos este modo de funcionamiento en elementos estructurales,

ser ms fcil comprender los conceptos implicados. De esta forma, podemos
obtener una definicin de la arquitectura por niveles, estructurada como sigue:
o
Un nivel de presentacin, que aglutina los elementos relativos al cliente.
Un nivel de aplicacin, compuesto por elementos relacionados con el

servidor.
Un nivel de comunicacin, que est formado por los elementos que

hacen posible la comunicacin entre el cliente y el servidor.
Un nivel de base de datos, formado por los elementos relacionados con

el acceso a los datos.
1.2 Modelos de dos y tres capas

Arquitectura en 2 niveles
La arquitectura en 2 niveles se utiliza para describir los sistemas cliente/servidor
en donde el cliente solicita recursos y el servidor responde directamente a la
solicitud, con sus propios recursos. Esto significa que el servidor no requiere otra
aplicacin para proporcionar parte del servicio.
Arquitectura en 3 niveles
En la arquitectura en 3 niveles, existe un nivel intermediario. Esto significa que la
arquitectura generalmente est compartida por:
1. Un cliente, es decir, el equipo que solicita los recursos, equipado con una
interfaz de usuario (generalmente un navegador Web) para la presentacin
2. El servidor de aplicaciones (tambin denominado software intermedio),
cuya tarea es proporcionar los recursos solicitados, pero que requiere de
otro servidor para hacerlo
3. El servidor de datos, que proporciona al servidor de aplicaciones los datos
que requiere
Comparacin entre ambos tipos de arquitecturas

La arquitectura en 2 niveles es, por lo tanto, una arquitectura cliente/servidor en la
que el servidor es polivalente, es decir, puede responder directamente a todas las
solicitudes de recursos del cliente.
Sin embargo, en la arquitectura en 3 niveles, las aplicaciones al nivel del servidor
son descentralizadas de uno a otro, es decir, cada servidor se especializa en una
determinada tarea, (por ejemplo: servidor web/servidor de bases de datos). La
arquitectura en 3 niveles
permite:
Un mayor grado de
flexibilidad
Mayor seguridad, ya
que
seguridad
se
puede
independientemente para
la
definir
cada servicio
y en cada nivel
Mejor rendimiento, ya
que
las
tareas se comparten entre servidores

1.3 Usos y Aplicaciones

Cuando la operacin entre clientes y servidores se realiza a travs de una red
(como es el caso de Internet), la informacin viaja codificada a lo largo de redes
que pueden ser del tamao de un edificio o de tamao planetario. En caso de
redes grandes, aparte de servidores y clientes, se necesita un tercer tipo de
mquinas para gestionar las transmisiones.
Se
denominan enrutadores ("Routers"),
funcionan
como
elementos
de
recepcin y transmisin de trfico Internet.

El paradigma cliente-servidor no solo se utiliza en referencia a las mquinas
fsicas, tambin a los programas que las hacen funcionar segn su utilidad. Por
ejemplo, son frecuentes expresiones tales como "cliente de correo" o "servidor de
noticias" en referencia a programas. La primera se refiere al que utilizamos
normalmente para interrogar nuestro buzn e-mail, "bajar" el correo y manipularlo
(verlo, imprimirlo, borrarlo, etc.). El segundo se refiere a un programa o sistema
de ellos, que en un servidor (mquina) realiza el trabajo de alojar los mensajes de
noticias, atender las peticiones de los "clientes", etc.
Observe que en realidad, el concepto cliente/servidor es muy genrico, y que
puede ser entendido incluso en el mbito de una sola mquina, donde unas
aplicaciones pueden prestar servicio a otras. Sin embargo, su significado desde el
punto de vista informtico suele presuponer la existencia de varias mquinas (al
menos dos) unidas en una red:
Un servidor es cualquier mquina que dispone un recurso para ser

compartido.
Un cliente es cualquier mquina que necesita un recurso externo.
Un servidor de determinado recurso puede ser cliente de otros y a la inversa. Un

cliente puede ser a su vez servidor de otro recurso.
1.4 Comunicacin entre programas

El proceso para la creacin de un servicio siempre comienza con la
creacin del Socker. As como el cliente necesita llamadas especficas en
determinados
momentos, el servidor
trabajo de modo
similar pero aade unas
pocas
llamadas
extras al sistema. El
servidor utiliza la
llamada del sistema
Socket, pero debe
hacer un trabajo extra
que era opcional
para el cliente,
el
cliente
siempre
realiza una conexin
activa
porque
la
persigue
enrgicamente los
servidores por otro lado
necesitan
proporcionar un numero
de puesto especifico
y
consiste
a
los
programas clientes si
les
va
a
prestar
servicio.
El programa
servidor que escriba
deber utilizar las
llamadas de sistema
socker (), bind (), listen (), accept (). Y mientras el programa cliente es una
conexin activa, el servidor es una conexin pasiva. Las llamadas del sistemas () y
accept () crean una conexin solo cuando el cliente pide una conexin (similar a la
accin de responder al timbre de un telfono.
10
El ejemplo de servidor escucha en un socket (puerto 8000) esperando peticiones

entrantes. Cualquier programa, como el cliente de ejemplo, puede conectar con
este servidor y pasarle hasta 16.384 bytes de datos.
El servidor trata los datos como datos ASCII y los convierte en maysculas antes
de pasrselos a! programa cliente. Estos dos sencillos programas se pueden
volver a utilizar fcilmente cuando se escriban programas cliente-servidor basados
en socket.
Los servidores que pueden recibir muchas peticiones simultneas lo usan para
crear un proceso separado para la administracin de peticiones de servicio
constitucionalmente caras. El servidor crea un socket permanente para la escucha
de peticiones de servicio; cuando un cliente conecta con el servidor, se crea un
socket temporal. Cada vez que un cliente conecta con un servidor, se abre un
nuevo socket temporal entre el cliente y el servidor.
1.5. Modelos de computacin distribuida

La computacin distribuida (o grid computing / network computing) es un modelo
de computacin basado en el uso de recursos de una red de mquinas
independientes para el procesado de unidades discretas de datos a travs de un
protocolo comn cuyo objetivo es crear una potente red de procesado de datos
que puede incluso superar a los grandes superordenadores.
Estas redes de computacin distribuida son mayoritariamente utilizadas para
investigaciones cientficas que necesitan largos tiempos de procesado mediante
ordenadores
Un sistema distribuido est compuesto de nodos, posiblemente heterogneos,
conectados mediante una red. Un sistema de esta clase puede utilizarse
efectivamente solo si el software es capaz de presentar al usuario el concepto de
single system image (SSI) sobre el sistema fsicamente distribuido. De esta forma
todos los recursos de un nodo deberan poder accederse transparentemente
desde cualquier otro nodo.
1.5.1. RMI
RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para
invocar un mtodo de manera remota. Forma parte del entorno estndar de
ejecucin de Java y proporciona un mecanismo simple para la comunicacin de
servidores en aplicaciones distribuidas basadas exclusivamente en Java. Si se
11
requiere comunicacin entre otras tecnologas debe utilizarse CORBA o SOAP en

lugar de RMI.
RMI se caracteriza por la facilidad de su uso en la programacin por estar
especficamente diseado para Java; proporciona paso de objetos por referencia
(no permitido por SOAP), recoleccin de basura distribuida y paso de tipos
arbitrarios (funcionalidad no provista por CORBA).
A travs de RMI, un programa Java puede exportar un objeto, con lo que dicho
objeto estar accesible a travs de la red y el programa permanece a la espera de
peticiones en un puerto TCP. A partir de ese momento, un cliente puede
conectarse e invocar los mtodos proporcionados por el objeto.
La invocacin se compone de los siguientes pasos:
Encapsulado (marshalling) de los parmetros (utilizando la funcionalidad

de serializacin de Java).
Invocacin del mtodo (del cliente sobre el servidor). El invocador se queda

esperando una respuesta.
Al terminar la ejecucin, el servidor serializa el valor de retorno (si lo hay) y

lo enva al cliente.
El cdigo cliente recibe la respuesta y contina como si la invocacin

hubiera sido local.
La arquitectura RMI puede verse como un modelo de cuatro capas.

Primera capa
La primera capa es la de aplicacin y se corresponde con la implementacin
real de las aplicaciones cliente y servidor. Aqu tienen lugar las llamadas a alto
nivel para acceder y exportar objetos remotos. Cualquier aplicacin que quiera
que sus mtodos estn disponibles para su acceso por clientes remotos debe
declarar dichos mtodos en una interfaz que extienda java.rmi.Remote.
Segunda capa
La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que
interacta directamente con la capa de aplicacin. Todas las llamadas a
objetos remotos y acciones junto con sus parmetros y retorno de objetos
tienen lugar en esta capa.
12
Tercera capa
La capa 3 es la de referencia remota, y es responsable del manejo de la parte
semntica de las invocaciones remotas. Tambin es responsable de la gestin
de la replicacin de objetos y realizacin de tareas especficas de la
implementacin con los objetos remotos, como el establecimiento de las
persistencias semnticas y estrategias adecuadas para la recuperacin de
conexiones perdidas. En esta capa se espera una conexin de tipo stream
desde la capa de transporte.
Cuarta Capa
La capa 4 es la de transporte. Es la responsable de realizar las conexiones
necesarias y manejo del transporte de los datos de una mquina a otra. El
protocolo de transporte subyacente para RMI es JRMP (Java Remote Method
Protocol), que solamente es "comprendido" por programas Java.
1.5.2. COM/DCOM.
Microsoft Distributed COM (DCOM) extiende COM (Component Object Model) para
soportar comunicacin entre objetos en ordenadores distintos, en una LAN, WAN, o
incluso en Internet. Con DCOM una aplicacin puede ser distribuida en lugares que dan
ms sentido al cliente y a la aplicacin.
Como DCOM es una evolucin lgica de COM, se pueden utilizar los componentes
creados en aplicaciones basadas en COM, y trasladarlas a entornos distribuidos. DCOM
maneja detalles muy bajos de protocolos de red, por lo que uno se puede centrar en la
realidad de los negocios: proporcionar soluciones a clientes.
La arquitectura DCOM
DCOM es una extensin de COM, y ste define como los componentes y sus
clientes interactan entre s. Esta interaccin es definida de tal manera que el
cliente y el componente pueden conectar sin la necesidad de un sistema
intermedio. El cliente llama a los mtodos del componente sin tener que
preocuparse de niveles ms complejos.
La Figura 1 ilustra esto en la notacin de COM
13
En los actuales sistemas operativos, los procesos estn separados unos de otros.
Un cliente que necesita comunicarse con un componente en otro proceso no
puede llamarlo directamente, y tendr que utilizar alguna forma de comunicacin
entre procesos que proporcione el sistema operativo. COM proporciona este tipo
de comunicacin de una forma transparente: intercepta las llamadas del cliente y
las reenva al componente que est en otro proceso.
La Figura 2 ilustra como las libreras de COM/DCOM proporcionan la forma de
comunicar el cliente y el componente:
Cuando el cliente y el componente residen en distintas mquinas, DCOM

simplemente reemplaza la comunicacin entre procesos locales por un protocolo
de red. Ni el cliente ni el componente se enteran de que la unin que los conecta
es ahora un poco ms grande.
La Figura 3 representa la arquitectura DCOM en su conjunto: Las librera de COM
proporcionan servicios orientados a objetos a los clientes y componentes, y
utilizan RPC y un proveedor de seguridad para generar paquetes de red estndar
que entienda el protocolo estndar de DCOM.
14
1.5.3. Servicios Web.

Los servicios web son esenciales en las Infraestructuras de Datos Espaciales
(IDE) porque permiten a los usuarios el acceder a datos de manera estndar
mediante Sistemas de Informacin Geogrfica y otras aplicaciones a travs de
Internet. Debido a que este tipo de servicios sirven como protocolo entre las
aplicaciones cliente y nuestro servidor de mapas, no pueden ser utilizados
directamente en un navegador como Microsoft Internet Explorer, Mozilla Firefox o
Google Chrome.
Adems de HTML, el desarrollo de nuevos lenguajes como XML ha hecho
posible la utilizacin de estndares que permiten que las aplicaciones descritas en
distintos lenguajes de programacin y ejecutadas en distintas plataformas puedan
interoperar entre ellas, es decir, puedan intercambiar los datos.
De esta forma, los distintos servicios que se ofrecen en la Word Wide Web
pueden combinarse para ejecutar operaciones complejas.
La interoperabilidad puede ser de 3 tipos:

Tcnica: capacidad para que los sistemas de informacin intercambien seales y
se realiza tanto a travs de una conexin fsica (cable, ondas, etc.), como por
medio de una serie de protocolos de comunicaciones (TCP/IP, etc.).
Sintctica: capacidad para que un sistema pueda leer e interpretar los datos de
otros sistemas. Para ello se utilizan una serie de aplicaciones como las Interfaz
de programacin de aplicaciones que permiten intercambiar y analizar los
datos.
Semntica: capacidad de intercambiar el contenido de la informacin basndose
en el significado.
Estos servicios proporcionan mecanismos de comunicacin estndares entre
diferentes aplicaciones, que interactan entre s para presentar informacin
dinmica al usuario. Para proporcionar interoperabilidad y extensibilidad entre
estas aplicaciones, y que al mismo tiempo sea posible su combinacin para
realizar operaciones complejas, es necesaria una arquitectura de referencia
estndar.
La estructura interna de un servicio web se basa en los siguientes protocolos y normas:
15
SOAP (Simple Object Access Protocol): establece la forma en que dos objetos
en diferentes procesos pueden comunicarse mediante el intercambio de datos en
lenguaje XML.
UDDI (Universal Description, Discovery and Integration): lista los servicios web
y los pone a disposicin de los usuarios.
WDSL (Web Services Description Language): permite que los servicios web
describan cmo deben ser tratados por otras aplicaciones.
1.5.4. Otros.
Modelo cliente-servidor: Es el modelo ms utilizado para realizar aplicaciones
distribuidas. Existe un proceso servidor y uno o varios procesos clientes. Este
modelo se utiliza en muchos servicios de Internet como HTTP, FTP, DNS... Este
concepto tambin puede aplicarse a los ordenadores servidor o cliente, cuyo
nombre se debe a que la ejecucin de la mayora de sus procesos son de tipo
servidor o de tipo cliente.
Peer-to-peer: En el modelo cliente-servidor hay una clara diferenciacin. El
servidor ofrece a los clientes servicios y los clientes utilizan estos servicios. En
sistemas P2P los procesos que participan en la comunicacin realizan los mimos
papeles: de cliente y de servidor. Este sistema est ms asociado a lo que es la
informtica distribuida, ya que se olvida de la centralizacin y tiene un sistema
ms dinmico y descentralizado.
16
Cluster: es un conjunto de ordenadores conectados por una red de alta velocidad

(Gigabit Ethernet, Myrineto InfiniBand). Los computadores individuales pueden ser
PC convencionales que se instalan en un rack. Todos los ordenadores trabajan
como un nico recurso de computacin, mostrndose como un nico sistema. En
un cluster todos los ordenadores comparten los discos y los distintos ordenadores
que lo forman estn continuamente monitorizando para detectar posibles fallos de
hardware. Si se detecta un fallo, se planifica el trabajo del nodo errneo en otro
ordenador, de forma que el usuario no percibe la parada del servicio. Los cluster
se realizan mediante un middleware que gestiona todo. Un cluster puede ser
homogneo (misma arquitectura, SO...) o heterogneo (distintos entornos,
middlewares ms complejos).
Grid: El concepto de grid, es similar al concepto de cluster. La principal diferencia
con un entorno cluster, es que en un entorno grid, los diferentes computadores del
grid no pertenecen a un mismo dominio de administracin y por tanto estn
sujetos a diferentes polticos de uso y de administracin. La primera mencin, y su
definicin viene dada por Ian Foster: "Un sistema que coordina recursos, que no
estn sujetos a un control centralizado usando interfaces y protocolos estndares,
abiertos y de propsito general para proveer de servicios relevantes".
Conclusin
Una arquitectura es un entramado de componentes funcionales que aprovechando
diferentes estndares, convenciones, reglas y procesos, permite integrar una amplia
gama de productos y servicios informticos, de manera que pueden ser utilizados
eficazmente dentro de la organizacin.
Referencias
Loger, A. (s.f.). Desarrollo de aplicaciones web. Obtenido de
http://alog78503.blogspot.mx/2013/02/121-aplicaciones-de-23-y-ncapas_25.html
Vignaga, A. (s.f.). Universidad de la Repblica, Facultad de Ingeniera. Obtenido
de
http://moodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/LP/AM/01/Arquitectur
as_y_tecnologias_para_el_desarrollo_de_aplicaciones_web.pdf
17
18

Unidad 1 - Contexto de La Programacion Cliente-Servidor

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unidad 1 - Contexto de La Programacion Cliente-Servidor

Uploaded by

Copyright:

Available Formats

INSTITUTO TECNOLOGICO DE ORIZABA

INSTITUTO TECNOLGICO DE ORIZABA

ISMAEL ALDANA FERNANDEZ

INSTITUTO TECNOLOGICO DE ORIZABA

ISMAEL ALDANA FERNANDEZ

INSTITUTO TECNOLOGICO DE ORIZABA

ISMAEL ALDANA FERNANDEZ

INSTITUTO TECNOLOGICO DE ORIZABA

Adems de la transparencia y la independencia del hardware y del software,

Debe utilizar protocolos asimtricos, donde el servidor se limita a

El servidor ofrecer recursos, tanto lgicos como fsicos a una cantidad

El servidor ofrecer tambin una serie de servicios, que sern usados

Se facilitar la integridad y el mantenimiento tanto de los datos como de

Los sistemas estarn dbilmente

Se facilitar la escalabilidad, de manera que sea fcil aadir nuevos

Elementos de la arquitectura cliente/servidor.

ISMAEL ALDANA FERNANDEZ

INSTITUTO TECNOLOGICO DE ORIZABA

ISMAEL ALDANA FERNANDEZ

INSTITUTO TECNOLOGICO DE ORIZABA

Por lo tanto, el middleware facilita el desarrollo de aplicaciones, porque

El protocolo de transporte, que ser comn para otras aplicaciones del

El sistema operativo de red

El protocolo del servicio, que ser especfico del tipo de sistema

ISMAEL ALDANA FERNANDEZ

INSTITUTO TECNOLOGICO DE ORIZABA

Si descomponemos este modo de funcionamiento en elementos estructurales,

Un nivel de presentacin, que aglutina los elementos relativos al cliente.

Un nivel de aplicacin, compuesto por elementos relacionados con el

Un nivel de comunicacin, que est formado por los elementos que

Un nivel de base de datos, formado por los elementos relacionados con

1.2 Modelos de dos y tres capas

INSTITUTO TECNOLOGICO DE ORIZABA

Comparacin entre ambos tipos de arquitecturas

tareas se comparten entre servidores

INSTITUTO TECNOLOGICO DE ORIZABA

1.3 Usos y Aplicaciones

denominan enrutadores ("Routers"),

recepcin y transmisin de trfico Internet.

Un servidor es cualquier mquina que dispone un recurso para ser

Un servidor de determinado recurso puede ser cliente de otros y a la inversa. Un

INSTITUTO TECNOLOGICO DE ORIZABA

1.4 Comunicacin entre programas

ISMAEL ALDANA FERNANDEZ

INSTITUTO TECNOLOGICO DE ORIZABA

El ejemplo de servidor escucha en un socket (puerto 8000) esperando peticiones

1.5. Modelos de computacin distribuida

INSTITUTO TECNOLOGICO DE ORIZABA

requiere comunicacin entre otras tecnologas debe utilizarse CORBA o SOAP en

Encapsulado (marshalling) de los parmetros (utilizando la funcionalidad

Invocacin del mtodo (del cliente sobre el servidor). El invocador se queda

Al terminar la ejecucin, el servidor serializa el valor de retorno (si lo hay) y

El cdigo cliente recibe la respuesta y contina como si la invocacin

La arquitectura RMI puede verse como un modelo de cuatro capas.

ISMAEL ALDANA FERNANDEZ

INSTITUTO TECNOLOGICO DE ORIZABA

ISMAEL ALDANA FERNANDEZ

INSTITUTO TECNOLOGICO DE ORIZABA

Cuando el cliente y el componente residen en distintas mquinas, DCOM

ISMAEL ALDANA FERNANDEZ

INSTITUTO TECNOLOGICO DE ORIZABA

1.5.3. Servicios Web.

La interoperabilidad puede ser de 3 tipos: