Deploy new applications on IBM PureSystems with plug-ins, Part 1

Design considerations & development efforts to enable a real-world SugarCRM solution

The introduction of IBM® PureSystems™ -- an expert, integrated, enterprise-level family of cloud system that encompass applications, services, hardware, and even the expertise (delivered in the form of best practices patterns) -- takes cloud computing to new heights. One way to prepare an application to leverage IBM PureSystems is to craft a plug-in, a bridge between the application package and the system. In this article, the authors, IBM Cloud labs team experts, describe the development efforts to enable SugarCRM, an independent software vendor application, on IBM PureSystems.


Chin Huang, Cloud Solutions Architect, IBM

Chin Huang is a cloud solutions architect specialized in IT and software architecture. His professional experience is in development of advanced solutions, including IaaS platform, SaaS integration, analytics cloud, web services, and IWD plug-ins. Chin is a certified cloud computing solution advisor, and author of more than 10 technical papers. He lives and works in Silicon Valley, California.

Ton Ngo (, Cloud Solutions Architect, IBM

author photoTon Ngo is a cloud solution architect and senior developer at the IBM Silicon Valley Lab, San Jose, California. Recently he was the architect for the High Performance Computing Cloud for the Nanyang Technological University, Singapore and the Test and Development Cloud for the Royal Bank of Canada. Previously he was a researcher at the IBM T.J. Watson Research Center and Almaden Research Center for 17 years and has published papers on a wide range of subjects.

11 April 2012

Also available in Chinese Russian Japanese Vietnamese

The introduction of IBM PureSystems — an expert, integrated, enterprise-level cloud system that encompasses applications, services, hardware, and even the expertise (delivered in the form of best practices patterns) — takes cloud computing to new heights. One way to prepare an application to leverage IBM PureSystems is to craft a plug-in, a bridge between the application package and the system.

In this two-part article series, the authors cover design considerations, development efforts, and the lessons they learned from the project. Part 1 describes the development efforts to enable SugarCRM, an independent software vendor application, on IBM PureSystems. SugarCRM is a PHP application that requires the LAMP stack (Linux®, Apache, MySQL, PHP). LAMP is not supported by IBM PureSystems out of the box, so the team developed a new pattern type and a set of plug-ins that support the modeling, deployment, and operation of the application atop the base Linux and IBM AIX image. Part 2 addresses the lessons learned from the project.

IBM PureSystems manages the full life cycle of an application. We began by gaining a deep understanding of SugarCRM by consulting with the IBM PureSystems subject matter experts at IBM, holding workshop with the ISV, and experimenting with the application. We also had to consider licensing issues because open source and vendor software are involved. The databases supported include MySQL and IBM DB2®, which is more strategic for IBM. Understanding the full picture allows us to lay out the architecture of the plug-ins and define how IBM PureSystems supports each cycle of SugarCRM.

In modeling the application, the plug-ins let a user drag and drop a SugarCRM box and connect to a database box, which can be MySQL or DB2. MySQL is modeled as an existing server, while DB2 can be a new or existing server.

When the user deploys the SugarCRM application pattern to the cloud, the plug-ins' scripts automate the installation and configuration of all middleware and applications. The scripts interact with IBM PureSystems to obtain deployment information and provide status update.

After the application has been deployed, the plug-ins lets the user start and stop the Apache service, and view logs from SugarCRM.

We gained valuable experience from the project in understanding not only the plug-in development but also the thought process when enabling an application in the cloud. During the development, we consulted regularly with the IBM PureSystems plug-in development team for their guidance and to provide feedback on the Plug-in Development Kit (PDK). Some of our feedback has resulted in new work items for the development team and new best practices. We also consulted the product team to ensure our design is consistent with IBM strategic direction.

Defining the challenge

SugarCRM is an ISV that provides solutions for customer relationship management. The strengths of SugarCRM solution include an intuitive user experience and a highly flexible open source platform. The solution is available in four editions and can be deployed on site, hosted by the company, or in the cloud.

What is SugarCRM

SugarCRM solution is a PHP application that typically runs on a LAMP stack (Linux, Apache, MySQL, PHP). Additional supporting software is used to improve performance, such as the Alternative PHP Cache (APC) and to implement scaling out, memcache.

LAMP stack support is not provided by IBM PureSystems as part of the initial setup. The cloud labs team developed the support necessary to run SugarCRM on IBM PureSystems.

Define the business scenario

The first step was to align business goals and technical solutions. We identified the following business scenarios to support the end-to-end experience, from enablement to running an application, for an IBM PureSystems customer who wants to run the SugarCRM application.

  • Enable SugarCRM and open source software in IBM PureSystems.
  • Model and configure SugarCRM applications .
  • Deploy and run SugarCRM application in the IBM PureSystems cloud.
  • Manage the life cycle of the SugarCRM running instances.
  • Support two databases as the data repository: MySQL and DB2.

Define the plug-in architecture

To define the plug-in architecture, look more closely at typical SugarCRM topologies, design considerations, and licensing issues that can affect the technology development.

SugarCRM as a PHP application

The software stack recommended by the ISV for System x and System p is summarized in Table 1:

Table 1. Suggested software stack for SugarCRM
System xSystem p
Red Hat Enterprise Linux 5AIX 7.1
Apache 2.2Apache 2.2
PHP 5.3 with required extensionsPHP 5.3 with required extensions
APC 3.1APC 3.1
MySQL 5.1DB2 9.7

The team from SugarCRM indicated that the typical topology is a single Apache server connected to a database server, as shown in Figure 1.

Figure 1. Single server topology
Single server topology

Less common is a cluster technology that handles a higher volume of users by scaling up the number of Apache servers, as shown in Figure 2.

Figure 2. Cluster topology
Cluster topology

In this case, SugarCRM uses memcache as the session manager and nginx as the load balancer. Because the application does write back to the local directory where Apache hosts the PHP files and data, the multiple Apache servers must share the same local directory; this is done by hosting the directory on an NFS server. The shared file system also helps in upgrading to a new version of SugarCRM because it allows all the servers to be upgraded at the same time.

Design considerations

A key concept in IBM PureSystems is to give the user an application-centric view of cloud, so that the user can focus on the application and ignore the underlying infrastructure. IBM PureSystems manages three aspects of an application: modeling, deployment, and operation. There can be a vast number of scenarios involved in these three aspects. Here are the considerations we used when making our choices:

  • While IBM PureSystems can support a cluster topology for SugarCRM by leveraging the scaling policy, the scope of our project is limited to a single server topology.
  • Although MySQL is more commonly used for the database in typical deployments, we want to focus on DB2 while accommodating MySQL. This was done by allowing the user to model DB2 as either a new or an existing instance, but MySQL is only supported as an existing instance.
  • The Apache/PHP software stack is a common platform for an open source web server; therefore a new collection of plug-ins supporting this stack can be reused in other engagements. Our initial thought was to model this stack as a standalone component and SugarCRM as a separate component linked to it to allow us to quickly add support for a new PHP application. We had concerns that such an application pattern would not fit well into the application-centric approach because it exposes the software stack part of the infrastructure so we decided to model the SugarCRM application and the full supporting software stack as a single component.
  • The configuration for SugarCRM is relatively simple and involves only a small set of parameters. We selected a subset of the parameters to expose with the SugarCRM component.
  • The full set of parameters for configuring the database is much more significant: We exposed only the parameters relevant for SugarCRM and set the remaining parameters to default values. The set of parameters is identical for DB2 and MySQL, even though they belong to different components.

Licensing issues

Normally licensing issues don't mean much in technology design, but since some ISV workloads might require non-IBM software, you have to properly manage software and middleware licensing. We decided on these approaches:

  • Bundle the software within the plug-ins. The software binaries or source code are included in the plug-in zip file and become available for use when the pattern type and the plug-in are enabled in the IBM PureSystems administrative console. During the pattern type enablement process, the cloud administrator reviews and accepts the software license agreements. The bundled software approach makes the software tightly integrated with the plug-in development and enablement processes.
  • Let the cloud administrator provide the software binaries or source code during plug-in enablement. The plug-ins will be imported into IBM PureSystems along with the pattern type package and stay in "disabled" state. The cloud administrator gathers the required software following typical licensing procedures and then uses the configure option for individual plug-ins in the IBM PureSystems administrative console. As a result, the plug-in is enabled and the software files are persisted in the IBM PureSystems store house. In this case, the software license agreement process is done outside of the IBM PureSystems environment.
  • Build the software binaries or source code into the base operating system image. The license agreements need to be accepted by the cloud administrator when the virtual machine is added to the IBM PureSystems catalog. Because the same base operating system image is shared across multiple pattern types and plug-ins, this approach works better with generic software for the entire IBM PureSystems domain than with plug-in specific software.

The SugarCRM application depends on some third-party and open source software, so we decided to bundle just SugarCRM files into our plug-ins and take additional software binaries and source code, IBM and open source, as input from the cloud administrator during plug-in enablement.

Design and development

The order of these subsections approximately represents the flow of our design and implementation processes in developing the SugarCRM plug-ins.

Solution design

The key solution design decision is to identify the roles and responsibilities of plug-ins. We considered primarily two approaches:

  • The first is to develop a set of generic plug-ins to support Apache, PHP, and database connectivity, and apply SugarCRM as an input to the plug-ins. This is more flexible to design and deliver truly general-purpose PHP capabilities that can be extended to other PHP applications in a similar fashion.
  • The second is to design and implement SugarCRM-specific PHP and database plug-ins to ensure fully functional SugarCRM applications. The application-centric design fits well with the virtual application concept and makes the ownership and responsibilities of plug-ins easy to define between all involved parties.

Given the highly dynamic nature of PHP configuration, we chose the application-centric design (that is, designed for SugarCRM) as the immediate enablement solution; our intent was to revisit the more generic and reusable approach by implementing modular code. Based on the IBM PureSystems plug-in interaction guidelines in the Plug-in Development Guide, our three plug-ins are designed to have distinct responsibilities.

  • SugarCRM plug-in
    • Define and collect user input for SugarCRM installation
    • Install required operating system packages
    • Install and configure required software including Apache, PHP, and APC
    • Copy and prepare SugarCRM Enterprise package
    • Provide SugarCRM log monitoring
    • Support basic run-time operations
  • DB2 link plug-in
    • Define and collect user input for an existing DB2 instance
    • Support a new DB2 instance in the same application pattern as SugarCRM
    • Install and configure required software including IBM data server client and IBM DB2 PHP extension
    • Reconfigure PHP to work with DB2
    • Install and configure SugarCRM Enterprise with DB2 as back-end database
  • MySQL link plug-in
    • Define and collect user input for an existing MySQL instance
    • Install and configure required software including MySQL client side packages
    • Reconfigure PHP to work with MySQL
    • Install and configure SugarCRM Enterprise with MySQL as back-end database

Because of the open source nature of Apache and PHP, another important decision for us is whether to bundle third-party software binaries or to build the prerequisite software on the fly. We decided to build from the user provided sources for greater flexibility and extensibility.

Solution packaging

Based on the design decisions and license considerations, the SugarCRM enablement solution is packaged as multiple files that are used to enable the business scenarios in IBM PureSystems.

The main plug-in file is the pattern type package that consists of the pattern type definition and four plug-ins. It has the Java™ code, JSON configuration, Python, and shell scripts we developed to support the SugarCRM application modeling, deployment, and operation. The file name is sugarcrm-

Table 2. SugarCRM pattern type package contents
File nameSubfolder in TGZDescription
sugarcrm- pattern type definition for version
sugarcrm- plug-in that supports Apache, PHP, APC, and SugarCRM Enterprise Edition v6.4.0
sugarcrmdb2- DB2 link plug-in that supports SugarCRM connectivity to DB2
sugarcrmmysql- DB2 link plug-in that supports SugarCRM connectivity to MySQL
sugarcrm-samples- sample plug-in provides sample application patterns and templates

Go to the SugarCRM site to download these packaged solutions files.

The others are plug-in enablement files containing freely downloadable third-party products and sources. The cloud administrators can choose to build their own or download the prebuilt packages and then configure individual plug-ins in the IBM PureSystems user interface. Because one of the first platforms supported in IBM PureSystems is Linux, the details of enablement files for Linux are described next.

Table 3. SugarCRM plug-in enablement package contents (SugarLinux.tgz)
File nameSubfolder in TGZSourceDescription
autoconf-latest.tgzLinux\SOURCES tool required by PHPize to compile PHP extensions
httpd-2.2.21.tgzLinux\SOURCES source package
PHP-5.3.8.tgzLinux\SOURCES source package
APC-3.1.9.tgzLinux\SOURCES source package
Table 4. DB2 link plug-in enablement package contents (DB2LinkLinux.tgz)
File nameSubfolder in TGZSourceDescription
ibm_data_server_client_linuxx64_v97.tar.gzLinux\Products data server client v9.7, used to build db2 extension
ibm_db2-1.9.2.tgzLinux\SOURCES for PHP extension "ibm_db2"
Table 5. MySQL link plug-in enablement package contents (MySQLLinkLinux.tgz)
File nameSubfolder in TGZSourceDescription
mysql-shared-compat-5.0.92-1.rhel5.x86_64.rpmLinux\RPMS required for PHP with MySQL option
mysql-devel-5.0.77-4.el5_4.2.x86_64.rpmLinux\RPMS required for PHP with MySQL option

Using PDK as a starting point

A plug-in can be structured as an Eclipse project, thereby leveraging a flexible and powerful platform for development. The internal organization of the plug-in, however, does follow a strict set of rules and conventions so that it can be built into well-formed packages and be processed by the IBM PureSystems subsystems. We found that a development tool was needed in two areas: Getting started and debugging. To this end, the Plug-in Development Kit (PDK) is available as part of IBM PureSystems as a ZIP file that you can download from the home page.

The PDK helps you get started by providing a sample set of two component plug-ins and one link plug-in. We used the sample plug-ins as a learning example and also as a starting point for development by modifying the samples. The implicit rules and conventions can be difficult to discern during development and the resulting errors often manifest themselves in mysterious manners during runtime, making debugging difficult. If there are violations to these rules, such errors most likely will be detected during build.

The PDK also helps with debugging through a debug plug-in. This component can be dragged and dropped into any virtual application pattern. It provides two debugging techniques:

  1. The user can deploy the pattern without actually deploying the VMs to the cloud, so that the topology artifact can be inspected. This can be useful at the initial stage of development when the code is not yet functional and the user can avoid the long cycle of deploying a VM.
  2. After the pattern is deployed to the cloud, the files used during activation are preserved in the VM so that the user can login and debug. This is useful during the latter phase of development for debugging shell and Python scripts.

Use of pattern type

A pattern type is a collection of plug-ins that identifies a specific solution and topology. In a development environment, a pattern type appears as a project. The developer can define name, version, description, and license agreements in patterntype.json and use the PDK-provided build script to generate the pattern type package files.

We packaged three functional plug-ins and a samples plug-in in the SugarCRM pattern type file. A cloud administrator simply imports the pattern type, enables it, and uses the TGZ files described in the Solution packaging section to activate the functional plug-ins. The samples plug-in is enabled when the pattern type is enabled because it does not require configuration.

Developing the application model

The components, links, policies, and user input parameters associated with a plug-in are modeled in the appmodel/metadata.json file. Based on the modeling decisions described in the Design considerations section, we constructed the SugarCRM plug-in to be component-only and the database plug-ins to support both components and links.

  • The id attribute of the component or link has to be unique and is used as the component name in transformation.
  • The type attribute identifies component, link, or policy.
  • The graphic aspect of the component, such as image and thumbnail, can also be specified.

The declarative approach allows the IBM PureSystems application builder to interact with all plug-ins, collect user input, and persist the application model as a JSON document in the store house.

The JSON segment shows how we defined a component and a link in the same metadata.json file.

 	"thumbnail"  : "appmodel/images/thumbnail/existing_DB2_thumb.png",
	"image"      : "appmodel/images/existing_DB2.png"

As illustrated in Figure 3, the user can select a SugarCRM component and one of the two supported database components, DB2 and MySQL.

Figure 3. Component palette
Component palette

The user fills in the parameters as needed for each component (Figures 4 and 5) and then simply drags and connects the two components. The DB2 component can be a new server or an existing server, while the MySQL component is only supported as an existing server.

Figure 4. SugarCRM parameters
SugarCRM parameters
Figure 5. Database component parameters
Database component parameters

Figure 6 shows an example pattern with SugarCRM and existing DB2. As a convenience, several ready-made templates are included in the pattern type for SugarCRM.

Figure 6. Example pattern with SugarCRM and DB2
Example pattern with SugarCRM and DB2

Implementing transformers

One important task of plug-in development is implementing transformers. All plug-ins provide transformers to transform a component, link, or policy in the application model into a topology document fragment that can be used for deployment by the IBM PureSystems framework. The application model and the topology document are both JSON documents.

There are two ways to implement a transformer:

  • For simple models, IBM PureSystems has a TemplateTransform class that allows the plug-in developer to write transformers as a JSON-based template using the Apache Velocity Engine. The developer can therefore develop more visually using JSON and Velocity macros.
  • For more complex models, the developer writes a Java implementation that extends the TopologyProvider class to build a more dynamic and flexible topology JSON object in Java code.

We chose the template approach for our database plug-ins because the transformation is relatively straightforward. The existing database component and the link each have a template. This template segment shows the parameter transformation for an existing DB2 database.

#set( $db_type = $provider.componentName.substring(1) )
    "name"  : "xDB2",
    "type"  : "xDB2",
    "parms" : {
        "db_type"     : "$db_type",
        "db_name"     : "$attributes.db_name",
        "db_hostname" : "$attributes.db_hostname",
        "db_port"     : "$attributes.db_port",
        "user"        : "$attributes.user",
        "password"    : "$attributes.password",
        "service"     : "$prefix"

The SugarCRM component transformation requires more functionality, so we developed the transformer using a Java implementation.

The use of Velocity templates or Java code is declared in the XML files under the OSGI-INF directory. This XML segment shows the use of a template, templates/xdb2_component.vm, as the transformer.

<scr:component xmlns:scr="" name="xDB2">
 <implementation class=""/>
		<provide interface=""/>
 <property name="component.template" type="String" value="templates/xdb2_component.vm"/>

The component documents, OSGI-INF/*.xml, must be listed in the manifest file META-INF/MANIFEST.MF. This manifest file segment shows two component documents used for the DB2 link plug-in.

Service-Component: OSGI-INF/SugarCRMDB2Transform.xml,OSGI-INF/xDB2Transform.xml

Automation scripts

The set of new plug-ins to support SugarCRM includes these components:

  1. Existing DB2: Represents an existing DB2 server and performs the necessary configuration such as initializing the database for SugarCRM.
  2. Existing MySQL: Represents an existing MySQL server and performs the necessary configuration such as initializing the database for SugarCRM.
  3. DB2 link: Represents the dependency between the SugarCRM and DB2 components and performs the final configuration when both the SugarCRM and DB2 servers are ready. This includes propagating the IP address of the DB2 server to the SugarCRM server.
  4. MySQL link: Represents the dependency between the SugarCRM and MySQL components and performs the final configuration when both the SugarCRM and MySQL servers are ready. This includes propagating the IP address of the MySQL server to the SugarCRM server.

For the actual implementation, we organized the code for these plug-ins as the following Eclipse projects:

  1. SugarCRM component as a single project.
  2. Existing DB2 component and link as a combined project.
  3. Existing MySQL component and link as a combined project.

The Plug-in Development Guide describes a well-defined structure for the Eclipse project that a plug-in implementation must follow. Figures 7 and 8 show the internal layout of the three Eclipse projects, focusing on the plug-in directory where our code resides.

Figure 7. Plug-in implementation for SugarCRM
Plug-in implementation for SugarCRM
Figure 8. Plug-in implementation for DB2 and MySQL
Plug-in implementation for DB2 and MySQL

The files highlighted in red are the entry points for IBM PureSystems: They contain the Python code to install and configure the software. Their names and locations are fixed so that the activation engine can invoke them during deployment.

The standard sequence is:


The remaining scripts are supporting scripts that are called from the main scripts. The binaries that can be packaged with the plug-in are in the files directory and they are placed in separate Linux and AIX directories. Similarly, the scripts are also placed in separate Linux and AIX directories.

In some implementations, the scripts are single-source; that means they are written to run on both Linux and AIX platforms. In our case, we found that the implementation is much too different between the two platforms, so we deemed it more manageable to maintain them separately.

Note in Figure 8 how the code for the component and the link is organized in the same plug-in.

For better consumability, we added a samples plug-in with predefined application patterns and templates as a separate Eclipse project. The included patterns help end users to quickly get to a workable pattern and the templates enable rapid deployment.

Figure 9 shows a template deployment screen with simple user input.

Figure 9. Deploy SugarCRM application using template
Deploy SugarCRM application using template

We used the IBM PureSystems application export feature to collect the metadata and placed the decompressed files into the /plug-in/applications folder as seen in Figure 10.

Figure 10. Plug-in structure for Samples
Plug-in structure for Samples

Reuse existing plug-ins

In the case of deploying a new DB2 server along with the SugarCRM node in the same application pattern, we would like to leverage the IBM PureSystems DB2 plug-in capabilities as much as possible. Working with the IBM PureSystems development teams, we identified and articulated two new features:

  • The ability to reuse existing plug-ins in new custom pattern types.
  • The ability to extend plug-in features and database configurations.

Reuse existing plug-ins in new custom pattern types
We want to include a new DB2 component during application modeling and configure a new DB2 server to work with SugarCRM during application deployment. With the current product capabilities, it is not possible because DB2 plug-ins are defined and loaded into IBM PureSystems to work with known pattern types such as dbaas and webapp.

We requested a new feature allowing a custom plug-in to indicate the inclusion of existing pattern types, and therefore plug-ins, in the plug-in definition. The IBM PureSystems links feature was developed so a "links" clause can be declared in a plug-ins config.json and the framework will make use of the linked plug-ins as if they were associated through the secondary pattern type declaration.

This turns out to be a generic and useful product feature that conveniently enables the reusability of plug-ins of all pattern types.

Extend DB2 plug-in features and database configurations
Two of the SugarCRM installation requirements are:

  • The full text search capability of the database server. DB2 has full text search as an add-on feature that is by default not enabled in the IBM PureSystems virtual application pattern deployment using DB2 plug-ins.
  • A customizable database configuration in buffer pool and table space.

To ensure the virtual application pattern provisioned database meets all the requirements, we clearly defined the proper extension points with the DB2 plug-in development team. A new product feature, custom database workload standard, was built and delivered. It allows end users to create a new database workload standard including a script package file with custom scripts to be run at each extension point. The custom database workload standard can be used for DB2 configuration in a virtual application pattern.

To do this, we customized and packaged these scripts:

  • Customize DB2 instance after it is first installed and started.
  • Customize database configuration after it is created.
  • Start full text search every time DB2 is (re)started.

With these two newly developed features, we successfully achieved our goals of reusing DB2 plug-ins for SugarCRM enablement.

In conclusion

In this article, we demonstrated the design considerations our team used as a template to guide us in creating a plug-in to enable the existing SugarCRM solution to deploy on IBM PureSystems. We also took you through our development efforts:

  • Developing the three plug-ins to enable SugarCRM.
  • Packaging the plug-ins.
  • Using the samples in the Plug-in Development Kit as a starting point (and especially for debugging our plug-ins).
  • Defining a pattern type and application model for our plug-ins (to make them quickly deployable).
  • Implementing transformers, the "engines" that convert application model bits into a topology document fragment that can be used for deployment by IBM PureSystems.
  • Building scripts to automate implementation and deployment tasks.
  • Building two new pattern-type-reuse and database-configuration plug-in features to meet the requirements of the SugarCRM solution.

But that's not all. Part 2 details the lessons we learned developing the plug-in for SugarCRM.


We'd like to thank the major supporters of this project:

  • Willy Chiu, Larry Hsiung, Thomas Truong, Jeffrey Coveyduc, Kai Young, Nauman Fakhar, Chris Kiernan, Raymond Wong of the cloud labs and HiPODS team
  • Steve Ims, Lin Sun, Ted Kirby of the IBM Workload Deployer development team
  • Ning Wang, Qi Rong Wang of the IBM Database as a Service development Tteam
  • Nasser Momtaheni, Joseph Peterson, Rodney Johnson of the IBM Innovation Center team
  • Stas Malyshev of SugarCRM



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Cloud computing on developerWorks

  • developerWorks Premium

    Exclusive tools to build your next great app. Learn more.

  • Cloud newsletter

    Crazy about Cloud? Sign up for our monthly newsletter and the latest cloud news.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

Zone=Cloud computing, Information Management
ArticleTitle=Deploy new applications on IBM PureSystems with plug-ins, Part 1