Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Contexto de La Programacion Cliente
Contexto de La Programacion Cliente
ORIZABA
MATERIA
Programación en ambiente cliente/servidor
PRESENTA
DOCENTE
Pelaez Camarena Silvestre Gustavo
CARRERA
INGENERIA INFORMATICA
10° SEMESTRE
1.1 Arquitectura del modelo 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.
Transparencia.
Independencia.
Protocolos asimétricos.
Recursos compartidos.
Servicio.
Encapsulamiento.
Integridad.
Acoplamiento débil.
Escalabilidad.
De lo dicho hasta ahora, podemos deducir que los principales elementos que
conforman la arquitectura cliente/servidor son los siguientes:
El servidor
El cliente
Igual 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.
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.
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.
El funcionamiento básico
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.
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
En los sistemas cliente servidor de dos capas, la lógica de la aplicación esta dentro
de la interfaz de usuario en el cliente o dentro de la base de datos en el servidor (o
en los dos lugares).
Tres capas es un concepto recargado, se empleo por primera vez para describir la
división f’ísica de una aplicación entre computadoras personales (primera capa),
servidores departamentales (segunda capa) y servidores empresariales tercera
capa). Después se utilizó para describir una división entre cliente (primera capa),
base de datos local (segunda capa) y base de datos empresarial (tercera capa). Hoy
en día la definición en boga es cliente (primera capa), servidor de aplicaciones
(segunda capa) y servidor de base de datos (tercera capa).
Características:
3 capas
Características:
Algunos servidores esperan las solicitudes en puertos bien conocidos de modo que
sus clientes saben a qué zócalo IP deben dirigir sus peticiones. El cliente emplea
un puerto arbitrario para comunicarse. Los clientes que se quieren comunicar con
un servidor que no usa un puerto bien conocido tienen otro mecanismo para saber
a qué puerto dirigirse. Este mecanismo podría usar un servicio de registro como
Portmap, que utiliza un puerto bien conocido.
Usted es quien toma las decisiones difíciles en el nuevo orden mundial. Para triunfar
debe elegir la plataforma cliente/servidor correcto, lo mismo que las herramientas,
fabricantes y arquitectura básica. Es necesario que identifique y se suba en la ola
correcta de la tecnología cliente/servidor. Si esa ola en los objetos distribuidos no
tiene sentido perder tiempo y energía en escribir procedimientos almacenados para
servidores en base de datos. Por eso es importante saber con exactitud que puede
hacer la tecnología por usted en un instante determinado.
Los usuarios invocan la parte cliente de la aplicación, que construye una solicitud
para ese servicio y se la envía al servidor de la aplicación que usa TCP/IP como
transporte.
En esta arquitectura la capacidad de proceso está repartida entre los clientes y los
servidores, aunque son más importantes las ventajas de tipo organizativo debidas
a la centralización de la gestión de la información y la separación de
responsabilidades, lo que facilita y clarifica el diseño del sistema.
La separación entre cliente y servidor es una separación de tipo lógico, donde el
servidor no se ejecuta necesariamente sobre una sola máquina ni es
necesariamente un sólo programa.
La idea es tratar a una computadora como un instrumento, que por sí sola pueda
realizar muchas tareas, pero con la consideración de que realice aquellas que son
más adecuadas a sus características [15]. Si esto se aplica tanto a clientes como
servidores se entiende que la forma más estándar de aplicación y uso de sistemas
Cliente/Servidor es mediante la explotación de las PC’s a través de interfaces
gráficas de usuario; mientras que la administración de datos y su seguridad e
integridad se deja a cargo de computadoras centrales tipo mainframe. Usualmente
la mayoría del trabajo pesado se hace en el proceso llamado servidor y el o los
procesos cliente sólo se ocupan de la interacción con el usuario (aunque esto puede
variar). En otras palabras, la arquitectura Cliente/Servidor es una extensión de
programación modular en la que la base fundamental es separar una gran pieza de
software en módulos con el fin de hacer más fácil el desarrollo y mejorar su
mantenimiento.
Esta arquitectura permite distribuir físicamente los procesos y los datos en forma
más eficiente lo que en computación distribuida afecta directamente el tráfico de la
red, reduciéndolo grandemente.
Cliente
Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes
puntos:
Servidor
Es el proceso encargado de atender a múltiples clientes que hacen peticiones de
algún recurso administrado por él. Al proceso servidor se le conoce con el término
back-end [15].
Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes
puntos:
También se conoce como aplicaciones de dos capas es aquella donde los datos y
la lógica del negocio se encuentran separados de la interfaz, este tipo de
aplicaciones también es llamado cliente servidor.
Otro escenario válido para una aplicación cliente/servidor se da separando los datos
de la interfaz y la lógica del negocio, este tipo de aplicación también se conoce como
cliente pesado.
1.4 Comunicaciones entre programas
El proceso para la creación de un servicio siempre comienza con la creación del
Socket. Así como el cliente necesita llamadas especificas 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 servido 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 de
isistemas() 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 servidor trata los datos como datos ASCII y los convierte en mayúsculas antes
de pasárselos al 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 utilizan fork para
crear un proceso separado para la administración de peticiones de servicio
constitucionalmente caras.
Server.c 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.
El resto de los colectivos no pueden afrontar el costo económico que supone adquirir
una máquina de estas características, y aquí es donde toma la máxima importancia
la idea de
poder disponer de esa potencia de cálculo, pero a un precio muy inferior. El
concepto de cluster nació cuando los pioneros de la súper computación intentaban
difundir diferentes procesos entre varias computadoras, para luego poder recoger
los resultados que dichos procesos debían producir. Con un hardware más
asequible, se pudo perfilar que podrían conseguirse resultados muy parecidos a los
obtenidos con aquellas máquinas mucho más costosas, como se ha venido
probando desde entonces.
Grid.
Globus.
XML.
Los servicios Web basados en XML, ofrecen una forma de acceder a diversos
servicios en un entorno distribuido. Recientemente, el mundo de la informática en
grid y los servicios Web caminan juntos para ofrecer el grid como un servicio Web.
La arquitectura está definida por la Open Grid Services Architecture (OGSA). La
versión 3.0 de Globus Toolkit, será una implementación de referencia acorde con el
estándar OGSA.
Clustering.
Aspectos de seguridad.
1.5.1 RMI
RMI (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 CORBAo 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 (Garbage Collector
distribuido) 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:
1.5.2 COM/DCOM
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 detales muy bajos de protocolos de red, por lo que uno se puede
centrar en la realidad de los negocios: proporcionar soluciones a clientes.
Atualmente DCOM viene con los sistemas operativos Windows 2000, NT, 98 y
también está disponible una versión para Windows 95 en la página de Microsoft.
También hay una implementación de DCOM para Apple Macintosh y se está
trabajando en implementaciones para plataformas UNIX como Solaris.
La arquitectura DCOM
DCOM es una extensión de COM, y éste define como los componentes y sus
clientes interactuan entre sí. Esta interacción es definida de tal manera que el cliente
y el componente puede 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
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.
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.
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.
Los Componentes y su reutilización
Muchas aplicaciones distribuidas no están desarrolladas
Al existir infraestructuras de hardware, software, componentes, al igual
que herramientas, se necesita poder integrarlas y nivelarlas para reducir el
desarrollo y el tiempo de trabajo y coste. DCOM toma ventaja de forma directa y
transparente de los componentes COM y herramientas ya existentes. Un gran
mercado de todos los componentes disponibles haría posible reducir el tiempo de
desarrollo integrando soluciones estandarizadas en las aplicaciones de usuario.
Muchos desarrolladores están familiarizados con COM y pueden aplicar fácilmente
sus conocimientos a las aplicaciones distribuidas basadas en DCOM.
Cualquier componente que sea desarrollado como una parte de una aplicación
distribuida es un candidato para ser reutilizado. Organizando los procesos de
desarrollo alrededor del paradigma de los componentes permite continuar
aumentando el nivel de funcionalidad en las nuevas aplicaciones y reducir el tiempo
de desarrollo.
Diseñando para COM y DCOM se asegura que los componentes creados serán
útiles ahora y en el futuro.
Independencia de la localización
Cuando se comienza a implementar una aplicación distribuida en una red reak,
aparecen distintos conflictos en el diseño:
Los componentes que interactuan más a menudo deberían estar localizados más
cerca.
Algunos componentes solo pueden ser ejecutados en máquinas específicas o
lugares específicos.
Los componentes más pequeños aumentan la flexibilidad, pero aumentan el tráfico
de red.
Los componentes grandes reducen el tráfico de red, pero también reducen la
flexibilidad.
Con DCOM, estos temas críticos de diseño pueden ser tratados se forma bastante
sencilla, ya que estos detalles no se especifican en el código fuente. DCOM olvida
completamente la localización de los componentes, ya esté en el mismo proceso
que el cliente o en una máquina en cualquier lugar del mundo. En cualquier caso, la
forma en la que el cliente se conecta a un componente y llama a los métodos de
éste es identica. No es solo que DCOM no necesite cambios en el código fuente,
sino que además no necesita que el programa sea recompilado. Una simple
reconfiguración cambia la forma en la que los componentes se conectan entre sí.
La independencia de localización en DCOM simplifica enormemente las tarea de los
componentes de aplicaciones distribuidas para alcanzar un nivel de funcionamiento
óptimo. Supongamos, por ejemplo, que cierto componente debe ser localizado en
una máquina específica en un lugar determinado. Si la aplicación tiene numerosos
componentes pequeños, se puede reducir la carga de la red situándolos en la misma
LAN, en la misma máquina, o incluso en el mismo proceso. Si la aplicación está
compuesta por un pequeño número de grandes componentes, la carga de red es
menor y no es un problema, por tanto se pueden poner en las máquinas más rápidas
disponibles independientemente de donde esten situadas.
Con la independencia de localización de DCOM, la aplicación puede combinar
componentes relacionados en máquinas "cercanas" entre si, en una sola máquina
o incluso en el mismo proceso. Incluso si un gran número de pequeños
componentes implementan la funcionalidad de un gran módulo lógico, podrán
interactuar eficientemente entre ellos.
Independencia del lenguaje de programación
Una cuestión importante durante el diseño e implementación de una aplicación
distribuida es la elección del lenguaje o herramienta de programación. La elección
es generalmente un termino medio entre el coste de desarrollo, la experiencia
disponible y la funcionalidad. Como una extensión de COM, DCOM es
completamente independiente del lenguaje. Virtualmentem cualquier lenguaje
puede ser utilizado para crear componentes COM, y estos componentes puede ser
utilizado por muchos más lenguajes y herramientas. Java, Microsoft Visual C++,
Microsoft Visual Basic, Delphi, PowerBuilder, y Micro Focus COBOL interactuan
perfectamente con DCOM.
Con la independencia de lenguaje de DCOM, los desarrolladores de aplicaciones
puede elegir las herramientas y lenguajes con los que estén más familiarizados. La
independencia del lenguaje permite crear componentes en lenguajes de nivel
superior como Microsoft Visual Basic, y después reimplementarlos en distintos
lenguajes como C++ o Java, que permiten tomar ventaja de características
avanzadas como multihilo.
Un servicio web (en inglés, Web Service o Web services) es una tecnología que
utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos
entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de
programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar
los servicios web para intercambiar datos en redes de ordenadores como Internet.
La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las
organizaciones OASIS y W3C son los comités responsables de la arquitectura y
reglamentación de los servicios Web. Para mejorar la interoperabilidad entre
distintas implementaciones de servicios Web se ha creado el organismo WS-I,
encargado de desarrollar diversos perfiles para definir de manera más exhaustiva
estos estándares. Es una máquina que atiende las peticiones de los clientes web y
les envía los recursos solicitados.
Arquitectura
Estándares empleados
La principal razón para usar servicios Web es que se pueden utilizar con HTTP
sobre Transmission Control Protocol (TCP) en el puerto de red 80. Dado que las
organizaciones protegen sus redes mediante firewalls (que filtran y bloquean gran
parte del tráfico de Internet), cierran casi todos los puertos TCP salvo el 80, que es,
precisamente, el que usan los navegadores web. Los servicios Web utilizan este
puerto, por la simple razón de que no resultan bloqueados. Es importante señalar
que los servicios web se pueden utilizar sobre cualquier protocolo, sin embargo,
TCP es el más común.
Otra razón es que, antes de que existiera SOAP, no había buenas interfaces para
acceder a las funcionalidades de otras computadoras en red. Las que había eran
ad hoc y poco conocidas, tales como Electronic Data Interchange (EDI), Remote
Procedure Call (RPC), u otras API.
Una tercera razón por la que los servicios Web son muy prácticos es que pueden
aportar gran independencia entre la aplicación que usa el servicio Web y el propio
servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar
al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a
construir grandes aplicaciones a partir de componentes distribuidos más pequeños
es cada día más utilizada.
Se espera que para los próximos años mejoren la calidad y cantidad de servicios
ofrecidos basados en los nuevos estándares.
Plataformas
1.5.4 Otros
Corba