Identifica los tipos de redes, protocolos y modelos, empleados en la interconexión de sistemas distribuidos.
Qué son los sistemas distribuidos
Los
sistemas computacionales están experimentando una revolución. De 1945, cuando
comenzó la era moderna de las computadoras, a 1985, éstas eran grandes y caras.
Incluso las minicomputadoras costaban al menos decenas de miles de dólares. Como
resultado, muchas empresas tenían solamente unas cuantas, y debido a la falta
de un medio de conexión entre ellas, operaban de manera independiente.
Sin
embargo, hacia la mitad de la década de 1980, dos avances en la tecnología
comenzaron a cambiar esa situación. El primero de estos avances fue el
desarrollo de poderosos microprocesadores. Inicialmente, los microprocesadores
eran máquinas de 8 bits, pero pronto se hicieron comunes las CPU de 16, 32 y 64
bits. Muchas de ellas tenían el poder de una mainframe (es decir, una
computadora grande), pero a una fracción de su precio. El resultado de estas
tecnologías es que ahora no solamente es factible, sino fácil, poner a trabajar
sistemas de cómputo compuestos por grandes cantidades de computadoras interconectadas
mediante una red de alta velocidad. Por lo general, a estos sistemas se les
conoce como redes de computadoras o sistemas distribuidos, al contrario de los
sistemas centralizados (o sistemas de un solo procesador) que por lo general
constan de una sola computadora, sus periféricos, y quizás algunas terminales
remotas.
Un sistema distribuido
es una colección de computadoras independientes que
dan al usuario la
impresión de constituir un único sistema coherente.
Esta
definición comprende diversos aspectos importantes. En primer lugar, tenemos
que un sistema distribuido consta de componentes (es decir, computadoras)
autónomos. El segundo aspecto es que los usuarios (personas o programas) creen
que realmente interactúan con un sistema único. Esto significa que de una
manera o de otra los componentes autónomos necesitan colaborar entre sí. La
forma de establecer la colaboración radica en el fondo del desarrollo de los
sistemas distribuidos. Observe que no hacemos suposiciones con respecto al tipo
de computadoras. En principio, incluso con un sistema individual, éstas podrían
componerse de computadoras mainframe de alto rendimiento o de pequeños
nodos ubicados dentro de redes de sensores.
En resumen,
los sistemas distribuidos consisten en computadoras autónomas que trabajan
juntas para dar la apariencia de un solo sistema coherente. Una ventaja
importante es que facilitan la integración de diferentes aplicaciones que se
ejecutan en distintas computadoras conectadas en un solo sistema. Por lo general, los sistemas
distribuidos son complejas piezas de software cuyos componentes se encuentran, por definición,
dispersos en diversas máquinas. Para dominar esta complejidad, resulta crucial que los sistemas se
encuentren organizados adecuadamente. Existen diferentes formas de visualizar
la organización de un sistema distribuido, pero un modo evidente es saber
diferenciar la organización lógica de la colección de componentes del software
de la organización física real.
La organización de los sistemas
distribuidos trata básicamente sobre los componentes de software que
constituyen el sistema. Estas arquitecturas de software nos dicen cómo se
organizarán los componentes de software, y cómo deben interactuar. En este
capítulo veremos primero algunos métodos aplicados comúnmente para organizar
sistemas (distribuidos) de cómputo. La organización real de un sistema
distribuido requiere que generemos las instancias y coloquemos los componentes
del software en máquinas reales. Existen diferentes alternativas para hacer esto.
La creación de instancias finales de una arquitectura de software también se
conoce como arquitectura de sistema. En este capítulo veremos arquitecturas
centralizadas tradicionales en las que un solo servidor implementa la mayoría
de los componentes de software (y, por tanto, la funcionalidad), mientras que
los clientes remotos pueden acceder a ese servidor utilizando medios de comunicación simples. Además,
consideraremos arquitecturas descentralizadas en las que las máquinas
desempeñan roles casi iguales, así como organizaciones híbridas.
Cómo funciona el Internet?
Cuando accedemos a internet a través
de un explorador, lo primero que nos muestra es una página llamada (inicio),
configurada en primera instancia por el navegador con el que trabajamos. Sin
embargo, como es posible que podamos ver en la pantalla de nuestra computadora
esa página? De donde salió? Donde se encuentra almacenada? Tiene algún nombre
en especial? Todas estas preguntas tienen una explicación racional y
tecnológica. Sucede que cuando nosotros accedemos a cualquier página web en la
Internet, se nos permite visualizar en nuestra computadora el contenido de un
documento codificado en lenguaje html (común mente). Pero como es que nuestra
computadora
logra mantener una comunicación entendible con las demás? Existen reglas que
nos ayuden en esta comunicación? Cuales serían esas reglas? Para solucionar
esto existen lo protocolos.
Un protocolo es un método estándar que permite la comunicación entre procesos
(que potencialmente se ejecutan en diferentes equipos), es decir, es un
conjunto de reglas y procedimientos que deben respetarse para el envío y la recepción
de datos a través de una red.
Para poder
establecer esta comunicación en la red, existe un modelo que gobierna esto, es
el modelo de red OSI
Mediante estas capas, las computadoras logran conectarse a la red y
acceder a la información ahí contenida. Cada computadora de la red se comunica
bajo la misma regla en cada capa.
Identificación
de protocolos.
Existen diversos protocolos de acuerdo a cómo se espera que sea la
comunicación. Algunos protocolos, por
ejemplo, se especializarán en el
intercambio de archivos (FTP); otros pueden utilizarse simplemente para
administrar el estado de la transmisión y los errores (como es el caso de ICMP), etc. En internet los
protocolos utilizados pertenecen a una sucesión de protocolos o a un conjunto
de protocolos relacionados entre sí. Este conjunto de protocolos se denomina
TCP/IP.
- IP: Protocolo de internet
- 2 TCP: Protocolo de control
- 3 HTTP: Protocolo de transferencia de hipertexto
- 4 SMTP: Protocolo de transferencia de correo simple
- 5 POP3: Protocolo de oficina de correo
- 6 Otros
Protocolo TCP/IP
Toda la información que trafica por la red, esta contralada por este
conjunto de protocolos, que al trabajar juntos, evitan la saturación del
tráfico en la red. Cuando un mensaje es enviado
(datos), de una computadora a otra, este mensaje no puede viajar de
forma “entera” por la red; el protocolo TCP divide este mensaje en secciones
(paquetes) y cada paquete puede tomar una ruta diferente hasta llegar a su
destino. Ahora bien, como es que los paquetes saben a dónde llegar? Para eso
existe el protocolo IP, así como cada ser humano tiene un nombre que nos
identifica, cada dispositivo electrónico de la red, tiene una dirección única
que lo identifica, su dirección IP. Cuando el protocolo TCP divide cada
paquete, IP se encarga de asignarle una dirección de destino a cada paquete, al
llegar al destino, TCP ordena los paquetes de la forma correcta para que el
mensaje pueda ser entregado de forma satisfactoria.
Protocolo HTTP
El Protocolo de Transferencia de HiperTexto (Hypertext Transfer
Protocol) es un sencillo protocolo cliente-servidor que articula los
intercambios de información entre los clientes Web y los servidores HTTP. La
especificación completa del protocolo HTTP 1/0 está recogida en el RFC 1945.
Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema
global de distribución de información como el World Wide Web.
Desde el
punto de vista de las comunicaciones, está soportado sobre los servicios de
conexión TCP/IP, y funciona de la misma forma que el resto de los servicios
comunes de los entornos UNIX: un proceso servidor escucha en un puerto de
comunicaciones TCP (por defecto, el 80), y espera las solicitudes de conexión
de los clientes Web. Una vez que se establece la conexión, el protocolo TCP se
encarga de mantener la comunicación y garantizar un intercambio de datos libre
de errores.
HTTP se
basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una
conexión con un servidor y envía un mensaje con los datos de la solicitud. El
servidor responde con un mensaje similar, que contiene el estado de la
operación y su posible resultado. Todas las operaciones pueden adjuntar un
objeto o recurso sobre el que actúan; cada objeto Web (documento HTML, fichero
multimedia o aplicación CGI) es conocido por su URL.
Etapas de una transacción HTTP.
Para profundizar más en el
funcionamiento de HTTP, veremos primero un caso particular de una transacción
HTTP; en los siguientes apartados se analizarán las diferentes partes de este
proceso.
Cada vez
que un cliente realiza una petición a un servidor, se ejecutan los siguientes
pasos:
- Un usuario accede a una URL, seleccionando un
enlace de un documento HTML o introduciéndola directamente en el campo
Location del cliente Web.
- El cliente Web descodifica la URL, separando sus
diferentes partes. Así identifica el protocolo de acceso, la dirección DNS
o IP del servidor, el posible puerto opcional (el valor por defecto es 80)
y el objeto requerido del servidor.
- Se abre una conexión TCP/IP con el servidor,
llamando al puerto TCP correspondiente.
Se realiza la petición. Para ello, se envía el comando necesario (GET, POST, HEAD,…), la dirección del objeto requerido (el contenido de la URL que sigue a la dirección del servidor), la versión del protocolo HTTP empleada (casi siempre HTTP/1.0) y un conjunto variable de información, que incluye datos sobre las capacidades del browser, datos opcionales para el servidor,… - El servidor devuelve la respuesta al cliente.
Consiste en un código de estado y el tipo de dato MIME de la información
de retorno, seguido de la propia información.
Se cierra
la conexión TCP.
Este
proceso se repite en cada acceso al servidor HTTP. Por ejemplo, si se recoge un
documento HTML en cuyo interior están insertadas cuatro imágenes, el proceso
anterior se repite cinco veces, una para el documento HTML y cuatro para las
imágenes.
SMTP
El protocolo SMTP (Protocolo simple de
transferencia de correo) es el protocolo estándar que permite la
transferencia de correo de un servidor
a otro mediante una conexión punto a punto. Este protocolo permite
crear una conexión directa con el servidor que almacena la información.
Éste es un
protocolo que funciona en línea, encapsulado en una trama TCP/IP. El correo se
envía directamente al servidor de correo del destinatario. El protocolo SMTP
funciona con comandos de textos enviados
al servidor SMTP (al puerto 25 de manera predeterminada). A cada comando
enviado por el cliente (validado por la cadena de caracteres ASCII CR/LF, que equivale a presionar la tecla Enter) le
sigue una respuesta del servidor SMTP compuesta por un número y un mensaje
descriptivo.
A
continuación se describe una situación en la que se realiza una solicitud para
enviar correos a un servidor SMTP:
1.
Al
abrir la sesión SMTP, el primer comando que se envía es el comando HELO seguido por un espacio (escrito <SP>) y el nombre de
dominio de su equipo (para decir "hola, soy este equipo"), y después
validado por Enter (escrito <CRLF>).
Desde abril de 2001, las especificaciones para el protocolo SMTP, definidas en RFC 2821, indican que el comando HELO sea
remplazado por el comando EHLO.
2.
El
segundo comando es "MAIL FROM:" seguido de la dirección de
correo electrónico del remitente. Si se acepta el comando, el servidor responde
con un mensaje "250 OK".
3.
El
siguiente comando es "RCPT TO:" seguido de la dirección de
correo electrónico del destinatario. Si se acepta el comando, el servidor
responde con un mensaje "250 OK".
4.
El
comando DATA es la tercera etapa para enviar un
correo electrónico. Anuncia el comienzo del cuerpo del mensaje. Si se acepta el
comando, el servidor responde con un mensaje intermediario numerado 354 que indica que puede iniciarse el
envío del cuerpo del mensaje y considera el conjunto de líneas siguientes hasta
el final del mensaje indicado con una línea que contiene sólo un punto. El
cuerpo del correo electrónico eventualmente contenga algunos de los siguientes
encabezados:
· Date (Fecha)
· Subject (Asunto)
· Cc
· Bcc (Cco)
· From (De)
El protocolo POP3
El protocolo
POP (Protocolo de oficina de correos), como
su nombre lo indica, permite recoger
el correo electrónico en un servidor remoto (servidor POP). Es
necesario para las personas que no están permanentemente conectadas a Internet,
ya que así pueden consultar sus correos electrónicos recibidos sin que ellos
estén conectados.
Existen dos
versiones principales de este protocolo, POP2 y POP3, a los que se le asignan
los puertos 109 y 110 respectivamente, y que
funcionan utilizando comandos de texto radicalmente diferentes. Al
igual que con el protocolo SMTP, el protocolo POP (POP2 y POP3) funciona con
comandos de texto enviados al servidor POP. Cada uno de estos comandos enviados
por el cliente (validados por la cadena CR/LF) está compuesto por una palabra
clave, posiblemente acompañada por uno o varios argumentos, y está seguido por
una respuesta del servidor POP compuesta por un número y un mensaje descriptivo.
El
Protocolo de oficina de correo 3 (POP3, <i>Post Office Protocol
3</i>) es un protocolo estándar para recuperar correo electrónico. El
protocolo POP3 controla la conexión entre un cliente de correo electrónico POP3
y un servidor donde se almacena el correo electrónico. El servicio POP3 emplea
el protocolo POP3 para recuperar el correo electrónico desde un servidor de
correo a un cliente de correo electrónico POP3.
El
protocolo POP3 tiene tres estados de proceso para controlar la conexión entre
el servidor de correo y el cliente de correo electrónico POP3: el estado de
autenticación, el estado de transacción y el estado de actualización.
Durante el
estado de autenticación, el cliente de correo electrónico POP3 conectado al
servidor debe autenticarse para que los usuarios puedan recuperar su correo
electrónico. Si el nombre de usuario y la contraseña suministrados por el
cliente de correo electrónico coinciden con los del servidor, el usuario se
autenticará y se pasará al estado de transacción. En caso contrario, se
mostrará al usuario un mensaje de error y no se permitirá la conexión para
recuperar correo electrónico.
Para impedir
daños en el almacén de correo una vez que se ha autenticado al cliente, el
servicio POP3 bloquea el buzón del usuario. El nuevo correo electrónico
entregado en el buzón después de la autenticación del usuario (y del bloqueo
del buzón) no estará disponible para su descarga hasta que la conexión haya
finalizado. Asimismo, sólo se puede conectar un cliente a un buzón cada vez y
se rechazan las solicitudes adicionales de conexión al buzón.
Durante el
estado de transacción, el cliente envía comandos POP3 que el servidor recibe y
responde de acuerdo con el protocolo POP3. Se omitirán todas las solicitudes de
cliente recibidas por el servidor que no sean compatibles con el protocolo POP3
y se devolverá un mensaje de error.
El estado
de actualización cierra la conexión entre el cliente y el servidor. Éste es el
último comando que transmite el cliente.
Tras el
cierre de la conexión, el almacén de correo se actualiza para reflejar los
cambios realizados mientras el usuario estaba conectado al servidor de correo.
Por ejemplo, una vez que el usuario ha recuperado correctamente el correo
electrónico, éste se marca para su eliminación y se elimina del almacén de
correo, a menos que en la configuración del cliente de correo del usuario se
especifique lo contrario.
La idea básica para el estilo en capas es sencilla: los componentes se estructuran (organizan) a modo de capas, donde al componente de la capa Li se le permite llamar a componentes de la capa subyacente Li_1, pero no del resto de capas, como ilustra la figura.
Este estilo se ha adoptado ampliamente en la comunidad de redes, y lo revisaremos brevemente en el capítulo 4. Una observación clave es que el control generalmente fluye de capa a capa: las peticiones se mueven hacia abajo en la jerarquía mientras que los resultados se mueven hacia arriba. La división de aplicaciones en capas, normalmente está compuesta por tres elementos:
1. Interfaz de usuario
2. Gestión del procesamiento
3. Gestión de la base de datos
La arquitectura clente/servidor tradicional es una solución de 2 capas. La arquitectura de 2 capas consta de tres componentes distribuidos en dos capas: cliente (solicitante de servicios) y servidor (proveedor de servicios).
Las capas que esta arquitectura presenta son las siguientes:
• Nivel de aplicación este nivel es en el que se encuentra toda la interfaz del sistema y es la que el usuario puede disponer para realizar su actividad con el sistema.
• Nivel de la base de datos. Este nivel de la base de datos también llamado el repositorio de datos, es la capa en donde se almacena toda la información ingresada en el sistema y que se deposita en forma permanente. Existen herramientas para el desarrollo en dos capas por ejemplo visual basic, access y sql.
Hay 2 tipos de arquitecturas cliente servidor de dos capas:
- Clientes obesos (thick clients): La mayor parte de la lógica de la aplicación (gestión del procesamiento) reside junto a la lógica de la presentación (interfaz de usuario) en el cliente, con la porción de acceso a datos en el servidor.
- Clientes delgados (thin clients): solo la lógica de la presentación reside en el cliente, con el acceso a datos y la mayoría de la lógica de la aplicación en el servidor.
La arquitectura de 3 capas es usada cuando se necesita un diseño cliente/servidor que proporcione, en comparación con la arquitectura de 2 capas, incrementar el rendimiento, flexibilidad, mantenibilidad, reusabilidad y escalabilidad mientras se esconde la complejidad del procesamiento distribuido al usuario.
Capa de presentación: Presenta el sistema al usuario, comunica la información y captura la información del usuario en un mínimo proceso. Esta capa se comunica únicamente con la capa de negocio.
Capa de negocio: Es donde residen los programas que se ejecutan, se reciben peticiones del usuario y se envían las respuestas tras el proceso, es aquí donde se establecen todas las reglas que deben cumplirse, se comunica con la capa de presentación, para recibir solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos.
Capa de datos: Es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.
Limitaciones
Construir una arquitectura de 3 capas es una tarea complicada. Las herramientas de programación que soportan el diseño de arquitecturas de 3 capas no proporcionan todos los servicios deseados que se necesitan para soportar un ambiente de computación distribuida.
Un problema potencial en el diseño de arquitecturas de 3 capas es que la separación de la interfaz gráfica de usuario, la lógica de gestión de procesamiento y la lógica de datos no es siempre obvia. Algunas lógicas de procesamiento de transacciones pueden aparecer en las 3 capas.
La ubicación de una función particular en una capa u otra debería basarse en criterios como los siguientes:
Facilidad de desarrollo y comprobación.
Facilidad de administración.
Escalabilidad de los servidores.
Funcionamiento (incluyendo procesamiento y carga de la red).
1. Representación distribuida
La interacción con el usuario se realiza básicamente en el servidor. El cliente hace de pasarela, de sistema de acceso a los elementos hardware pantalla y teclado.
2. Representación remota
Los datos se envían sin formatear, y es el cliente el responsable de formatear los datos y realizar las acciones de interacción con el usuario. En este caso, la aplicación y la base de datos se encuentran en el servidor
3. Lógica distribuida
En el cliente se llevan a cabo la interacción con el usuario y la parte más trivial de la lógica de la aplicación. En este caso, se llevan a cabo controles básicos de rango de campos, campos obligatorios, etc, mientras que el grueso de la lógica permanece en el servidor.
4. Gestión remota de datos
Tanto la interacción con el usuario como la aplicación residen en el cilente, siendo el servidor el
depositario de los datos.
5. Base de datos
El cliente debe conocer la topología de la red, así como la disposición y ubicación de los datos.
En este caso, se delega parte de la gestión de base de datos a los clientes.
En las primeras aplicaciones distribuidas por C/S, todos los servicios proporcionados por los servidores habían de ser programados a medida. Servicios como impresión, acceso a BD, traspaso de ficheros, etc. que hoy son habituales, debían ser desarrollados por las propias aplicaciones que luego iban a usarlos.
Al finalizar esta primera generación de aplicaciones C/S se hacia evidente que este camino debía andarse de otra manera. Los servicios “habituales” podían ser desarrollados de forma estándar y incluidos en todas las aplicaciones como software “prefabricado”. Surgen así los estándares de impresión aportados por la red, ODBC, OLE, CORBA, etc... Y una segunda generación de aplicaciones C/S, todavía anterior a la explosión de Internet, basadas en su utilización como componentes ya construidos a los que se delega filtrar la heterogeneidad del sistema.
Surge así la idea del Middleware. Se conoce como Middleware el conjunto de servicios que permiten distribuir datos y procesos a través de un sistema multitarea, una red local, una red remota o Internet.
1. Software intermedio general
Servicios generales que requieren todos los clientes y servidores, por ejemplo: software para las comunicaciones usando el TCP/IP, software parte del sistema operativo que, por ejemplo, almacena los archivos distribuidos, software de autenticación, el software intermedio de mensajes de clientes a servidores y viceversa
2. Software intermedio de servicios
Un software que permite a bases de datos diferentes conectarse a una red cliente-servidor. Probablemente el mejor ejemplo de este tipo de software sea la ODBC (Conectividad abierta de bases de datos) Open Database Connectivity)) producida por Microsoft. Esta permite que existan felizmente en una red la vasta mayoría de sistemas de gestión de bases de datos. Un software específico de objetos distribuidos tal como el que está asociado a CORBA. CORBA es una tecnología de objetos distribuida que permite a objetos escritos en una gran variedad de lenguajes que coexistan felizmente en una red de tal forma que cualquier objeto pueda enviar mensajes a otro objeto. El software intermedio de CORBA tiene que ver con funciones tales como configurar objetos distribuidos, comunicación y seguridad entre objetos. Un software intermedio de Web asociado al protocolo HTTP. Un software intermedio de software de grupo que administra los archivos que describen a los equipos de trabajo y sus interacciones. Un software intermedio asociado a productos de seguridad específicos. Un buen ejemplo es el software intermedio asociado a lo que se conoce como conexiones (sockets) seguras. Estas son conexiones que se pueden utilizar para enviar datos seguros en una red de tal forma que hace imposible que intrusos escuchen a escondidas los datos.
En los sistemas Cliente/Servidor, un objeto distribuido es aquel que esta gestionado por un servidor y sus clientes invocan sus métodos utilizando un “método de invocación remota”. El cliente invoca el método mediante un mensaje al servidor que gestiona el objeto, se ejecuta el método del objeto en el servidor y el resultado se devuelve al cliente en otro mensaje.
La característica fundamental de un objeto es que encapsula datos, llamado el estado, y las operaciones incluidas en tales datos, llamadas métodos. Los métodos se ponen a disposición mediante una interfaz. Es importante entender que no existe una forma “legal” en que un proceso pueda acceder o manipular el estado de un objeto que no sea a través de la invocación de los métodos disponibles para ello vía la interfaz del objeto. Un objeto puede implementar múltiples interfaces. Asimismo, dada una definición de interfaz, puede haber varios objetos que ofrezcan una forma de implementarla.
Esta separación entre interfaces y los objetos que las implementan resulta crucial en los sistemas distribuidos. Una estricta separación nos permite colocar las interfaces en una máquina en tanto que un objeto reside en otra máquina. Esta organización, mostrada en la figura, comúnmente se conoce como objeto distribuido.
Lo único que hace es organizar las invocaciones a métodos en mensajes y desorganizar los mensajes de respuesta para devolver el resultado de la invocación a un método al cliente. El objeto real reside en la máquina de un servidor, donde ofrece la misma interfaz que en la máquina del cliente. Las solicitudes de invocación entrantes primero se pasan al resguardo de un servidor, el cual las desempaqueta para crear invocaciones a métodos en la interfaz del objeto ubicada en el servidor. El resguardo del servidor también es responsable de desempaquetar las respuestas y de remitir mensajes de respuesta al proxy del lado del cliente.
Fue el primer framework para crear sistemas distribuidos de Java. El sistema de Invocación Remota de Métodos (RMI) de Java permite, a un objeto que se está ejecutando en una Máquina Virtual Java (VM), llamar a métodos de otro objeto que está en otra VM diferente. Esta tecnología está asociada al lenguaje de programación Java, es decir, que permite la comunicación entre objetos creados en este lenguaje.
El soporte para RMI en Java está basado en las interfaces y clases definidas en los paquetes:
Características de Java RMI:
– java.rmi
– java.rmi.server
– Los argumentos y resultados se pasan mediante RMI por valor (nunca por referencia).
– Un objeto remoto se pasa por referencia.
– Es necesario tratar mayor número de excepciones que en el caso de invocación de métodos locales.
Distributed Component Object Model.- El Modelo de Objeto Componente Distribuido, está incluido en los sistemas operativos de Microsoft. Es un juego de conceptos e interfaces de programa, en el cual los objetos de programa del cliente, pueden solicitar servicios de objetos de programa servidores en otras computadoras dentro de una red. Esta tecnología esta asociada a la plataforma de productos Microsoft.
COM (Component Object Model) es un estándar que permite la creación de objetos que ejecuten tareas que resuelven problemas específicos pero comunes a varias aplicaciones que puedan desear hacer uso de ellos. Estos pueden ser invocados por diferentes programas que los requieran, tanto OLE como ActiveX están basados en esta tecnología. La idea es tener un mundo de objetos independientes de un lenguaje de programación. Por ello COM proporciona un estándar para las comunicaciones entre componentes, de tal forma, que una aplicación puede utilizar características de cualquier otro objeto de la aplicación, o del sistema operativo, y permite actualizar el software de un componente sin afectar a la operación de la solución global.
COM soporta comunicación entre objetos de equipos de cómputo distintos, en una LAN, WAN, o incluso en Internet. DCOM extiende el estándar COM de objetos remotos, para su utilización en redes. Inicialmente se desarrolló para Windows NT 4.0, y posteriormente para Solaris 2.x y Macintosh, así como para diferentes versiones UNIX. Se encarga de manejar los detalles muy bajos de protocolos de red, por lo que el desarrollador se puede centrar en la realidad de los negocios, proporcionando así mejores soluciones a los clientes. La arquitectura define cómo los componentes y sus clientes interactúan entre sí. Esta interacción es definida de tal manera que el cliente y el componente puede conectarse 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. DCOM olvida completamente la localización de los componentes, no importando que estén 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 idéntica. No es sólo que 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 tareas 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ándose 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 dónde estén situadas. DCOM está pensado para que el sistema pueda funcionar bajo cualquier tipo de red, ya sea LAN, WAN o Internet, de forma que se solucionen los múltiples problemas que añaden estos entornos.
Common Object Request Broker Architecture.- Tecnología introducida por el Grupo de Administración de Objetos OMG, creada para establecer una plataforma para la gestión de objetos remotos independiente del lenguaje de programación
CORBA
(Common Object Request Broker Architec-ture), es una arquitectura de objetos distribuidos, que con el patrocinio del grupo OMG (Object Managament Group) compuesto por compañías como American Airlines, Canon, Data General, HP, Philips Telecomunicaciones, Sun, 3Com, Simulación de sistemas distribuidos Microsoft y Unisys entre otros; se ha convertido en un estándar y gracias a ello permite a aplicaciones de software implementadas incluso en diferentes lenguajes comunicarse entre sí, a través de sistemas de cómputo, que a su vez pueden estar conformados por hardware, sistemas operativos distintos y que forman parte de alguna red. Además, la ejecución de objetos remotos se puede lograr sin la necesidad de un servidor Web. CORBA al ser un estándar cuenta con un conjunto de especificaciones, sobre las cuales los vendedores de implementaciones de CORBA, conocidas como Object Request Broker (ORB) se apegan, para facilitar la comunicación con la implementación de otro vendedor. CORBA cuenta con tres elementos principales en los cuales se basa: El lenguaje de definición de interfaces IDL (Interface Definition Language), el ORB (Object Request Broker) y el protocolo GIOP (General Inter ORB Protocol).
En cuanto al modelado de los objetos, CORBA hace uso del modelo cliente/servidor para el manejo de los mensajes y así establecer la comunicación entre ellos, cuando un objeto en una aplicación cliente requiere ejecutar los métodos de un objeto remoto en una aplicación servidor, hace uso del ORB que es específico para el lenguaje y la plataforma de cada aplicación, el cual traduce la llamada del cliente a un formato neutro, totalmente independiente, que puede transportarse sobre cualquier medio para el cual exista un protocolo de comunicación. Un esquema conceptual de la arquitectura de CORBA se muestra en la figura.
B. Identificación de Arquitecturas Cliente/servidor
La idea de estilo arquitectónico es importante. Tal estilo se formula en términos de componentes, la forma en que los componentes interactúan entre sí, el intercambio de datos entre los componentes y, por último, en cómo es que estos elementos se configuran juntos en un sistema. Un componente es una unidad modular con las interfaces requeridas bien definidas; dicha unidad es reemplazable dentro de su ambiente (OMG, 2004b). La cuestión importante sobre un componente para sistemas distribuidos es que pueda ser reemplazado, a condición de respetar sus interfaces. Un concepto de cierta manera más difícil de entender es el de conector, el cual generalmente se describe como un mecanismo que media la comunicación, coordinación o cooperación entre componentes.
Una arquitectura Cliente/Servidor es una forma de diseñar Sistema de Información a partir de distribuir el trabajo en servicios especializados basada en la existencia de programas que piden SERVICIOS, los CLIENTES, a otros programas especializados que los suministran, los SERVIDORES. De recoger y transportar los mensajes que se intercambian cliente y servidor se encarga el TRANSPORTISTA. Clientes, servidores y transportista funcionan y se apoyan en el conjunto de hardware, sistemas operativos, redes y comunicaciones que constituyen la PLATAFORMA o SISTEMA.
1. Interfaz de usuario
2. Gestión del procesamiento
3. Gestión de la base de datos
1.- Arquitectura de 2 Capas
La arquitectura clente/servidor tradicional es una solución de 2 capas. La arquitectura de 2 capas consta de tres componentes distribuidos en dos capas: cliente (solicitante de servicios) y servidor (proveedor de servicios).
Las capas que esta arquitectura presenta son las siguientes:
• Nivel de aplicación este nivel es en el que se encuentra toda la interfaz del sistema y es la que el usuario puede disponer para realizar su actividad con el sistema.
• Nivel de la base de datos. Este nivel de la base de datos también llamado el repositorio de datos, es la capa en donde se almacena toda la información ingresada en el sistema y que se deposita en forma permanente. Existen herramientas para el desarrollo en dos capas por ejemplo visual basic, access y sql.
- Clientes obesos (thick clients): La mayor parte de la lógica de la aplicación (gestión del procesamiento) reside junto a la lógica de la presentación (interfaz de usuario) en el cliente, con la porción de acceso a datos en el servidor.
- Clientes delgados (thin clients): solo la lógica de la presentación reside en el cliente, con el acceso a datos y la mayoría de la lógica de la aplicación en el servidor.
2.- Arquitectura de 3 capas
La arquitectura de 3 capas es usada cuando se necesita un diseño cliente/servidor que proporcione, en comparación con la arquitectura de 2 capas, incrementar el rendimiento, flexibilidad, mantenibilidad, reusabilidad y escalabilidad mientras se esconde la complejidad del procesamiento distribuido al usuario.
Capa de presentación: Presenta el sistema al usuario, comunica la información y captura la información del usuario en un mínimo proceso. Esta capa se comunica únicamente con la capa de negocio.
Capa de negocio: Es donde residen los programas que se ejecutan, se reciben peticiones del usuario y se envían las respuestas tras el proceso, es aquí donde se establecen todas las reglas que deben cumplirse, se comunica con la capa de presentación, para recibir solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos.
Capa de datos: Es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.
Construir una arquitectura de 3 capas es una tarea complicada. Las herramientas de programación que soportan el diseño de arquitecturas de 3 capas no proporcionan todos los servicios deseados que se necesitan para soportar un ambiente de computación distribuida.
Un problema potencial en el diseño de arquitecturas de 3 capas es que la separación de la interfaz gráfica de usuario, la lógica de gestión de procesamiento y la lógica de datos no es siempre obvia. Algunas lógicas de procesamiento de transacciones pueden aparecer en las 3 capas.
La ubicación de una función particular en una capa u otra debería basarse en criterios como los siguientes:
Facilidad de desarrollo y comprobación.
Facilidad de administración.
Escalabilidad de los servidores.
Funcionamiento (incluyendo procesamiento y carga de la red).
C. Identificación de los sistemas cliente/servidor
1. Representación distribuida
La interacción con el usuario se realiza básicamente en el servidor. El cliente hace de pasarela, de sistema de acceso a los elementos hardware pantalla y teclado.
2. Representación remota
Los datos se envían sin formatear, y es el cliente el responsable de formatear los datos y realizar las acciones de interacción con el usuario. En este caso, la aplicación y la base de datos se encuentran en el servidor
3. Lógica distribuida
En el cliente se llevan a cabo la interacción con el usuario y la parte más trivial de la lógica de la aplicación. En este caso, se llevan a cabo controles básicos de rango de campos, campos obligatorios, etc, mientras que el grueso de la lógica permanece en el servidor.
4. Gestión remota de datos
Tanto la interacción con el usuario como la aplicación residen en el cilente, siendo el servidor el
depositario de los datos.
5. Base de datos
El cliente debe conocer la topología de la red, así como la disposición y ubicación de los datos.
En este caso, se delega parte de la gestión de base de datos a los clientes.
D) Identificación de Middleware
En las primeras aplicaciones distribuidas por C/S, todos los servicios proporcionados por los servidores habían de ser programados a medida. Servicios como impresión, acceso a BD, traspaso de ficheros, etc. que hoy son habituales, debían ser desarrollados por las propias aplicaciones que luego iban a usarlos.
Al finalizar esta primera generación de aplicaciones C/S se hacia evidente que este camino debía andarse de otra manera. Los servicios “habituales” podían ser desarrollados de forma estándar y incluidos en todas las aplicaciones como software “prefabricado”. Surgen así los estándares de impresión aportados por la red, ODBC, OLE, CORBA, etc... Y una segunda generación de aplicaciones C/S, todavía anterior a la explosión de Internet, basadas en su utilización como componentes ya construidos a los que se delega filtrar la heterogeneidad del sistema.
Surge así la idea del Middleware. Se conoce como Middleware el conjunto de servicios que permiten distribuir datos y procesos a través de un sistema multitarea, una red local, una red remota o Internet.
1. Software intermedio general
Servicios generales que requieren todos los clientes y servidores, por ejemplo: software para las comunicaciones usando el TCP/IP, software parte del sistema operativo que, por ejemplo, almacena los archivos distribuidos, software de autenticación, el software intermedio de mensajes de clientes a servidores y viceversa
2. Software intermedio de servicios
Un software que permite a bases de datos diferentes conectarse a una red cliente-servidor. Probablemente el mejor ejemplo de este tipo de software sea la ODBC (Conectividad abierta de bases de datos) Open Database Connectivity)) producida por Microsoft. Esta permite que existan felizmente en una red la vasta mayoría de sistemas de gestión de bases de datos. Un software específico de objetos distribuidos tal como el que está asociado a CORBA. CORBA es una tecnología de objetos distribuida que permite a objetos escritos en una gran variedad de lenguajes que coexistan felizmente en una red de tal forma que cualquier objeto pueda enviar mensajes a otro objeto. El software intermedio de CORBA tiene que ver con funciones tales como configurar objetos distribuidos, comunicación y seguridad entre objetos. Un software intermedio de Web asociado al protocolo HTTP. Un software intermedio de software de grupo que administra los archivos que describen a los equipos de trabajo y sus interacciones. Un software intermedio asociado a productos de seguridad específicos. Un buen ejemplo es el software intermedio asociado a lo que se conoce como conexiones (sockets) seguras. Estas son conexiones que se pueden utilizar para enviar datos seguros en una red de tal forma que hace imposible que intrusos escuchen a escondidas los datos.
E. Identificación de Tecnologías orientadas a los objetos distribuidos
En los sistemas Cliente/Servidor, un objeto distribuido es aquel que esta gestionado por un servidor y sus clientes invocan sus métodos utilizando un “método de invocación remota”. El cliente invoca el método mediante un mensaje al servidor que gestiona el objeto, se ejecuta el método del objeto en el servidor y el resultado se devuelve al cliente en otro mensaje.
La característica fundamental de un objeto es que encapsula datos, llamado el estado, y las operaciones incluidas en tales datos, llamadas métodos. Los métodos se ponen a disposición mediante una interfaz. Es importante entender que no existe una forma “legal” en que un proceso pueda acceder o manipular el estado de un objeto que no sea a través de la invocación de los métodos disponibles para ello vía la interfaz del objeto. Un objeto puede implementar múltiples interfaces. Asimismo, dada una definición de interfaz, puede haber varios objetos que ofrezcan una forma de implementarla.
Esta separación entre interfaces y los objetos que las implementan resulta crucial en los sistemas distribuidos. Una estricta separación nos permite colocar las interfaces en una máquina en tanto que un objeto reside en otra máquina. Esta organización, mostrada en la figura, comúnmente se conoce como objeto distribuido.
Lo único que hace es organizar las invocaciones a métodos en mensajes y desorganizar los mensajes de respuesta para devolver el resultado de la invocación a un método al cliente. El objeto real reside en la máquina de un servidor, donde ofrece la misma interfaz que en la máquina del cliente. Las solicitudes de invocación entrantes primero se pasan al resguardo de un servidor, el cual las desempaqueta para crear invocaciones a métodos en la interfaz del objeto ubicada en el servidor. El resguardo del servidor también es responsable de desempaquetar las respuestas y de remitir mensajes de respuesta al proxy del lado del cliente.
1. RMI
Fue el primer framework para crear sistemas distribuidos de Java. El sistema de Invocación Remota de Métodos (RMI) de Java permite, a un objeto que se está ejecutando en una Máquina Virtual Java (VM), llamar a métodos de otro objeto que está en otra VM diferente. Esta tecnología está asociada al lenguaje de programación Java, es decir, que permite la comunicación entre objetos creados en este lenguaje.
El soporte para RMI en Java está basado en las interfaces y clases definidas en los paquetes:
Características de Java RMI:
– java.rmi
– java.rmi.server
– Los argumentos y resultados se pasan mediante RMI por valor (nunca por referencia).
– Un objeto remoto se pasa por referencia.
– Es necesario tratar mayor número de excepciones que en el caso de invocación de métodos locales.
2. DCOM
Distributed Component Object Model.- El Modelo de Objeto Componente Distribuido, está incluido en los sistemas operativos de Microsoft. Es un juego de conceptos e interfaces de programa, en el cual los objetos de programa del cliente, pueden solicitar servicios de objetos de programa servidores en otras computadoras dentro de una red. Esta tecnología esta asociada a la plataforma de productos Microsoft.
COM (Component Object Model) es un estándar que permite la creación de objetos que ejecuten tareas que resuelven problemas específicos pero comunes a varias aplicaciones que puedan desear hacer uso de ellos. Estos pueden ser invocados por diferentes programas que los requieran, tanto OLE como ActiveX están basados en esta tecnología. La idea es tener un mundo de objetos independientes de un lenguaje de programación. Por ello COM proporciona un estándar para las comunicaciones entre componentes, de tal forma, que una aplicación puede utilizar características de cualquier otro objeto de la aplicación, o del sistema operativo, y permite actualizar el software de un componente sin afectar a la operación de la solución global.
COM soporta comunicación entre objetos de equipos de cómputo distintos, en una LAN, WAN, o incluso en Internet. DCOM extiende el estándar COM de objetos remotos, para su utilización en redes. Inicialmente se desarrolló para Windows NT 4.0, y posteriormente para Solaris 2.x y Macintosh, así como para diferentes versiones UNIX. Se encarga de manejar los detalles muy bajos de protocolos de red, por lo que el desarrollador se puede centrar en la realidad de los negocios, proporcionando así mejores soluciones a los clientes. La arquitectura define cómo los componentes y sus clientes interactúan entre sí. Esta interacción es definida de tal manera que el cliente y el componente puede conectarse 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. DCOM olvida completamente la localización de los componentes, no importando que estén 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 idéntica. No es sólo que 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 tareas 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ándose 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 dónde estén situadas. DCOM está pensado para que el sistema pueda funcionar bajo cualquier tipo de red, ya sea LAN, WAN o Internet, de forma que se solucionen los múltiples problemas que añaden estos entornos.
3. CORB
Common Object Request Broker Architecture.- Tecnología introducida por el Grupo de Administración de Objetos OMG, creada para establecer una plataforma para la gestión de objetos remotos independiente del lenguaje de programación
CORBA
(Common Object Request Broker Architec-ture), es una arquitectura de objetos distribuidos, que con el patrocinio del grupo OMG (Object Managament Group) compuesto por compañías como American Airlines, Canon, Data General, HP, Philips Telecomunicaciones, Sun, 3Com, Simulación de sistemas distribuidos Microsoft y Unisys entre otros; se ha convertido en un estándar y gracias a ello permite a aplicaciones de software implementadas incluso en diferentes lenguajes comunicarse entre sí, a través de sistemas de cómputo, que a su vez pueden estar conformados por hardware, sistemas operativos distintos y que forman parte de alguna red. Además, la ejecución de objetos remotos se puede lograr sin la necesidad de un servidor Web. CORBA al ser un estándar cuenta con un conjunto de especificaciones, sobre las cuales los vendedores de implementaciones de CORBA, conocidas como Object Request Broker (ORB) se apegan, para facilitar la comunicación con la implementación de otro vendedor. CORBA cuenta con tres elementos principales en los cuales se basa: El lenguaje de definición de interfaces IDL (Interface Definition Language), el ORB (Object Request Broker) y el protocolo GIOP (General Inter ORB Protocol).
En cuanto al modelado de los objetos, CORBA hace uso del modelo cliente/servidor para el manejo de los mensajes y así establecer la comunicación entre ellos, cuando un objeto en una aplicación cliente requiere ejecutar los métodos de un objeto remoto en una aplicación servidor, hace uso del ORB que es específico para el lenguaje y la plataforma de cada aplicación, el cual traduce la llamada del cliente a un formato neutro, totalmente independiente, que puede transportarse sobre cualquier medio para el cual exista un protocolo de comunicación. Un esquema conceptual de la arquitectura de CORBA se muestra en la figura.
No hay comentarios.:
Publicar un comentario