Federation Computing: A pragmatic approach for the Future Internet

Transcription

1 Federation Computing: A pragmatic approach for the Future Internet Christos Tranoris and Spyros Denazis Electrical and Computing Engineering dept. Univeristy of Patras Patras, Greece tranoris@ece.upatras.gr, sdena@upatras.gr Abstract Future Internet research investigates mechanisms for providing access to information and communication technology infrastructures and resources beyond boundaries of single administrative domains, thus enabling sustainable, cost-effective, energy efficient solutions. This paper discusses how Federation Computing, a paradigm shift and a pragmatic approach for the Future Internet, can ease the description and operation of required heterogeneous resources and infrastructures for a new richer infrastructure. The Panlab s Federation Mechanisms are used as a case-study where we apply Federation Computing concepts by exploiting Panlab s mechanisms and architectural elements. Keywords - federation; federation computing; Future Internet; Panlab; Resource as a Service I. INTRODUCTION Future Internet research requires experimental facilities and testbeds for supporting approaches that exploit, extend or redesigncurrent Internet architecture and protocols. Global efforts like GENI [1] and FIRE [2] are leading the development of future experimental facilities and propose solutions and architectures for Future Internet. These efforts are oriented toward combining and provisioning infrastructure, resources and services in the form of a federation of various independent domains. The expected benefits are a) increased scalability of experiments, b) diversity of available resources, c) experimentation under realistic network conditions, and d) involvement of real users. Under FIRE initiative, the Pan- European laboratory [3], Panlab, builds on a federation of interconnected and distributed facilities allowing third parties to access a wide variety of resources like platforms, networks, and services for broad testing and experimentation purposes. In this context, Panlab defines a provisioning framework and a meta-architecture that give rise to a number of Federation Mechanisms and Architecture Elements to be used for experimentation in the Future Internet. Discussing what federation is, dictionaries like Oxford English Dictionary or Wikipedia [4] give the political view of the term: a Federation is a union of partially self-governing states united by a central (federal) government. Panlab s definition of federation is [5]: Federation is a model for the establishment of a large scale and diverse infrastructure for communication technologies, services, and applications and can generally be seen as an interconnection of two or more independent administrative domains for the creation of a richer environment and for the increased multilateral benefits of the users of the individual domains. Another definition proposed by the cloud computing community, is stated as [6]: Federation is the act of combining data or identities across multiple systems. Federation can be done by a cloud provider or by a cloud broker. A broker has no cloud resources of its own, but matches consumers and providers based on the SLA required by the consumer. The consumer has no knowledge that the broker does not control the resources. Aligning the last two definitions, the architecture element of Panlab Office is defined as the central federal entity that contains all the necessary mechanisms and operations for acting as a provider and broker of administrative domains. Panlab s shared resources are highly heterogeneous and range from generalpurpose virtual and physical machines, to Cloud Computing resources, services, platforms and specialized devices and infrastructures. Finally, Panlab s mechanisms allow federation of federations. This paper discusses Federation Computing, a paradigm shift and a pragmatic approach for the Future Internet. The Panlab s Federation Mechanisms are used as a case-study where we apply Federation Computing concepts by exploiting Panlab s mechanisms and architecture elements. Although Federation Computing shares many concepts with Cloud Computing as discussed in subsequent sections, its main difference is that Federation Computing is a layer above Cloud Computing. The sections of this paper are organized as follows: first we briefly present Panlab s core concepts, infrastructure and architectural elements. Section 3 gives our perspective and definition of Federation Computing. Section 4 specifies a federation scenario, a model, a process and a tool for specifying Federation Scenarios. Section 5 presents a process for operating specified Federation Scenarios by means of a Federation API followed by an example presented in section 6. Finally we conclude this work /$26.00 c 2010 IEEE 190 This paper was peer reviewed at the direction of IEEE Communications Society by subject matter experts for publication in the CNSM 2010 proceedings.

2 II. THE PANLAB INFRASTRUCTURE The Panlab infrastructure manages interconnections of different geographically distributed testbeds to provide services to customers for various kinds of federation scenarios. A Federation Scenario is a well-defined specification of required (heterogeneous) resources along with their configurations, offered by a diverse pool of organizations in order to form new richer infrastructures. A Federation Scenario is instantiated as an SLA which is required by the customer. These federation scenarios represent customer needs such as i) evaluation and testing specifications of new technologies, products, services, ii) execution of network and application layer experiments, or even iii) complete commercial applications that are executed by the federation s infrastructure in a cost-effective way. A. Panlab Concepts and architecture The architectural overview of Panlab is depicted in Figure 1. The main roles identified are: i) The Panlab Partner who acts as the provider of infrastructural elements. Partners are connected to the Panlab Office for offering functionality along with their respective resources to the customers. ii) The Panlab customer who utilizes services provided by the Panlab office and defines federation scenarios. iii) The Panlab Office, which is the central federal entity that acts as a provider and broker among different administrative resource domains. It realizes mechanisms that enable Panlab partners to be part of a federation, and Panlab customers to define federation scenarios. Figure 1: Architectural overview of Panblab The architecture of Panlab includes many software components. A Web Portal is available where customers and providers can access services, a visual Creation Environment which is called Virtual Customer Testbed (VCT) tool where a customer can define requested services, a repository which keeps all persistent information like resources, partners, defined federation scenarios, etc. Experimenters can browse through the resource registry content and can select, configure, deploy and access reserved resources. Finally, an Orchestration Engine is responsible for orchestrating the provisioning of the requested services. The above components interact with each other in order to offer a service called Teagle. Part of Teagle is also the Teagle Gateway, the component that is responsible for transferring provisioning and configuration commands to selected resources lying in various administrative domains. The functionality of Panlab office is complemented by a Policy engine, a metering and a monitoring component. All components communicate via an HTTP-based (REpresentation State Transfer) RESTful interface. Panlab s architecture introduces additional components for integrating testbeds that belong to various administrative domains, in order to become available to participate in federation scenarios. The first component is the Panlab Testbed Manager (PTM) (Figure 1). PTM is responsible for accepting RESTful commands from the Teagle Gateway in order to configure the domain s resources. PTM implements the so called Resource Adaptation Layer where Panlab partners plug-in their Resource Adapters (RA). A Resource Adapter (a concept similar to device drivers) wraps a domain s resource API in order to create a homogeneous API defined by Panlab. Details and specifications of Panlab s components can be found at [3]. III. FEDERATION COMPUTING Federation Computing aspires to be a paradigm shift and a pragmatic approach for the Future Internet. It is a paradigm shift since it shifts the traditional application development process from the simulation lab or sandbox testing (academic/commercial) to close-production environments (i.e. real best-effort environment). Environments toward evaluation and testing specifications of new technologies, products, services, execution of network and application layer experiments or even complete commercial applications into the federation s infrastructure. Federation Computing aims to be pragmatic since it adopts practical ideas and tools that already exist and widely used by developers in the fields of Infrastructure as a Service (IaaS), or Resource as a Service and Software Engineering. Finally, Federation Computing paradigm goes a step beyond the specification mechanisms and architectures of resource federations (as all efforts of current experimental facilities like GENI and FIRE do): it also considers processes on how one can exploit such mechanisms and architectures in a convenient way after provisioning the requested resources, in the operating phase. Federation Computing shares a lot with Cloud Computing which NIST defines in [7] as a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Still we believe that Federation Computing stands alone because it aims to be a layer above Cloud Computing, 2010 International Conference on Network and Service Management CNSM

3 since it can view a Cloud as a resource. Moreover, Federation Computing tries to meet the increasing demand among researchers and production system architects, and combine computational, storage, and network resources from multiple sources (e.g., the organization s own resources, their partners resources, commercial and academic clouds, programmable network substrates). In this work we discuss two aspects of Federation Computing: the specification of federation scenarios and the operation of federation scenarios. IV. SPECIFICATION OF FEDERATION SCENARIOS Federation scenarios as already mentioned, usually involve heterogeneous resources offered by a diverse pool of organizations that own real or experimental infrastructures. To this end, there is a need for introducing practices that result to unambiguous federation scenario specifications that can be used later for creating an SLA between a customer and the central federal entity, the Panlab Office. To address this problem, we consider Federation Computing as a problem space on its own. Dealing with it we adopt a software engineering methodology: the Domain-specific modeling (DSM). DSM involves the systematic use of a Domain Specific Language (DSL). A DSL is defined as a specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain. For the language definition an abstract syntax (the meta-model) and a concrete syntax are needed. A. Specifying a federation model As already discussed there is a need for a federation model, or more precisely, a meta-model that is used to specify federation models. The federation model is realized by what we call the Office meta-model. An Office meta-model defines what an office is, which are the participating entities and their relationships. In other words, it defines what a resource is, and what a service is, how a service is supported by a resource, service taxonomies, service compositions, SLAs, users, etc. The Office is defined as an entity that offers services and resources by providers under specific Contracts (availability, cost, etc). The Office meta-model, is defined in Ecore: a variant of OMG s MOF [8] that has been developed in the Eclipse Modeling Framework [9] and is more or less aligned on OMG's Essential MOF (EMOF). Part of the meta-model is illustrated in figure 2. In the meta-model the entity Federation Scenario is also defined: the Office aggregates Requested Federation Scenarios where an SLA is created for each one of them. Panlab office is a realization of the Office meta-model as illustrated in figure 3. Moreover, in cases of a cross-domain specification (i.e. between GENI and FIRE) we consider a model-to-model transformation from the model of the foreign domain (source) to our model (target). B. A concrete syntax for Federation Scenarios and support tooling Having the abstract syntax (the meta-model) we can now define a DSL for the specification of Federation Scenarios. We define a DSL for Federation Scenarios specification, called Federation Scenario Description Language (FSDL), which takes the form of a concrete textual syntax for specifying federation scenarios. The Office meta-model is the abstract syntax of the language. The FSDL s concrete syntax is supported by a textual editor which implements instances of the office meta-model. As shown in figure 4 the Federation Scenario designer works on a Federation Scenario project in order to specify the requirements. We have opted for a solution based on textual description of the specification because: a) it provides rapid prototyping and validation of the underlying model b) it supports unambiguous requirement specifications c) helps the Federation Scenario designer to specify simple or complex Federation Scenarios avoiding ambiguities of design and configuration and d) it enables text version control and distributed definitions by versioning tools (i.e. svn, cvs, etc.) Figure 2: Part of the Office meta-model Figure 3: The Office meta-model and Panlab office model The specification of a Federation Scenario consists of request statements for Offered Services (regardless of International Conference on Network and Service Management CNSM 2010

4 organization) or Offered Resources by specific organizations and providers. The Federation Scenario designer may define configuration values and the configuration workflow, (if it is necessary) when this workflow cannot be easily derived by the system. The editor is based on the textual modeling framework (TMF) of Eclipse and specifically the Xtext framework [11], which helps implementing rich editors by a definition of a specific syntax. Figure 5 displays the implemented editor where we define the meta-model (for the abstract syntax) and implement the concrete syntax and validation mechanisms during specifying a Federation Scenario in FSDL. Syntax highlighting, context assistance, validation errors and warnings are some of the features. The presented support language tooling is available for the Eclipse [10] workbench. This Federation Scenario specification framework is called Federation Scenario Integration Development Environment (FSIDE) and is installed as Eclipse plugins. mentioned, the Federation Scenario contains offered services of the central federal entity, the Panlab Office. Additionally the Office meta-model defines that an office maintains Contracts that matches how a resource implements a specific service, under what availability, cost, policy, etc. All this contractoriented information is used by a module called Resource Advisor (see Figure 6), which transforms the Federation Scenario into a detailed list of requirements for specific resources. As displayed in Figure 6, the Resource Advisor proposes to the Federation Scenario developer different Implementation Plans to continue, under certain cost and availability of the resources. Figure 5: Specifying a scenario in the FSDL editor Figure 4: The Federation Scenario specification workbench (FSIDE) Moreover, we define import definitions of different Offices for helping the user on selecting Offered Services and Offered Resources. This is implemented in the FSDL syntax with Import statements (see figure 5 top), allowing the creation of federation scenarios from services offered by different organizations. Figure 5 presents an example federation scenario for specifying a request with offered services and offered resources both from Panlab and University of Patras. This is possible of course if the imported office models conform to the same office meta-model. Additionally, the defined syntax helps configure the requested Services, i.e: storage capacity, login username and password, etc. C. Generation of a Federation Scenario SLA: from requested services to actual reserved resources and provisioning Although the DSM methodology often includes the idea of automated code generation, in our case we use it to generate an SLA for the requested Federation Scenario. As already Figure 6: Selecting an implementation plan in the Resource Advisor 2010 International Conference on Network and Service Management CNSM

5 In this way we have created a model of an SLA for federation scenarios in order to assign responsibilities to a certain resource for every item contained in an SLA. An SLA aggregates contracts for each requested service. So, a provider s resource is responsible for a specific requirement of the SLA. This approach of contracts and responsibilities of resources helps also towards monitoring an SLA for different aspects (ie metering, service quality, security, etc). In Panlab provisioning of a federation scenario (for which an SLA has been created) is done through the Panlab Office by issuing RESTful commands from the FSIDE to architectural components like Teagle Gateway. It is worth mentioning here that other mechanisms and components of Panlab Office can be triggered at this stage e.g. checking user eligibility, security concerns, charging, metering and monitoring (see figure 1). The provisioning approach presented in the last paragraph can be easily applied for any similar central federal entity, like the Panlab Office. The only capability needed is an open API to access central federal entity s offered services. V. OPERATING FEDERATION SCENARIOS Another aspect of Federation Computing, besides specifying Federation Scenarios, is the real time operation of deploying federation scenarios on to actual testbeds. What is critical with the operational part of a federation scenario is the proper and valid run-time configuration of the participating resources. While the scenario is operated by a customer (i.e. during an experiment), the federation must ensure that all SLA terms are fulfilled and nothing is violated or falls out of the scope of the SLA. To this end, the SLA must be constantly monitored for different aspects (i.e. metering, service quality, security, etc). Operating the scenario with proper federation mechanisms is crucial for maintaining the integrity of the federation and the SLA on behalf of the customer and the resource providers. This is necessary for the following reasons: i) The resources of the federation reserved on behalf of the customer are not infinite except otherwise stated in the SLA of the federation scenario. In cloud computing this property of infinite scaling is called elastic. Elasticity in federation should be explicitly requested, within requested boundaries because it is under a certain cost and access. (e.g. configuring latency, or CPU capacity) ii) The central federal entity (the broker) should measure and control requests to the resources during operation, because this is crucial for billing and access control. Many resources have pay-per-use charging scheme or hourly charging. This means that, while the running scenario starts/stops or configures resources the central federal entity must measure everything. iii) Policies should be continuously checked by either the central federal entity or by the domain s manager or finally by the resource itself. During the operation of a federation scenario, all runtime requests should be checked against policies of the federation, or the resource provider. The policies reside in a repository and Panlab architecture offers a policy engine. For the above reasons, it appears that the customer s scenario running in federation resources must access and configure the resources in a uniform manner of arbitrary granularity from a single entry point. This single entry point is the central federal entity and the uniform manner will be a Federation API (Application Programming Interface). A. Operating federation scenarios by exploiting Panlab s architecture and the role of Federation APIs Operating a federation scenario by exploiting Panlab s architecture is illustrated in Figure 7. As already discussed, a federation scenario is specified by a customer and involves execution of network or application experiments or complete commercial applications. All these are executed in the federation infrastructure depicted as UA/SUT (User Application or System Under Test) in figure 7. UA/SUT can run either outside of the federation infrastructure (e.g. customer s premises, left of figure 7) or inside a resource of the federation infrastructure (e.g. a virtual machine, bottom of figure 7). Figure 7: Operating scenarios by exploiting Panlab UA/SUT can access federation resources through the Federation API which wraps RESTful commands to UA/SUT target language. These requests are dispatched as http/https calls (GET/POST/PUT/DELETE) toward Panlab office via the Panlab gateway. The commands of the Federation API wrap only the resources that are needed to support the current federation scenario enabling UA/SUT to configure resources on demand. The advantage of this approach is that everything can be measured, monitored and controlled since all commands International Conference on Network and Service Management CNSM 2010

6 pass from a central control point, that is, the Panlab office. Requests out of scope of the current federation scenario or not part of the initial SLA are discarded as Method not allowed. Additionally, a resource (through the Resource Adapter) can prohibit calls that are not conformant with the local domain policies. Again a Method not allowed is returned back to the UA/SUT. The Federation API is instantiated and delivered to the customer after the generation of the SLA. Not only does it contain the necessary libraries but also the alias of the resources that are used in the federation scenario. This allows UA/SUT to access the testbed resources during execution of the experiment in order to manage and configure various environment parameters necessary for influencing the runtime behavior of the experiment. As an example, assume that a reserved resource, i.e. a MySQL database, can be accessed via the alias uop_db789. The resource provider has signed a contract with the federation and charges a small amount for every new database that is created. The username and the password for accessing the database are defined in the SLA. The Federation API will provide to the customer, for a Java implemented UA/SUT, the following command uop_db789.setdbname(string name). The customer can then call this command from his application at runtime to create Databases and be charged when an HTTP 200 OK is returned back by the federation. (It will not be charged if the database already exists for his account!). Of course, there are more commands to properly configure the resource available by the API and the resource s provider. Another advantage of the Federation API is the option to check status or get other useful information from the resources. For example: assuming that a resource has the capability of exposing CPU utilization, the customer s application can question this value and configure other parameters or resources of the federation scenario, i.e. a load balancer. A solution for automatically generating this Federation API for any target programming language is presented in the next section. Current prototype implementations of this automatically generated Federation APIs have been made for Java and C (called Federation Computing Interface FCI [12]). B. Toward automated generation of Federation APIs In this section we propose a method for automatically generating Federation APIs for target languages, to be used next by customer UA/SUTs. The solution again is given by the model driven development software methodology and specifically the model transformations. Figure 8 displays how to automatically generate a Federation API that later is delivered to the customer. A modelto-text workflow needs to be defined for a target language of the API. This workflow consists of templates and the engine that runs this workflow takes into account the following parameters: i) the SLA of the federation scenario and its participating resources, ii) the model of the Panlab office regarding the resources interface and iii) the Federation API core which implements simple RESTful APIs for the target language. Figure 8: Automated generation of a Federation API VI. AN EXAMPLE FEDERATION SCENARIO In this section an example is given that demonstrates how to exploit the Federation Computing concepts. According to this scenario a researcher wants to test an http proxy software written in C programming language that implements a new admission algorithm. To carry out the experiment the researcher requests some http traffic generators and some http web servers as resources. The scenario presented can be easily scaled up with many clients and web applications. Also, the proxy we test can be replaced by one or more load balancers. The federation scenario is depicted in Figure 9 and requires as resources three traffic generators (GenA, GenB and GenC), two web servers (WebA and WebB) and a virtual machine (VM) that will host the proxy algorithm. Figure 9: Proxy algorithm federation scenario example The federation scenario can be specified in FSDL as follows: Scenario ProxyScen import office "Panlab.officedl"; ScheduledPlan { From "now" Until "30/6/ :00:00" RequestServices { Service "PanlabOffice.HTTPClientsGenerator" as GenA with s { "ProxyURL" set"vmproxy"." ComputingResource.IP" "ProxyPORT" = "8080" "RequestURL" =" Service "PanlabOffice.HTTPClientsGenerator" as GenB with s { "ProxyURL" set"vmproxy"." ComputingResource.IP" "ProxyPORT" = "8080" "RequestURL" =" International Conference on Network and Service Management CNSM

7 Service "PanlabOffice.HTTPClientsGenerator" as GenC with s { "ProxyURL" set"vmproxy"." ComputingResource.IP" "ProxyPORT" = "8080" "RequestURL" =" Service "PanlabOffice.HTTPDummyWebServer" as WebA with s { "HTTPDummyWebServer.ExclusiveUsage" = "true" "HTTPDummyWebServer.ListenPort" = "80" Service "PanlabOffice.HTTPDummyWebServer" as WebB with s { "HTTPDummyWebServer.ExclusiveUsage" = "true" "HTTPDummyWebServer.ListenPort" = "80" Service "PanlabOffice.ComputingResource" as VMProxy with s { "ComputingResource.InstalledOS" set "LinuxInstaller"."OS_Linux_Installer.PanlabVersion" Service "PanlabOffice.OS_Linux_Installer" as LinuxInstaller The scenario specification named ProxyScen imports the Panlab s model (import office "Panlab.officedl") that is used by the editor. The ScheduledPlan contains the desired reservation period of the resources. The section RequestServices contains the requested services of the scenario from the available pool of offered services in Panlab. Each Service has a type-name and the variable name that we specify in the scenario. For example the scenario specifies three "PanlabOffice.HTTPClientsGenerator" services with names GenA, GenB, GenC. For each service many s can be defined. For instance, each "PanlabOffice.HTTPClientsGenerator" service is configured with "ProxyURL" as the IP of the Virtual Machine that will host the proxy algorithm ("VMProxy"." ComputingResource.IP"), an optional port number "ProxyPORT" = "8080" and an optional request URL that the generator makes HTTP requests. The two web servers that the scenario needs are of service "PanlabOffice.HTTPDummyWebServer" with names WebA, WebB respectively. The only settings that are set are the "HTTPDummyWebServer.ExclusiveUsage" = "true" so that this HTTP web server is used exclusively by this scenario and no other federation customer has access or can make requests. The algorithm, as already described, will be hosted in a virtual machine of a service "PanlabOffice.ComputingResource" with name VMProxy. The scenario also requests Linux installed on the requested VMProxy Virtual Machine so we need a "PanlabOffice.OS_Linux_Installer" service with the alias LinuxInstaller. So for the VMProxy the setting "ComputingResource.InstalledOS" is assigned with the value "LinuxInstaller"."OS_Linux_Installer.PanlabVersion". The Resource Adapter of a ComputingResource will handle this. The next step is to specify the resources across Panlab federation that meet these requests for services. Using the Resource Advisor, we proceed for example with a plan of offered resources like the one depicted in figure 10. The total cost that appears is for the desired reservation period. However this is the maximum cost since some resources are used per hour. We will start and stop them later during the execution of our federation scenario, so the final billed amount will be much smaller. As a side note, with FSDL it is also possible to specify the exact name of a resource provider for a requested service in case the customer cares for a specific provider s resources or wants his application to be executed on the resources of only one provider for performance reasons. Figure 10: A Reservation Plan for our resources The federation scenario is then transformed to a temporary SLA-like federation scenario request with the detailed resources selected from the offered plan. The SLA-like is specified as follows: Scenario ProxyScen import office "Panlab.officedl" ; ScheduledPlan { From "27/05/ :51:07" Until "30/06/ :00:00" RequestInfrastructure { //Credentials to make requests Credentials username = "myuser" password = "mypass" OfferedResource "ProviderA.WCL.HttpGen" as "GenA" { ResourceSetting "ProxyURL" = "VMProxy.IP" ResourceSetting "ProxyPORT" = "8080" ResourceSetting "RequestURL" =" OfferedResource "ProviderB.bsite.HttpTrafficGen_v01" as "GenB" { ResourceSetting "ProxyURL" = "VMProxy.IP" ResourceSetting "ProxyPORT" = "8080" ResourceSetting "RequestURL" = " OfferedResource "ProviderA.WCL.HttpGen" as "GenC" { ResourceSetting "ProxyURL" = "VMProxy.IP" ResourceSetting "ProxyPORT" = "8080" ResourceSetting "RequestURL" =" OfferedResource "ProviderA.WCL.WebServer-0a" as "WebA" { ResourceSetting "ExclusiveUsage" = "true" ResourceSetting "ListenPort" = "80" OfferedResource "ProviderA.WCL.WebServer-0a" as "WebB" { International Conference on Network and Service Management CNSM 2010

8 ResourceSetting "ExclusiveUsage" = "true" ResourceSetting "ListenPort" = "80" OfferedResource "ProviderB.bsite.VMI-MEDIUM-02" as "VMProxy" { ResourceSetting "InstalledOS" Assign "LinuxInstaller.OS" OfferedResource "Panlab.PanlabSite.OS_Linux_InstallerResource" as "LinuxInstaller" { ResourceSetting "OS" = "true" Having the above specification the user can proceed with the proposed RequestInfrastructure plan or he can further fine tune the requested resources. The resources of each provider might have many capabilities that the user may further configure. The requested plan will be the final SLA: the example explains that a reservation will be done to resources of ProviderA where the GenA, GenC, WebA, WebB are located and to ProviderB where the GenB, VMProxy are located. This final request is submitted to the web service of the Panlab office (reservation engine, orchestration engine). At the defined scheduled time the reservation and the provisioning of the requested infrastructure will follow. For the operational phase of our example, after the provisioning phase, Panlab mechanisms assign some unique access identifiers to the reserved resources. A C library implementing the Federation API (just HTTP wrappers to the Panlab gateway), the identifiers of the Resource Adapters and their interface are sent to the customer that reserved this infrastructure. The customer must configure his application (UA/SUT) for properly making requests to the reserved resources. The Federation API library for C currently supports commands like: configure( 'HttpGen-001', 'Active', 'true' ); which for example starts the HTTP generator (this is translated into a POST request towards the Panlab gateway with an XML body payload of the configuration). Currently we use http; https is under development. As an example, the C request configure( 'HttpGen-001', 'Active', 'true' ); is a POST to address with the payload: <HttpGen><configuration> <context> <vctid> ctranoris_fedscenario </vctid></context> <configuration><active>true</active></configuration> </configuration></ HttpGen >. There are some commands that also check the current status of the resource (if this is exposed by the Resource Adaptor). For example a status('httpgen-001'); returns an XML containing the current values of a resource (this is translated into a GET request towards the Panlab gateway). We use this mechanism in order that the customer s algorithm can check the CPU utilization of the web application servers and redirect traffic to the proper web application server. CONCLUSIONS AND FUTURE WORK This paper introduces Federation Computing as an emerging paradigm shift and pragmatic approach for the Future Internet supported by tangible examples. Federation Computing has been defined as a federated development model where application development is done in a federated infrastructure by adopting practical ideas and tools that already exist and widely used by developers in the fields of Infrastructure as a Service (IaaS), Resource as a Service and Software Engineering. As a result new research challenges are identified, like security, identity, application performance, policies, monitoring and many others. The Federation Scenario Description Language is under continuous definition and implementation as more domain experts are involved. A graphical notation is also under consideration. Prototypes of a Federation API (called Federation Computing Interface FCI [12]) already exist in C and Java and we will experiment with other languages like Python if demand increases. Mechanisms for the automated generation of the Federation API are implemented using well-known Model Driven Development software tools. For the presented approaches and tools, we are also investigating the possibility of applying them in Cloud Computing in operation with cloud frameworks like jclouds [13] in order to kick-off federation scenarios between cloud providers like Amazon, VMWare, Azure, and Rackspace. All presented tools are licensed under the Apache License, Version 2.0. More details, instructions, source code and downloads soon will be available at Panlab s web site and at our local web site ACKNOWLEDGMENT The work presented in this paper has been performed during PII a Seventh Framework Program (FP7) project funded by EU. REFERENCES [1] National Science Foundation, GENI website: [online] Last cited: May 21, 2010 [2] European Commission, FIRE website: [online] Last cited: May 21, 2010 [3] Website of Panlab and PII European projects, supported by the European Commission in its both framework programmes FP6 ( ) and FP7 ( ): [4] Federation, Wikipedia, [online] Last cited: May 21, 2010 [5] Wahle S., Campowsky K., Harjoc B., Magedanz T., Gavras A., Pan- European Testbed and Experimental Facility Federation Architecture Refinement and Implementation, Int Journal of Com. Networks and Distributed Systems, Vol.5 No ½, 2010 [6] Opencloudmanifesto, Cloud Computing Use Cases White Paper, [online] Last cited: May 21, 2010 [7] Cloud Computing, NIST Definition of Cloud Computing v15, [online] Last cited: May 21, 2010 [8] OMG website. Catalog of OMG Modeling and Metadata Specifications. [Online] Last cited: April 14, documents/modeling_spec_catalog.htm [9] EMF website. [Online] Last Cited: April 14, emf/?project=emf [10] Eclipse Foundation website. [Online] Last Cited: April 14, [11] Xtext framework website. [Online] Last Cited: April 14, [12] Federation Computing Interface (FCI), Panlab wiki website: Last Cited August 9, 2010 [13] Jclouds, OSS framework for the cloud, website [Online] Last Cited: April 14, International Conference on Network and Service Management CNSM