OW2 Wildcat use cases

version 2.3.0


Table of Contents

1. Monitoring a bank application
Wildcat Sensor
Wildcat context
Implementation
Building and running the demo
2. Monitoring a SCA application
Wildcat Sensor
Wildcat context
Building and running the demo

Chapter 1. Monitoring a bank application

In this usecase, we show how can Wildcat be used to monitor a simple bank application. First, we are going to create a new sensor to monitor bank accounts. Then, we design a wildcat hierarchy of bank resources to be able to write queries and extract meaningful data from this hierarchy. Finally, we describe the scenario implementation and how to build/run it.

Wildcat Sensor

Let's create a new sensor 'AccountSensor' to be used to monitor a bank account activity. As described in chapter 'Wildcat Sensors', we simply extend the 'POJOAttribute' class.

public class AccountSensor extends POJOAttribute {
			
	public AccountSensor() {
		super(null);
	}
	
	public AccountSensor(Object value) {
		super(value);
	}	
}

		

This new sensor will be "injected" to the following simple bank account class :

public class Account {

  private int id;
  private double balance;
  private AccountSensor accountSensor; // wildcat sensor

  public Account(int id) {
	this.id = id;
	balance = 0;
	accountSensor = new AccountSensor();
  }

  public void deposit(double amount) throws IllegalArgumentException{
	if (amount < 0)	throw new IllegalArgumentException();
	
		balance += amount;
		//notify change to the wildcat context that the sensor is mount to 
		accountSensor.setValue(balance);
	}
  public void withdraw(double amount) throws InsufficientAmountException,
			IllegalArgumentException {
	if (amount < 0)	throw new IllegalArgumentException();

	if (balance - amount < 0) throw new InsufficientAmountException();
		
	balance -= amount;

	//notify change to the wildcat context that this sensor is mount to
	accountSensor.setValue(balance);
	}
 }
		

In this class, the private attribute 'accountSensor' is the wildcat sensor. This attribute will notify the account activity in methods 'withdraw' and 'deposit'. In this usecase, we consider the new balance value as the monitoring data to be notified by this sensor. Finally, this sensor has to be attached to a wildcat context to notify such events as shown in next section.

Wildcat context

We consider the following representation of bank resources in a wildcat hierarchy :

To keep the scenario simple, each account has two basic attributes : an identifier and a balance. From this simple hierarchy design, we can aggregate a higher level information (such as the average of transactions amount, total account activity, etc) simply by writing wildcat queries. For instance, to get the account with the higher balance, one can use the following query :

			select max(value.balance) from WAttributeEvent(source like 'self://bank/accounts%')
		

Implementation

In addition to the above 'Account' and 'AccountSensor' classes, we use other utility classes to implement this scenario :

  • BankDatabase : a data class used instead of a real data base

  • TxDetails : a class encapsulating a transaction details(date, client, account, operation,etc)

  • BankGUI : a user interface that allows to perform operations on client accounts

The following screenshot shows this user interface.

Building and running the demo

  • First, checkout the usecase source code with the following command

    svn checkout svn://svn.forge.objectweb.org/svnroot/wildcat/trunk/wildcat/examples/bank

  • Then, to build the demo, run the following command

    mvn install

  • Finally, start the demo by simply running

    mvn -Prun

Chapter 2. Monitoring a SCA application

In this usecase, we show how can Wildcat be used to monitor a simple SCA application running in OW2 FraSCAti runtime. The application used is the helloword SCA sample described here. First, we are going to create a new sensor to monitor service QoS criteria such as service response time. Then, we design a wildcat hierarchy of services provided by the application to be able to write queries and extract meaningful data from this hierarchy. Finally, we describe how to build/run the demo.

Wildcat Sensor

OW2 FraSCAti provides convenient interfaces to add non-functional policies to components in an aspect oriented fashion thanks to intents .For more information about FraSCAti intents, please refer to FraSCAti documentation here . In this scenario, the wildcat sensor will be an aspect that will intercept a service call and compute the monitoring data we want to notify. The listing below shows the 'MonitoringData' class that encapsulate the monitoring data to be notified : the service response time, the component that provides the service called, the service called and the method invoked.

public class MonitoringData {

	private String componentName;
	private String serviceName;
	private String methodName;
	private long responseTime;
	
	//constructor
	
	//getters and setters

}
		

The listing below is the implementation of the intent handler interface. The monitoring data defined above is computed and then notified to the wildcat context.

public class MonitoringIntentHandler implements IntentHandler {
	
	private long startTime;
	private long estimatedTime;
	
	/**
	 * Monitoring data to be sent to wildcat context
	 */
	MonitoringData monitoringData;

	@Init
	public void init() {
	  monitoringData = new MonitoringData();
	}
	
	public Object invoke(IntentJoinPoint ijp) throws Throwable {

	    Component c = ((Interface) ijp.getComponentContext()).getFcItfOwner();
	    String componentName = Fractal.getNameController(c).getFcName();
	    String serviceName = ijp.getInterface().getFcItfName();
	    String methodName = ijp.getMethod().getName();
		
		Object ret = null;
		
		startTime = System.currentTimeMillis();
		    
		 ret = ijp.proceed();
		    
		estimatedTime = System.currentTimeMillis() - startTime;
		
		/*
		 * Set monitoring data to be notified
		 */
		monitoringData.setComponentName(componentName);
		monitoringData.setServiceName(serviceName);
		monitoringData.setMethodName(methodName);
		monitoringData.setResponseTime(estimatedTime);
		
		/*
		 * notify monitoring data to wildcat context
		 */
		WildcatContext.getInstance().notify(monitoringData);
		
		return ret;
	}

}
	

Finally, this new monitoring aspect is declared as a SCA component named wildcatMonitor and added to the server component declaratively with the requires attribute as shown below :

  1 <?xml version="1.0" encoding="ISO-8859-15"?>
  2 <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
  3            name="helloworld-pojo">
  4 
  5   <service name="r" promote="client/r"/>
  6   
  7   <component name="client">
  8     <implementation.java class="org.ow2.frascati.examples.helloworld.pojo.Client"/>
  9     
 10     <service name="r">
 11       <interface.java interface="java.lang.Runnable"/>
 12     </service>
 13     
 14     <reference name="printService" target="server/printService">
 15       <interface.java interface="org.ow2.frascati.examples.helloworld.pojo.PrintService"/>
 16     </reference>
 17   </component>
 18   
 19   <component name="server">
 20     <implementation.java class="org.ow2.frascati.examples.helloworld.pojo.Server"/>
 21     
 22     <service name="printService" requires="wildcatMonitor">
 23       <interface.java interface="org.ow2.frascati.examples.helloworld.pojo.PrintService"/>
 24     </service>
 25     
 26     <property name="header">--->> </property>
 27   </component>
 28   
 29 </composite>

Wildcat context

In this use case, the monitored resources are the services provided by the application components. The following wildcat hierarchy may be used for a service based application :

From this simple hierarchy, we can extract meaningful data such as the average of services response time, services tacking too long to respond,etc with simple wildcat queries. To keep this scenario as simple as possible, the implemented wildcat context holds a basic attribute containing the monitoring data as described in previous section and which will be printed to the console for each service call.

Building and running the demo

  • First, checkout the usecase source code with the following command

    svn checkout svn://svn.forge.objectweb.org/svnroot/wildcat/trunk/wildcat/examples/sca

  • Then, to build the demo, run the following command

    mvn install

  • Finally, start the demo by simply running

    mvn -Prun