dr. juan josé aranda aboy aspectos avanzados de la tecnología de objetos 7. tópicos avanzados

50
Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Upload: susana-solorzano

Post on 06-Feb-2015

5 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Aspectos Avanzados de la

Tecnología de Objetos

7. Tópicos avanzados

Page 2: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Contenidos

• Concurrencia.– Patrones utilizados para resolver la

Concurrencia

• Distribución: CORBA y RMI.– Patrones utilizados para resolver la Distribución– Patrones utilizados para resolver la

Presentación

• Desarrollo bajo el modelo cliente - servidor e Internet.

Page 3: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Objetivos específicos

• Conocer, describir y aplicar apropiadamente los patrones utilizados para resolver la concurrencia y la distribución.

• Explicar las características de CORBA y Java RMI, comparándoles adecuadamente.

• Utilizar el modelo Cliente – Servidor para construir sistemas.

Page 4: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Comunicación entre sistemas heterogéneos

• El sistema del departamento de Compras está en Windows/Visual Basic y requiere información del departamento de Contabilidad que utiliza HP-UX/Oracle.

• El nuevo departamento de Web requiere acceso tanto al de Contabilidad y Compras para desplegar información de clientes pero éste ya se encuentra en el flexible y portable lenguaje Java.

• Las incongruencias se hacen evidentes: desde privilegios de acceso (seguridad), representación de datos, transacciones y otra gran gama de posibilidades.

• Esta comunicación entre sistemas heterogéneos presenta el siguiente problema:

¿Cómo interactuamos?

Page 5: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Remote Procedure Call - RPC • El protocolo de Llamada a Procedimiento Remoto permite a un

programa ejecutar código en un computador remoto sin tener que preocuparse por las comunicaciones entre ambos.

• Fue propuesto inicialmente por Sun Microsystems como un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, que quedaban encapsuladas dentro de las RPC.

• Las RPC son muy utilizadas dentro del paradigma cliente-servidor, siendo el cliente quien inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando éste de vuelta el resultado de dicha operación al cliente.

• Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun (RFC 1057), Distributed Computing Environment (DCE), DCOM de Microsoft, no siendo compatibles entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL) que define los métodos exportados por el servidor.

• Hoy en día se está utilizando el XML como lenguaje para definir el IDL y el HTTP como protocolo de red, dando lugar a los Servicios Web.

Page 6: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Pasos en RPC

1. El procedimiento cliente llama al stub (zona de resguardo) cliente de manera normal.

2. El stub cliente construye un mensaje y llama al SO local. El empaquetamiento de parámetros en un mensaje recibe el nombre de ordenamiento de parámetros.

3. El SO del cliente envía el mensaje al SO remoto.4. El SO remoto entrega el mensaje al stub del servidor5. El stub del servidor desempaqueta los parámetros y llama al

servidor.6. El servidor realiza la tarea y entrega sus resultados al stub.7. El stub del servidor empaqueta estos resultados en un mensaje

y llama al SO local del servidor.8. El SO del servidor envía el mensaje de respuesta al SO remoto

del cliente.9. El SO del cliente entrega el mensaje al stub del cliente.10. El stub cliente desempaqueta el resultado y lo entrega al cliente.

Page 7: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Llamada y mensajes en RPC

• Cada elipse representa un solo proceso con su stub (zona de resguardo).

Page 8: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Escribiendo Cliente y Servidor• Pasos para escribir un cliente y un servidor en ambientes de

computación distribuida (distributed computing environments – DCE) RPC.

Page 9: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Ligando al Cliente con el Servidor

• Ligadura Cliente-a-Servidor en DCE.

Page 10: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Objetos Distribuidos

• Organización común de un objeto remoto con proxy del lado del cliente.

Page 11: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Ligando el cliente a un objeto

a) Ejemplo con ligadura implícita utilizando solamente referencias globales.

b) Ejemplo con ligadura explícita utilizando referencias globales y locales.

Distr_object* obj_ref; //Declare a systemwide object referenceobj_ref = …; // Initialize the reference to a distributed objectobj_ref-> do_something(); // Implicitly bind and invoke a method

(a)

Distr_object objPref; //Declare a systemwide object referenceLocal_object* obj_ptr; //Declare a pointer to local objectsobj_ref = …; //Initialize the reference to a distributed objectobj_ptr = bind(obj_ref); //Explicitly bind and obtain a pointer to the local proxyobj_ptr -> do_something(); //Invoke a method on the local proxy

(b)

Page 12: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Paso de parámetros

• Situación cuando se pasa un objeto por referencia ó por valor.

Page 13: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Modelo DCE Distributed-Object

a) Objetos dinámicos distribuidos en DCE.b) Objetos nombrados (Distributed named objects)

Page 14: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Persistencia y sincronismo en la comunicación (1)

• Organización general de un sistema de comunicación en el cual los hosts están conectados mediante una red.

Page 15: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Persistencia y sincronismo en la comunicación (2)

a) Comunicación asincrónica persistente.b) Comunicación sincrónica persistente.

Page 16: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Protocolos RPC

• Constituyen el primer aspecto a considerar. En teoría, cualquiera que lleve los bits necesarios entre cliente y servidor.

• Puede elegirse entre protocolos orientados a la conexión ó sin conexión:

• La ventaja de contar con una conexión es que la comunicación es mas fácil.

• La desventaja es la pérdida de desempeño.• La mayoría de los sistemas distribuidos ubicados en un

único edificio ó campus utilizan protocolos sin conexión.• Otra decisión es si utilizar un protocolo estandarizado (IP –

UDP) de propósito general ó alguno diseñado específicamente para RPC.

Page 17: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Uso de IP y UDP

• Tiene a su favor:1. El protocolo ya ha asido diseñado, lo que

ahorra tiempo.

2. Se dispone de muchas implementaciones, lo que ahorra trabajo.

3. Sus paquetes pueden ser enviados y recibidos por casi todos los sistemas tipo UNIX, e incluso Windows.

4. Los paquetes IP y UDP pueden transmitirse a través de muchas redes existentes.

Page 18: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Áreas de problemas en RPC

• La RPC mediante el modelo cliente - servidor se utiliza ampliamente como base de los SO distribuidos.

• Lo ideal es que la RPC sea transparente: – El programador no debe poder decir si los procedimientos de

biblioteca son locales o remotos. – El programador debe poder escribir procedimientos sin importar si

serán ejecutados en forma local o remota. – La introducción de RPC en un sistema que se ejecutaba antes en

una única cpu no debe ir acompañada de una serie de reglas que: • Prohíban construcciones antes válidas. • Exijan construcciones que antes eran opcionales.

• La mayoría de los SO distribuidos no cumplen totalmente con estos criterios de transparencia.

Page 19: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Java Remote Method Invocation - RMI• Mecanismo ofrecido en Java para llamar remotamente a un método. Al

ser parte estándar del entorno de ejecución Java, usarlo provee un mecanismo simple en una aplicación distribuida que solamente necesita comunicar servidores codificados para Java.

• Al estar específicamente diseñado para Java, RMI es muy amigable para los programadores, proveyendo paso por referencia de objetos, cosa que no hace SOAP, "recolección de basura" distribuida y paso de tipos arbitrarios, funcionalidad no provista por CORBA.

Page 20: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

RMI (2)• Por medio de RMI, un programa Java puede exportar un

objeto. • A partir de esa operación este objeto está disponible en la

red, esperando conexiones en un puerto TCP. • Un cliente puede entonces conectarse e invocar métodos. • La invocación consiste en dar formato (marshaling) de los

parámetros utilizando la funcionalidad de "serialización" que provee Java, para seguir con la invocación del método en el servidor.

• Mientras esto sucede, el cliente que llamó queda esperando por una respuesta.

• Una vez que termina la ejecución, el valor de retorno es serializado y enviado al cliente.

• El programa cliente recibe este valor como si la invocación hubiera sido local.

Page 21: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

RMI (3)

Page 22: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

RMI (4)

• Para implementar un servidor RMI se debe crear una interfaz que enumere las funciones provistas por el objeto a ser exportado por la red.

• Esta interfaz es compartida entre cliente y servidor. • Del lado servidor es necesario implementar esta interfaz con una

clase que provea la funcionalidad. • Del lado cliente el llamador accede a la misma interfaz, pero

debajo hay un "stub" que da comienzo a la llamada vía la red. • Hasta versiones recientes de Java era necesario generar

manualmente el "stub" por medio de un compilador especial llamado rmic.

• El lado cliente y el lado servidor deberán tener ambos acceso a la definición de las clases utilizadas para el intercambio de parámetros y de valores de retorno.

• Para esto Java tiene la capacidad de dinámicamente obtener las clases que se necesiten desde un servidor.

Page 23: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Desventajas de RMI

Algunas desventajas que pueden comentarse son:• Solo interconecta programas Java. Esto puede subsanarse

utilizando una versión "híbrida" de RMI que utiliza CORBA como transporte.

• Los objetos a ser exportados tienen que heredar (¡sí o sí!) de un objeto base dado por la API.

• En general la implementación de RMI tiende a ser bastante invasiva, condicionando varios aspectos de la solución.

• RMI envía bastante información propia a través de la conexión además de los datos del objeto en sí mismo, por lo que no es apto para cuando la conexión hardware es "lenta", por ejemplo a través de un puerto serie si se requiere un refresco rápido de la información.

• Si se requiere comunicarse con otras tecnologías debe usarse CORBA o SOAP en lugar de RMI.

Page 24: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Common Object Request Broker Architecture (CORBA)

• Estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos.

• Fue definido y está controlado por el Object Management Group (OMG) que define las APIs, el protocolo de comunicaciones y los mecanismos necesarios para permitir la interoperabilidad entre diferentes aplicaciones escritas en diferentes lenguajes y ejecutadas en diferentes plataformas, lo que es fundamental en computación distribuida.

• En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje como un paquete que contiene información adicional sobre las capacidades del código que contiene, y sobre cómo llamar a sus métodos.

Page 25: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

CORBA (2)

• Los objetos que resultan pueden entonces ser invocados desde otro programa u objeto CORBA desde la red.

• En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras pero con más información.

• Una parte medular de CORBA es denominada IDL ("Interface Definition Language").

• A través de este lenguaje neutro se definen interfases utilizadas para generar objetos vía CORBA.

Page 26: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Lenguaje de definición de interfaces - IDL

• CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar los interfaces con los servicios que los objetos ofrecerán.

• Existen implementaciones estándar para Ada, C, C++, Smalltalk, Java y Python. Hay también implementaciones para Perl y TCL.

• Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto).

• El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente.

• El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto.

• CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones.

Page 27: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

CORBA/IDL• CORBA fue uno de los primeros mecanismos utilizados

para lograr interoperabilidad entre Sistemas Empresariales.• A través de CORBA es posible aislar un sistema del

lenguaje en el que está diseñado. En otras palabras: la comunicación se lleva acabo a través de objetos CORBA.

• Obviamente, lo anterior implica que un sistema debe ser diseñado con CORBA.

• Como es probable que una empresa posea algún sistema que opere en CORBA, es conveniente saber que un "Application Server/EJB Container" es capaz de comunicarse con éste.

• El funcionamiento de IDL es actuar como un puente entre determinado lenguaje y el mundo CORBA. Esto es: a partir de un mismo IDL es posible generar interfases para otros lenguajes como C++, Smalltalk y Java.

Page 28: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

CORBA/IDL (2)

• En Java existen dos distinciones de esta terminología IDL:• IDL-a-Java implica que es posible generar interfases Java

a partir de cierto IDL: Suponga que le proporcionan las definiciones IDL de "x" sistema CORBA. A partir de estas definiciones IDL, se generan las respectivas interfases Java, las cuales pueden ser utilizadas en EJB's. Esto permite que sus EJB's interactúen con el sistema CORBA.

• El término Java-a-IDL significa que, partiendo de definiciones Java (EJB's), es posible generar un IDL. Una vez obtenido este IDL, es posible utilizarlo para implementar objetos CORBA en otros lenguajes: C++, Ada, Smalltalk ,etc. Lo anterior permite que una aplicación escrita en estos lenguajes sea capaz de invocar métodos (en efecto actuando como cliente) en un "Enterprise Java Bean“.

Page 29: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

CORBA IDL, Java y C++

CORBA IDL Java C++

Module Package Namespace

Interface Interface Pure abstract class

Method Method Member function

Puede especificarse a partir de este IDL la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. CORBA está diseñado para suministrar transparencia en el lenguaje:

Page 30: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

UML y CORBA• Desde 1999, OMG mantiene una extensión

de UML para CORBA (ver UML CORBA FamIntDef)

• Este documento explica UML CORBAfacility, un repositorio para modelos expresados en UML.

• Permite crear, almacenar y manipular modelos UML.

• Permite que los clientes a ser desarrollados• brinden amplia variedad de posibilidades de

desarrollo basadas en modelos, incluyendo:– Dibujo y animación de modelos en UML y

otras notaciones.– Reforzamiento de los lineamientos de

estilo de procesos y métodos.– Métricas, consultas y reportes.– Automatización de ciertas actividades del

ciclo de vida de desarrollo mediante “design wizards” y generación de código.

UML: Diagrama de estados concurrentes

Page 31: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

General Inter-Orb Protocol (GIOP)

• Es el protocolo utilizado por CORBA por comunicación entre ORBs.

• GIOP define los mensajes y el formato que es pasado sobre ORB entre el cliente y el objeto.

• GIOP es un protocolo de alto nivel que se ubica en la parte mas elevada de un protocolo de transporte como TCP/IP.

• Realmente GIOP puede funcionar sobre cualquier protocolo de la capa de transporte, como puede ser, por ejemplo, UDP.

• La combinación de GIOP ejecutándose sobre TCP/IP es IIOP.

Page 32: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Internet Inter-Orb Protocol (IIOP)• Protocolo desarrollado por Object Management Group (OMG) para

implementar soluciones CORBA sobre World Wide Web. • IIOP permite que los navegadores (browsers) y servidores intercambien

enteros, arreglos, y objetos mas complejos, a diferencia de HTTP, que soporta solamente la transmisión de texto.

• Posibilita que programas escritos en diferentes lenguajes de programación se comuniquen sobre la Internet

• IIOP es una parte crítica de CORBA. • Utilizándole conjuntamente con otros protocolos relacionados, una

compañía puede escribir programas capaces de comunicarse entre si o con los de otra compañía e incluso con programas a desarrollar en el futuro sin necesidad de comprender algo respecto al funcionamiento de los otros programas excepto los servicios suministrados y un nombre.

• CORBA e IIOP compiten con la estrategia similar de Microsoft: Distributed Component Object Model (DCOM).

• Microsoft y OMG se han coordinado para desarrollar puentes de software entre ambos modelos para que los programas diseñados para CORBA puedan comunicarse con los programas diseñados para DCOM.

Page 33: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

RMI-IIOP • Este estándar fue creado intentando simplificar el desarrollo de las aplicaciones

CORBA, mientras preservaba todos los beneficios principales. • RMI-IIOP está ampliamente basado en el concepto Objeto por Valor (descrito

en CORBA) que sirve como un contenedor o un reemplazo directo para estructuras CORBA, uniones, secuencias, arrays y strings.

• No se usa IDL. En cambio, las definiciones de la estructura de datos "supuestas" automáticamente, recolectan los datos necesarios a través de mecanismos de reflexión.

• Cuando CORBA normalmente necesita una clase generada suplementaria para cada estructura de datos no trivial que está siendo transferida, RMI-IIOP solo usa el código generado para los objetos remotos. Menos código generado resulta en menos huella.

• Ambas CORBA y RMI-IIOP usan el mismo estándar de comunicación: General Inter-ORB Protocol GIOP.

• Si se necesitara, es posible generar las definiciones de IDL para las estructuras de datos RMI-IIOP involucradas y usar esas definiciones para alcanzar la interoperabilidad entre las aplicaciones RMI-IIOP y CORBA planas.

• Las versiones recientes de RMI-IIOP derivan sus servants desde la clase estándar Servant (CORBA). Por lo tanto es posible conectarlos al CORBA ORB manualmente, involucrando, si es necesario, el Adaptador de Objeto Portable, Interceptores Portables, servicio de nombrado CORBA y todas las demás características estándar CORBA.

Page 34: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Distributed Component Object Model - DCOM

• El Modelo de Objetos de Componentes Distribuidos, es una tecnología propietaria de Microsoft para desarrollar componentes software distribuidos sobre varios ordenadores y que se comunican entre sí.

• Extiende el modelo 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 .NET • 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).

Page 35: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Capas de componentes de servicios y aplicaciones distribuidas creadas con .NET

1. Componentes de interfaz de usuario (IU)

2. Componentes de proceso de usuario

3. Flujos de trabajo empresariales 4. Componentes empresariales 5. Agentes de servicios 6. Interfaces de servicios 7. Componentes lógicos de acceso a

datos 8. Componentes de entidad

empresarial 9. Componentes de seguridad,

administración operativa y comunicación

Tipos de componentes utilizados en un escenario comercial de ejemplo:

Page 36: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Sistemas de cómputo distribuido

• Las principales tecnologías: CORBA, J2EE y DCOM poseen buenas características para realizar aplicaciones distribuidas.

• Sin embargo, no ofrecen una plataforma realmente manejable para compartir recursos entre los miembros de una organización virtual.

• Algunas carencias notables incluyen descubrimiento de recursos entre los participantes virtuales, seguridad colaborativa y declarativa, construcción dinámica de la organización virtual, y el factor de escala relacionado con entornos potenciales para compartir recursos.

• Otra gran carencia es la baja interoperabilidad entre las tecnologías asociadas a estos protocolos.

Page 37: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

CORBA: ¿La solución por excelencia?

• Muchas empresas emplean CORBA, logrando interoperabilidad de sistemas. Sin embargo, esta interoperabilidad es complicada y costosa.

• Entrar en los detalles específicos de un diseño CORBA sería excesivo. Basta decir que antes de programar en "x" lenguaje, debe ser llevado a un diseño en un IDL, lo que es de por si solo una ardua labor.

• Posteriormente debe realizarse el diseño (vía el IDL) en el lenguaje especifico, instalar un software llamado ORB ("Object Request Broker") que aísla a los diversos sistemas y finalmente coordinar toda esta instalación.

• Obviamente lo anterior requiere no solo trabajo extenso, sino un conocimiento exhausto acerca de las implicaciones que trae a un sistema CORBA: Seguridad, Transacciones, y otras consideraciones.

• Con los Servicios Web, todo se simplifica.

Page 38: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

¿Qué es un Servicio Web?

• Un servicio Web (Web service) es una colección 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.

Page 39: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Estándares empleados

• Web Services Protocol Stack: Así se denomina al conjunto de servicios y protocolos de los servicios Web.

• XML: Es el formato estándar para los datos que se vayan a intercambiar.

• REST, SOAP o XML-RPC: 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 HTTP, FTP, o SMTP.

• WSDL: 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: Protocolo para publicar la información de los servicios Web. Permite a las aplicaciones comprobar qué servicios Web están disponibles.

• WS-Security: Protocolo de seguridad aceptado como estándar por OASIS. Garantiza la autenticación de los actores y la confidencialidad de los mensajes enviados.

Page 40: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Ventajas • Aportan interoperabilidad entre aplicaciones de software

independientemente de sus propiedades o de las plataformas sobre las que se instalen.

• Los servicios Web fomentan los estándares y protocolos basados en texto, que hacen más fácil acceder a su contenido y entender su funcionamiento.

• Al apoyarse en HTTP, los servicios Web pueden aprovecharse de los sistemas de seguridad firewall sin necesidad de cambiar las reglas de filtrado.

• Permiten que servicios y software de diferentes compañías ubicadas en diferentes lugares geográficos puedan ser combinados fácilmente para proveer servicios integrados.

• Permiten la interoperabilidad entre plataformas de distintos fabricantes por medio de protocolos estándar.

Page 41: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Desventajas• Para realizar transacciones, aún no pueden compararse en

su grado de desarrollo con los estándares abiertos de computación distribuida como CORBA.

• Su rendimiento es bajo, si se compara con otros modelos de computación distribuida tales como RMI, CORBA, o DCOM. Es uno de los inconvenientes derivados de adoptar un formato basado en texto, dado que entre los objetivos de XML no se encuentran ni la concisión ni la eficacia de procesamiento.

• Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en firewall cuyas reglas tratan de bloquear o auditar la comunicación entre programas en ambos lados de la barrera.

• Existe poca información de servicios Web para algunos lenguajes de programación.

Page 42: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Motivaciones para crear Servicios Web

• La principal razón para usar servicios Web es que se basan en HTTP sobre TCP en el puerto 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. Los servicios Web se vehiculan por este puerto, por la simple razón de que no resultan bloqueados.

• Otra razón es que antes de que existiera SOAP, no había buenas interfaces para acceder a las funcionalidades de otros computadores en red. Las existents eran ad hoc y poco conocidas, tales como EDI, RPC, u otras APIs.

• 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 acusada.

Page 43: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Resumen

• La heterogeneidad es un reto importante para los diseñadores: – Los sistemas distribuidos deben construirse sobre una

variedad de diferentes redes, sistemas operativos, arquitecturas de computadores y lenguajes de programación.

• Los protocolos de comunicación en Internet enmascaran las diferencias entre redes, así como las plataformas middleware pueden manejar las restantes diferencias: – Representación de datos externa y formato de

parámetros (marshalling). – CORBA empaqueta datos para uso por los receptores

que tienen conocimiento previo de los tipos de sus componentes utilizando un lenguaje para especificación (IDL) de los tipos de datos.

Page 44: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Resumen (2)

• Java serializa datos para incluir información acerca de los tipos de sus contenidos, permitiendo al receptor reconstruirles. – RMI – Cada objeto posee una referencia de objeto (global) remota y

una interfaz remota que especifica cuales, entre sus operaciones, pueden ser invocadas remotamente.

– Las llamadas a métodos locales suministran semántica exactamente una; lo mejor que RMI puede garantizar es como máximo una.

– Las componentes middleware (proxies, skeletons, dispatchers) ocultan a los programadores los detalles del empaquetado, paso de mensajes y localización de objetos.

• Los Servicios Web y la Arquitectura Orientada a Servicios (SOA) constituyen la tecnología que debe establecerse y consolidarse en los próximos años.

Page 46: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Referencias• Patterns for Concurrent, Parallel, and Distributed Systems• Concurrency Patterns• Java 2 Platform, Enterprise Edition (J2EE) Software

Components• Eclipse: Proposal for Enterprise Component Framework• Enterprise Component Services in Windows• Arquitectura de aplicaciones de .NET: Diseño de aplicacion

es y servicios

• Microsoft patterns & practices:– Web Client Software Factory – Web Service Software Factory – Application Block Software Factory

Page 47: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Referencias CORBA y RMI• Object Management Group

– The OMG's CORBA Website– Object Management Group – UML– Estándar oficial CORBA y GIOP

• Universidad de Navarra – Recursos• CORBA / UML Success Story• Distributed Objects and Remote Invocation• IIOP: OMG's Internet Inter-ORB Protocol• IIOP (Internet Inter-ORB Protocol)• Remote Method Invocation Home• Java remote method invocation – Wikipedia• Java RMI over IIOP • RMI-IIOP Programmer's Guide

Page 48: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Referencias BPM• Business Process Management (en español)• Centro Oficial del BPM • Bussiness process modeling• Business Process Management Initiative • BPM Directory• Resources for BPM• Workflow Management Coalition• NetBeans Enterprise Pack SOA Applications and UML

Learning Trails• Select business solutions• Global strategy, innovation and business performance

leadership• From Business Processes to Running Applications

Page 49: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Referencias sobre BPMN, BPEL y BPEL4WS

• Business Process Modeling Notation• Business Process Execution Language (BPEL)• Mapping from UML to the Business Process Execution

Language for Web Services (BPEL4WS)• What is BPEL4WS? Build Better Business Processes with

Web Services in BizTalk Server 2004• OASIS Web Services Business Process Execution

Language (WSBPEL) TC• Introducing BPEL4WS• Java Business Integration• Patterns and Best Practices for Enterprise Integration• Best practices for Web services

Page 50: Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 7. Tópicos avanzados

Dr. Juan José Aranda Aboy

Referencias sobre arquitectura orientada a servicios (SOA)

• Service-oriented architecture• SOA Practitioners Guide: Why Services-Oriented

Architecture? • Service-oriented analysis and design• “Patterns: Service-Oriented Architecture and Web Services“• Patterns for e-business• IBM patterns for e-business (Resources)• Web Service Choreography• Orchestration• Service-oriented modeling and architecture (SOMA)• Service-oriented architecture implementation framework• Enterprise service bus