AdaptiveCells/J consists of highly customisable and functionally identical test beans cells. All test bean cells are structurally identical EJBs; in fact, they contain the same Java classes. The difference between them is their deployment descriptor, which can contain different values for key parameters (environment entries in the EJB deployment descriptor). These values drive the behaviour and runtime footprint of the test bean cell. Test bean cells simulate “real” EJBs by emulating computational load (CPU and memory overhead) and calling other test cells, in different calling patterns. No code is required (and therefore no compilation) when using CAT to create a test-bed. Instead, a declarative programming approach is taken in which XML tags are added to the deployment descriptors of the participating test beans.
 

The emulation parameters controlling the test bean actions are:

• CPU overhead (the integer value representing the number of repetitions for generating a pseudorandom Gaussian value with mean 0.0 and deviation 1.0)

• Memory overhead (the size of a byte array that will be allocated by the EJB when it is called)

• Memory leaks (the size of in bytes of memory that will be allocated and leaked - not garbage collected)

• Exception to be raised (the name of the exception class such as java.lang.RuntimeException)

• First Target EJB (the JNDI name of the first EJB to call)

• Second Target EJB (the JNDI name of the second EJB to call)

A cell configuration contains zero or one for each of the above parameters. All parameters are optional when specifying a cell configuration. Each test bean cell can contain any number of configurations. A configuration is identified by a configuration name and each of the parameters it contains is labeled with the configuration name in order to separate them from parameters corresponding to other configurations.

Test beans expose a single business method, simulateBusinessLogic(). This method has a configuration name as a parameter, which it uses to decide the behaviour it will emulate. For the received configuration name, it will use the corresponding emulation parameters to generate the appropriate overhead (CPU and memory) and call the appropriate target test beans. When calling the target beans, the configuration name is passed on to them (again as a parameter to simulateBusinessLogic()). This ensures that adaptation configurations are preserved across all the participants of an interaction.

It is important that the same configuration names be used for all the test beans. This guarantees that if the interaction is started with a configuration, each bean in the interaction “understands” it and therefore can generate the appropriate behaviour. The planning of a particular test configuration (e.g. config1) contains the following steps:

• Devise a test interaction (containing the participating EJBs and their call patterns). Each test-bed interaction can contain any number of test EJBs.

• Decide on the amount of resource usage each EJB must emulate.

• Write the information in all the deployment descriptors for the participating EJBs (i.e. each deployment descriptor must contain the configuration config1 with some or all of the parameters config1cpu, config1mem, config1firstCalee, config1secondCalee). Of course, the value of the parameters corresponding to the configuration in each deployment descriptor would normally differ between the test EJBs.

The figure below illustrates a test-bed configuration consisting of 5 Test Beans (TB). The notes attached to each EJB element contain a simplified version of the associated configuration parameters. For TB2, there are two configurations available (they also exist in the other beans but are not shown). In the first configuration, TB2 will call only TB3. In the second configuration, TB2 will call both TB3 and TB4.