Modeling software with AADL: the CARISM architecture

CARISM is a middleware architecture for client/server applications. It has been developped at the École nationale supérieure des télécommunications of Paris (ENST) to address dynamic adaptation issues.

Within a typical client/server architecture, the client application sends requests to the server and gets responses, without wondering if the server is heavily loaded, or if the network can correctly transmit the information, etc. Yet, in the case of a mobile client (e.g. a personnal digital assistant), it is important to consider those parameters (especially the network quality); we also have to take the capabilities of the mobile device into account (is it better to compress the data, thus consuming more battery power, but less network bandwidth?...)

The CARISM project proposes an architecture that manages those questions by driving the requests of the application, according to some rules. This way, the client application may send requests for a "degraded" service if it detects that asking for a full service request is not adequate with the current environment.

For example, in the case of a weather forecast service, the client may ask for a picture representing the map of the country, with suns and clouds, and figures for the temperatures, pressures, etc. But if it detects that a service of such a quality is not possible, it may ask for a single text describing weather and temperature.

One of the main aspects of CARISM is that this kind of adaptation is fully transparent to the user. It is built on Java Message Service (JMS), a message passing middleware implementation.

More information on the CARISM project can be found at http://www.picolibre.org/projects/carism/.

The goal of this session is to show how to describe an architecture like CARISM using the AADL. We will focus on the client architecture, since it is the main actor of a CARISM system.

The main idea is to model the different adaptation states of the client (full service requests, degraded service requests, etc.) as AADL modes, thus illustrating that these are different configurations of the application.

The questions often suggest a way to model the elements of the architecture, but you are absolutely free to design your system the way you feel it (provided that you obtain something which seems consistent): this session is made to let you experiment on the possibilites of AADL.

This session is focused on software components. So we will not describe the execution platform components, such as buses, processors, etc.

You first have to model the client and the server using component types. Since they both are computer programs, describing them as process seems to be a good choice. Yet, the server may be described as a system, to avoid giving too much information on its structure.

Since CARISM is based on message passing middleware, data exchanged between the client and the server shall be modeled with event data ports.

The server is supposed to send information related to its status (load, capabilities, etc.) to the client, so that the client can have a global knowledge of the environment. This kind of information may be modeled using data port or event data port.

Typically, the architecture of the server is made of two main components:

• the main application
• a configuration manager that controls the way the application should behave (level of the demanded service, data compression, fragmentation of the messages, etc.)

The manager configures the application according to information comming from both the server (server load, etc.) and the client (latency between the request and the response, etc.)

A good way to model such an architecture is to use two threads: one for the application, the other for the configuration manager. The manager receives information from the server and from the client application, computes them, and sends signals to the client application to change its configuration (i.e. its mode). Those threads are subcomponents of the process defined in the first step.

So, the manager should be modeled by a thread which can receive event data from the server and the client application, and send events to the application to make it change its current mode.

The features of the application should be like this:

• in event ports to receive the signals of the manager;
• out event data ports or out data ports to send status information to the manager;
• event data ports for message exchanges with the server.

Now we have modeled the client as a process with two thread types, thus describing the data and signals exchanged between the application and the manager.

The application in itself is actually made of subprograms, representing:

• the application in itself
• the middleware core, i.e. the JMS implementation
• some filters that lie below the JMS core to manage message fragmentation, retransmission, etc.

Typically, we have this sequence:

1. a subprogram emits the request to the JMS core
2. the JMS core then send it to the network filters
3. the network filters send the request to the server through the network
4. the incoming messages from the server are received by the network filter, then transmitted to the JMS core, and then delivered to the user application.

The current mode can define which network filter has to be used, etc.

In order to model the architecture of the application, you then have to describe the subprogram call sequences and the modes (and mode transitions) within an implementation of the application thread.

You should have modeled something like this: