Interacción orientada a aspectos en entornos multiorganizacionales

Interacci´on Orientada a Aspectos en Entornos Multiorganizacionales∗ Rafael Corchuelo†Jos´eA.P´erez‡Antonio Ruiz–Cort´es§ Abstract Unfortunately, current proposals that focus on separation of concerns assume that objects interact by means of object-oriented method calls, which implies that they embed interactions with others into their functional code. This makes them dependent on this interaction model, and makes it difficult to reuse them in a context in which another interaction model is more suited. In this paper, we show that functionality can be described separately from the interaction model used, which helps enhance reusability of functional code and coordination patterns. In order to show that it is feasible, we adapted the multiparty interaction model to the context of Multi-Organisational Web-Based Systems and developed a class framework to build business objects whose performance rates comparably to a handmade implementation; the development time, however, decreases significantly. Keywords:Aspect orientation, interaction models, multiparty interactions. Resumen Por desgracia, las propuestas actuales de separaci´on de aspectos asumen que los objetos interact´uan mediante invocaci´on de m´etodos, lo que implica que tienen que embeber las interacciones dentro del c´odigo funcional. Esto los hace dependientes de este modelo de interacci´on y hace dif´ıcil reutilizarlos en un contexto en el que otro modelo de interacci´on sea m´as adecuado. En este art´ıculo mostramos que la funcionalidad puede ser descrita de forma independiente al modelo de interacci´on usado, lo que mejora la facilidad de reutilizaci´on del c´odigo funcional y los patrones de coordinaci´on. Para demostrar que es viable, hemos adaptado el modelo de interacci´on entre m´ultiples participantes al contexto de los sistemas multiorganizacionales basados en la web y hemos desarrollado un framework de clases que permite construir objetos de negocio cuyo rendimiento es comparable al de una implementaci´on artesanal; el tiempo de desarrollo, por el contrario, se reduce de forma muy significativa. Palabras clave:Orientaci´on a aspectos, modelos de interacci´on, interacciones multipartitas. ∗Este trabajo est´a subvencionado por la Comisi´on Interministerial de Ciencia y Tecnolog´ıa de Espa˜na (TIC2000-1106-C02-01) †Departamento de Lenguajes y Sistemas Inform´aticos. Escuela T´ecnica Superior de Ingenieros Inform´aticos. Universidad de Sevilla, Espa˜na. e–mail: [email protected] ‡Departamento de Lenguajes y Sistemas Inform´aticos. Escuela T´ecnica Superior de Ingenieros Inform´aticos. Universidad de Sevilla, Espa˜na. e–mail: [email protected] §Departamento de Lenguajes y Sistemas Inform´aticos. Escuela T´ecnica Superior de Ingenieros Inform´aticos. Universidad de Sevilla, Espa˜na. e–mail: [email protected] 1 Introducci´on Los sistemas distribuidos se consideran hoy en d´ıa piezas clave en el desarrollo de sistemas multiorganizacionales. Muchas compa˜n´ıas punteras se han dado cuenta de que Internet es mucho m´as que una zona de compras y ventas y ofrece innumerables posibilidades de triunfar en el mundo de la web. Conforme Internet se asienta, las compa˜n´ıas est´an encontrando nuevas formas de sacar partido a las capacidades que ofrece y existe una demanda creciente de frameworks [14, 15, 16] para construir sistemas multiorganizacionales basados en la web (MOWS, Multi-Organisational Web-based systems) [11, 12] a unos precios razonables. Estos frameworks describen generalmente los MOWS como colecciones de componentes que implementan un conjunto de objetos de negocio que encapsulan un protocolo sem´antico para realizar una unidad de trabajo l´ogico: transferir dinero, procesar una factura, actualizar el registro de un cliente, etc´etera. Desde un punto de vista abstracto, los objetos de negocio modelan actores y datos reales, por lo que permiten mejorar la comunicaci´on entre desarrolladores y clientes y ayudan a reducir los costes de desarrollo [17]. En teor´ıa, los programadores s´olo tienen que preocuparse por la funcionalidad que proporcionan. Por desgracia, esta visi´on es muy idealista puesto que los objetos de negocio deben preocuparse de aspectos tales como la sincronizaci´on, la persistencia o la replicaci´on y en raras ocasiones est´an aislados dentro de un sistema. Es decir, constituyen la parte funcional de un protocolo sem´antico y deben trabajar con otros para conseguir un objetivo com´un. La separaci´on de aspectos ha sido presentada como una herramienta muy prometedora para mejorar la modularidad, facilidad de comprensi´on y de reutilizaci´on del c´odigo funcional. De hecho, esta es la piedra angular del nuevo paradigma de programaci´on orientada a aspectos (AOP) [13, 23, 25]. Desde los primeros trabajos en esta materia, la sincronizaci´on [25], la distribuci´on [25, 36], la seguridad [37], la coordinaci´on [1, 32], la persistencia [24] o la replicaci´on [5] han sido considerados aspectos claros que se pueden tratar usando lenguajes espec´ıficos. Por desgracia, ninguna de las propuestas orientadas a aspectos actuales logran separar la funcionalidad de la interacci´on con otros objetos en un sistema, es decir, el mecanismo mediante el cual dos o m´as objetos entran en contacto y pueden desarrollar conjuntamente una parte del trabajo. Tal y como mostramos en la secci´on 5, las propuestas actuales est´an basadas en variaciones del modelo de interacci´on cl´asico de paso de mensajes y embeben las llamadas a m´etodos en el c´odigo funcional de los objetos, lo que impide a los desarrolladores adaptar su c´odigo con facilidad si el modelo de interacci´on debe ser cambiado. Adem´as, los protocolos sem´anticos suelen estar codificados dentro del c´odigo funcional, lo que hace dif´ıcil tambi´en su reutilizaci´on en escenarios similares [1, 21]. M´as all´a de la comunicaci´on punto a punto, existen otros muchos modelos de interacci´on [28], algunos de los cuales tambi´en proporcionan mecanismos de sincronizaci´on y coordinaci´on. Cada uno tiene sus propias ventajas e inconvenientes, de forma que no existe ning´un modelo de interacci´on universalmente aceptado, sino un amplio abanico de posibilidades. Por lo tanto, parece razonable que existan lenguajes orientados a aspectos que traten el problema de la interacci´on. Estos lenguajes mejorar´ıan la facilidad de reutilizaci´on del c´odigo funcional y de los patrones de coordinaci´on. Adem´as, permitir´ıan a los programadores decidir qu´e modelo de interacci´on se adapta mejor a sus necesidades, lo que tiene un efecto directo sobre la facilidad de comprensi´on, de mantenimiento y evoluci´on. Adem´as, esta tecnolog´ıa para la interacci´on de objetos deber´ıa ser aplicada de forma autom´atica de forma que los objetos de negocio sean tan reutilizables como resulte posible [1, 21]. Esta motivaci´on est´a avalada por resultados previos de investigaci´on de otros autores. En [27], por ejemplo, se indica que gran parte de la evoluci´on, reutilizaci´on e integraci´on del software es de naturaleza inesperada. No obstante, esto no es necesariamente debido a un pobre dise˜no, sino al hecho de que la tecnolog´ıa cambia de una forma tan r´apida que es imposible predecir los caminos a trav´es de los que evolucionar´a. Seleccionar un modelo de interacci´on adecuado es una decisi´on importante puesto que la misma funcionalidad encapsulada en una clase podr´ıa ser integrada de una forma m´as simple en un escenario usando paso de mensajes, pero espacios de tuplas en otro. Por lo tanto, tener una forma de cambiar el modelo de interacci´on mientras se preserva la funcionalidad, parece razonable. Hasta donde alcanza nuestro conocimiento, la separaci´on entre funcionalidad e interacci´on es algo nuevo e innovador que no ha sido tratado hasta ahora en el contexto de la orientaci´on a aspectos. En este art´ıculo demostramos que la idea es viable presentando un modelo de interacci´on para MOWS denominado Open Multiparty Interaction Model yun framework de clases que permite implementar nuestras ideas de forma muy efectiva. El resto del trabajo se organiza como sigue: en la secci´on 2 demostramos que nuestra idea puede ir m´as all´adelainvocaci´on de m´etodos y presentamos el modelo de interacci´on al que aludimos previamente; en la secci´on 3 presentamos el framework de clases que hemos dise˜nado para implementar la propuesta; en la secci´on 4 demostramos que el desarrollo de un MOWS puede beneficiarse del uso de nuestro framework y lo evaluamos teniendo en cuenta el rendimiento y el tiempo de desarrollo; en la secci´on 5 analizamos el trabajo de otros autores y concluimos que ninguno de ellos intenta separar el modelo de interacci´on de otros aspectos; finalmente, presentamos nuestras conclusiones en la secci´on 6. 2 Un modelo de interacci´on de alto nivel para MOWS Un MOWS se puede ver como un sistema compuesto de varios objetos de negocio de grano grueso que residen en diferentes organizaciones y necesitan cooperar frecuentemente. Las primitivas cliente/servidor como el paso de mensajes o la llamada a procedimientos remotos son el est´andar industrial de facto para la interacci´on entre objetos en este contexto. Por desgracia, las soluciones basadas en estas primitivas son dif´ıciles de llevar a cabo en un MOWS en el que varios objetos tienen que cooperar simult´aneamente para llegar a cabo una tarea [19]. Ejemplos habituales son la transferencia de dinero de una cuenta a otra mediante un cajero autom´atico (tres objetos), el pago de impuestos a trav´es de la Red (el contribuyente, la Hacienda p´ublica y la F´abrica Nacional de Moneda y Timbre en el caso de Espa˜na), filtrado en el comercio electr´onico (un cliente, un sistema de filtrado y diversos proveedores de servicio), etc´etera. La tecnolog´ıa actual proporciona servidores de transacciones para agrupar interacciones individuales, pero no existe una clara separaci´on entre el problema a solucionar y la tecnolog´ıa subyacente o el protocolo necesario para coordinar los objetos involucrados en una transacci´on. La mayor parte de los m´etodos de an´alisis o dise˜no orientados a objetos reconocen la necesidad de coordinar a varios objetos al mismo tiempo utilizando diferentes t´erminos: diagramas de objetos [4], modelos de procesos [6], conexiones de mensaje [7], grafos de colaboraci´on [38], diagramas de escenario [33] o colaboraciones [35]. Recientemente, esta necesidad tambi´en ha sido identificada en el campo de las sociedades multiagentes [3, 26]. El modelo de interacci´on subyacente es, sin embargo, llamado a m´etodos en todos los casos, lo que significa que los dise˜nadores a´un tienen que descomponer colaboraciones complejas en secuencias de llamadas. Por desgracia, los lenguajes de programaci´on actuales no ofrecen un soporte adecuado que permita a varios objetos interactuar simult´aneamente, aunque se ha llevado a cabo una gran cantidad de investigaci´on en este campo [28]. JavaSpaces [20] es una de las propuestas m´as actuales. Proporciona mecanismos mediante los cuales un objeto puede recuperar o introducir otros objetos en un espacio de tuplas compartido, lo que permite desarrollar protocolos sem´anticos en forma de flujos de objetos que se mueven a trav´es de uno o varios espacios de tuplas. JavaSpaces es perfecto para aquellas aplicaciones en las que los flujos de trabajos son adecuados, pero no es suficiente en general, principalmente en el campo de los MOWS o las aplicaciones de comercio electr´onico en particular. La raz´on es que muchos problemas en este contexto precisan de varios objetos que cooperen simult´aneamente y transformar estas colaboraciones en flujos de trabajo no es nada sencillo. Por ejemplo, supongamos que deseamos dise˜nar un sistema de tarjetas de d´ebito [34]. Este sistema se compone de varios puntos de venta, varios ordenadores que tienen las cuentas de los vendedores y las de los clientes; el objetivo es dise˜nar un objeto de negocio que sea responsable de transferir dinero de una cuenta de un cliente a una cuenta de un vendedor a trav´es de un punto de venta cada vez que el primero usa su tarjeta de d´ebito. Con JavaSpaces, por ejemplo, es relativamente sencillo desarrollar una soluci´on para resolver este problema, pero tendr´ıa dos inconvenientes fundamentales: primero, la transacci´on completa se puede ver como una interacci´on que coordina a tres objetos, pero este modelo de interacci´on lleva a una soluci´on en la que es necesario descomponer este evento en varias llamadas am´etodos que deben ser coordinadas mediante un protocolo espec´ıfico; adem´as, este protocolo puede ser reutilizable en situaciones similares, pero la separaci´on con JavaSpaces no es suficiente, por lo que no se pueden reutilizar con facilidad [23]. 2.1 Nuestra propuesta Sobre la base de la discusi´on previa, queda clara la necesidad de contar con un modelo de interacci´on capaz de coordinar la acci´on conjunta de varios objetos. Para dise˜nar este modelo partimos del Modelo de Interacci´on entre M´ultiples Participantes [18], que es muy adecuado para capturar la esencia de estos problemas. Proporciona un alto grado de abstracci´on que permite ignorar por completo cu´al es la forma en que varios objetos se sincronizan simult´aneamente o intercambian informaci´on. Esto, adem´as, abre las puertas a una mayor facilidad de adaptaci´on de las aplicaciones puesto que los algoritmos utilizados quedan a un nivel de abstracci´on menor y pueden ser cambiados con facilidad sin afectar al sistema dise˜nado. Este modelo ha atra´ıdo la atenci´on de un buen n´umero de investigadores que se han centrado en aspectos de implementaci´on [9, 19, 39]. No obstante tiene varios defectos que dificultan su aplicaci´on a los MOWS: el modelo no tiene en cuenta la existencia de objetos pasivos, los objetos deben ser conocidos en tiempo de compilaci´on y tienen que tener acceso al estado local de otros objetos para poder comunicarse con ellos. Esta es la raz´on por la que hemos desarrollado una versi´on avanzada del mismo a la que nos referimos como Open Multiparty Interaction Model (OMIM). Para soportar OMIM, hemos dise˜nado un lenguaje llamado CAL [8] y un conjunto de algoritmos que permiten implementarlo [29, 30, 31]. En las secciones siguientes resumimos el trabajo que llevamos hecho; en la secci´on 3, presentamos el framework que hemos desarrollado para implementarlo. 2.2 Soporte ling¨u´ıstico En esta secci´on describimos CAL someramente mediante el ejemplo del sistema de tarjetas de d´ebito presentado previamente. Este problema se puede describir f´acilmente utilizando nuestro modelo puesto que realmente se puede reducir a una interacci´on tripartita entre un punto de venta, una cuenta de cliente y una cuenta de vendedor. La figura 1 muestra una descripci´on del sistema en CAL que analizamos en las secciones siguientes. 2.2.1 Descripci´on de interacciones Las interacciones se definen usando la siguiente sintaxis: interaction nombre[objetos participantes](ranuras) where permisos de lectura/escritura Cada una tiene un nombre diferente, algunos participantes, algunas ranuras y un conjunto de permisos de lectura/escritura. interaction transfer[PointOfSales pos; Account source, dest] (float sum; boolean approval) where pos writes sum, reads approval; source writes approval, reads sum; dest reads approval, sum; behaviour PointOfSales requires interface IPointOfSales; { *[ Wait For Sale(); transfer[pos!self, source!Get Customer Account(), dest!Get Merchant Account()] { sum = Get Price(); Report Result(approval); } ] } behaviour Account requires interface IAccount; { *[ transfer[source!self] { approval = Authorise Payment(sum); [approval →Charge(sum);]; } [] transfer[dest!self] { [approval →Pay In(sum);]; } ] } Figure 1: Una descripci´on en CAL del sistema de tarjetas de d´ebito. En el ejemplo en la figura 1 se ha definido una interacci´on tripartita denominada transfer que permite interactuar a un objeto que interpreta el papel pos y dos cuentas que interpretan los papeles source ydest. Esta interacci´on se convierte as´ı en el canal mediante el cual pueden coordinar sus actividades para conseguir transferir fondos desde la cuenta origen (source) hasta la cuenta destino (dest) mediante el punto de ventas (pos). Las interacciones tienen un estado local que se compone de varias ranuras. transfer,por ejemplo, tiene dos ranuras denominadas sum yapproval. La primera se utiliza para almacenar la cantidad de dinero a transferir y la segunda es un indicador de si la cuenta origen tiene saldo suficiente como para transferir esa cantidad a la cuenta destino. Estas ranuras dan interface IPointOfSales { void Wait For Sale(); float Get Price(); oid Get Customer Account(); OID Get Merchant Account(); void Report Result(boolean done); } interface IAccount { void Charge(float sum); void Pay In(float sum); boolean Authorise Payment(float sum); } Figure 2: Interfaces requeridas por los comportamientos en la figura 1. lugar a un estado local que simula el estado global temporal del modelo de interacci´on entre m´ultiples participantes b´asico [19]. La diferencia m´as importante es que un objeto ya no necesita tener acceso al estado local de otros para obtener la informaci´on que necesita. Los permisos de lectura/escritura indican qu´e participante puede leer o escribir cada ranura. En nuestro ejemplo, el punto de venta es responsable de almacenar la suma a transferir en la ranura sum, mientras que tan s´olo necesita leer la ranura approval para mostrar el mensaje apropiado en la pantalla; la cuenta que interpreta el papel source puede leer la ranura sum para decidir si puede transferir la suma indicada y escribe en la ranura approval para almacenar su decisi´on; finalmente, la cuenta destino puede leer ambas ranuras, pero no tiene permiso para escribir en ninguna de ellas. Un objeto puede ofrecer participaci´on en una o m´as interacciones al mismo tiempo. En cada oferta debe indicar qu´e papel quiere interpretar y puede establecer restricciones sobre qu´e otros objetos deben interpretar los restantes papeles. Una interacci´on se puede ejecutar siempre y cuando exista un conjunto de objetos que est´e de acuerdo en interaccionar. Generalmente nos referimos a esa interacci´on y el conjunto de objetos que la pueden ejecutar como una habilitaci´on. Dado que es necesario garantizar la exclusi´on mutua, un objeto no puede ejecutar m´as de una interacci´on al mismo tiempo. No obstante, como un objeto puede ofrecer participaci´on en diversas interacciones al mismo tiempo, puede encontrarse en m´as de una habilitaci´on. Por esta raz´on, cuando dos o m´as habilitaciones comparten objetos, no pueden ejecutarse al mismo tiempo. El conjunto de habilitaciones que no se pueden ejecutar se dice que son rechazadas. 2.2.2 Descripci´on de los comportamientos Como hemos visto, los objetos participantes en una interacci´on deben interpretar papeles concretos en ella. La sintaxis que utilizamos para describirlos es la siguiente: behaviour nombre requires interfaces { descripci´on de comportamiento } Cada descripci´on requiere que los objetos sobre los que se aplica implementen un conjunto de interfaces. En el ejemplo de la figura 1 se han mostrado dos comportamientos: PointOfSales, que describe el la forma en que se comportan los puntos de venta, y Account, que describe el comportamiento de las cuentas bancarias, ya sea como deudoras o como acreedoras. PointOfSales requiere la interfaz IPointOfSales descrita en la figura 2. Las operaciones de esta interfaz permiten a un objeto esperar a que se produzca la siguiente venta (Wait For Sale) y obtener su importe (Get Price), as´ı como obtener referencias a las cuentas del cliente y el vendedor (Get Customer Account,Get Merchant Account) y mostrar un mensaje en pantalla con los resultados de la operaci´on (Report Result). De manera similar, Account requiere la implementaci´on de una operaci´on para retirar dinero de una cuenta (Charge), para ingresar dinero en ella (Pay In) o para autorizar un pago (Authorise Payment). Las operaciones requeridas por un comportamiento son aqu´ellas cuya ejecuci´on se coordina mediante interacciones multipartitas. Para modelar la forma en que un punto de venta y dos cuentas cooperan utilizamos instrucciones de la forma I[participant list]{comm stat},en donde Ies el nombre de una interacci´on, la lista entre corchetes identifica los objetos que se desea hacer participar en la interacci´on y comm stat es una lista de instrucciones de comunicaci´on que involucra las ranuras de la interacci´on I. Los participantes en la interacci´on se indican mediante expresiones de la forma role!id, lo que significa que el papel role debe ser interpretado por el objeto identificado por id.Laexpresi´on role!self se utiliza para indicar que el papel role ser´a interpretado por el objeto que ejecuta la instrucci´on de interacci´on. Si no se indica nada para un papel, se asume que cualquier objeto puede interpretarlo. Por lo tanto, el comportamiento de un punto de venta se puede resumir as´ı: es un bucle infinito en el que primero espera a que comience una nueva operaci´on de venta y entonces intenta ejecutar la interacci´on transfer junto a los objetos que modelan la cuenta del cliente y del vendedor. Si se llega a ejecutar esta interacci´on, el punto de venta ejecuta entonces su c´odigo de comunicaci´on, que consiste en almacenar la suma a transferir en la ranura sum y mostrar un mensaje en su pantalla. El comportamiento Account tambi´en consiste en un bucle infinito en el que la participaci´on en la interacci´on transfer se ofrece tanto como cuenta de origen como de destino de la transferencia. Si se ejecuta la interacci´on en la que interpreta el primer papel, entonces comprueba si puede afrontar el cargo, almacena el resultado en la ranura approval y actualiza su saldo convenientemente. Si se ejecuta la otra interacci´on, entonces simplemente lee la ranura approval y actualiza el saldo. Evidentemente, una interacci´on multipartita retrasa la ejecuci´on de un objeto que intenta leer una ranura hasta que ha recibido un valor por parte de otro participante. Es decir, un punto de venta que intenta ejecutar la instrucci´on Report Result(approval), es retrasado en su ejecuci´on hasta que la cuenta origen de la transferencia escribe su decisi´on en la ranura approval. Por lo tanto, las instrucciones de comunicaci´on se ejecutan en una regi´on cr´ıtica en la que no pueden producirse condiciones de carrera. 2.2.3 Aplicaci´on de comportamientos a clases Los patrones de comportamiento son abstractos porque describen c´omo un objeto que implementa un conjunto de operaciones puede cooperar con otros. Estas operaciones son tambi´en abstractas y, a menudo, necesitan ser adaptadas antes de aplicar un comportamiento sobre una clase concreta. CAL proporciona un mecanismo simple para adaptar operaciones que se muestra en la figura 3. En este ejemplo, el comportamiento Account ha sido aplicado sobre una clase Java llamada bankAccount. Si se fija, esta clase no proporciona las operaciones que requiere el comportamiento, aunque no es dif´ıcil adaptarlas. Por ejemplo, la operaci´on Authorise Payment(sum) se puede adaptar f´acilmente mediante la expresi´on getBalance() ≥sum. Esta adaptaci´on nos permite escribir comportamientos completamente abstractos y reutilizables. Esto es importante puesto que en otros lenguajes orientados a aspectos como COOL [25], RIDL [25] o AspectJ [22], los aspectos hacen referencia a las clases sobre las que se aplican por nombre, lo que provoca dependencias entre ellos y hace dif´ıcil reutilizar los primeros. class bankAccount { private float balance; public void updateBalance(float sum) {balance += sum; } public boolean getBalance() {return balance; } } map behaviour Account onto class bankAccount where Charge(sum) = updateBalance(-sum); Pay In(sum) = updateBalance(+sum); Authorise Payment(sum) = (getBalance() ≥sum); Figure 3: Aplicaci´on del comportamiento Account sobre la clase bankAccount. 3 Nuestro framework Hemos dise˜nado un framework de clases que ofrece todos los servicios necesarios para implementar CAL1Nuestros objetivos principales a la hora de dise˜narlo fueron los siguientes: 1. Deber´ıa ser extensible de forma que se pudieran incorporar en ´el nuevos middlewares y algoritmos de coordinaci´on de una forma simple. Esto mejora las posibilidades de elecci´on del dise˜nador a la hora de producir la versi´on final de sus objetos de negocio. 2. Debe tener en cuenta la existencia de objetos pasivos y tratarlos adecuadamente. El modelo de interacciones entre m´ultiples participantes tradicional asume que todos los objetos son activos y cuentan con su propio hilo de ejecuci´on, lo que no suele ser cierto en el contexto de los MOWS. 3. Debe permitir integrar otros aspectos ortogonales con facilidad. La figura 4 muestra una fotograf´ıa de un sistema en ejecuci´on que ilustra la arquitectura de nuestra propuesta. Se compone de los elementos siguientes: El gatekeeper:Es uno de los elementos m´as importantes puesto que es responsable de tareas como las pol´ıticas de seguridad, facturaci´on, generar y gestionar los UUID, localizar los coordinadores de interacci´on, etc´etera. Coordinadores de interacci´on: Son responsables de detectar qu´e interacciones est´an habilitadas y de arbitrar entre aqu´ellas que son conflictivas, es decir, comparten objetos. Representantes: Los objetos del usuario se consideran entidades externas al framework que utilizan representantes para interactuar. Esto permite establecer una clara separaci´on entre la funcionalidad y los detalles de coordinaci´on, aunque tambi´en simplifica el dise˜no del framework ya que ´este s´olo tiene que tratar con los representantes. Esto significa que los objetos de usuario puede tener funcionalidad pura o han podido ser previamente mezclados con otros aspectos. Por ejemplo, un objeto que tenga restricciones de sincronizaci´on y de persistencia puede ser implementado utilizando COOL [25] y la propuesta de [5], pero estos detalles son irrelevantes para el framework. Gestores de comunicaci´on: Son los responsables de gestionar la comunicaci´on entre los objetos que participan en una misma interacci´on, es decir, permiten la comunicaci´on, 1Este framework est´a disponible solicit´andolo a los autores. Env´ıe una carta electr´onica a jp[email protected] si desea obtener una copia. O 2 Coordinador de interacción Gestor de comunicación Representante Objeto de negocio I 2 O 1 I 1 O 3 Gatekeeper Repositorio Herramienta de administración Figure 4: La arquitectura de nuestra soluci´on. tienen en cuenta los fallos que se puedan producir, etc´etera. Dado que es posible que existan varias ocurrencias de la misma interacci´on ejecut´andose simult´aneamente, cada una de ellas tiene su propio gestor de comunicaciones. A primera vista, podr´ıa parecer que el gatekeeper es un cuello de botella, pero esto no es as´ı. La raz´on es que la funcionalidad que ofrece se utiliza s´olo cuando aparecen nuevos objetos o interacciones en el sistema o cuando un objeto necesita localizar las referencias a los coordinadores responsables de las interacciones en las que participan. Tambi´en debemos indicar que nada nos impide crear varios gatekeepers que se ejecutan concurrentemente, reduciendo de esta forma el impacto de una ca´ıda o fallo del sistema. Sin embargo, dado que todas las copias del componente en ejecuci´on son funcionalmente equivalentes entre s´ı, solemos referirnos al mismo como “el gatekeeper”. Tambi´en es interesante mencionar que tener representantes para los objetos de usuario no significa ineficiencia puesto que residen en el mismo espacio de memoria que los objetos que representan. Adem´as, separar los aspectos de coordinaci´on de los objetos de negocio en tiempo de ejecuci´on tambi´en dibuja una clara l´ınea de separaci´on entre la funcionalidad que encapsulan y la forma en que interact´uan con otros. Esto facilita la construcci´on de weavers puesto que los representantes se pueden implementar f´acilmente usando una colecci´on de patrones de dise˜no a la que de forma colectiva se le suele hacer referencia como Role Object Pattern [15]. Esto ayuda a mantener separados los distintos contextos en los que un objeto puede participar y facilita el mantenimiento de los mismos. La figura 5 muestra el aspecto del framework que hemos dise˜nado. F´ıjese en que nuestro dise˜no es lo suficientemente general como para acomodar con facilidad diversos middlewares o algoritmos de coordinaci´on o de comunicaci´on propuestos en la bibliograf´ıa, entre ellos los nuestros [30, 29]. El dise˜nador puede de esta forma decidir cu´al es la mejor forma de implementar sus objetos de negocio: si todos los objetos conocen aqu´ellos con los que van a interactuar se puede utilizar un algoritmo cl´asico como el de Bagrodia et al. [2] o los de Corchuelo et al. [9, 10]; en caso contrario ser´a preciso utilizar los algoritmos de P´erez et al. [30, 29]. [19] N. Francez and I. Forman. Interacting processes: A multiparty approach to coordinated distributed programming. Addison–Wesley, 1996. [20] E. Freeman, S. Hupfer, and K. Arnold. JavaSpaces Principles, Patterns, and Practice. Addison–Wesley Longman, June 1999. [21] S. Frølund and G. Agha. A language framework for multi-object coordination. In O. Nierstrasz, editor, Proceedings of the European Conference on Object-oriented Programming ECOOP’93, pages 346–360, Kaiserslautern, Germany, 1993. Springer–Verlag. [22] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersen, J. Palm, and W.G. Griswold. An overview of AspectJ. In Proceedings European Conference on Object-Oriented Programming ECOOP’01, volume 2072 of Lecture Notes in Computer Science, pages 327–353. Springer-Verlag, 2001. [23] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J. Loingtier, and J. Irwin. Aspect-oriented programming. In Proceedings of the European Conference on Object-Oriented Programming ECOOP’97, pages 220–242. Lecture Notes in Computer Science, Springer–Verlag, 1997. [24] K. Liebherherr. From transience to persistence in object-oriented programming: Patterns and architectures. ACM Computing Surveys, 28A(4):39–41, December 1996. [25] C.V. Lopes. D: A Language Framework for Distributed Programming. PhD thesis, Xerox Palo Alto Research Center, 1998. [26] J. Odell, H.V.D. Parunak, and B. Bauer. Representing agent interaction protocols in UML. In P. Ciancarini and M. Wooldridge, editors, Proceedings of the 22nd International Conference on Software Engineering ISCE’01, number 1957 in LNCS, pages 121–140. Springer–Verlag, June 2001. [27] H. Ossher and P. Tarr. Using multidimensional separation of concerns to (re)shape evolving software. Communications of the ACM, 44(10):43–50, 2001. [28] G. Papadopoulos and F. Arbab. Coordination models and languages. In Advances in Computers, volume 46. Academic Press, 1998. [29] J. A. P´erez, R. Corchuelo, D. Ruiz, and M. Toro. An order–based, distributed algorithm for implementing multiparty interactions. In Coordination Models and Languages. Proceedings of the 5th International Conference COORDINATION 2002., Lecture Notes in Computer Science, pages 250–257, York, United Kingdom, 2002. Springer. [30] J.A. P´erez, R. Corchuelo, D. Ruiz, and M. Toro. A framework for aspect–oriented multiparty coordination. In Working Conference on Distributed Applications and Interoperable Systems DAIS’01, page To appear, Krakow, Poland, 2001. Kluwer Academic Publishers. [31] J.A. P´erez, R. Corchuelo, D. Ruiz, and M. Toro. An enablement detection algorithm for open multiparty interactions. In Applied Computing 2002. Proceedings of the 2002 ACM Symposium on Applied Computing, pages 378–384, Madrid, Spain, March 2002. ACM Press. [32] M. Pinto, L. Fuentes, M.E. Fayad, and J. M. Troya. Separation of coordination in a dynamic aspect-oriented framework. In Proceedings of the First International Conference on AspectOriented Software Development AOSD’01, Enschede, The Netherlands, April 2002. [33] T. Reenskaug, P. Wold, and O.A. Lehne. Working With Objects. The OOram Software Engineering Method. Manning Publications Co., August 1995. [34] A. Ruiz-Cort´es, R. Corchuelo, J.A. P´erez, A. Dur´an, and M. Toro. An aspect–oriented approach based on multiparty interactions to specifying the behaviour of a system. In Principles, Logics, and Implementations of High-Level Programming Languages PLI’99. Workshop on Object-Oriented Specification Techniques for Distributed Systems and Behaviours, pages 56–65, Paris, France, 1999. [35] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Object Technology Series. Addison Wesley Longman, Reading, Massachussetts, 1999. [36] A.R. Silva, P. Sousa, and J.A. Marques. Development of distributed applications with separation of concerns. In Proceedings of the 1995 Asia-Pacific Software Engineering Conference APSEC’95. IEEE Press, 1995. [37] J. Viega and D. Evans. Separation of concerns for security. In P. Tarr, A. Finkelstein, W. Harrison, H. Nusibeh, H. Osser, and D. Perry, editors, Proceedings of the Workshop on MultiDimensional Separation of Concerns in Software Engineering at ICSE’00, 2000. [38] R. Wirfs-Brock and B. Wilkerson. Designing Object-Oriented Software. Prentice–Hall, August 1990. [39] A.F. Zorzo and R.J. Stroud. A distributed object-oriented framework for dependable multiparty interactions. ACM Sigplan, 34(10):435–446, October 1999.