ProActive Parallel Suite es un software de código abierto para la orquestación de cargas de trabajo empresariales , parte de la comunidad OW2 . Un modelo de flujo de trabajo permite definir un conjunto de ejecutables o scripts , escritos en cualquier lenguaje, junto con sus dependencias, de modo que ProActive Parallel Suite pueda programar y orquestar ejecuciones mientras optimiza el uso de recursos computacionales .
ProActive Parallel Suite se basa en el patrón de diseño de " objeto activo " (ver Objetos activos) para optimizar la distribución de tareas y la tolerancia a fallos.
El modelo fue creado por Denis Caromel, profesor de la Universidad de Niza Sophia Antipolis . [1] Posteriormente, los miembros del equipo OASIS del INRIA realizaron varias ampliaciones del modelo . [2] El libro A Theory of Distributed Objects presenta el cálculo ASP que formaliza las características de ProActive y proporciona semántica formal al cálculo, junto con las propiedades de la ejecución del programa ProActive. [3]
Los objetos activos son las unidades básicas de actividad y distribución que se utilizan para crear aplicaciones concurrentes mediante ProActive. Un objeto activo se ejecuta con su propio hilo . Este hilo solo ejecuta los métodos invocados en este objeto activo por otros objetos activos y los de los objetos pasivos del subsistema que pertenece a este objeto activo. Con ProActive, el programador no tiene que manipular explícitamente los objetos Thread, a diferencia de lo que ocurre en Java estándar.
Los objetos activos pueden crearse en cualquiera de los hosts involucrados en el cómputo. Una vez que se crea un objeto activo, su actividad (el hecho de que se ejecuta con su propio hilo) y su ubicación (local o remota) son perfectamente transparentes. Cualquier objeto activo puede manipularse como si fuera una instancia pasiva de la misma clase.
Un objeto activo se compone de dos objetos: un cuerpo y un objeto Java estándar. El cuerpo no es visible desde el exterior del objeto activo.
El cuerpo es responsable de recibir llamadas (o solicitudes ) en el objeto activo y almacenarlas en una cola de llamadas pendientes. Ejecuta estas llamadas en un orden especificado por una política de sincronización. Si no se especifica una política de sincronización, las llamadas se gestionan de forma " primera en entrar, primera en salir " (FIFO).
El hilo de un objeto activo elige entonces un método en la cola de solicitudes pendientes y lo ejecuta. No se proporciona paralelismo dentro de un objeto activo; esta es una decisión importante en el diseño de ProActive, que permite el uso de condiciones "pre-post" e invariantes de clase .
Del lado del subsistema que envía una llamada a un objeto activo, el objeto activo está representado por un proxy . El proxy genera objetos futuros para representar valores futuros, transforma las llamadas en objetos Request (en términos de metaobjeto, esto es una reificación ) y realiza copias profundas de los objetos pasivos pasados como parámetros.
ProActive es una biblioteca diseñada para desarrollar aplicaciones en el modelo introducido por Eiffel//, una extensión paralela del lenguaje de programación Eiffel .
En este modelo, la aplicación se estructura en subsistemas . Hay un objeto activo (y, por lo tanto, un subproceso) para cada subsistema, y un subsistema para cada objeto activo (o subproceso). Por lo tanto, cada subsistema está compuesto por un objeto activo y cualquier número de objetos pasivos (posiblemente ningún objeto pasivo). El subproceso de un subsistema solo ejecuta métodos en los objetos de este subsistema. No hay "objetos pasivos compartidos" entre subsistemas.
Estas características afectan la topología de la aplicación. De todos los objetos que componen un subsistema (el objeto activo y los objetos pasivos), solo el objeto activo es conocido por los objetos externos al subsistema. Todos los objetos, tanto activos como pasivos, pueden tener referencias a objetos activos. Si un objeto o1 tiene una referencia a un objeto pasivo o2 , entonces o1 y o2 son parte del mismo subsistema.
Esto también tiene consecuencias en la semántica del paso de mensajes entre subsistemas. Cuando un objeto en un subsistema llama a un método en un objeto activo, los parámetros de la llamada pueden ser referencias en objetos pasivos del subsistema, lo que daría lugar a objetos pasivos compartidos. Es por eso que los objetos pasivos pasados como parámetros de llamadas en objetos activos siempre se pasan por deep-copy . Los objetos activos, por otro lado, siempre se pasan por reference . Simétricamente, esto también se aplica a los objetos devueltos de los métodos llamados en objetos activos.
Gracias a los conceptos de llamadas asincrónicas , futuros y sin intercambio de datos, una aplicación escrita con ProActive no necesita ningún cambio estructural (en realidad, casi ningún cambio), ya sea que se ejecute en un entorno secuencial, multiproceso o distribuido .
Siempre que sea posible, una llamada a un método en un objeto activo se convierte en una solicitud asincrónica. Si no es posible, la llamada es sincrónica y se bloquea hasta que se recibe la respuesta. Si la solicitud es asincrónica, devuelve inmediatamente un objeto futuro .
El objeto futuro actúa como un marcador de posición para el resultado de la invocación del método que aún no se ha realizado. Como consecuencia, el hilo que realiza la llamada puede continuar con la ejecución de su código, siempre que no necesite invocar métodos en el objeto devuelto. Si surge la necesidad, el hilo que realiza la llamada se bloquea automáticamente si el resultado de la invocación del método aún no está disponible. Aunque un objeto futuro tiene una estructura similar a la de un objeto activo, un objeto futuro no está activo. Solo tiene un stub y un proxy.
El fragmento de código que aparece a continuación resalta la noción de objetos futuros. Supongamos que un usuario llama a un método fooy a un método barde un objeto activo a; el foométodo devuelve void y el barmétodo devuelve un objeto de la clase V:
// una comunicación asincrónica tipificada unidireccional hacia el AO (remoto) a // se envía una solicitud a a . foo ( parámetro ); // una comunicación asincrónica tipificada con resultado. // v es primero un Futuro esperado, que se completará de forma transparente después de // el servicio de la solicitud y la respuesta V v = a . bar ( param ); ... // uso del resultado de una llamada asincrónica. // si v sigue siendo un futuro esperado, activa una espera automática: Espera por necesidad v . gee ( param ); Cuando foose llama a un objeto activo a, retorna inmediatamente (ya que el hilo actual no puede ejecutar métodos en el otro subsistema). De manera similar, cuando barse llama a a, retorna inmediatamente pero el resultado vaún no se puede calcular. Se devuelve un objeto futuro, que es un marcador de posición para el resultado de la invocación del método. Desde el punto de vista del subsistema que realiza la llamada, no hay diferencia entre el objeto futuro y el objeto que se habría devuelto si se hubiera realizado la misma llamada a un objeto pasivo.
Una vez que ambos métodos han regresado, el hilo que realiza la llamada continúa ejecutando su código como si la llamada se hubiera realizado efectivamente. La función del mecanismo futuro es bloquear el hilo que realiza la llamada cuando geese llama al método vy el resultado aún no se ha establecido: esta política de sincronización entre objetos se conoce como esperar por necesidad .
{{cite book}}: |journal=ignorado ( ayuda ){{cite book}}: |journal=ignorado ( ayuda )