WSAG4J Architecture

The WSAG4J framework is designed as a generic SLA layer that can be used in a wide set of scenarios. Therefore, it needs to be as extensible and modular as possible. The concepts of extensibility and modularity are key concepts of the framework, which have influenced the framework design from the very beginning. The framework comprises the following modules:

API Module contains interface definitions and implementations that are shared by the dif-ferent modules of the framework. Client Module is an implementation of the client API defined in the API module. It is im-plemented for accessing the WSAG4J web service stack. SLA Engine Module is the core of the WSAG4J framework. It provides a generic implementation of a WS-Agreement based SLA engine. It implements the standard functionality for processing agreement offers, creating agreements, monitoring the agreements runtime states, and evaluating and accounting agreement guarantees. Agreement acceptance policies and business logic for instantiating and monitoring SLA aware services can easily plugged in. Web Service Module implements the remote frontend for the WSAG4J engine. It implements the WS-Agreement port types and delegates the calls to the WSAG4J engine, if necessary. The web service module is implemented on the base of the Apache Muse framework. This framework provides the WSRF container required by the WS-Agreement specification. Server Distribution comprises the WSAG4J server including the web service stack, the SLA engine and all required configurations. It is a packaged web application archive which can easily deployed in a wide set of application servers.

WSAG4J Architecture

Since the WSAG4J framework was designed in a very modular way, it is possible to exchange complete modules. It is for example possible to use the SLA engine in a different WSRF stacks, such as Globus or UNICORE. In that case, only the WSAG4J engine and the dependent modules (e.g. the API module and additional types) are required for the integration. It is also possible to use the WSAG4J engine without a remote stack at all, e.g. in a desktop application. Vice versa, it is possible using the web application module and the web service module with another implementation of a WS-Agreement engine. This implementation only needs to implement the respective Server API. Note that WSAG4J Engine and Agreement are components that are implemented as part of the WSAG4J engine module. The Agreement Factory Capability and the Agreement WSRF Resource are part of the WSAG4J web service module.

The agreement factory component is a central component of the WSAG4J framework. It is the primary interaction point for applications to create new agreements and it is responsible for agreement offer validation and service instantiation. Therefore, it is subsequently also called WSAG4J engine.

Agreement Factory Architecture

Figure above shows the basic components of the WSAG4J agreement factory. The WSAG4J engine implements the agreement factory interface. It encapsulates its subsystems and therefore acts as a facade. A facade is an object-oriented design pattern with the goal to provide a unified interface to a set of interfaces in a subsystem. A facade defines a higher level interface that makes the subsystem easier to use. By implementing this pattern the WSAG4J engine provides a high level interaction point, which can be easily accessed through a web service interface. It provides a method to access the agreement templates that are registered with this engine and a method to create agreements based on incoming offers.