unidad 1- contexto de la programacion cliente-servidor

INSTITUTO TECNOLÓGICO DE ORIZABA

ING. INFORMÁTICA

PROGRAMACION EN AMBIENTE CLIENTE-SERVIDOR

Hora: 13 a 14

PRESENTA:

ALDANA FERNANDEZ ISMAEL

No. DE CONTROL:

11010383

PROFESOR:

PELAEZ CAMARENA SILVESTRE GUSTAVO

ISMAEL ALDANA FERNANDEZ 1

INSTITUTO TECNOLOGICO DE ORIZABA

INVESTIGACION UNIDAD 1

Contexto de la programación cliente-servidor

ContenidoIntroducción.......................................................................................................................................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 básico...............................................................................................................6

1.2 Modelos de dos y tres capas........................................................................................................7

Arquitectura en 2 niveles...............................................................................................................7

Arquitectura en 3 niveles...............................................................................................................7

Comparación entre ambos tipos de arquitecturas.........................................................................8

1.3 Usos y Aplicaciones......................................................................................................................8

1.4 Comunicación entre programas...................................................................................................9

1.5. Modelos de computación 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

Conclusión........................................................................................................................................17

Referencias.......................................................................................................................................17



Introducción La arquitectura cliente-servidor define una relación entre el usuario de una

estación de trabajo (el cliente frontal) y un servidor posterior de archivos,

impresión, 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 relación 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 más sencillo realizar el

mantenimiento y la seguridad de unos servidores situados en un mismo lugar, y

más simple el proceso de realización de copias de seguridad, siempre que los

datos se encuentren en una única ubicación y una misma autoridad los gestione.

Desarrollo

1.1. Arquitectura cliente/servidor

La arquitectura cliente/servidor persigue el objetivo de procesar la información de un modo distribuido. De esta forma, los usuarios finales pueden estar dispersos en un área geográfica más o menos extensa (un edificio, una localidad, un país,…) y acceder a un conjunto común de recursos compartidos.

Además, el acceso debe ser transparente (el cliente puede desconocer la ubicación física del recurso que pretende utilizar) y, preferiblemente, multiplataforma, es decir, independiente del sistema operativo, del software de aplicación e incluso del hardware.

En definitiva, cuando hablamos de la implantación de una arquitectura cliente/servidor, nos referimos a un sistema de información distribuido.



Además de la transparencia y la independencia del hardware y del software, una implantación cliente/servidor debe tener las siguientes características:

o Debe utilizar protocolos asimétricos, donde el servidor se limita a escuchar, en espera de que un cliente inicie una solicitud.

o El servidor ofrecerá recursos, tanto lógicos como físicos a una cantidad variable y diversa de clientes (por ejemplo, espacio de almacenamiento, bases de datos, impresoras, etc.)

o El servidor ofrecerá también una serie de servicios, que serán usados por los clientes. Estos servicios estarán encapsulados, para ocultar a los clientes los detalles de su implementación (por ejemplo, aceptar el requerimiento de un cliente sobre una base de datos o formatear los datos obtenidos antes de transmitirlos al cliente).

o 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.

o Los sistemas estarán débilmente acoplados, ya que interactúan mediante el envío de mensajes.

o Se facilitará la escalabilidad, de manera que sea fácil añadir nuevos clientes a la infraestructura (escalabilidad horizontal) o aumentar la potencia del servidor o servidores, aumentando su número o su capacidad de cálculo (escalabilidad vertical)

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:



http://somebooks.es/wp-content/uploads/2013/08/sor0101.png

El servidor

Cuando hablamos de una forma genérica, 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 definición de cliente más abajo).

Es muy frecuente que, para referirse a un proceso servidor, se utilice el término back-end.

Según 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 clienteIgual que antes, al hablar de forma genérica 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 petición de un usuario.

En entornos cliente/servidor, suele utilizarse el término 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 gráficas (GUI). Además, se encargará de formular las solicitudes al servidor y recibir su respuesta, por lo que deberá encargarse de una parte de la lógica de la aplicación y de realizar algunas validaciones de forma local.

El MiddlewareEs 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 tecnologías propietarias.

Por lo tanto, el middleware facilita el desarrollo de aplicaciones, porque resuelve la parte del transporte de mensajes y facilita la interconexión de sistemas heterogéneos sin utilizar tecnologías propietarias.

Además, ofrece más control sobre el negocio, debido a que permite obtener información desde diferentes orígenes (uniendo tecnologías y arquitecturas distintas) y ofrecerla de manera conjunta.

Podemos estructurar el middleware en tres niveles:



o El protocolo de transporte, que será común para otras aplicaciones del sistema.

o El sistema operativo de red

o El protocolo del servicio, que será específico del tipo de sistema cliente/servidor que estemos considerando.

El funcionamiento básicoAunque es probable que a estas alturas ya te hagas una idea sobre el funcionamiento general del modelo cliente/servidor, vamos a concretarlo a continuación:

1. Lo primero que debe ocurrir es que se inicie el servidor. Esto ocurrirá durante el arranque del sistema operativo o con la intervención posterior del administrador del sistema. Cuando termine de iniciarse, esperará de forma pasiva las solicitudes de los clientes.

2. En algún momento, uno de los clientes conectados al sistema realizará una solicitud al servidor.

3. El servidor recibe la solicitud del cliente, realiza cualquier verificación necesaria y, si todo es correcto, la procesa.

4. Cuando el servidor disponga del resultado solicitado, lo envía al cliente.

5. Finalmente, el cliente recibe el resultado que solicitó. A continuación 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á más fácil comprender los conceptos implicados. De esta forma, podemos obtener una definición de la arquitectura por niveles, estructurada como sigue:

o Un nivel de presentación, que aglutina los elementos relativos al cliente.

o Un nivel de aplicación, compuesto por elementos relacionados con el servidor.



http://somebooks.es/wp-content/uploads/2013/08/sor0122.png

o Un nivel de comunicación, que está formado por los elementos que hacen posible la comunicación entre el cliente y el servidor.

o Un nivel de base de datos, formado por los elementos relacionados con el acceso a los datos.

1.2 Modelos de dos y tres capasArquitectura 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 aplicación 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 presentación

2. El servidor de aplicaciones (también 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

Comparación entre ambos tipos de arquitecturasLa 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 la seguridad se puede definir independientemente

para cada servicio y en cada nivel

Mejor rendimiento, ya que las tareas se comparten entre servidores

1.3 Usos y Aplicaciones

Cuando la operación entre clientes y servidores se realiza a través de una red

(como es el caso de Internet), la información viaja codificada a lo largo de redes

que pueden ser del tamaño de un edificio o de tamaño planetario. En caso de

redes grandes, aparte de servidores y clientes, se necesita un tercer tipo de

máquinas para gestionar las transmisiones.

Se denominan enrutadores ("Routers"), y funcionan como elementos de

recepción y transmisión de tráfico Internet.

El paradigma cliente-servidor no solo se utiliza en referencia a las máquinas

físicas, también a los programas que las hacen funcionar según 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 buzón 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 (máquina) 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 genérico, y que

puede ser entendido incluso en el ámbito de una sola máquina, donde unas



aplicaciones pueden prestar servicio a otras. Sin embargo, su significado desde el

punto de vista informático suele presuponer la existencia de varias máquinas (al

menos dos) unidas en una red:

Un servidor es cualquier máquina que dispone un recurso para ser compartido.

Un cliente es cualquier máquina 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 Comunicación entre programas

El proceso para la creación de un servicio siempre comienza con la creación del Socker. Así como el cliente necesita llamadas específicas en determinados momentos, el servidor trabajo de modo similar pero añade 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 conexión activa porque la persigue enérgicamente 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 conexión activa, el servidor es una conexión pasiva. Las llamadas del sistemas () y accept () crean una conexión solo cuando el cliente pide una conexión (similar a la acción de responder al timbre de un teléfono.



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 mayúsculas antes de pasárselos a! programa cliente. Estos dos sencillos programas se pueden volver a utilizar fácilmente cuando se escriban programas cliente-servidor basados en socket.

Los servidores que pueden recibir muchas peticiones simultáneas lo usan para crear un proceso separado para la administración 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 computación distribuidaLa computación distribuida (o grid computing / network computing) es un modelo de computación basado en el uso de recursos de una red de máquinas independientes para el procesado de unidades discretas de datos a través de un protocolo común cuyo objetivo es crear una potente red de procesado de datos que puede incluso superar a los grandes superordenadores.

Estas redes de computación distribuida son mayoritariamente utilizadas para investigaciones científicas que necesitan largos tiempos de procesado mediante ordenadores

Un sistema distribuido está compuesto de nodos, posiblemente heterogéneos, 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 físicamente distribuido. De esta forma



todos los recursos de un nodo deberían poder accederse transparentemente desde cualquier otro nodo.

1.5.1. RMIRMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para invocar un método de manera remota. Forma parte del entorno estándar de ejecución de Java y proporciona un mecanismo simple para la comunicación de servidores en aplicaciones distribuidas basadas exclusivamente en Java. Si se requiere comunicación entre otras tecnologías debe utilizarse CORBA o SOAP en lugar de RMI.

RMI se caracteriza por la facilidad de su uso en la programación por estar específicamente diseñado para Java; proporciona paso de objetos por referencia (no permitido por SOAP), recolección de basura distribuida y paso de tipos arbitrarios (funcionalidad no provista por CORBA).

A través de RMI, un programa Java puede exportar un objeto, con lo que dicho objeto estará accesible a través 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 métodos proporcionados por el objeto.

La invocación se compone de los siguientes pasos:

Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad de serialización de Java).

Invocación del método (del cliente sobre el servidor). El invocador se queda esperando una respuesta.

Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo envía al cliente.

El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local.

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

La primera capa es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier aplicación que quiera que sus métodos estén disponibles para su acceso por clientes remotos debe declarar dichos métodos 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 interactúa directamente con la capa de aplicación. Todas las llamadas a objetos remotos y acciones junto con sus parámetros y retorno de objetos tienen lugar en esta capa.

Tercera capa

La capa 3 es la de referencia remota, y es responsable del manejo de la parte semántica de las invocaciones remotas. También es responsable de la gestión de la replicación de objetos y realización de tareas específicas de la implementación con los objetos remotos, como el establecimiento de las persistencias semánticas y estrategias adecuadas para la recuperación de conexiones perdidas. En esta capa se espera una conexión 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 máquina 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 comunicación entre objetos en ordenadores distintos, en una LAN, WAN, o incluso en Internet. Con DCOM una aplicación puede ser distribuida en lugares que dan más sentido al cliente y a la aplicación.

Como DCOM es una evolución lógica 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 extensión de COM, y éste define como los componentes y sus clientes interactúan entre sí. Esta interacción 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 métodos del componente sin tener que preocuparse de niveles más complejos.

La Figura 1 ilustra esto en la notación de COM



En los actuales sistemas operativos, los procesos están 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 comunicación entre procesos que proporcione el sistema operativo. COM proporciona este tipo de comunicación de una forma transparente: intercepta las llamadas del cliente y las reenvía al componente que está en otro proceso.

La Figura 2 ilustra como las librerías de COM/DCOM proporcionan la forma de comunicar el cliente y el componente:

Cuando el cliente y el componente residen en distintas máquinas, DCOM simplemente reemplaza la comunicación entre procesos locales por un protocolo de red. Ni el cliente ni el componente se enteran de que la unión que los conecta es ahora un poco más grande.

La Figura 3 representa la arquitectura DCOM en su conjunto: Las librería 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 estándar que entienda el protocolo estándar de DCOM.



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 estándar mediante Sistemas de Información Geográfica y otras aplicaciones a través 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.

Además de HTML, el desarrollo de nuevos lenguajes como XML ha hecho posible la utilización de estándares que permiten que las aplicaciones descritas en distintos lenguajes de programación 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:

Técnica: capacidad para que los sistemas de información intercambien señales y se realiza tanto a través de una conexión física (cable, ondas, etc.), como por medio de una serie de protocolos de comunicaciones (TCP/IP, etc.).

Sintáctica: 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 programación de aplicaciones que permiten intercambiar y analizar los datos.

Semántica: capacidad de intercambiar el contenido de la información basándose en el significado.

Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes aplicaciones, que interactúan entre sí para presentar información dinámica al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al mismo tiempo sea posible su combinación para realizar operaciones complejas, es necesaria una arquitectura de referencia estándar.



La estructura interna de un servicio web se basa en los siguientes protocolos y normas: 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 disposición de los usuarios.

WDSL (Web Services Description Language): permite que los servicios web

describan cómo deben ser tratados por otras aplicaciones.

1.5.4. Otros.

Modelo cliente-servidor: Es el modelo más 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 también puede aplicarse a los ordenadores servidor o cliente, cuyo nombre se debe a que la ejecución de la mayoría de sus procesos son de tipo servidor o de tipo cliente.

Peer-to-peer: En el modelo cliente-servidor hay una clara diferenciación. El servidor ofrece a los clientes servicios y los clientes utilizan estos servicios. En sistemas P2P los procesos que participan en la comunicación realizan los mimos papeles: de cliente y de servidor. Este sistema está más asociado a lo que es la informática distribuida, ya que se olvida de la centralización y tiene un sistema más dinámico y descentralizado.



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 computación, mostrándose como un único sistema. En un cluster todos los ordenadores comparten los discos y los distintos ordenadores que lo forman están continuamente monitorizando para detectar posibles fallos de hardware. Si se detecta un fallo, se planifica el trabajo del nodo erróneo 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 homogéneo (misma arquitectura, SO...) o heterogéneo (distintos entornos, middlewares más 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 administración y por tanto están sujetos a diferentes políticos de uso y de administración. La primera mención, y su definición viene dada por Ian Foster: "Un sistema que coordina recursos, que no están sujetos a un control centralizado usando interfaces y protocolos estándares, abiertos y de propósito general para proveer de servicios relevantes".

Conclusión

Una arquitectura es un entramado de componentes funcionales que aprovechando diferentes estándares, convenciones, reglas y procesos, permite integrar una amplia gama de productos y servicios informáticos, de manera que pueden ser utilizados eficazmente dentro de la organización.

Referencias

Loger, A. (s.f.). Desarrollo de aplicaciones web. Obtenido de http://alog78503.blogspot.mx/2013/02/121-aplicaciones-de-23-y-n-capas_25.html

Vignaga, A. (s.f.). Universidad de la República, Facultad de Ingeniería. Obtenido de http://moodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/LP/AM/01/Arquitecturas_y_tecnologias_para_el_desarrollo_de_aplicaciones_web.pdf



unidad 1- contexto de la programacion cliente-servidor

Documents