Home Objectives

Service–Oriented Architectures (SOAs) constitute a major architectural style for large–scale infrastructures and applications that are built from loosely–coupled well–separated services and that are subject to dynamic configuration, operation and evolution. Nowadays, SOAs are the structuring principle of a multitude of commercial infrastructures and applications and the enabling technology for new software paradigms such as Software–as–a–Service (SaaS), Mashup or Social Network applications. The execution of this new type of software eventually spans a number of different organizations, and may involve powerful servers as well as resource–constrained devices (e.g., mobile devices).

Today, most business oriented SOA applications are what we could call "closed SOAs", in which all components have been developed, are controlled, maintained and executed by the same entity. Yet to achieve all its benefits, we have to look at "open SOAs" in which not all services are developed, maintained, controlled and executed in–house. Many companies are faced with the challenge of moving their current applications into the service world, but find it difficult because this has to be done without adding new security risks. Unfortunately, from a security point of view, the implementation of even a closed SOA can be extremely complex, taking into account the business–critical applications that developers want to expose as Web services. In the case of open SOAs, the fact that trust becomes an essential element has motivated that, opposed to closed SOAs, the number of open SOAs that run critical or security sensitive applications is still minimal.

Assessing the trustworthiness of such complex and continuously evolving software ecosystems is a challenging task for businesses and citizens since:

  1. The methodologies – mainly based on certification processes – have been developed for assessing conventional static systems and components and thus have difficulty in dealing with the dynamicity and variety of SOA based systems.
  2. Few artifacts can be used to support and automate the assessment of the trustworthiness of a stand–alone service.
  3. No mechanism exists to specify certification requirements at design time and to use them at run time for assessing the fit of services with required assurance level.
  4. No means exist to assess the trustworthiness of composite applications, from an end–user or an auditor perspective.
  5. No automated procedure has been proposed to challenge the effectiveness of security properties after the certification phase.

To address these drawbacks, the ASSERT4SOA infrastructure will (i) develop enhanced methods for the certification of complex and continuously evolving SOA–based software systems and services and make use of existing certification processes within the SOA context (where possible), (ii) develop mechanisms and tools for the assessment of SOA–based systems' and services' trustworthiness, both at design time and runtime, based on systems and service certification, (iii) integrate the methods, mechanisms and tools of (i)–(ii) into the SOA lifecycle.

template joomla