Modelo Orientado a Objetos

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.