MODELO CLIENTE - SERVIDOR
"Dentro de veinte años estarás más decepcionado por las cosas que no hiciste, que por las que hiciste. Así que suelta las amarras. Navega lejos del puerto seguro. Atrapa los vientos alisios en tus velas".
-Mark Twain
Objetivo:
Conocer el marco Corba
aplicado a los modelos
de Arquitectura
Empresarial con el fin de
comprender su
aplicación en los entornos
laborales
El modelo cliente-servidor es la arquitectura más citada cuando
se discuten los sistemas distribuidos. Es el modelo más
importante y sigue siendo el más ampliamente utilizado.
En particular, los procesos de cliente interactúan con los
procesos de servidor individuales en equipos anfitriones (host)
potencialmente separados, con el fin de acceder a los recursos
compartidos que administran.
PROXI
Es un servidor que se emplea como intermediario entre las
peticiones de recursos que realiza un cliente a otro servidor. Por
ejemplo, si una computadora A solicita un recurso a una
computadora C, lo hará mediante una petición a la
computadora B que, a su vez, trasladará la petición a la
computadora C. De esta manera, la computadora C no sabrá
que la petición procedió originalmente de la computadora A.
Esta situación estratégica de punto intermedio suele ser
aprovechada para soportar una serie de funcionalidades, como:
•Proporcionar caché.
•Control de acceso.
•Registro del tráfico.
•Prohibir cierto tipo de tráfico.
•Mejorar el rendimiento.
•Mantener el anonimato
El proxy más conocido es el servidor proxy web, su función
principal es interceptar la navegación de los clientes por
páginas web por motivos de seguridad, rendimiento,
anonimato, entre otros.
Clúster
En informática, el término clúster (“grupo” o “racimo”) hace
referencia a conjuntos o conglomerados de computadoras
construidos mediante el uso de hardware común y que se comportan
como si fueran una única computadora.
El uso de los clústeres varía desde las aplicaciones de
supercómputo, servidores web y comercio electrónico hasta el
software de misiones críticas y bases de datos de alto
rendimiento. El cómputo con clústeres es el resultado de la
convergencia de varias tendencias tecnológicas actuales, entre las
que se pueden destacar:
Los servicios esperados de un clúster principalmente son:
• Alto rendimiento.
• Alta disponibilidad.
• Escalabilidad.
• Balanceo de carga.
Típicamente respecto a la rapidez y
disponibilidad, se espera que un clúster sea más
económico que el uso de computadoras
individuales.
Un clúster puede ser:
• Homogéneo.
• Semihomogéneo.
• Heterogéneo
Un clúster es homogéneo cuando todas las
computadoras tienen la misma configuración en
hardware y sistema operativo.
Es semihomogéneo cuando las computadoras
tienen diferente rendimiento pero guardan una
similitud con respecto a su arquitectura y sistema
operativo. Finalmente, un clúster es heterogéneo
cuando las computadoras tienen diferente hardware
y sistema operativo.
Grid
El cómputo grid es un paradigma del cómputo distribuido,
frecuentemente usado para indicar una infraestructura de gestión
de recursos distribuidos que se centra en el acceso coordinado a
los recursos informáticos remotos. Estos recursos de cómputo son
colectados desde múltiples localizaciones para alcanzar una
meta común. A diferencia del cómputo de cluster (en grupo o
racimo), el cómputo grid tiende a ser más heterogéneo y disperso
geográficamente. Generalmente las grids son usadas para una
variedad de propósitos, pero puede haber grids especializadas para
fines específicos.
Beneficios del cómputo grid :
• Explotación de recursos infrautilizados.
• Capacidad de CPU paralelos.
• Recursos virtuales y organizaciones virtuales para la colaboración.
• Acceso a recursos adicionales.
• Balanceo de recursos.
• Fiabilidad.
• Mejor gestión de infraestructuras de TI más grandes y distribuidos.
CORBA
CORBA es una arquitectura de comunicaciones que soporta la
construcción e integración de tecnologías de diferente fabricante
independientemente del tiempo de creación, así como pueden
intercambiar información personas que dominan diferente idioma, sin
importar que no sea usado actualmente.
El paradigma orientado a objetos juega un importante rol en el
desarrollo de software y cuenta con gran popularidad desde su
introducción. La orientación a objetos se comenzó a utilizar para el
desarrollo de sistemas distribuidos en la década de 1980. El Grupo de
Gestión de Objetos (OMG-Object Management Group) se creó en
1989 como una asociación de las empresas líderes de la tecnología
software para definir especificaciones que puedan ser
implementadas por ellas y que faciliten la interoperabilidad de sus
productos.
Los middlewares basados en objetos distribuidos están diseñados para
proporcionar un modelo de programación basado en principios
orientados a objetos y, por tanto, para llevar los beneficios del enfoque
a objetos para la programación distribuida. Los principales ejemplos de
middleware basados en objetos distribuidos incluyen Java RMI y CORBA.
Es usado en Distintos sistemas operativos (Unix, Windows, MacOS,
OS/2), Distintos protocolos de comunicación (TCP/IP, IPX),
Distintos lenguajes de programación (Java, C, C++), Distinto hardware.
Para construir componentes que utilicen el entorno CORBA se
deben seguir los siguientes pasos:
1. Definir la interfaz remota. Se define, en primer lugar, la interfaz
del objeto remoto en IDL. Dicha interfaz permitirá generar, de
manera automática, el código fuente del stub y el skeleton así
como todo el código necesario para comunicarse con el ORB.
Si sólo se implementa el cliente porque el servidor ya existe, se
tendría que proporcionar el fichero IDL correspondiente a la
interfaz que expone el servidor.
2.Compilar la interfaz remota. El compilador genera todo el código
fuente
mencionado en el paso anterior.
3.Implementar el servidor. A partir de los esqueletos
que genera el compilador idl es sencillo implementar
el servidor. Además de los métodos que implementan
la interfaz remota, el código del servidor crea un
mecanismo para arrancar el ORB y esperar por la
invocación de un cliente.
4.Implementar el cliente. De una manera similar al servidor, el
cliente hace uso de los stubs generados en el paso 2. El cliente se
basa en el stub para arrancar su ORB, encontrar el servidor
utilizando el servicio de nombrado, obtener una referencia al
objeto remoto e invocar sus métodos.
5. Arrancar los programas. Una vez está todo implementado, se
arranca el servicio
de nombrado, el servidor y finalmente, el cliente
Características fundamentales
de la Arquitectura CORBA
1 Objetos CORBA
Las implementaciones de los objetos reciben las invocaciones
como llamadas hacia arriba (up-call), desde el ORB hacia la
Implementación de la interfaz. La implementación de la interfaz
puede elegir un adaptador de objetos entre un conjunto de ellos,
una decisión que estará basada en la clase de servicios que pueda
requerir dicha implementación
Los objetos CORBA se diferencian de los objetos de los lenguajes
habituales de programación en que:
• Pueden estar localizados en cualquier lugar de la red.
• Pueden ejecutarse en cualquier plataforma de hardware y
de sistema operativo.
• Pueden estar escritos en cualquier lenguaje.
• Pueden tener la capacidad de detectar el entorno, procesar
información y además tienen la capacidad de comunicación.
2. ORB object requestbróker
Componente que permite que clientes y objetos puedan
comunicarse en un ambiente distribuido. Y que contempla cada
una de las interfaces que el ORB manipula. El bus de objetos es
el intermediario entre clientes y servidores que transmite las
peticiones cliente- servidor y las respuestas servidor-cliente. Se
necesita un ORB en cada máquina. El ORB soporta cuatro tipos
de interfaces de objetos.
Object Services: Son interfaces para servicios generales.
Son usadas en cualquier programa basado en objetos distribuidos.
Common Facilities: Son interfaces orientadas al usuario final y que se
programan por la aplicación específica.
Domain Interfaces: Son interfaces de dominio específico para las
aplicaciones.
Application Interfaces: Este tipo de interfaz acepta interfaces
que no sean estandarizadas y se utilizan en aplicaciones
específicas.
4. IDL (Interface Definition Language)
Para poder especificar los servicios que ofrecen los objetos
que forman parte de un sistema abierto y distribuido, se
necesita contar con algún lenguaje preciso, bien definido,
e independiente de cualquier posible representación de los
datos o estructuras que él define, así como la futura
implementación de los objetos que especifica. La norma
ISO/IEC 14750 (ITUT X.920) define dicho lenguaje, al que se
conoce como lenguaje de definición de interfaces de
ODP, o ODP IDL por su acrónimo en inglés. Su principal
objetivo es describir la signatura de los objetos que
especifica, en términos de las estructuras de datos que se
manejan y el perfil de las operaciones que definen sus
servicios. De esta forma se consigue la ocultación
necesaria para el desarrollo de aplicaciones abiertas10.
5. Stub
Es el intermediario entre el cliente y el ORB. El Stub recoge del
cliente llamadas a métodos y las transmite al ORB. Se requiere
una clase de stub por cada clase remota.
Además, es un componente que actúa como servidor,
puede estar ejecutándose en cualquier máquina conectada a la
red que recibe peticiones por parte de los clientes que pueden ser
locales o remotos. Indistintamente de ello, el cliente siempre
tendrá la ilusión de que la llamada se ejecuta localmente. En
otras palabras el stub logra que el programador no se ocupe de las
instrucciones de programación remotas ya que son objetos que
residen en el cliente y que representan objetos remotos instalados
en un servidor. En él se identifica: Host, puerto e identificador del
objeto
6. Esqueleto: Es el intermediario entre ORB y los objetos del
servidor. Recibe llamadas del ORB y ejecuta los
métodos correspondientes en el servidor sobre
el objeto que corresponda. Cuando el cliente
establece un objeto local (con servicio remoto), la
petición se realiza por intermedio del protocolo de
comunicaciones IIOP a través del ORB. El servidor
recibe la petición, busca el objeto definido
(compara el esqueleto del método en el módulo
esqueleto) lo ejecuta y retorna la respuesta al
cliente.
Comunicación transitoria
orientada a mensajes
Tiempo de desempeño
Además, la ejecución asíncrona permite que los procesos controlen la
gestión y terminación de tarea y que el cliente pueda finalizar o continuar
haciendo otras cosa en su sistema, por otro lado se reduce el tráfico en la red y
la capacidad de cómputo del cliente
Movilidad
Reducción de la dependencia de la disponibilidad de la red y del
cliente/servidor. Los procesos migrados al sistema servidor no se ven afectados
por los fallos del cliente o de la red. Los procesos se ejecutan realizando tareas
específicas en lugares diferentes.
Automatización de las tareas distribuidas.
El problema fundamental de los sistemas de integración es el software. Aún
no existe mucha experiencia en el diseño, implantación y uso de
software como CORBA. Precisamente, éste es un campo de investigación
actual. Las redes son indispensables para la comunicación entre máquinas; sin
embargo, pueden plantear problemas de saturación, embotellamiento,
interrupción o pérdidas de mensajes. El posible acceso a todo el sistema por
parte de los usuarios plantea el inconveniente de la necesidad de un sistema
de seguridad adecuado y estándar, aunque CORBA maneja la seguridad.
Comentarios
Publicar un comentario