The implementation of the adapter has been split in two parts: the local part and the remote part. The local part has been integrated in a currently existing project in the Cloud4SOA ecosystem while the remote adapter has been implemented as a brand new RESTful service decoupled from the rest of the components.
The Cloud4SOA ecosystem is formed by a set of projects, each one implementing one component. Moreover, each component exposes its interface in a common project (the API project), so that other components that need to use it only have to set the API project as a dependency. This creates a decoupled infrastructure, where the connection point is this API project. Remote adapters follow a similar approach, by pointing to a common project that
defines the exposed API, so that clients using the remote adapters only need this common project as a dependency.
11.3.1
Technologies involved
Both adapters have been implemented in Java, since this has been the programming language adopted for the Cloud4SOA project. Other technologies involved include Maven and JAX-RS
Maven
Maven3 is a project management and building tool for Java projects. This tool is used consis- tently in all projects within the Cloud4SOA ecosystem in order to manage dependencies and to manage the project’s building process, although Maven can be used for a much wider range of functionalities.
Maven manages a project through an XML file (the Project Object Model or POM) that contains a description about its components, dependencies, build actions, etc. in a similar fash- ion to GNUmakeorAnt. When building a project, all specified dependencies are automatically downloaded from Maven repositories and included in the project classpath.
Maven also allows creating hierarchies of POMs, so that all actions and dependencies can be inherited. This mechanism is used within Cloud4SOA by specifying a “Master POM” from which the rest of POMs inherit.
JAX-RS
JAX-RS4, part of JAX-WS, is a Java library that eases the creation of RESTful Web Services.
In Cloud4SOA, this library is used to create the RESTful services for the remote part of the adapters.
JAX-RS allows transforming an entity class with a set of methods into a RESTful Web Ser- vice by annotating its methods with the path, the parameters and the HTTP verb. An example of such a method is shown in the following code snippet:
@GET
@Path("/ems/application/{appid}")
@Produces({"application/json", "application/xml", "text/plain"})
public ListApplicationResponse getApplicationDetails(@PathParam("appid") String appid) {
ListApplicationResponse response = new ListApplicationResponse(); [...]
return response; }
With these annotations, JAX-RS configures the service appropriately, deals with HTTP headers, incoming requests, outgoing responses, etc. JAX-RS provides a wide set of tools to perform advanced operations such as filters, message interceptors, HTTP headers operations, etc. However, Cloud4SOA only uses the core functions of the library.
3http://maven.apache.org
11.3.2
Local Adapter
The implementation of the local part of the adapter is integrated within one of the currently ex- isting projects which contains the business logic for the local implementation of all the adapters. An example of a method in the CloudFoundry local adapter can be seen in the following code snippet:
public static String createAndDeployCF(String email, String password, String appName, String binary) throws Cloud4SoaException {
CloudFoundryClient client = null; try {
client = init(email, password);
// check whether an application with appName name // already exists
try {
client.getApplication(appName); } catch (CloudFoundryException ce) {
// create it if it doesn’t exist, otherwise propagate // the exception
if (ce.getStatusCode() == HttpStatus.NOT_FOUND) { AuxAdapter.createApplicationCFbase(email, password, appName, client);
} else {
throw ce; }
}
File f = new File(binary);
client.stopApplication(appName);
// stop application before uploading the code to // avoid conflicts
client.uploadApplication(appName, f);
// after uploading the code, start the application again client.startApplication(appName);
CloudApplication app = client.getApplication(appName); return app.getUris().get(0);
} catch (CloudFoundryException e) {
// In case of error, check it and propagate the // appropriate exception
if (e.getStatusCode().equals(HttpStatus.NOT_FOUND)) { throw new Cloud4SoaException(
"The application cannot be found"); }
throw new Cloud4SoaException(e.getMessage()); } catch (IOException e) {
throw new Cloud4SoaException("An error occured uploading"); } finally {
} }
The first part of the method initializes a newCloudFoundryClientby creating a new instance of the object and logging in with the provided credentials. Then, the method checks whether an application with the same name has already been created and creates it otherwise. Finally, the application is stopped, the new code uploaded and the application started again so that the Cloud Controller can stage the application with the new code.
The following snippet shows the code of theinitmethod:
public static CloudFoundryClient init(String email, String password) throws Cloud4SoaException {
try {
// create client object with the given credentials and URL CloudFoundryClient client = new CloudFoundryClient(
new CloudCredentials(email, password), new URL(CC_URL)); client.login();
return client;
} catch (ResourceAccessException e) { throw new Cloud4SoaException( "Connection with the PaaS was refused.");
} catch (CloudFoundryException e) {
// check if the error is due to incorrect credentials if (e.getStatusCode().equals(HttpStatus.FORBIDDEN)) {
throw new Cloud4SoaException("Authentication error."); }
throw new Cloud4SoaException(e.getMessage()); }
}
The method basically creates a new client object with the given credentials and URL and authenticates the user. The method also checks the exceptions returned and tries to determine the cause of the error in order to propagate the appropriate exception (refused connection, bad credentials or other).
11.3.3
Remote Adapter
The remote adapter has been implemented as a brand new project that basically contains a RESTful web service implementing the Harmonized API, along with the CloudFoundry Java library. We have used JAX-RS in order to implement the external interface of the web service, by annotating each of the methods with its path and its HTTP verb.
As said in the introduction of this section, the remote adapter complies with a common interface defined in an independent project. This project defines the routes and its associated methods along with their Request and Response objects which group the parameters of the requests and responses. The method shown in the JAX-RS section above , for instance, returns
11.3.4
Integration with Cloud4SOA
A crucial part of the implementation of the adapters is to fully integrate them with the central- ized part of Cloud4SOA.
Cloud4SOA has two points of contact with the adapters: theExecution Management Service
Module(EMS) and theMonitoring Module, both in the Governance layer. Due to the decoupled
nature of the remote part of the adapters, the integration with it has been straightforward and has not required any changes on these modules. When an application is deployed through Cloud4SOA, the URL of the remote part of the adapter is stored in the database and it is then used to execute operations on it. This way, the behavior in the governance layer is the same regardless of the actual adapter that is being invoked. Integration with the local part, in contrast, has required including some additional logic into the EMS in order to distinguish the case of CloudFoundry and to invoke the adapter methods accordingly.
Another crucial part of the integration with Cloud4SOA is to create the semantic profile for the platform based on the PaaS Offering semantic model and include it into the PaaS repository. The goal is to ultimately allow users themselves to add new platforms to the repository through the Cloud4SOA dashboard, however at the time of implementing the CloudFoundry adapter this feature is still not functional, instead the following steps have to be followed:
1. Create the semantic profile using an ontology editor, based on the PaaS Offering model 2. Use the Semantic Initializer component to update the database with the new semantic
profile.
Figure 11.7 shows a part of the CloudFoundry instantiation of the model.