DAOP

Home Page
CAM
DAOP-ADL
DAOP
Implementations
Applications
Tools
Publications
Members
Contact Info

Dynamic Aspect-Oriented Platform

The underlying infrastructure supporting the CAM model is a Component-Aspect Platform (DAOP, a Dynamic Aspect Oriented Platform) where the plugging of software aspects into components is performed at runtime. The DAOP platform is a distributed component-aspect middleware platform for running applications conforming to the CAM model. Figure 3 shows the architecture of the DAOP middleware platform.

Figure 1. Architecture and Services of the DAOP Platform

For each user connecting to a distributed CAM/DAOP application, an instance of the DAOP platform is created. These instances will register themselves in a lightweight CAM/DAOP kernel. The main objects of this kernel are a HomeInfo object, which stores information about all the applications initiated in that kernel and a DirService object, which provides access to a LDAP directory server to be used by applications.

Infrastructure of the DAOP Platform

In this section we explain the internal structure of the DAOP platform (the elements that appear below the DAOP Platform class in Figure 1). Basically, the DAOP platform arranges its internal information in two objects. The information contained in these objects is used to implement the services offered by the DAOP platform.

1. The ApplicationArchitecture class and its subclasses store the architectural description of the application. This information is specified in an XML-based document using the DAOP-ADL language. Using this language, the CAM model of the application is transformed to a set of XML documents that can be easily interpreted by the DAOP platform at runtime to perform the dynamic weaving of components and aspects.

2. The ApplicationContext object holds the references of all the components and aspects currently instantiated for a specific application. Thus, the ApplicationContext class is like a name service that links component and aspect instances with their role names and role instance names.

Since for each user who is connected to a CAM/DAOP application an instance of the DAOP platform is created, these instances must implement the RemoteDAOPPlatform interface. This interface defines the methods needed to allow the communication among the different instances of the DAOP platform.

Services of the DAOP Platform

Similar to other component platforms, the DAOP platform provides a set of common services to develop distributed applications (the elements that appear above the DAOP Platform class in Figure 1). The DAOP platform uses the information stored in the ApplicationArchitecture object and the ApplicationContext described above to provide all these services.

1. Component and Aspect Instantiation. DAOP components and aspects can create or destroy other components using the corresponding methods of the ComponentFactory interface (see Figure 3). Components are identified by a role and a role instance name. Thus, a software component just needs to specify strings with the role name and the instance name, and never its implementation class. Likewise, aspects are also created or destroyed, but only by the platform using a similar interface that also identifies aspects by their role name, which is this case is private and only used by the DAOP platform.

2. Component Communication and Coordination Service. As in other component platforms, DAOP allows components to send synchronous and asynchronous messages, as well as to broadcast a message to several targets. DAOP also allows components to throw events to other components. DAOP implements four primitives in order to send messages and events between components (see the CommunicationService interface and all its subinterfaces in Figure 1). Communication by events is very useful to decouple components, and is specially suited to enable (re)use. By intercepting the throwing of events, the DAOP platform provides a join point that occurs within the execution of a component method. The location (local/remote) of the target component or a message or an event is transparent to the source component and is resolved at runtime by the DAOP platform.

3. Aspect Evaluation. The component composition mechanism described above is extended in DAOP to incorporate dynamic evaluation of aspects. When a component creates or finalizes other components or sends a message or an event using any DAOP communication primitives, the DAOP platform intercepts it and evaluates the corresponding aspects. DAOP aspects should implement the AspectEvaluationService interface that includes the different advice methods.

4. Property Storage. The CAM model defines the concept of property to solve data dependencies between entities of the CAM model. Using this service a producer entity will set the value of a property with the setProperty(String propertyname,Object value) method of the PropertyService interface in Figure 3, and later a consumer entity of that property will get its current value with the getProperty(String propertyname) method. Property instances are stored in the ApplicationContext object of the DAOP platform.

5. Persistence. The PersistenceService interface provides the functionality required to store and retrieve the current state of components. This service may be used to implement a persistence aspect that simply has to invoke the {\small\sf storeComponent(CID component)} and {\small\sf retrieveComponent(CID component)} methods. The implementation of these methods serializes or de-serializes the attributes that are part of the state of a component (see the {\small\sf State} class of the CAM model of Figure~\ref{fig:CAMmodel}), and then store or retrieve them in a data repository of the DAOP platform.

6. Application Architecture Configuration. The AAConfigurationService interface provides a set of methods to modify at runtime the software architecture of the application, which is stored in the ApplicationArchitecture object as described before. It is possible to add, modify or remove the description of components, aspects, properties, or even composition rules using the corresponding methods of the AAConfigurationService interface.

 

Home Page | CAM | DAOP-ADL | DAOP | Implementations | Applications | Tools | Publications | Members | Contact Info

 Copyright
UMA CBSD & AOSD Group, 2005.
Last Update: 05 jun 2006.