In recent years, there has been considerable interest in Intercloud. Intercloud allows clouds to be interconnected, forming a cloud/network of clouds. Intercloud seeks to provide collaborative services or more powerful cloud computing services. We created a Intercloud Communications Protocol (ICCP) to allow clouds to communicate with each other using a common protocol, which is transparent to the underlying APIs of different clouds. It also includes security functions to ensure confidentiality and integrity.
Inspired by the successful HyperText Transfer Protocol (HTTP), an extensible protocol called the Intercloud Communications Protocol (ICCP), was created. ICCP allow clouds to communicate with each other securely using the same protocol, which is transparent to the underlying APIs of different clouds. Since the ICCP is based on the Extensible Markup Language (XML), it greatly facilitates the development of Intercloud applications. It also includes security functions or measures to ensure confidentiality and integrity depending on different cases.
In summary, clouds communicate with each other by exchanging XML-based messages, of which there are three types: Request, Response, and Exception with two major attributes, Version and ID. “Version” specifies the version number of the protocol while “ID” identifies the request-and-response or request-and-exception pair (i.e., for session identification purposes). Within a message, General Information, Request/Response/Exception Information, and Additional Information can be defined in the “GeneralInformation,” “RequestInformation,” “ResponseInformation,” “ExceptionInformation,” and “AdditionalInformation” tags, respectively. In general, the messages can be described using XML schemas here.
General Information provides the general information of the message. In the “GeneralInformation” tag, the sending cloud is specified in the “From” attribute, while the receiving cloud is specified in the “To” attribute. The “Date” and “Time” define the date and time of the creation of the message, respectively. Request/Response/Exception Information provides request/response/exception-specific information. The Command attribute provides the command for the request (i.e., similar to the action used in HTTP). Additional Information provides the additional information to be included in each message (e.g., data). Based on the aforementioned schemas, different tags can also be defined. They are similar to HTTP headers in providing specific information or functions.
The Intercloud Gateway provides an innovative mean for data communication between clouds. Based on ICCP, the Gateway has built-in support for: Object Storage: AWS S3, Google Cloud Storage, Azure Storage, CenturyLink and Minio. Virtual Machine: AWS EC2, VMware ESXi and Hyper V.
The interconnection between Gateways follows the IEEE P2303 draft standard. Roots provide cloud resources directory services. They connect and work with Exchanges. Exchanges facilitate resources provisioning and matching, and store ontology information from Roots. They mediate communication between clouds and Roots.
The Gateway is extensible and customizable. Developers can develop their own applications to invoke the Gateway’s API functions by application calls or sending requests in JSON. They can further develop Gateway modules to implement new ICCP commands by programming new Intercloud APIs and Command execution classes.
It is important to understand the difference between Intercloud operations and a Client-cloud operations. The Gateway only performs Intercloud operations.
Client-cloud is something like client-server in terms of Internet. A client may interact with the cloud to perform operations such as putting/uploading a file from his/her own PC. Therefore, there are only two parties – one cloud, one client.
Intercloud operations are cloud-to-cloud, like server-to-server. To perform such operations, an Intercloud Gateway is needed. However, there should be someone (i.e. client) to instruct the Gateway to take the required actions. The Gateway continuously listens port 2001 for requests from clients.
In theory, in a production environment, the Gateway should always be running, like a HTTP Web server. To conclude, there are always three (or even more) parties involve in Intercloud operations – one client and at least two clouds.
The Intercloud Gateway functions like an HTTP Web server to handle requests/responses. The figure below shows the basic architecture of the Intercloud Gateway. The communication module essentially deals with the communications between clouds. Once a message is received, it will be placed in the message queue. The XML parser then parses the message and determines the command. The message will be passed to the command module for further processing. After processing, a response message is generated and sent to the communication module. The communication module then forwards the response message to the corresponding Gateway. Based on the Java Cryptography Architecture, the security module manages and performs security functions such as the generation/verification of digital signatures, computation of message digests, and data encryption/decryption.
Intercloud Gateways communicate with each other by exchanging ICCP messages. Various tags can be defined in a request or response message in order to provide specific information for the requested command. The figures below show the basic workflow of two of the most commonly used commands: PutObject and GetObject. The contents of the exchanged messages are marked in green color.
The Intercloud Gateway supports two levels of data security: public and private. The level of data security can be defined when issuing a data transfer request using the Gateway’s API.
In a “public” data tranfer, no security process is performed. The data are transferred right away to the Gateway of the storage cloud without encryption. Both of the owner cloud and the storage cloud can retrieve the original data.
On the other hand, whenever a cloud transfers a piece of private data to another cloud, “private” data transfer should be used.
In a “private” data transfer, the corresponding Gateway encrypts the data with symmetric encryption using a unique AES key generated by the cloud’s private key together with the object name at runtime. Only the owner cloud can decrypt the data. The storage cloud is unable to retrieve the original data. Once the owner cloud needs to retrieve the encrypted data from the storage cloud, its Gateway sends a request message to the Gateway of the storage cloud. The Gateway of the owner cloud receives the encrypted data from the storage cloud, decrypts the data and retrieve the original data.
An ICCP message can be digitally signed to protect its integrity. Before sending a signed message, a Gateway first compute the digest of the message with the SHA-1 algorithm. The Gateway encrypts the message digest with the cloud’s private key, and the encrypted result is attached to the message as a digital signature afterwards.
After a signed ICCP message is received, the receiving Gateway divides the message into: (1) the original message and (2) the signature. The Gateway (1) hashes the original message with the SHA-1 algorithm, and (2) decrypts the signature with the required public key to obtain the message digest computed by the sending cloud. If the results of (1) and (2) are equal, the message is regarded as authentic and the Gateway accepts the message.
Whether digital signature is used or not can be defined when issuing a request using the Gateway’s API.
Here are some useful links related to the project:
Our project is supported by the following parties:
Mobile cloud computing provides an effective way to manage data and computing resources for mobile terminals over the Internet. While current work mostly focuses on computational offloading, another important mobile cloud computing service is cloud-based mobile data service, which makes various smart computing applications possible. In recent years, there has been various related work on mobile data service over clouds. Based on the IEEE P2302 architecture and our previous work on the InterCloud Communications Protocol (ICCP), we developed App Inventor graphical programming blocks for creating mobile Intercloud applications. We present three innovative use cases or smart computing applications and evaluate the implementation of an automatic file transfer application. By using graphical programming blocks, various mobile Intercloud applications can be developed effectively and efficiently.
Block | Description |
---|---|
![]() |
Save different cloud configurations. |
![]() |
Load cloud configuration. |
![]() |
Invoke actions after loading the cloud configuration. |
![]() |
Load the gateway’s list. |
![]() |
Invoke actions after loading the gateway’s list. |
![]() |
Save names of files that need to be transferred automatically. |
![]() |
Load names of files that need to be transferred automatically. |
![]() |
Invoke actions after loading the file names of automated transfers. |
![]() |
Save names of files that need to maintain a backup. |
![]() |
Load names of files that need to maintain a backup. |
![]() |
Invoke actions after loading the names of files that need to maintain a backup. |
![]() |
Transfer files from origin cloud to multiple destination clouds. |
![]() |
Get file list from the cloud. |
![]() |
Download multiple files from the cloud. |
![]() |
Upload multiple files to the cloud. |
![]() |
Delete multiple files from the cloud. |