MODELO ORIENTADO A OBJETOS Los objetos encapsulan atributos (forman el estado) y métodos (servicios que brinda) lo que le da una cierta funcionalidad. Los objetos coordinan sus actividades a través del llamado mutuo de métodos. En los ’09 hubo un gran interés en combinar el modelo orientado a objetos con el paralelo/distribuido, teniendo en cuenta las características del primero que ayudan a la creación de grandes sistemas: • Encapsulación: dada por una clara separación entre interfaz e implementación. Los objetos pueden implementarse en diferentes lenguajes, solo se necesita una forma común de definir la interfaz. Esto ayuda para el mantenimiento, debbuging, y el desarrollo en forma colaborativa. • Herencia: los objetos relacionados pueden compartir parte del código. Mejora la productividad. El modelo orientado a objetos tiene un gran número de objetos autónomos con distinta funcionalidad disponibles en un sistema distribuido. Los objetos corren en espacios de direccionamiento disjuntos. A partir de rutinas de comunicación explicitas ellos invocan y usan la funcionalidad de los otros objetos. Se distinguen tres enfoques para combinar el modelo orientado a objetos con el paralelo/distribuido: • Paralelismo oculto dentro del objeto. • Procesos independientes de los objetos, que llaman a distintos métodos de distintos procesos. Se necesitan mecanismos de sincronización. Modelo Java Threads. • Cada objeto está asociado con uno o más procesos que ejecutan los accesos al objeto. A este modelo llamaremos Modelo Orientado a Objetos. Se ven dos clases de Modelo Orientado a Objetos: • Objetos Distribuidos. • Objetos Activos. MODELO DE OBJETOS DISTRIBUIDOS En este modelo se distribuyen objetos coarse grained. Del punto de vista del paralelismo es la tercer forma de realizar el paradigma cliente/servidor (a parte de socket y RPC), así, los objetos distribuidos son tareas paralelas y MPMD, donde cada interacción entre dos objetos sigue el patrón cliente/servidos. En muchos casos la estructura del sistema es peer-to-peer, lo cual significa que el rol de cliente o servidos puede cambiar. Al relacionar el modelo de objetos distribuidos con el paradigma cliente/servidor, los métodos pasan a ser servicios. Cada objeto distribuido está sujeto a un proceso server que realiza las operaciones del objeto. Los procesos clientes deben pedirlo a un proceso server. La mecanismo de comunicación entre un cliente y un servidor es llamado remote method invocation (RMI), el cual es una adaptación de RPC, por lo cual tiene ciertos progresos con respecto a este. Una diferencia a tener en cuenta es que una misma invocación (mismo método y parámetros) puede dar resultados diferentes según el estado del objeto, mientras que en RPC, el mismo llamado (igual procedimiento y parámetros) produce el mismo resultado (a menos que acceda a Base de Datos o variables globales). Se utilizan en sistemas middleware como CORBA, DCOM, JavaRMI. CORBA (Common Object Request Broker Architecture) Es un standar soportado por muchas implementaciones y tiene un importante significado comercial. Algunas características a tener en cuenta es la forma de manejar los siguientes puntos: • Interfaces. • Transparencia de Ubicación. • Invocación a métodos remotos. • Activación de los objetos. • Creación de objetos. Interfaces CORBA soporta el trabajo en entornos heterogéneos (permite interoperabilidad entre distintas máquinas y con objetos escritos en diferentes lenguajes) gracias a la clara separación entre la interfaz y la implementación. Para lograr esto necesita que los objetos definan su intefaz de forma común, aunque la implementación se realice en diferentes lenguajes. Para esto CORBA define un lenguaje de definición de interfaces (IDL), a través del cual cada objeto define su interfaz, la cual consiste del nombre del objeto, el nombre de los servicios que brinda (junto con los parámetros que necesita) y posibles atributos y excepciones a los cuales se puede acceder. Cualquier programa nuevo o existente puede convertirse a un objeto CORBA definiendo su interfaz en este lenguaje (IDL). Este lenguaje (IDL) soporta un mecanismo de herencia para la organización de los objetos. Este mecanismo se aplica solo a las interfaces, en la implementación se debe hacer con los mecanismos del lenguaje usado (si lo provee). Transparencia de Ubicación La idea es hacer referencia a otros objetos sin que se conozca la ubicación real de este. Este manejo tiene varias ventajas como: facilita la programación, permite la migración de objetos, permite sacar, agregar o modificar objetos sin alterar el resto del sistema. En CORBA, existe un componente básico llamado Object Request Broker (ORB), el cual se encarga de manejar la comunicación entre el objeto cliente y el objeto servidor de manera de lograr la transparencia de Ubicación buscada. El cliente conoce una referencia al servidor en vez de la ubicación física de este. Esta referencia es un identificador unívoco en todo el sistema que se le otorga al ser creado el objeto. El cliente envía el pedido al ORB indicando la referencia al objeto servidor y el método invocado, este obtiene la ubicación física del servidor, y le reenvía el pedido para que lo resuelva. Invocación a Métodos Remotos (RMI) CORBA soporta dos variantes básicas de RMI a partir de diferentes módulos: • Invocación Estática. • Invocación Dinámica. La Invocación Estática es similar a RPC. La interfaz de un objeto se envía junto con un precompilador con el cual se genera un fragmento de código del lado del cliente (stub) y otro del lado del servidos (skeleton). Una invocación estática sigue los siguientes pasos: 1. El cliente envía el pedido a su stub correspondiente, y queda esperando el resultado en forma pasiva. 2. El stub transforma la invocación (en el lenguaje de la implementación del objeto cliente) a una forma común para todos los objetos (en lenguaje IDL). Y la envía al ORB. 3. El ORB determina la ubicación física del servidor y pasa el pedido al objeto Adapter. 4. El objeto Adapter invoca al skeleton del servidor. 5. El Skeleton transforma la invocación en IDL a una forma conocida por el lenguaje de implementación del objeto servidor y realiza dicha invocación. 6. Al terminar el servicio, el resultado es retornado al cliente. La Invocación Dinámica es más compleja. CORBA mantiene un depósito de interfaces, la cual almacena todas las interfaces del sistema. Usando este depósito, el cliente puede obtener detalles del objeto servidor, tales como el nombre y los parámetros de un servicio. También se define una Interfaz de Invocación Dinámica (DII) en cada objeto, el cual es una especie de stub de propósito general. Para realizar una Invocación Dinámica el cliente utiliza el depósito de interfaces para obtener el nombre y los parámetros para la invocación, y envía el pedido al DII, el cual actúa de la misma forma que los stub de la invocación estática (transforma el pedido y lo envia al ORB). Este tipo de invocación es más flexible, pero más complejo y lento. Usa un protocolo de dos fases no bloqueante. El cliente entrega el pedido al DII y continua con su trabajo, después se llama a una segunda función para esperar explícitamente la finalización del servicio. Un modo especial de invocación soportado por CORBA el llamado Oneway. En este caso el cliente no necesita ninguna respuesta al servicio pedido, por lo cual realiza el pedido y continua con su trabajo, sin asegurarse que el servicio haya sido realizado. De por sí, la invocación estática es bloqueante y la dinámica es no bloqueante, pero esto puede modificarse. Activación de Objetos Como no todos los procesos necesitan correr continuamente, los procesos son activados y desactivados por necesidad, y esto es manejado por el objeto Adapter. Una misma interfaz puede ser implementada por multiples objetos, cada uno con una referencia o identificador diferente. Los objetos son creados por procesos server, el cual es responsable del objeto durante toda su vida. CORBA mantiene un depósito de implementaciones (de objetos) en donde cada objeto es ubicado al crearse indicando, entre otras cosas, el proceso server que lo creo. Cuando un cliente quiere acceder a un objeto a través de RMI, el objeto adapter chequea si el proceso responsable del objeto al que se quiere acceder está activado, y en caso contrario lo activa, para después enviar el requerimiento. Todo esto se maneja de forma transparente al programador. Cada vez que se desactiva un proceso, el estado de todos sus objetos (objetos de los cuales es responsable) se pierde. Para mantener el estado, este debe ser guardado en memoria persistente al desactivar el server, de la cual es recuperado al volver a activar el proceso. Creación de Objetos Normalmente, los objetos son creados por servidores. CORBA provee unos objetos especiales llamados Factory, los cuales crean objetos en nombre de los clientes. DCOM (Distributed Component Object Model) Es la competencia de CORBA realizado por Microsoft. Su funcionalidad es muy parecida a la de CORBA, y en la actualidad se soporta la interoperabilidad entre CORBA y DCOM. Java RMI Es otro sistema middleware como CORBA y DCOM. No soporta interoperabilidad entre lenguajes, solo trabaja con Java. Su funcionalidad es bastante más reducida que los anteriores. MODELO DE OBJETOS ACTIVOS Conceptualmente la diferencia principal con el modelo de Objetos Distribuidos es que el modelo de Objetos Activos se enfoca en la comunicación asincrónica en vez de la comunicación sincrónica del primer modelo. Por otro lado, el modelo de Objetos Activos está orientado al área de investigación de la integración del modelo orientado a objetos con el paralelismo, en lugar de estar orientado al desarrollo de sistemas comerciales. Los objetos activos no son solo para programación distribuida, sino también para programación paralela. Aunque se puede implementar el paradigma cliente/servidor, las comunicaciones individuales no siguen este patrón. En cambio, los objetos son considerados peers que coordinan sus actividades por intercambiar mensajes. Aunque el propósito del intercambio de mensajes puede ser el uso de servicios remotos, el modelo no asocia explícitamente la comunicación con el uso de servicios. Los objetos Activos tienen dos características claves: • Además de Datos y Métodos, encapsulan uno o varios procesos. • Se comunican por intercambio de mensajes asincrónicos. Este modelo se origina con el modelo Actor. El Modelo Actor En este modelo una comunidad de actores cooperan entre sí para obtener el resultado. Cada actor es una entidad autónoma que se caracteriza por: • Su Conducta: se refiere a la funcionalidad. En términos de programación orientada a objetos, se corresponde con el conjunto de valores para los atributos, y con el conjunto de métodos que el actor implementa. • Su Cola de Mails: cola con requerimientos pendientes para el objeto. • Su Dirección de Mail: identificador o referencia del objeto. Los Actores son reactivos, es decir que se encuentran en forma pasiva hasta que llega un mensaje (requerimiento) para procesar, y vuelven a su estado pasivo hasta un nuevo pedido. Para el intercambio de mensajes entre los actores se procede de la siguiente manera: 1. El que envía el mensaje, especifica la dirección de mail del receptor (igual que el identificador en el modelo de objetos distribuidos) y el contenido del mensaje. Y continua con su trabajo (comunicación no bloqueante) confiando en que en algún momento el mensaje se entregará. 2. Al llegar al receptor, el mensaje se encola al final de la cola de mails. 3. Cuando llega su turno se analiza el mensaje, y según su contenido, el actor responde con una o más de las siguientes opciones: • Envía un mensaje a otro actor. • Crea otro actor. • Reemplaza su conducta. El modelo actor soporta paralelismo en dos niveles: • Inter-Actor: distintos actores que corren en paralelo en el mismo o diferente nodo del sistema distribuido. • Intra-Actor: múltiples líneas de control que corren en paralelo en un actor. Es difícil de lograr por la necesidad de sincronización en el acceso al comportamiento (a los atributos) del actor. IMPLEMENTACIÓN DE LENGUAJES Existen muchos lenguajes que implementan este modelo. Ellos se diferencian por la forma en que se resuelven los problemas producidos por el paralelismo, como la sincronización, comunicación, etc. Algunos de los criterios para clasificar y caracterizar los lenguajes orientados a objetos paralelos/distribuidos son: • Grado de concurrencia: si brindan paralelismo intra-objetos, inter-objetos, o ambos. • Mecanismos de Sincronización: como se maneja la sincronización en caso de permitir paralelismo intra-objetos. • Selección de Mensajes: si brinda alguna manera de seleccionar o restringir los servicios que puede ejecutar en un cierto momento (por ejemplo por guardas). • Soporte para Paralelismo de Datos: si posee constructores para crear múltiples objetos al mismo tiempo. • Localidad: si provee constructores para explícitamente ubicar y migrar objetos.