Integrating WebSphere CloudBurst capabilities in an iPhone solution, Part 1

Architecture, decision model, and tools for a simple Web 2.0 application


The IBM WebSphere CloudBurst Appliance is a self-service cloud management device that can deliver immediate return on investment through decreased IT operations costs and increased hardware utilization. It is a new class of hardware appliance that sits in a data center and dispenses IBM WebSphere Application Server topologies into an external pool (cloud) of virtualized hardware. Using the vast REST-based APIs provided, WebSphere CloudBurst offers many integration opportunities for a Web 2.0 environment.

One WebSphere CloudBurst integration possibility, for example, is with an Apple iPhone. Web browsing with an iPhone is easy, but for a better user experience a full-client application solution is more desirable. You would be able to retrieve information from the appliance and format it for a user interface on the device.

This series of articles walks you through the process of creating a full client application for an iPhone device that collaborates with WebSphere CloudBurst using a REST API. To that end, Part 1 is a high level introduction to the various pieces involved and architectural make-up to help you prepare your development environment.

This article series assumes a general familiarity with Web2.0 technologies including Rest, ATOM, JSON, and Objective-C. The sample application described in these articles is realized in Objective-C using the Apple iPhone SDK 3.x to be run on an iPhone (or iPod Touch) device with a 3.x firmware. To perform the steps and run the examples from this article, you will need a computer with the Apple SDK 3.0 or higher installed, running a compatible version of Mac OS. You also need access to a WebSphere CloudBurst Appliance running in your environment.

WebSphere CloudBurst overview

IBM WebSphere CloudBurst Appliance helps you create, deploy, and manage WebSphere virtual systems within a private cloud. The appliance ships with IBM WebSphere Application Server Hypervisor Edition, which is a virtual image of IBM WebSphere Application Server packaged according to the Open Virtualization Format (OVF) standard. This package includes the operating system, WebSphere Application Server profiles and binaries, and IBM HTTP Server. All are pre-installed and ready to be deployed into a hypervisor.

WebSphere CloudBurst can be used by private or on-premise cloud computing environments -- and also by service providers providing hosted public clouds and software-as-service environments -- to simplify and standardize repeated deployments. It is part of a powerful and comprehensive set of cloud computing and virtualization solutions for intelligently deploying and managing SOA applications, services, and environments to achieve smarter business outcomes. Figure 1 shows the WebSphere CloudBurst big picture.

Figure 1. WebSphere CloudBurst Appliance big picture
Figure 1. WebSphere CloudBurst Appliance big picture
Figure 1. WebSphere CloudBurst Appliance big picture

WebSphere CloudBurst provides both a command line interface and REST APIs for data center automation and integration with automated resource provisioning solutions. For example, WebSphere CloudBurst deployments can be automated into service management automation solutions, such as IBM Tivoli® Service Automation Manager, to provide additional process automation and control over the end-to-end provisioning process.

This article applies these concepts in creating a collaboration between an iPhone client and the WebSphere CloudBurst Appliance. Specifically, the client will issue an API request to display the list of the clouds managed by WebSphere CloudBurst. For each available cloud, you will be able to retrieve information such as:

  • Cloud description
  • Cloud name
  • Cloud status
  • Cloud start time.

With this application, the WebSphere CloudBurst admistrator will be able to see the status of these clouds using only his smartphone. Figure 2 illustrates the overview architecture of this solution.

Figure 2. Architectural overview diagram
Figure 2. Architectural overview diagram
Figure 2. Architectural overview diagram

The iPhone client data will be retrieved on demand. The data will be retrieved using a REST call; the REST invocation is simply based on an HTTP GET request. (The REST protocol can manage the other HTTP collaboration protocols, such as POST, DELETE, and so on, but in this example the client is used for inquiry only.) The request will be caught by WebSphere CloudBurst, and a JSON response file containing the requested cloud status data is returned to the device. Optionally, you can store the retrieved data on the iPhone using a local SQLite database integrated in the iPhone environment.

iPhone client: Fat or thin client

An example of a thin client is a generic Web browser. A thin client is considered light from a coding point of view, but it is also light from an interface functionality standpoint as well. Of course, PHP and related technologies can increase the capacity of a Web browser GUI. If you want to get the maximun benefit out of your user interface, then you want a solution based on a fat client.

A fat client is essentially an application that runs on the client. If portability is a major concern to you, then this might not be the best solution. In this case, however, because the application is being built for a smartphone, GUI functionality is arguably more of a priority than portability. A fat client is robust from a coding point of view, but a thin policy can then be applied to the data application.

Remember, because your client is not a PC, you really can’t store all your data on the client, and so the application data will be retrieved on demand. The data will be retrieved using a REST call, based on an HTTP GET request. The request will be received by the back end, which in turn will send back a JSON response file containing the requested data to the device. To store the necessary file on the iPhone, you can use a local SQLite database integrated in the iPhone environment.

REST API overview

Each WebSphere CloudBurst Appliance exposes a REST API; there are no special configuration settings to be done in order to enable or disable this interface. The REST API is available on the same IP address or hostname that you use to access the appliance GUI and command line interface (CLI). The REST API is only supported over the HTTPS protocol on port 443. The appliance uses a self-signed certificate for its SSL sessions. The same certificate is used for GUI, CLI, and REST API sessions. The REST API only supports the sending and receiving of UTF-8 encoded data.

The sample application described in this article will use the REST API to manage your virtual systems information with the data that is shown in Table 1. The REST API returns data in JSON format. The URI patterns for all the HTTP GET requests shown in the first column will be prefixed with "/resources/" (for example, /resources/virtualSystems).

Table 1. REST API for virtual system cloud information
URI patternSuccess codesError codes
/virtualSystems200: Returns the list of virtual systems that are visible to the client. 403: The requester has not been assigned the cloud administration role.
500: CloudBurst Appliance internal error while processing the request.
/virtualSystems/{id}200: Returns the virtual system associated with the given ID.403: The requester does not have access to the requested virtual system.
404: requested virtual system is not defined.
500: CloudBurst Appliance internal error while processing the request.

A virtual system has these attributes:

  • created: Creation time of the virtual system, represented as the number of milliseconds since midnight, January 1, 1970 UTC. This value is numeric and is automatically generated by the appliance.
  • currentmessage: Message associated with the current status of the virtual system.
  • currentmessage_text: The textual representation of currentmessage.
  • currentstatus: String representing the current status of the virtual system.
  • currentstatus_text: The textual representation of currentstatus.
  • id: ID of the virtual system. This numeric value is automatically generated by the appliance.
  • name: Display name associated with this virtual system.
  • owner: URI of the user that owns this virtual system.
  • updated: Time the virtual system was last updated, represented as the number of milliseconds since midnight, January 1, 1970 UTC. This value is numeric and is automatically generated by the appliance.

JSON response data model

Listing 1 shows a REST response example for a /resources/clouds request that returns the list of the clouds managed by the appliance.

Listing 1. GET /resources/virtualSystems example
		"created": 1245041940730,
		"currentmessage": null,
		"currentmessage_text": null,
		"currentstatus": "RM01036",
		"currentstatus_text": "Queued",
		"desiredstatus": "",
		"desiredstatus_text": null,
		"id": 6,
		"name": "futurevs",
		"owner": "/resources/users/1",
		"pattern": "/resources/patterns/1",
		"updated": 1245041940730
		"created": 1245356439153,
		"currentmessage": "RM07045",
		"The virtual system has been deployed and is ready to use",
		"currentstatus": "RM01006",
		"currentstatus_text": "Started",
		"desiredstatus": "",
		"desiredstatus_text": null,
		"id": 9,
		"name": "test virtual system",
		"owner": "/resources/users/1",
		"pattern": "/resources/patterns/6",
		"updated": 1245357249316

The response data is in JSON format. JSON is popular in the Ajax (Asynchronous JavaScript™ and XML) community because it is simple to manage this data format within a PHP program. JSON objects are constructed in a key:value pair format. The elements of the object are separated by commas, and each object is contained within curly braces {}. An array of objects is contained within square brackets []. This is a common approach used to transfer a series of rows from a database to an array of objects in which each array element corresponds to a database row, and each property of the object represents a column of data.

In your client, you will be managing this data format using C. One simple way to convert this data is to create general parser code that converts JSON data into an Objective-C application data object. The array is normally stored in an Array native data object, supplied by any OO language (in Objective-C, the NSMutableArray class declares the interface to objects that manages a modifiable array of objects), the key:value data is normally stored in a dictionary (in Objective-C, the NSMutableDictionary class declares the interface to manage a generic data object associated with an arbitrary key). The parser code receives a JSON file as input and returns a data dictionary (or an array) containing all the objects described inside the JSON file.

If you prefer not to write this parser yourself, there are many open source projects available that have these functionalities embedded in a set of classes. Whichever way you decide to manage the JSON to Objective-C data conversion, you must include this set of classes inside your project. For the purpose of this article, the JSON conversion is assumed to occur outside the steps described here.

SQLite overview

If you want a fast and easy way to store a simple set of data, SQLite is a good way to do this. You can store all your necessary application data inside an SQL database, resulting in a single file that is easy to maintain. The iPhone offers native support for SQLite, a simple but complete database engine that requires no special configuration to set up, and enables all database data to be stored in a single file. SQLite support is available in native mode on Mac OS X, and on the iPhone and iPod with no additional libraries.

To create an SQLite database for your new application:

  1. Open a command window and create a new folder to store the database, using the commands shown in Listing 2.
    Listing 2. Create SQLite database: MyDataBase.sql
    cd /Users/<myUser>/Documents
    mkdir SQLiteTutorial
    cd SQLiteTutorial
    sqlite3 MyDataBase.sql
  2. At the SQLite command line prompt, enter the SQL commands shown in Listing 3 to create a database table for the application variables:
    • Table name: configValueTable
    • Columns: key, tag, value, description.
    Listing 3. Create configValueTable table
    CREATE TABLE configValueTable 
               ( key INTEGER PRIMARY KEY, 
                 tag VARCHAR(50), 
                 value VARCHAR(255), 
                 description TEXT );
          configValueTable (tag, value, descrption) 
          VALUES ('tag', 'value', 'description');
  3. Make sure that the table has been created by entering the command SELECT * FROM configValueTable; It should return the table with the columns that were created. When you are confident that the database is properly configured, type quit to exit the command window.

Detailed information on working with SQLite is beyond the scope of this article. See Related topics for more information.

iPhone app development

Apple's SDK (software developer’s kit) is a set of tools and APIs that enable you to develop native applications for Apple devices, such as the iPhone. You will need some knowledge of Cocoa (Objective-C) to get started. Although this article does not provide a deep dive into the programming language, some Objective-C fundamentals are provided below. If you are already familiar with C/C++/Java™, you will notice many similar concepts with respect to classes, methods, and basic expressions. The SDK also includes tools such as Xcode, Interface Builder, iPhone simulator, and more.

To install the SDK:

  1. Download the .dmg SDK file (see Related topics) to your machine that is running Mac OS.
  2. Double-click on the downloaded file in the User > Downloads folder to open the disk image.
  3. Double-click on the installer package inside of the disk image. The installer will launch so you can install the SDK. Follow the on-screen instructions. Remember that the SDK installation requires up to 3GB of hard disk space.
  4. When the installation is complete, a new Developer folder will display at the top of your directory structure. This directory contains the main tools and libraries that you need to create iPhone applications.

Before you begin developing, you should know about the fundamental design patterns you’re going to use in developing your iPhone app:

  • Delegation: A pattern where one object periodically sends messages to another object that is specified as its delegate.
  • Model View Controller: A paradigm of breaking an application into three parts: the user interacts with the view, the controller handles the input event from the view, the controller notifies the model of the user action.
  • Target-Action: The mechanism that enables a view object to present a control in response to a user event; for example, a click to send the action message to the target object.

Create an iPhone project

You are now ready to create your first iPhone project using Xcode:

  1. On your Mac OS machine, launch Xcode (located in /Developer/Application by default).
  2. Select File > New Project and make sure iPhone is selected for Product (Figure 3).
  3. Select View-based Application. This template provides a starting point for an application that uses a single view icon. Then click Choose (Figure 3).
    Figure 3. Create new project
    Figure 3. Create new project
    Figure 3. Create new project
  4. Name your project HelloWorld and click Save. The tools will create all the required classes for your application. Each class is in a file with a .m extension and includes a header file with a .h extension (Figure 4):
    • main.m: Main file.
    • HelloWordAppDelegate.m: Application delegate class.
    • HelloWordAppDelegate.h: Application delegate header file, included in the .m file.
    • MainWindow.xib: Object that defines your main window application.
    • Other files: Other project configuration files.
    Figure 4. Application files
    Figure 4. Application files
    Figure 4. Application files
  5. Select the Build and Go icon. The tool compiles and installs your application in the iPhone Simulator, which starts with your application automatically. At this point, you should only see a simple white screen. In the end, you should have the project classes shown in Figure 5.
    Figure 5. Application project classes
    Figure 5.                     Application project classes
    Figure 5. Application project classes

Adding SQLite framework

To manage the SQLite access from the iPhone application, you need to include the SQLite libraries in the tool. To do this:

  1. Right click on the Frameworks folder in the left pane, then select Add > Existing Frameworks... (Figure 6).
    Figure 6. Adding SQLite framework
    Figure 6. Adding SQLite framework
    Figure 6. Adding SQLite framework
  2. Navigate to /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS2.0.sdk/usr/lib/ from the main system root directory. Double-click on the libsqlite3.0.dylib file.
  3. Click Add in the dialog, and the library will be added to your project.

You should now see the included framework inside the iPhone SDK when you select the Frameworks folder in the left pane (Figure 7).

Figure 7. Included framework
Figure 7. Included framework
Figure 7. Included framework

Objective-C fundamentals

Let's examine a very simple Hello World program in Objective-C. This is not an iPhone-specific example, just a small piece of the code to illustrate show how Objective-C is similar with the C++ language. This example will be helpful if you are already familiar with C++ principles.

Listing 4 shows a common Hello World program in C++.

Listing 4. Hello world sample program
#include <stdio.h>
int main(void)
        printf("Hello, World!");
        return ;

To create a class called "Sample" in Objective-C, you need to create an header file named Sample.h (Listing 5).

Listing 5. Header file - Sample.h
#import <Cocoa/Cocoa.h>

@interface Sample : NSObject
  int a;

- (void) printValue;

This is only the class declaration. You are establishing which methods and attributes will have the Sample class. The class inherits from the Cocoa base class, NSObject. The class declaration begins with the @interface directive and ends with the @end directive. Following @interface is the class name, name of the parent class, instance variables of the class (also called ivars) declared in a block delimited with braces, and then the list of methods that you will implement in the class.

Now, you can implement the class in the main file, as shown in Listing 6.

Listing 6. Implementation file Sample.m
#import "Sample.h"

@implementation Sample

- (void) printValue{
  NSLog(@"The value of the sample parameter  is: %d\n",a);

- init {
  if(![super init]){
    return nil;
  a = 7;
  return self;

The class generally has a constructor that is prefixed with "init." When the header file and the implementation file are ready, you can create an instance with the code in Listing 7.

Listing 7. Class instantiation main.m
#import "Sample.m"
void myFunction(){
  Sample *mySample = [[Sample alloc] init];
  [mySample printValue];

Before you can work with an object in Objective-C, you need to create an instance of the object. In doing so, you also need to allocate memory and create the object. This is done in Listing 7 with the alloc parameter.

Next, let’s look at how an array can be used in Objective-C. The required class in this example is NSMutableArray. In Objective-C, you can put anything into array -- even mix and match objects. Listing 8 shows an example of creating an array and then adding three elements to it.

Listing 8. Array creation
//Array creation
NSMutableArray *arr = [[NSMutableArray alloc] init];

//Add three elements 
[arr addObject:@"Object 1"];
[arr addObject:@"Object 2"];
[arr addObject:@"Object 3"];

Listing 9 shows an example of retrieving an object from a specific element in an array.

Listing 9. Retrieving objects from an array
//Retrieve an object 
NSLog([arr objectAtIndex:0]); 
NSLog([arr objectAtIndex:4]);

Listing 10 shows how you can retrieve the last element from an array.

Listing 10. Retrieving the last object from an array
//Retrieve the last object in an array
NSLog([arr lastObject]);

Listing 11 shows how to implement a for-each loop to repeat the same action on every object in the array.

Listing 11. Loop on an array
	for (NSString *s in arr) {

If the array is not yet required, then you must release it, as shown in Listing 12.

Listing 12. Releasing an array
            [arr release];

Some points to remember about using Objective-C:

  • As in C++, remember that the header file declares only methods and parameters; classes must be implemented in the .m file.
  • There are two types of methods in Objective-C. Execution of an instance method is scoped to a particular instance of the class; you must create an instance of the class before you can invoke the method of the class. In contrast, class methods do not require you to create an instance.
  • Methods that are preceded by a minus (-) sign are instance methods. The colon characters declare the presence of a parameter. If a method has no parameters, the colons after the first can be omitted.


This article provided some very basic fundamentals to get you ready to work with the Apple SDK, create an iPhone project on a Mac, and code in Objective-C. This information will help set the stage for the next installment of this series, which will describe the view component of the sample application and the class skeleton of the controller class.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=WebSphere, Cloud computing, Web development
ArticleTitle=Integrating WebSphere CloudBurst capabilities in an iPhone solution, Part 1: Architecture, decision model, and tools for a simple Web 2.0 application