• No results found

B.1 HTTP Return codes

11.1 CloudFoundry domain model

Entity

This abstract class has metadata properties common to some of the entities in CloudFoundry. The GUID is used to uniquely identify each entity.

Application

An application created on the CloudFoundry platform. The num_instancesandmemoryprop- erties are used to set how many resources to assign to this application in terms of number of

concurrent agents executing it and available memory. These parameters can be tweaked to manually scale an application. Note also that an application can be bound to more than one URI.

Space and Organization

A space is basically an environment in which applications and services can live. Typical spaces are Testing, Development and Production. A space pertains to an organization, so that several organizations could coexist together in a more or less isolated way.

Application Service

This encompasses any external service that can be used by applications, the most common being databases. The way to model services is slightly different in V1 and V2, however in both versions services are created from available Service Configurations (for example, “MySQL database”).

In V1 a Service Configurationoffers a set ofTiers, representing different usage plans (for instance, “free plan”, “light plan” and “pro plan”). Servicesare created from one of this con- figurations and plans. Note that the attributes in the Application Serviceand Service V1 are replicated; this is because a service, actually, has no direct access to its configuration.

In V2 a Service Configuration is associated to an Offering (such as “MySQL database”), which at the same time has a set ofPlans(analog toTiers). Note that since bothOfferingand

Planspecialize from Entitytheir basic information, like the name, is represented through the entity.

Stats

Stats for an application are calculated through the stats of each of its running instances. Cloud- Foundry only provides information about basic metrics: CPU usage, memory usage, disk oc- cupation and uptime.

Info

This encompasses a set of general information about the CloudFoundry installed platform. Since CloudFoundry allows placing the authorization component (UAA) anywhere, or even having a different authorization server based on OAuth2, theauthorization_endopointproperty tells how to access this authorization server. The info also contains information about available runtimes (such as “Java 1.6”) and frameworks (such as “Spring”).

11.2.5

Client library conceptual model

The client library will be used as a black-box whenever possible following the rule of minimum modifications; however, it is useful to see its structure and the exposed methods since it can help to understand how to use the library and how to extend it when needed.

Diagram 11.2 shows a class diagram depicting the different components that form the li- brary and how the adapter will use them. It has been simplified to show only the relevant parts

for the project. The library is divided into two separate components, the library used to exe- cute REST operations on the Cloud Controller (from now on, REST library) which includes most of the operations needed by the harmonized API, and the library used to open tunnels to application services through Caldecott (from now on, Caldecott library).

The adapter uses the REST library to perform most of the operations. The library’s point of contact with the adapter is theCloudFoundry Client. This class is basically a proxy for the

Controller Clients. TheCF Client first uses theFactoryto create aController Client and from

that point, it interact with the created Client. The Factory either creates a V1 or V2 client depending on the version of the Cloud Controller. The Controller Client interface shows the methods that both versions of the client implement. The clients may also optionally have an OAuth2 Client, in case the Cloud Controller is using the UAA-based authentication mechanism. The adapter uses a custom client to access the Caldecott library. The client first creates a

Cloud Foundry Clientwhich uses to deploy, govern and bind the service to the Caldecott app

through the Tunnel Helper. Then it creates a local Tunnel Server that is the responsible for opening the actual tunnel. The server then uses a set of auxiliary classes to open the tunnel at the CloudFoundry side by sending a request through HTTP and to connect to it through a Socket. Once the socket is bound to the service, it is accessible through the “localhost” address. As it can be seen from the diagram, the library makes a strong use of the Factory design pattern2 and an extensive use of interfaces. This further contributes to make the adapter more scalable and extensible.

There is actually much more going on in the internals of both libraries. The intention of these descriptions is not to give a full and detailed description of these components but rather to give and overview that helps to understand them.

11.2.6

Behavioral Model

This section shows the design sequence diagram of each of the operations in the harmonized API. The internal business logic of the client libraries is not shown, however the REST calls made from the library to the Cloud Controller are still shown so that it can be seen how finally a request reaches the CloudFoundry instance. It is assumed that the library communicates with a V1 Cloud Controller, except for the operations that are not available in this version.

As said in the previous sections, there is both a remote and a local part of the adapter, there- fore, it is specified which one contains each operation. The diagrams also show the concrete signature of each method.

Authentication

Authentication in CloudFoundry is done using access tokens issued by an OAuth2 compliant authorization server, so that when the adapter wants to act on behalf of a certain user, it first has to get an access token by using thee-mailandpasswordof the user. Once the access token has been issued, the adapter can freely use it to access the Cloud Foundry API until it expires.

2The Factory design pattern was introduced in [GHJV95] and consists on having afactoryclass whose respon-

sibility is to create and configure objects of a particular type. This encapsulates the creation and configuration of complex objects into a single place, increasing the cohesion and maintainability of the system. For example, the Controller Client Factoryis afactoryobject that has acreateClientmethod, which receives a set of configuration

Cloud Foundry Adapter Client Library for Caldecott access

Client Library for REST operations

Abstract Controller Client - name: String - cloud_controller_URL: URL - authorization_endpoint: URL - access_token: String + getCloudControllerURL(): URL + getInfo(): Info + supportSpaces(): boolean + getSpaces(): Space [*] + login(): String + logout() + getServices(): Service [*] + createService(service: Service) + getService(name: String): Service + deleteService(name: String) + deleteAllServices()

+ getServiceConfigurations(): ServiceConfiguration [*] + getApplications(): Application [*]

+ getApplication(name: String): Application + getApplicationStats(name: String): ApplicationStats + getDefaultApplicationMemory(framework: String): Number

+ createApplication(name: String, runtime_model: String, framework: String, memory: Number, URIs: String[*], service_names: String[*], check_if_exists: Boolean) + uploadApplication(name: String, file: File, callback: Callback) + uploadApplication(name: String, archive: Archive, callback: Callback) + startApplication(name: String)

+ stopApplication(name: String) + restartApplication(name: String) + deleteApplication(name: String) + deleteAllApplications()

+ updateApplicationMemory(name: String, memory: Number) + updateApplicationInstances(name: String, instances: Number) + updateApplicationServices(name: String, services: String[*]) + updateApplicationURIs(name: String, URIs: String[*]) + updateApplicationEnv(name: String, env: Map(String -> String)) + getFile(app_name: String, instance_index: Number, file_path: String): String + bindService(app_name: String, service_name: String)

+ unbindService(app_name: String, service_name: String) + getApplicationInstances(name: String): InstancesInfo + rename(app_name: String, new_name: String)

<<interface>>

Controller Client Credentials

- email: String - password: URL - token: URL - proxy_user: String 1 <<implements>> OAuth Client - authorization_URL: URL 0..1 1

Controller Client V1 Controller Client V2 1 Space

Controller Client Factory <<creates>> <<use>> 0..1 1 HTTP Tunnel - URL: String - host: String - port: Number - auth: String Tunnel Helper + getTunnelAppInfo() + deployTunnelApp() + bindServiceToTunnelApp() + getTunnelURI() + getTunnelAuth() + getTunnelServiceInfo()

CloudFoundry Client Info

1 1 <<use>> <<use>> Tunnel Server - local_IP: IPAddress HTTP Tunnel Factory - URL: String - host: String - port: Number - auth: String <<creates>> 1 Tunnel Acceptor Tunnel Handler <<use>> 1 Socket Client 1 <<interface>> Tunnel <<implements>> <<interface>> Tunnel Factory <<implements>> <<interface>> Client 1 <<implements>>

Caldecott Client <<use>>

<<creates>> <<use>> <<use>> Adapter <<use>> Credentials - email: String - password: String