UNIDAD 1.

CONTEXTO DE LA
PROGRAMACIN
CLIENTE/SERVIDOR
6 DE OCTUBRE DE 2014
INSTITUTO TECNOLGICO DEL ISMO
1
CONTENIDO
INTRODUCCIN............................................................................................... 2
1.1 ARQUITECTURA DEL MODELO CLIENTE/SERVIDOR.................................... 3
1.2.- MODELOS DE DOS Y TRES CAPAS ............................................................ 6
1.3 USOS Y APLICACIONES.............................................................................. 9
1.4 COMUNICACIONES ENTRE PROGRAMAS................................................. 10
1.5 MODELOS DE COMPUTACIN DISTRIBUIDA............................................ 12
1.5.1 RMI ....................................................................................................................................... 13
1.5.2 COM/DCOM ......................................................................................................................... 15
1.5.3 SERVICIOS WEB .................................................................................................................... 17
1.5.4 OTROS................................................................................................................................... 19
CONCLUSIN................................................................................................. 21
FUENTES DE INFORMACIN: ......................................................................... 22
2
INTRODUCCIN
En esta unidad vamos a hablar de los conceptos bsicos de los modelos
cliente/servidor.
En el tema 1.1 que es la arquitectura del modelo Cliente/ servidor nos habla
de lo que es un modelo de este tipo y como est constituido y los elementos que
interactan en el modelo
En el tema 1.2 que es el modelo de capa 2 y capa 3 nos explica cada una de
estas capas; en la de 2 capas nos dice que la arquitectura nivel 2 es donde el cliente
solicita recursos y el servidor responde a la solicitud con sus propios recursos y en
el modelo de 3 capas ya nos menciona que se involucran tres elementos, lo que son
el cliente, servidor y el gestor.
En el tema 1.3 que es el uso y aplicaciones del modelo cliente servidor nos
da mencin de cmo se utiliza el modelo cliente/servidor y cules son las
operaciones que realiza por medio del internet y las aplicaciones que el servidor
pone a disposicin de los clientes
En el tema 1.4 es comunicacin entre programas nos menciona el cmo se
comunica los programas por medio del operador socker() que es el que hace el
enlace entre el cliente y el servidor y por ltimo en el tema 1.5 modelo de
computacin distribuida es modelo que sirve para resolver problemas de
computacin masiva que utiliza un gran nmero de computadoras organizadas, y
nos explica cada uno de los modelos como son el RMI, COM/DCOM, SERVIDOR
WEB entre otros.
3
1.1 ARQUITECTURA DEL MODELO CLIENTE/SERVIDOR
La arquitectura cliente/servidor consiste en procesar la informacin de un
modo distribuido. As, 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.
Las peticiones que el cliente realiza al servidor, estas son contestadas de
manera eficaz y eficiente.
Caractersticas del ambiente cliente/servidor.
o Utiliza protocolos asimtricos, donde el servidor se limita a escuchar, en
espera de que un cliente inicie una solicitud.
o El servidor ofrecer recursos, tanto lgicos como fsicos a una cantidad
variable y diversa de clientes ejemplo puede ser una impresin,
almacenamiento.
o Se facilitar la integridad y el mantenimiento tanto de los datos como de los
programas para que tenga un buen uso de las mismas.
4
o Los sistemas estarn dbilmente acoplados, ya que interactan mediante el
envo de mensajes entre las peticiones del cliente al servidor.
o 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)
ELEMENTOS DE LA ARQUITECTURA CLIENTE/SERVIDOR.
El servidor.
Consta de un ordenador, normalmente con prestaciones elevadas, que
ejecuta servicios para atender las demandas (peticiones) 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.
El cliente
Un cliente es un proceso que solicita los servicios de otro, normalmente a
peticin de un usuario.
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,
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 facilita el desarrollo de aplicaciones, porque resuelve la parte
del transporte de mensajes y facilita la interconexin de sistemas heterogneos sin
utilizar tecnologas propietarias.
Podemos estructurar el middleware en tres niveles:
o El protocolo de transporte, que ser comn para otras aplicaciones del
sistema.
5
o El sistema operativo de red.
o El protocolo del servicio, que ser especfico del tipo de sistema
cliente/servidor que estemos considerando.
EL FUNCIONAMIENTO BSICO.
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. 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.
6
1.2.- MODELOS DE DOS Y TRES CAPAS
MODELO CLIENTE SERVIDOR DOS CAPAS
La arquitectura nivel 2 es donde el cliente solicita recursos y el servidor
responde a la solicitud con sus propios recursos.
Una arquitectura cliente/servidor clsica tiene dos capas (two-tier)
La primera es interface del cliente con el servidor
La segunda donde el gestor de base de datos interpreta las peticiones del
cliente la lgica de la aplicacin se divide entre el cliente y servidor
Un ejemplo de esta configuracin podra ser un applet Java que se carga en el
navegador del cliente y trabaja directamente con la base de datos mediante JDBC.
Figura A: Esquema de arquitectura Cliente/Servidor clsica.
VENTAJAS DE ESTE MODELO
Existe buen rendimiento debido a la conexin directa con la base de datos.
Realiza envo y recepcin de datos en una sola conexin
Mantiene buena conexin con la base de datos
7
Se minimizan las peticiones en el servidor trasladndose la mayor parte del
trabajo al cliente.
DESVENTAJAS
Depende del controlador JDBC para acceder a la base de datos
Es necesario que el cliente tenga instalado controladores en su sistema para
que se produzca la comunicacin con la base de datos
Adems hay que tener en cuenta que el modelo de seguridad de Java impide
que desde un applet sin validar (lo que se conoce como untrusted applet), como lo
son la mayora de los que se ejecutan en un navegador, se puedan realizar las
siguientes operaciones:
1. El acceso general, y presupuesto mediante JDBC, a bases de datos situadas
en direcciones URL distintas a las que procede el mismo applet.
2. La configuracin de recursos locales como, por ejemplo, la informacin de la
fuente de datos ODBC para usar el puente JDBC-ODBC.
3. La descarga de clases nativas, es decir, aquellas cuyo nombre empieza
por Java. Esta restriccin afecta directamente a los navegadores que utilizan
JDK 1.0.2 o anterior, pues JDBC es posterior a esta versin, de forma que
las clases apropiadas no estarn instaladas localmente ni podrn ser
descargadas de Internet por el applet.
4. Finalmente debemos tener en cuenta que es bien conocido que los
programas Java pueden ser descompilados muy fcilmente con lo que
introducir el acceso a nuestras bases de datos mediante un applet Java
conlleva un riesgo considerable en cuanto a la seguridad.
MODELO CLIENTE SERVIDOR TRES CAPAS
En este nivel ya existe un intermediario est compuesta por
1. CLIENTE: el equipo que solicita los recursos
8
2. EL SERVIDOR: proporciona los recursos solicitados pero requiere de otro
servidor para hacerlo
3. El Gestor Y el Servidor de Datos tienen que hablar el mismo lenguaje
VENTAJAS DE ESTE MODELO:
No existe problema con controladores para acceder a la base de datos
El cliente no necesita instalar nada adicional para poder acceder a la base
de datos
Existen mejoras desde el punto de viste de portabilidad de la aplicacin ,
escalabilidad, robustez y reutilizacin del cdigo
Facilita la tarea de cambios en el sistema gestor de base de datos
Desaparecen las restricciones debidas a las limitaciones de los applets
impuestas por el modelo de seguridad de Java.
DESVENTAJAS
Esta solucin es algo menos eficiente que la del modelo de dos capas, ya
que hemos aadido una capa intermedia ms de software.
9
1.3 USOS Y APLICACIONES
Cuando realizamos una operacin entre cliente y servidor por medio del
internet, la informacin viaja en forma de cdigo a lo largo de redes que pueden
abarcar grandes tamaos. En el caso de las grandes redes se necesita un tercer
tipo de mquinas para gestionar las transmisiones, aparte del cliente y servidor.
Se le denominan enrutadores (Routers), que funciona como elemento de
recepcin y transmisin de trfico internet.
El modelo cliente-servidor no solo se utiliza para darle referencia a las
maquinas fsicas, sino tambin a los programas con los cuales funcionan segn su
utilidad, como por ejemplo las frecuentes expresiones como cliente de correo o
servidor de noticias relacionados a los programas. La primera se refiere al que
utilizamos frecuentemente para interrogar nuestro buzan e-mail, como para
descargar el correo y manipularlo. El segundo se refiere a un programa o sistema,
que en un servidor (maquina) realiza el trabajo de colocar los mensajes de noticias,
atiende las peticiones de los clientes, etc.
Tipos de sistemas de los Cliente-Servidor dependiendo de las aplicaciones que el
servidor pone a disposicin de los clientes.
Servidores de Impresin, mediante el cual los usuarios comparten
impresoras.
Servidores de Archivos, con el cual los clientes comparten discos duros.
Servidores de Bases de Datos, donde existe una nica base de datos.
Servidores de Lotus Notes, que permite el trabajo simultneo de distintos
clientes con los mismos datos, documentos o modelos.
Servidores Web, tambin utilizan la tecnologa Cliente- Servidor, aunque
aaden aspectos nuevos y propios a la misma.
10
1.4 COMUNICACIONES ENTRE PROGRAMAS
El desarrollo para la iniciacin de un servicio inicia siempre con la creacin del
Socker. De esta manera es como el cliente requiere llamadas especificas en ciertos
momentos, el servidor trabaja de modo similar pero agrega unas pocas llamadas
extras al sistema. El servidor utiliza la llamada del sistema Socker(), 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 entretanto 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 (semejante a la accin de
contestar al timbre de un telfono.
El ejemplo del servidor escucha en un socket (puerto 8000) esperando solicitudes
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 antes de pasrselos al programa
cliente los convierte en maysculas. Cuando se escriban programas cliente-servidor
basados en socket, estos dos sencillos programas se pueden volver a utilizar
fcilmente.
Los servidores que pueden recibir muchas peticiones a la vez lo utilizan para crear
un proceso separado para la administracin de solicitudes de servicio
constitucionalmente caras. El servidor crea un socket continuo 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
permanente entre el cliente y el servidor.
11
12
1.5 MODELOS DE COMPUTACIN DISTRIBUIDA
La computacin distribuida o informtica en malla, es modelo que sirve para
resolver problemas de computacin masiva que utiliza un gran nmero de
computadoras organizadas en racimos incrustados en una infraestructura de
telecomunicaciones 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 utilizadas para investigaciones
cientficas que necesitan largos tiempos de procesado mediante ordenadores. Con
ello son capaces de avanzar en sus investigaciones de manera muy eficiente
gracias a la aportacin altruista de miles de personas que donan su tiempo de
procesador en beneficio de dichas investigaciones cientficas.
La computacin distribuida utiliza los recursos no aprovechados del
ordenador eso quiere decir que son los recursos cuando el ordenador no se
encuentra haciendo nada o poco. Muchos de nuestros ordenadores tienen
modernos y potentes y con buena cantidad de memoria y que pasan mucho tiempo
encendido sin hacer nada, esos recursos que no se usan son usados para estudios
cientficos, realizando trabajos sin que te des cuenta y sin molestar en segundo
plano.
Este software trabaja en segundo plano, con prioridad baja, solo usa los recursos
que t no usas, si en algn momento el ordenador necesita toda su potencia, el
proyecto no trabajar, estando tu equipo disponible a plena capacidad. Por poner
un ejemplo imaginemos que el ordenador esta sin hacer nada, slo aprovechando
los recursos y trabajando en estos proyectos. Si en ese momento ejecutamos
cualquier programa, o grabamos un CD, o abrimos un procesador de texto, los
13
proyectos en segundo plano se pararn, de manera que tenga la potencia necesaria
para ejecutarse, sin que la presencia de los proyectos en segundo plano moleste en
absoluto.
La principal razn de la aparicin de este tipo de computacin son los
siguientes: 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 para invocar un
mtodo de manera remota ofrecido por Java. Proporciona un mecanismo simple
para la comunicacin de servidores en aplicaciones distribuidas basadas
exclusivamente en Java y forma parte del entorno estndar de ejecucin de Java.
Si se requiere comunicacin entre otras tecnologas debe utilizarse CORBA o SOAP
en lugar de RMI.
RMI la principal caracterstica es 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 (Garbage
Collector distribuido) y paso de tipos arbitrarios (funcionalidad no provista por
CORBA).
A travs de RMI, un programa Java puede exportar un objeto, y este 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.
14
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
Toda aplicacin RMI normalmente se descompone en 2 partes:
Un servidor, que crea algunos objetos remotos, crea referencias para
hacerlos accesibles, y espera a que el cliente los invoque.
Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los
invoca.
En cuanto a 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.
15
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
COM:
Component Object Model (COM) es una plataforma de Microsoft para
componentes de software introducida en 1993. Esta plataforma es utilizada para
permitir la comunicacin entre procesos y la creacin dinmica de objetos, en
cualquier lenguaje de programacin que soporte esta tecnologa.
COM es una manera de implementar objetos neutrales con respecto al
lenguaje, de manera que pueden ser usados en entornos distintos de aquel en que
fueron creados, a travs de fronteras entre mquinas. Las diferentes semnticas de
reserva de memoria estn acomodadas haciendo a los objetos responsables de su
propia creacin y destruccin por medio del contador de referencias. Para
componentes bien creados, COM permite la reutilizacin de objetos sin
conocimiento de su implementacin interna, porque fuerza a los implementadores
de componentes a proveer interfaces bien definidas que estn separados de la
implementacin
16
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 diversos 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 llega a manejar detalles muy bajos de protocolos de red, por lo
que uno se puede centrar en la realidad de los negocios que es 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 sin la necesidad de un sistema intermedio pueden conectar. 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
En los sistemas operativos actuales, los procesos estn separados unos de
otros. Un cliente que necesita comunicarse con un componente estando 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.
17
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.
1.5.3 SERVICIOS WEB
Los servicios web son esenciales en las Infraestructuras de Datos Espaciales
(IDE) ya que permiten a los usuarios el acceder a datos de manera estndar
18
mediante Sistemas de Informacin Geogrfica y otras aplicaciones a travs de
Internet.
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
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 como por medio de una serie de protocolos de
comunicaciones (TCP/IP, etc.) como tambin a travs de una conexin fsica (cable,
ondas, etc.),
Sintctica: capacidad para que un sistema pueda interpretar y leer los datos
de otros sistemas. Para que se pueda realizar esto se utilizan una serie de
aplicaciones como las Interfaz de programacin de aplicaciones que permiten
intercambiar y analizar los datos.
Semntica: capacidad de poder intercambiar el contenido de la informacin
basndose en el significado.
Estos servicios pueden proporcionar mecanismos de comunicacin
estndares entre diferentes aplicaciones, que interactan entre s para presentar
informacin dinmica al usuario. Es necesaria una arquitectura de referencia
estndar para proporcionar interoperabilidad y extensibilidad entre estas
aplicaciones, y que al mismo tiempo sea posible su combinacin para realizar
operaciones complejas,
La estructura interna de un servicio web se basa en los siguientes protocolos y
normas:
19
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): prepara 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:
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 es de tipo
servidor o de tipo cliente. Es el modelo ms utilizado para realizar aplicaciones
distribuidas. Existe un proceso servidor y uno o varios procesos clientes.
Peer-to-peer:
En el modelo cliente-servidor hay una clara diferenciacin. El servidor ofrece
servicios a los clientes y estos utilizan estos servicios. En los 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,
20
ya que se olvida de la centralizacin y tiene un sistema ms dinmico y
descentralizado.
Cluster:
Es un conjunto de ordenadores conectados por una red de alta velocidad
(Gigabit Ethernet, Myrineto InfiniBand). Todos los ordenadores trabajan como un
nico recurso de computacin, mostrndose como un nico sistema. Los
computadores individuales pueden ser PC convencionales que se instalan en un
rack. 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 llega a detectar un fallo, el usuario no percibe la
parada del servicio ya que se planifica el trabajo del nodo errneo en otro ordenador.
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".
21
CONCLUSIN
Esta unidad se dio a conocer el proceso que se lleva en el ambiente cliente
servidor, nos define loes elementos de este modelo, as como sus caractersticas.
Nos dice que un servicio es toda aquella peticin que puede solicitar el cliente
al servidor, y el servidor se tiene que encargar de responder a dicha peticin de una
manera eficaz y eficiente, pero para que haya esa comunicacin hay una serie de
procesos.
Tambin entendimos que se divide en diferentes capas, y en cada capa tiene
sus propios elementos como ejemplo en la capa 2 nada ms incluye el servidor y el
cliente. Y en la capa 3 ya incluye otro elemento que es el gestor de base de datos.
Adems las aplicaciones que se tiene en el cliente/ servidor son servicios de
impresin, servicios base de datos, entre otros.
Tambin nos menciona la manera de cmo puede accesar a la informacin
ya sea por medio de los servicios web o por RMI entre otros.
22
FUENTES DE INFORMACIN:
http://somebooks.es/?p=3357
http://todosobreprogramacionclienteservidor.blogspot.mx/
http://www.zator.com/Internet/A4_4.htm
http://todosobreprogramacionclienteservidor.blogspot.mx/
http://www.buenastareas.com/ensayos/2-1-1-Comunicacin-Con-Cliente-
Servidor-Sockets/1613125.html
http://cala.unex.es/cala/epistemowikia/index.php?title=Computacion_Distrib
uida_/_Computaci%C3%B3n_Grid
http://es.wikipedia.org/wiki/Java_Remote_Method_Invocation
http://www.elai.upm.es/webantigua/spain/Investiga/GCII/areas/administracio
n/DCOM.htm#Introduccin
http://sitel.jalisco.gob.mx/portal2/index.php/top-servicios
http://www.hipertexto.info/documentos/web_tecnolog.htm
ftp://www.cc.uah.es/pub/Alumnos/I.T.I.Gestion/Sist.Operativos/TECWeb/T1/
web/node/27.html
ANA LILIA SANCHEZ CELAYA