Arquitectura cliente servidor

Modelos de computación distribuida:

RMI, COM-DCON, CORBA, SERVICIOS WEB
Modelos de computación distribuida
• COM-DCON
• RMI
• CORBA
• SERVICIOS WEB
Modelos de computación distribuida
• En las primeras épocas de la computación las computadoras operaban
independientemente una de otra sin tener comunicación entre ellas.
• Las aplicaciones de software eran comúnmente desarrolladas para un
propósito especifico.
• Compartir los datos entre sistemas era mínimo y se hacían de una manera
muy fácil, se transportaban los medios de almacenamiento (tarjetas, cintas,
discos, etc.) de un lado a otro.
• El próximo paso fue conectar las computadoras a través de una red usando
protocolos propietarios, luego los protocolos fueron estandarizados.
• Luego llego la era de los sistemas abiertos y la integración de sistemas por los
cuales un cliente podía elegir varios componentes de hardware de diferentes
vendedores e integrarlos para crear una configuración necesaria con costos
razonables.
Modelos de computación distribuida
• Nuevas técnicas de desarrollo de software se fueron sucediendo una tras otra,
desde la programación estructurada y modular hasta la programación orientada a
objetos, siempre buscando reducir costos y aumentar la capacidad de rehúso .
• Si bien la programación orientada a objetos fomentó el rehúso y permitió reducir
costos, no se ha logrado aún el objetivo último: comprar componentes de varios
proveedores e integrarlos para formar aplicaciones que a su vez se integren para
formar sistemas completos.
• Para lograr la integración total de componentes realizados por terceras partes es
necesario llegar a un acuerdo común en el que se establezcan los mecanismos
necesarios para que esa integración se haga efectiva.
• Será necesario especificar de manera independiente al lenguaje de programación
en el que se desarrolló el componente cuáles son sus puntos de acceso (funciones),
luego será necesario establecer los mecanismos de comunicación entre
componentes, que podrían estar ejecutándose en una máquina remota.
Modelos de computación distribuida

• En este sentido, y buscando satisfacer esa necesidad de mecanismos

estándar e interfaces abiertas, son tres los esfuerzos que más han
sobresalido.
• Por un lado, Microsoft ha introducido en el mercado sus tecnologías
COM, DCOM y COM+.
• Otro participante es Sun Microsystems, que ha presentado Java Beans.
• El tercero es el Object Management Group, un consorcio integrado por
varias industrias importantes, que ha desarrollado CORBA (Common
Request Broker Architecture).
 COM / DCOM
• El Modelo de Objetos de Componentes Distribuidos (Distributed Component Object Model,
DCOM) es una tecnología propietaria de Microsoft para desarrollar componentes de software
distribuidos sobre varias computadoras y que se comunican entre sí.
• Extiende el modelo Component Object Model (COM) de Microsoft y proporciona el sustrato de
comunicación entre la infraestructura del servidor de aplicaciones COM+ de Microsoft.
• Ha sido abandonada en favor del framework Microsoft .NET.
• El agregado de la "D" a COM fue por el uso extensivo de DCE Remote Procedure Call (DCE/RPC),
o más específicamente la versión mejorada de Microsoft, conocida como MSRPC.
• En términos de las extensiones que añade a COM, DCOM tenía que resolver los problemas de:
• Aplanamiento: serializar y deserializar los argumentos y valores de retorno de las llamadas
a los métodos "sobre el cable".
• Recolección de basura distribuida: asegurándose que las referencias mantenidas por
clientes de las interfaces sean liberadas cuando, por ejemplo, el proceso cliente ha caído o
la conexión de red se pierde.
 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 fue una evolución lógica de COM, se pueden utilizar los componentes
creados en aplicaciones basadas en COM, y trasladarlas a entornos distribuidos.
• COM 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.
• DCOM trabajaba con sistemas operáticos como Windows NT, 2000 o XP.
• Luego estuvo disponible una versión para implementar de DCOM para Apple
Macintosh y adicionalmente en implementaciones para plataformas UNIX como
Solaris.
• Pero mantenía problemas de conectividad en determinados escenarios.
 COM / DCOM: La arquitectura
• Uno de los factores clave para resolver estos problemas es el uso de DCE/RPC
como el mecanismo Remote Procedure Call (RPC) subyacente bajo DCOM.
• DCE/RPC define reglas estrictas en cuanto al aplanamiento y a quién es
responsable de liberar la memoria.
• DCOM fue uno de los mayores competidores de CORBA.
• Los defensores de ambas tecnologías sostenían que algún día serían el
modelo de código y servicios sobre Internet.
• Sin embargo, las dificultades que suponía conseguir que estas tecnologías
funcionasen a través de cortafuegos y sobre máquinas inseguras o
desconocidas, significó que las peticiones HTTP normales, combinadas con
los navegadores web les ganasen la partida.
• Microsoft, en su momento intentó y fracasó anticiparse a esto añadiendo un
transporte extra HTTP a DCE/RPC denominado "ncacn_http" (connection-
based, over HTTP).
 COM / DCOM: Independencia del protocolo
• Muchas aplicaciones distribuidas tienen que ser integradas en la
infraestructura de una red existente.
• Necesitar un protocolo específico de red, obligará a mejorar todos los
cliente, lo que es inaceptable en muchas situaciones.
• Los desarrolladores de aplicaciones tienen que tener cuidado de
mantener la aplicación lo más independiente posible de la
infraestructura de la red.
• DCOM proporciona esta transparencia: DCOM puede utilizar cualquier
protocolo de transporte, como TCP/IP, UDP, IPX/SPX y NetBIOS. DCOM
proporciona un marco de seguridad a todos estos protocolos.
• Los desarrolladores pueden simplemente utilizar las características
proporcionadas por DCOM y asegurar que sus aplicaciones son
completamente independiente del protocolo.
 COM / DCOM: Independencia de la localización
• Cuando se comienza a implementar una aplicación distribuida en una red, aparecen distintos conflictos
en el diseño:
• Los componentes que interactúan 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 idéntica. 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.
 COM / DCOM vs Microsoft .NET
• .NET es un framework de Microsoft que hace un énfasis en la transparencia
de redes, con independencia de plataforma de hardware y que permita un
rápido desarrollo de aplicaciones.
• Basado en ella, la empresa intenta desarrollar una estrategia horizontal que
integre todos sus productos, desde el sistema operativo hasta las
herramientas de mercado.
• .NET podría considerarse una respuesta de Microsoft al creciente mercado de
los negocios en entornos Web, como competencia a la plataforma Java de
Oracle Corporation y a los diversos framework de desarrollo web basados en
PHP.
• Su propuesta es ofrecer una manera rápida y económica, a la vez que segura
y robusta, de desarrollar aplicaciones –o como la misma plataforma las
denomina, soluciones– permitiendo una integración más rápida y ágil entre
empresas y un acceso más simple y universal a todo tipo de información
desde cualquier tipo de dispositivo.
 JAVA 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 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 (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.
 JAVA RMI
• Básicamente RMI proporciona la capacidad para llamadas a métodos sobre objetos remotos, los
cuales convierten al componente de transporte del objeto en arquitectura de objeto distribuido.
• También proporciona mecanismos para el registro y persistencia del objeto. Ofrece servicios
distribuidos tales como Java IDL que proporciona una forma de conectar, transparentemente, a los
clientes Java a los servidores de red utilizando la industria estándar:
• Lenguaje de Definición de Interfaces (IDL Interface Definition Language).
• Las aplicaciones RMI están, a menudo, compuestas de dos programas separados: un servidor y un
cliente.
• Una aplicación común del servidor crea algunos objetos remotos, realiza referencias para accederlos
y se encuentra en espera de que los clientes invoquen los métodos sobre éstos objetos remotos.
• Una aplicación del cliente tiene una referencia remota a uno o más objetos remotos en el servidor y
entonces invoca al método sobre ellos.
• RMI proporciona los mecanismos a través de los cuales el servidor y el cliente se comunican e
intercambian información.
 JAVA RMI
• Las aplicaciones utilizan uno o dos mecanismos para obtener referencias a objetos remotos.
Una aplicación registra sus objetos remotos con la facilidad de denominación del RMI, o
bien la aplicación pasa y regresa la referencia a los objetos remotos como parte de su
operación normal.
• Los detalles de comunicación entre objetos remotos está a cargo del RMI; para el
programador, la comunicación remota se asemeja a la invocación del método Java.
• Dado que RMI permite que un solicitante pase objetos a objetos remotos, RMI proporciona
los mecanismos necesarios para cargar un código de objeto, así como también de transmitir
sus datos.
• RMI soporta su propio protocolo de transporte denominado Protocolo de Mensajes
Remotos Java (JRMP Java Remote Messaging Protocol) para definir el conjunto de formatos
de mensajes que permiten que los datos pasen a través de una red de computadoras a otra.
• La siguiente ilustración representa una aplicación distribuida RMI que utiliza el registro para
obtener una referencia a un objeto remoto.
JAVA RMI
 JAVA RMI
• El servidor llama al registro para asociar (o ligar) un nombre con un objeto remoto. El cliente busca el
objeto remoto por su nombre en el registro del servidor y entonces invoca un método sobre él. La
ilustración también muestra que el sistema RMI utiliza un servidor Web para cargar los códigos en
bytes de las clases, del servidor al cliente y del cliente al servidor, para los objetos cuando se les
necesita.
• RMI pasa objetos por su tipo verdadero permitiendo que nuevos tipos sean introducidos en una
máquina virtual remota por consiguiente extendiendo el comportamiento de una aplicación de
manera dinámica. RMI trata un objeto remoto de manera diferente de un objeto local cuando el
objeto se le pasa de una máquina virtual a otra. En lugar de hacer una copia de la implementación
del objeto en la máquina virtual receptora.
• El solicitante invoca un método en el stub local que tiene como responsabilidad cargar la llamada al
método en el objeto remoto. Un stub para objetos remotos implementa el mismo conjunto de
interfaces remotas que el mismo objeto remoto implementa.
• Esto permite que un stub se acople a cualquiera de las interfaces que el objeto remoto implemente.
Sin embargo, esto también significa que solamente aquellos métodos, definidos en una interface
remota, estén disponibles para su solicitud en la máquina virtual receptora.
 JAVA RMI: Capas
• La arquitectura RMI puede verse como un modelo de cuatro capas.
• 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: 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: 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 (stream-oriented
connection) desde la capa de transporte.
• Cuarta Capa: 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.
 JAVA RMI - Java IDL
• Java IDL esta basado en CORBA (Common Object Request Brokerage Architecture).

• Una característica clave de CORBA es un lenguaje-neutral IDL (Interface Definition

Language).

• Cada lenguaje que soporta CORBA tiene su propio traductor IDL y como su nombre lo dice,
Java IDL soporta la traducción para Java.

• Para soportar la interacción entre objetos en programas separados, Java IDL proporciona un
ORB (Object Request Broker).

• El ORB es una librería clase que facilita la comunicación de bajo nivel entre las aplicaciones
Java IDL y otras aplicaciones.
 JAVA RMI - ¿RMI o IDL?
• Java RMI es una solución 100% Java para objetos remotos que proporciona todas las ventajas de
las capacidades de Java "una vez escrito, ejecutarlo en cualquier parte".
• Los servidores y clientes desarrollados con Java RMI se muestran en cualquier lugar en la
red sobre cualquier plataforma que soporta el ambiente de ejecución de Java.
• Java IDL, en contraste, está basado en una industria estándar para solicitar, de manera remota, a
objetos escritos en cualquier lenguaje de programación.
• Como resultado, Java IDL proporciona un medio para conectar aplicaciones "transferidas"
que aún cubren las necesidades de comercio pero que fueron escritos en otros lenguajes.
• Actualmente Java RMI y Java IDL emplean protocolos diferentes para la comunicación entre
objetos sobre diferentes plataformas.
• Java IDL utiliza el protocolo estándar de CORBA IIOP (Internet Inter-Orb Protocol).
• Al igual que IDL, IIOP facilita la residencia de objetos en diversas plataformas y escritos en
diversos lenguajes para interactuar de manera estándar.
• Actualmente Java RMI utiliza el protocolo JRMP (Java Remote Messaging Protocol), un
protocolo desarrollado específicamente para los objetos remotos de Java.
 JAVA RMI - ¿RMI o IDL?
• En Java IDL, un cliente interactúa con un objeto remoto por referencia.
• Esto es, el cliente nunca tiene una copia actual del objeto servidor en su propio
ambiente de ejecución.
• En su lugar, el cliente utiliza stubs en la ejecución local para manipular el objeto
servidor residiendo sobre la plataforma remota.
• En contraste, RMI facilita que un cliente interactúe con un objeto remoto por referencia, o
por su valor descargándolo y manipulándolo en el ambiente de ejecución local.
• Esto se debe a que todos los objetos en RMI son objetos Java.
• RMI utiliza las capacidades de serialización del objeto, que proporciona el lenguaje Java,
para transportar los objetos desde el servidor al cliente.
• Java IDL, dado que interactúa con objetos escritos en cualquier lenguaje, no toma ventaja
de "una vez escrito, ejecutarlo en cualquier parte", característica del lenguaje de
programación Java.
 Arquitectura de CORBA
• CORBA define una arquitectura para los objetos distribuidos.
• Common Object Request Broker Architecture (CORBA) es un estándar definido por Object
Management Group (OMG) que permite que diversos componentes de software escritos
en múltiples lenguajes de programación y que corren en diferentes computadoras, puedan
trabajar juntos; es decir, facilita el desarrollo de aplicaciones distribuidas en entornos
heterogéneos.
• CORBA fue el primer producto propuesto por OMG. Su objetivo es ayudar a reducir la
complejidad, disminuir los costes y acelerar la introducción de nuevas aplicaciones
informáticas, promoviendo la teoría y la práctica de la tecnología de objetos en los sistemas
distribuidos.
• Es una tecnología que oculta la programación a bajo nivel de aplicaciones distribuidas.
• No obstante también brinda al programador una tecnología orientada a objetos; las
funciones objetos y estos objetos pueden estar en diferentes máquinas, pero el
programador accederá a ellos a través de funciones normales dentro de su programa.
 Arquitectura de CORBA
• CORBA es más que una especificación multiplataforma, también define
servicios habitualmente necesarios como seguridad y transacciones. Y así este
no es un sistema operativo en sí, en realidad es un middleware.
• El paradigma básico de CORBA es el de un pedido servicios de un objeto
distribuido. Todo definido por el OMG está en términos de este paradigma
básico.
• Los servicios que un objeto proporciona son dados por su interfaz .
• Los interfaces se definen en la lengua de la definición de interfaz de OMG
(IDL).
• Los objetos distribuidos son identificados por las referencias del objeto, que
son mecanografiadas por los interfaces de IDL.
 Arquitectura de CORBA: Características
Entre las principales características de CORBA, encontramos:
• Independencia en el lenguaje de programación y sistema operativo: CORBA fue
diseñado para liberar a los ingenieros de las limitaciones en cuanto al diseño del
software.
• Actualmente soporta Ada, C, C++, C++11, Lisp, Ruby, Smalltalk, Java, COBOL, PL/I y
Python.
• Posibilidad de interacción entre diferentes tecnologías: uno de los principales
beneficios de la utilización de CORBA es la posibilidad de normalizar las interfaces entre
las diversas tecnologías y poder así combinarlas.
• Transparencia de distribución: ni cliente ni servidor necesitan saber si la aplicación está
distribuida o centralizada, pues el sistema se ocupa de todo eso.
• Transparencia de localización: el cliente no necesita saber donde ejecuta el servicio y el
servicio no necesita saber donde ejecuta el cliente.
 Arquitectura de CORBA: Características
• Integración de software existente: se amortiza la inversión previa reutilizando el
software con el que se trabaja, incluso con sistemas heredados.
• Activación de objetos: los objetos remotos no tienen por qué estar en memoria
permanentemente, y se hace de manera invisible para el cliente.
• Otras como: el tipado fuerte de datos, la alta capacidad de configuración, libertad
de elección de los detalles de transferencia de datos, o la compresión de los datos.
 Web services (Servicio web)
• 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.
 Web services (Servicio web)
• 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.
 Web services: Estándares empleados
• Web Services Protocol Stack: conjunto de servicios y protocolos de los servicios web.
• XML (Extensible Markup Language): formato estándar para los datos que se vayan a intercambiar.
• SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure Call): protocolos sobre los que se
establece el intercambio.
• Otros protocolos: los datos en XML también pueden enviarse de una aplicación a otra mediante protocolos
normales como Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), o Simple Mail Transfer Protocol
(SMTP).
• WSDL (Web Services Description Language): es el lenguaje de la interfaz pública para los servicios web. Es una
descripción basada en XML de los requisitos funcionales necesarios para establecer una comunicación con los
servicios web.
• UDDI (Universal Description, Discovery and Integration): protocolo para publicar la información de los servicios
web. Permite comprobar qué servicios web están disponibles.
• WS-Security (Web Service Security): protocolo de seguridad aceptado como estándar por OASIS (Organization
for the Advancement of Structured Information Standards). Garantiza la autenticación de los actores y la
confidencialidad de los mensajes enviados.
• REST (Representational State Transfer): arquitectura que, haciendo uso del protocolo HTTP, proporciona una API
que utiliza cada uno de sus métodos (GET, POST, PUT, DELETE, etcétera) para poder realizar diferentes
operaciones entre la aplicación que ofrece el servicio web y el cliente.
 Web services (Servicio web)
• 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.