Fig-34: Overview of On-line Compliance Testing
This section addresses Reqs. D1.2-6.14-Compat, D1.2-6.15-MinPolicy, and D1.2-12.16-OnlineTst.
Implementation of SOA based applications result from the integration of several services. Services composing an application can change at run-time without informing all the other services integrated in the application. Furthermore, features like dynamic binding, or context-dependency prevent knowing before run-time the actual interaction among service instances.
Speaking in general terms, services are typically controlled and owned by different organizations. Thus, dealing with architectures that are not under the full control of one organization, means that the service lifecycle cannot be structured in well-defined development stages. In particular, for a (composite) service it is not clear when testing activities starts or should end.
To ensure trust and dependability the TAS3 architecture must also include adequate technology and actors to test that services within a TAS3 Trust Network behave in compliance with their expected specifications. Such testing activities must be performed on-line by special TAS3 guards, verifying that the services with a choreography actually behave as expected.
To achieve trustworthy SOA, there is the need to develop and use a methodology and tools supporting the "perpetual" (i.e. event-driven, periodically) and automatic testing of software services. The benefits with the "perpetual" and automatic testing we envision:
repeatability of testing (improving the efficiency and the efficacy of the test)
increase the quality and the trust perceived by the users of the service
Fig-34: Overview of On-line Compliance Testing
The extent to which compliance is tested may vary, also depending on the registration information that should accompany services (e.g. models describing interfaces, policies, usage, etc.), which is part of the governance contract.
A minimal assumption is that services should access and perform within a TAS3 infrastructure according to an explicitly declared set of policies and that the infrastructure should not allow violation to the declared policy, or at least should recognize such violation. Testing is applied in order to reduce the risk that services within a TAS3 infrastructure will get in contacts with unreliable services. Therefore services within a TAS3 compliant infrastructure will be regularly submitted to testing session aiming to assess that a service does not break its policy.
As important remark, we advise that this on-line testing approach does not prevent the execution of canonical off-line testing activities (e.g. where the service is tested by its developer trying to anticipate possible usage scenarios), rather it is an additional mean to increase the trustworthiness of the TAS3 architecture.