Difference between revisions of "SAM Tools"
Andrea.manzi (Talk | contribs) (→SAM Plugins) |
Andrea.manzi (Talk | contribs) (→SAM Plugins) |
||
| Line 5: | Line 5: | ||
== SAM Plugins == | == SAM Plugins == | ||
Being gCube a SOA infrastructure, the natural way to perform active tests on the production services was to implement a new Service responsible for the availability testing. The service was going to be designed as highly configurable with the possibility to dynamic inject and configure new tests. | Being gCube a SOA infrastructure, the natural way to perform active tests on the production services was to implement a new Service responsible for the availability testing. The service was going to be designed as highly configurable with the possibility to dynamic inject and configure new tests. | ||
| − | But looking on what was already available on the gCube framework, we decided to exploit the plugin mechanism offered by the Executor Service. | + | But looking on what was already available on the gCube framework, we decided to exploit the plugin mechanism offered by the '''[[Executor]]''' Service. |
Revision as of 12:43, 17 August 2010
Contents
SAM : Service Availability Monitoring
The goal of the service availability monitoring is to provide a reliable tool to continuously verify the status of the infrastructure service (i.e. if the infrastructure functionality works as expected). This tool is based on gCube Executor service and on tailored plug-ins that verify concrete infrastructure functionality.
SAM Plugins
Being gCube a SOA infrastructure, the natural way to perform active tests on the production services was to implement a new Service responsible for the availability testing. The service was going to be designed as highly configurable with the possibility to dynamic inject and configure new tests. But looking on what was already available on the gCube framework, we decided to exploit the plugin mechanism offered by the Executor Service.
Concerning the plug-ins, these can be seen as specific tests focused on concrete functional areas of the infrastructure. They recreate a number of invocations to a set of services that provide a given functionality. These invocations represent the standard usage of the infrastructure can be executed periodically. The following plug-ins are planned to be implemented:
