The Testbed Manager (PTM) is installed at every testbed the resources of which are intended to be offered through the Experimentation platform.

As the following picture show, every request arriving from the Experimentation control tools passes through the Fedway (for checking policies) and then the request proceeds to the testbed manager. The TM gateway receives the call and forwards it to an orchestration service which is responsible for brokering the call to subsequent calls to resource adapters for controlling the necessary resources that participate in an experiment.

[update 10/6/2013]: The installation of Openlab's SFAWrap services, together with an implementation of a local XMLRPC server, enables the Testbed Manager to federate with other OpenLab? resources and display controlled resources to MySlice?

PTM consists of two parts:

The Core PTM is deployed on the GlassFish? ESB v2.1 Application Server. It consists of two JBI Service Assemblies that implement the core logic of the PTM and a Web Application that is the administration interface of the PTM. The role of the Core PTM is:

to provide a service interface that can be invoked by Teagle during the process of setting up a VCT to provide a service interface that can be invoked by the RAs for notifying the PTM of various events to process the requests received from Teagle so that these can be properly forwarded to the appropriate RAs to persist information per RA and RA identifier so that it can be re-applied after re-start of the RAL

The core PTM exposes two web services based interfaces:

​http://localhost:9100/axis/services/RANotify ​https://{PTM HOST}:9181/axis/services/T1

The first interface is the notification interface available to RAs while the second one is used by Teagle.

---

Resource Adaptation Layer

The Resource Adaptation Layer (RAL) role is to integrate the resources offered by testbed owners in the PII platform. The instantiation of RAL is based on the accumulation of the runtime images of Resource Adaptors (RA). RAs are providing a common interface for communication towards the PTM components while towards each resource they implement the resource specific communication and configuration protocols. RAL as a runtime concept provides mechanisms that aid resource discovery and monitoring by generating specific change events to communicate the resource status as well as any control information to PTM components.

Resource Adapters

The testbed resources are entities that are published to be available for provisioning using resource adaptors (RA). RAs reside in the Resource Adaptation layer where they can be dynamically plugged-in as required. A Resource Adaptor is primarily characterized by a unique resource type throughout a PTM installation. This type definition is the subject to be published and made available as a testbed offering. It is actually an advertisement of the real resource that will be participating in testbed assemblies.

Apart from the resource type definition that is the static part of all the RAs, the dynamic part of the RA is instantiated as many times as the number of the specific resource type has been deployed and brought into the federation. Since the RA is deployed in the RA Layer that resides in the PTM machine, instantiation of the dynamic part of the RA requires the existence of binding information with the resource hosted or being on a different machine. In the simplest form this information can be a network address at which the RA has to send all the configuration requests using the appropriate communication protocol. Association of the dynamic part of an RA with the actual resource that is controlling is completed by the assignment of a unique Resource Identifier that is propagated throughout the PII infrastructure.

Every instance of the dynamic part of an RA implements a common interface that consists of the four CRUD operations: Create-Update-Query-Delete. All the interaction with the RAs is based on the use of these operations. Upon reception of such a command an RA should be able to translate it into the actual resource specific semantics and apply the appropriate management towards the resource, thus implementing the network agnostic behaviour needed by the PII concepts. The common interface is published by the RA as a web service available at a URL that is unique and closely related with the Resource Identifier.

Apart from the instruction interface that an RA is implementing for receiving all the configuration and provisioning requests it is also able to inject information into the core PTM engine for further processing. The PTM is providing a service for receiving notifications from the Resource Adaptation Layer. The notifications may originate either from the RAs or from the RAL Manager. Each reported event is marked by an Event Type so that the PTM can process it accordingly. For every instance of an RA that is bound with resource, a web service interface is launched. The URL of such an interface (available to the Core PTM) is ​http://localhost:2000/axis/services/{RA Identifier} RAL Implementation

The Resource Adaptation Layer is a concept that is instantiated as set of OSGi bundles deployed in an OSGi framework. More specifically, Oscar has been selected as the OSGi framework.

Relationships among RA types

Between two resources and consequently between the corresponding RAs two kinds of associations are envisaged:

The two resources reference each other, or One of the two contains the other

These two types of resource linking is determined during VCT design. During orchestration an RA can be requetsed to:

update its configuration with a reference to the other resource for the first case create the other resource in the second case

In both cases the resource being instructed receives an indication of the type of the other resource to which it has to establish a relationship linking (either reference or containment according to VCT tool terminology). It is up to the developer of the RA to process the specific type association in the proper way. If update was issued, the RA must realise the kind of configuration update it has to perform on the actual resource, e.g. configure an Asterisk with an additional extension that should be resolved into the IP address of the softphone that is actually the second resource. In case of a create request the RA must know how to install on its resource the child resource requested. It must also configure the connectivity information for the newly created resource so that its RA when launched is able to be properly bound with the new resource. A create related example can be the installation of a software package on a host OS. In such case the OS is the parent and the software package is the child. In the resource creation case, there is a differentiation stemming from the fact that the configuration information contained in the orchestration create request may be vital to setting up the child resource or not. For example, if a virtual image has to be launched on a virtual server then the configuration of the image at least regarding its IP address and the root credentials have to be taken care of by the virtual server RA. On the other hand, configuration of a softphone is normally performed by its actual RA and not by the OS hosting it. Therefore, the first kind of resources are considered as non-self-configurable while the second one are considered as self-configurable. The difference is that the PTM modifies the create request in the case of self-configurable. More specifically, the configuration set sent by the Teagle is replaced in the request with an indication of the package name that is required to be used for the resource installation and the extracted configuration is submitted as an update to the newly launched RA.