Architectural Style

The overall architecture of the CTF platform can be realized using many different architectural patterns that support rich interaction between a set of distributed components. Taking into consideration our stated design principles, we have decided to base the CTF design on the Representational State Transfer (REST) architectural style.

REST is a set of design constraints for developing rich resource-oriented systems that mirror the scalability and the flexibility of the Web. In contrast to Service Oriented Architecture (SOA) and other Remote Procedure Call (RPC)-based architectural styles where the data is kept private, encapsulated and hidden behind the processing components, in REST, the state and the nature of the data elements play a central role.

The resource is the main abstraction of information in a RESTful system. The resource representation captures the current or intended state of the resource. The components (clients, servers, etc.) act on the resources by transferring and modifying their representations. A resource identifier is used to uniquely identify the resource involved in the interaction.

Resource Model

According to the REST style, the APIs are specified through the resource model and the semantics of the application of the unified HTTP method set on those resources. The following table provides an overview of the main resources and their association with the Testbed Federation API (TF API) and the Testbed Adaptation API (TA API).

Uniform Interface

REST mandates a uniform interface between the components in the system. Since all resources in the system can be manipulated with the same method set, the components don’t have to implement specialized code for accessing different resources in the system.

The semantics of each operation is well defined and uniform across all resources and components. This leads to an interface that is easy to understand and simplifies the interoperability between large number of uncoordinated actors. The uniform method set also opens the possibility of using a standardized set of return values to inform the caller about the success of the method invocation.

The following table provides a succinct overview of the semantics of the most common HTTP methods when applied in a RESTful context on resource collections or individual resources.

Invocation Example

"Registering new experiment"

Request

POST /projects/456/experiments

Host: federation.com

Accept: application/ctf.Experiment+json

Content-Type: application/ctf.Experiment+json

Representation

{

"name":"Test Experiment",
"description":"A simple test experiment",
"user":{
"uri":"http://federation.com/users/123",
"name":"John Smith",
"media_type":"application/ctf.User+json"
   },
"project":{
"uri":"http://federation.com/projects/456",
"name":"Test Projest",
"media_type":"application/ctf.Project+json"
   },
"sharing":"public"
}

Response

HTTP/1.1 201 Created

Location: federation.com/projects/456/experiments/789