Navigate a shared services workload in PureApplication System

Learn to build shared services, a workload that provides common capabilities for other workloads

IBM® PureApplication™ System and IBM Workload Deployer provide capabilities to run many different workloads in the cloud — one of those is shared services, a type of workload, that helps clients provide common capabilities for other workloads. These common capabilities and runtime services improve the cloud density while simplifying the usage of complex or advanced features. In this article, the authors explain some basic concepts of shared services, describe the sample shared service plug-ins in the Plug-in Development Kit (PDK) which provides a strong starting point to create new shared services. They also walk you through converting the sample shared service into a functional generic media shared service, a generic file storage repository where client deployments can obtain common files.


Jim Riordan (, Developer, IBM

Jim Riordan has been with IBM for 10 years and has written multiple test cases, internal development documentation (like design documents, developer guides, and user guides), and has reviewed and written external information center documentation for multiple IBM products, including WebSphere®, WebSphere Business Integration/Connect, and IBM Workload Deployer. He currently works as a developer in the IBM Workload Deployer and the IBM PureApplication System technologies.

James Kochuba, WebSphere Cloud Shared Services Architect, IBM

James Kochuba photoJames Kochuba is the WebSphere cloud shared services architect and serviceability lead working on Workload Deployer and PureScale Application System. His previous roles in IBM include the WebSphere Application Server security test architect, AIM premium support team, and WebSphere Application Server support team. He is the technical lead for shared services (like logging, monitoring, and caching services) and services (troubleshooting) for the IBM Platform as a Service products. Using his previous client and technical background, Jim helps produce higher quality services to match client usage needs.

01 October 2012

Also available in Chinese Japanese Portuguese

A shared service is a pre-defined pattern that is deployed and shared by multiple client application deployments (such as virtual applications, virtual systems, and virtual appliances) in the cloud. A shared service provides certain runtime services to multiple applications or services to the end-user on behalf of multiple applications.

You usually find only one single reference to the shared service per cloud group (which is a physical group of hardware that defines a cloud) — that shared service can be used by all application deployments in the cloud group. That means the shared service has to provide multi-tenent access.

Figure 1. A shared service is a pre-defined pattern, deployed and shared by multiple app deployments
A shared service is a pre-defined pattern, deployed and shared by multiple app deployments

For the purposes of this article, we define a shared service as a single deployment that is usable by other virtual application deployments (client deployments). One or more client deployments can connect to the single shared service deployment to access a common data repository.

This article describes the steps for importing and customizing the sample shared service from the Plug-in Development Kit (PDK), referred to as sample shared service or media service.

For some good complementary learning resources to this article (maybe even prerequisites depending on your level of experience with this topic), see the sidebar.

Concept of a media shared service

Often a virtual application deployment requires some form of prerequisite binary media to install; for example, binaries on a build server or ISO DVD images. There may be reasons not to package these binaries with the application pattern or components plug-ins, such as licensing, code distribution concerns, or the binary may need to be updated independently of the application pattern.

To get you started

Before working through this article, you might want to familiarize yourself with the concepts of a virtual application and the Plug-in Development Kit (PDK) mentioned in the summary. These resources can help:

The ones in bold are highly recommended by the authors. Editor

In a cloud environment, multiple application deployments may need to reference the same media files. If the required files are on a slower (perhaps remote) network outside the cloud, it can take considerable time to download the files into each deployed virtual application.

To solve these problems, we suggest creating a new media shared service that will host a binary file repository for use by any virtual application in the cloud group. The media service can be deployed and loaded with prerequisite files independently of the virtual applications and plug-ins.

Rather than copying files from something outside the cloud each time new application deployments are started, you can copy the files once into the media service virtual machine (VM), making them locally available in the cloud. This lets the administrator manage this service in a more centralized design versus independent VMs that share no common framework.

The file copy speed from the media service to the virtual app will be much faster since it is all internal to the rack (meaning the PureApplication System) and cloud group, allowing multiple deployments to quickly access the data.

The following example is a typical flow for the media service:

  1. Deploy the shared service/media service.
  2. The media service VM starts and is loaded with binary files to share via NFS on the cloud group.
  3. Deploy a virtual application that uses the media service (component flag or policy in the pattern).
  4. The virtual application asks the media service for the binary file location(s) and/or connection information.
  5. The virtual application can NFS mount the file repository from the media service VM.
  6. Repeat for multiple virtual application deployments. Each one is given access to the shared file(s) via the media service.

We'll first go through the sample shared service provided in Plug-in Development Kit, reviewing with you the elements provided and then importing the shared service to the IBM PureApplication System or IBM Workload Deployer product to deploy into the cloud. This provides you with an overview of how to add a generic shared service.

Then we'll explain how to modify the sample shared service plug-ins to become a media shared service, showing how easy you can add a new shared service. Following this section are the steps and code snippets of how to do this so you can easily take what is provided and create your own media shared service and future custom shared services.

Building and installing the PDK, service, and client virtual app

The sample shared service found in the PDK v1.0.0.4 serves as a good skeleton for customization. It sets up the needed file structure and core scripts defining the following:

  • A sample shared service with a REST API administrative interface.
  • A client virtual application component that uses the sample shared service calling to the REST API administrative interface.

Start by importing the example code and then proceed to adding custom functionality.

Download PDK v1.0.0.4. The minimum requirement to deploy the plug-ins is IBM Workload Deployer or IBM PureApplication System v1.0. See the sidebar references for instruction on using the PDK.

A few things to keep in mind:

  1. Make sure you import all projects including the shared service and the shared service client.
  2. Go to the plug-in.depends project and use ANT to run build.xml. Execute the clean and publish targets in that order. This builds all the plug-in projects including the shared service and shared service client.
  3. Go to patterntype.hello and use ANT to run build.patterntype.xml. Execute the clean and publish targets in that order. This packages the output from plug-in.depends into a single pattern to import.

Now let's install the pattern type in Workload Deployer or PureApplication System.

Installing the pattern type in IWD or IBM PureApplication System

To install the pattern type which contains the sample shared service plug-ins:

  1. In the IBM Workload Deployer console or PureApplication System Workload console, go to Cloud > Pattern types.
  2. If the pattnertype.hello pattern type exists already, select it and click Delete.
  3. Note: Make sure no running deployments are using the plug-ins from this pattern type or you won't be able to delete it. Also, please wait a moment for the process to complete and the page to refresh.
  4. Click on the green plus sign to import your new pattern type.
  5. Import the file from your Eclipse workspace: patterntype.hello/export/ptype.hello- file.
  6. After import is complete, select the patterntype.hello pattern and enable it by accepting the license.

Note: If you want to modify and redeploy the client without redeploying the shared service, you can package it separately, changing the version number (only unique versions can be imported) and uploading it through the Cloud > System Plug-ins page.

Next, deploy the sample shared service.

Deploying the sample shared service

To deploy the sample shared service into a cloud group so this shared service is ready for use:

  1. In the Workload Deployer console or PureApplication System Workload console, go to Cloud > Shared Services.
  2. Select the Sample Shared Service under the sample shared service header.
  3. Click Deploy.
  4. Enter the required deployment parameters:
    1. Enable REST API: checked.
    2. Management VM Number: 1.
    3. Service VM Number: 0.
    Figure 2. The deployment parameters of the sample shared service
    The deployment parameters of the sample shared service
  5. Click OK.
  6. On the next screen, specify the correct deployment parameters for your environment and click OK.
  7. View the deployment under Instances > Shared Services.

Wait until the deployed sample shared service goes green and is ready for use before moving to the next step, deploying the shared service client.

Deploying the shared service client

Create a pattern for the shared service client that will use the sample shared service. Note that the shared service client depends on the sample shared service to be running before it can be deployed successfully.

  1. In the Workload Deployer console or PureApplication System Workload console, go to Patterns > Virtual Applications.
  2. Select patterntype.hello in the drop-down list and select the plus sign to create a new pattern.
  3. In the Pattern Editor, drag the Shared Service Client Sample from the left frame into the center.
    Figure 3. Creating a pattern for the shared service client
    Creating a pattern for the shared service client
  4. Click Save and name your new application. We name it SharedServiceClient.
  5. Close the App Builder window and refresh the Virtual Application Patterns screen.
  6. Select the new client SharedServiceClient.
  7. Click Deploy.
  8. Specify the correct deployment parameters for your environment and click OK.
  9. View the deployment under Instances > Virtual Applications.

Wait until the deployed client pattern is green for go and ready to use before moving to the next step, getting to the Management Operations console where you can interact with deployed VMs.

Unveiling the Management Operations console screen

The Management Operations screen allows users to interact with deployed VMs. There is a Management Operations screen for the sample shared service deployment and for the shared service client application deployment.

To view the Management Operations screen for the sample shared service:

  1. View the deployment under Instances > Shared Services > Sample Shared Service.
  2. After it is running, click Manage link.
  3. Click the Operation tab.
  4. Click the SharedService-Management.ServiceSample role. Note that this link does not exist until you add some operations to it. You'll do that a little later.

To view the Management Operations screen for the shared service client:

  1. View the deployment under Instances > Virtual Applications.
  2. After it is running, click Manage link.
  3. Click the Operation tab.
  4. Click the SharedService-Client.ServiceClient role.
Figure 4. The Management Operations page of the shared service client
The Management Operations page of the shared service client

In the example code, you can use the client's Management Operations to interact with the sample shared service REST APIs. You can see the interaction by using the Operation screen to submit a REST call to the shared service. For example:

  1. Expand the REST Calls section.
  2. Enter the following:
    URL:  test
    JSON:  {}
  3. Click Submit.

This calls the REST API on the shared service, but it does not really do anything useful yet.

This is one way the administrator of the deployment can cause the client to interact with the shared service. The client could also have its life cycle script automatically call the shared service to complete actions without the user requirement. This is all based on how the client wants to expose the interaction to the shared service. We'll walk through an example implementation of this in the next sections.

Let's look at the code of the shared service to modify the sample shared service into a media service.

Code walkthrough of the sample service and client

The sample shared service plug-in (from the PDK) that provides the life cycle scripts and pre-defined pattern to create and manage the shared service is called It creates one or more VMs and runs a REST API for use by clients. You will be customizing this to create a media service.

The following files are also inside the plug-in package you obtained from the PDK:

  • src / / This file defines the registry response information for this shared service. For example, the client code calls getRegistry and this method returns the IP of this shared service. The registry object that is returned is a JSON object, so it can contain any additional data as well. This code is running in the management process of the system (for example, in the IBM Workload Deployer appliance or the PureApplication System manager node). Note, the name and package of this file can be customized, but you need to make sure to also update the file name in the OSGI-INF file (OSGI-INF / serviceRegistryProvider.xml).
  • OSGI-INF / serviceRegistryProvider.xml: This file contains the OSGI details for the bundle creating a reference for others to call this bundle and properly execute. This file name can be customized and requires the manifest file (META-INF / MANIFEST.MF) for the plug-in to note the custom name.
  • plug-in / appmodel / metadata.json: This defines the deployment parameters when the user deploys the shared service. In this case, the user can enable or disable the REST API and set the number of VMs to create for both management and service VM. This file name is not customizable.

    The sample shared service contains the ability to deploy multiple VMs — one management VM and one or more service VMs. The concept is that the service VMs are scalable to allow for failover or provisioning additional resources when needed.

    • The management VM hosts the main REST API and run the REST API scripts.
    • The service VMs also hosts a REST API, but is redundant.
    The idea is that the user can implement the data redundancy logic and communication among service VMs, as well as setting scale-in or scale-out metrics for dynamically creating or removing service VMs. These are more advanced topics and are beyond the scope of this article.

    For the purpose of this article, we assume only one sample shared service VM is deployed: The management VM. We ignore the service VMs to avoid confusion.

  • plug-in / templates / servicesample.vm: This is the VM template file that defines the VMs that get created. In this file, two VMs types are defined:
    • SharedService-Management for the management VMs.
    • SharedService-Service for the service VMs.
    The attributes referenced in the file are supplied by the user at deployment time by directly mapping to metadata.json. For example, servicesample.vm contains ${attributes.managementNum} which is defined in metadata.json: "id":"managementNum".

    The VM template is based on Apache Velocity, so you can add logic into this to dynamically change the final topology generated. As you can see, the #if logic defines the SharedService-Service VM only if the user entered a number greater than 0 at deployment time: #if (${attributes.serviceNum} > 0). For this article, we do not deploy SharedService-Service VMs, so attributes.serviceNum is 0.

  • plug-in / nodeparts / servicesampleapi / common / install / This script is run during VM installation to set up the REST API. The name needs to start with a number to properly run in the expected order when nodeparts runs, but the name after the underscore ( can be customized.
  • plug-in / nodeparts / servicesampleapi / servicesampleapi / properties / servicesampleapi.json: This JSON file defines the REST API methods to be exposed.
  • plug-in / parts / servicesample.scripts / scripts / ServiceSample / This is the Python script that runs when the REST API is called. It is referenced in servicesampleapi.json for each REST API call. The file name can be customized, but you need to make sure the servicesampleapi.json properly uses the custom name.

The shared service client plug-in is When it is deployed, it provides the capability for the client deployment to interact with the shared service. The following files are also inside the plug-in package:

  • src / / This is the client service provisioner. It is run when the client is deployed, before the client VMs are created. It shows how to get the reference to the shared service and call the shared service REST API.

    One example usage of a provisioner is to tell the shared service that another client is being provisioned. For example, using the REST API, the shared service can create a new user/password and return that data for use by the client connections. This is not required, but it provides the capability for the client deployment to fail gracefully if the shared service is not correct for this deployment. Another example: If the expectations of the service are not correct, this can stop the client deployment from happening. The user then needs to work with the shared service administrator to fix the shared service before wasting resources on failed application deployment VMs.

  • plug-in / appmodel / operation.json: This JSON file defines the operations available on the Management Operations console screen for the deployment. This allows the administrator of the client deployment to have easy-to-use operations. This file name is not customizable. When the operation is run, it calls the script as defined by this line: "script": " call".
  • plug-in / parts / clientsample / scripts / ServiceClient / This script is run when the user runs an operation from the Management Operations console. It generates a REST call to the shared service, then uses the maestro.pcurl command to execute the HTTP call.

Now you should have a better understanding about the pieces that make up the client and service relationship for a shared service scenario. Let's move on and look at customizing the sample shared service into a media service. We'll describe the simple modifications that are needed to create a custom media service.

Media service details

Make the following changes to the project.

  1. Add one more bit of information to the shared service registry. Edit the file src / / by adding this line in the getRegistry command just before the registry is returned:
    registry.put("mountPoint", "/shared_repository");

    This extra bit of information is the file path of the NFS mount point that you are creating. The client code needs to read this value to know how to NFS mount the repository.

  2. Add to the shared service REST API. Modify the file plug-in / nodeparts / servicesampleapi / servicesampleapi / properties / servicesampleapi.json by adding the new function for listRepository in the GET section:
    { "resource":"listRepository", 
    "script": " listRepository", 
    "timeout" : 60000},

    This defines the following:

    • A GET call to listRepository.
    • That it is available to other client deployments (not just the core IBM Workload Deployer/IPAS code).
    • That it is run by the VM role type SharedService-Management.ServiceSample.
    • That when called, it runs the script and passes listRepository as the parameter. You'll update the script to use this new parameter in a moment.
    • That response timeout is set to 60 seconds.
  3. Add the same operations for this service to be exposed on the Management Operations screen. Define two operations: listRepository and importFile.

    Create a new file called plug-in/appmodel/operation.json:

         "ServiceSample": [
                   "id": "listRepository", 
                   "label": "List repository", 
                   "description": "List files in the repository", 
                   "script": " listRepository"               
                "id": "importFile",                
                "label": "Import file via HTTP", 
                "description": "Import a single file into the repository via http url.", 
                "script": " importFile", 
                "attributes": [                         
                             "label": "URL to import", 
                             "type": "string", 
                             "id": "url", 
                             "required": true, 
                             "description": "HTTP URL of a single file to import into 
                                             the repository."
  4. Write the Python methods that get executed when the operations are run. Create a new file called parts/servicesample.scripts/scripts/ServiceSample/ This script is called when an operation is run from the Management Operations page. It contains the two new methods and the needed framework logic to run them.
  5. Update the parts/servicesample.scripts/scripts/ServiceSample/ script to add the new REST API. To add a new method to the script:
    def listRepository():
        logger.debug('Called listRepository in restapi')
        ret = os.listdir(SHARED_REPOSITORY_PATH)
        #create JSON string out of return value
        ret = '{"fileList":"'+str(ret)+'"}'
        logger.debug('return value = ' + str(ret))
        maestro.operation['return_value'] = ret

    To update the main run() method to call the new method:

    def run():
        elif mode == "listRepository":
  6. Add the logic to the life cycle script to actually create the NFS share.

With these modifications, you have created a media service that is ready to be built and deployed.

Now you can test the shared service. Build the pattern type, reinstall, and redeploy the shared service. After deployment, go to the Operations screen and try importing a file and listing the repository.

Note that file import URLs must be network-visible to this VM. If you prefer, you can customize the operation parameters and Python script to import using the scp command or even an NFS share. The Python scripts can call a shell script as well, so there are many possibilities.

Figure 5. The Management Operations page after uploading a file to the media service
The Management Operations page after uploading a file to the media service

Optional: Loading files before you deploy

So far, this exercise has been good for loading files after deployment time, but what if you wanted to specify the files to load before you click deploy? We don't include this in the example code, but here are a few pointers.

You can add an optional user entry field to the deployment parameters, metadata.json:

            "label":"URL listing of files to load",
            "description":"List one or more URLs of files to import into the repository.
                           Multiple URLs must be separated by a comma.",

And place the user entry in the topology document, templates/servicesample.vm.

Under the vm-template for SharedService-Management, edit the roles block to add the parms section:

            "roles": [
                    "type": "ServiceSample", 
                    "name": "ServiceSample"
                        #if ( ${attributes.filesToLoad })
                        "filesToLoad":"${attributes.filesToLoad }",

These parms are available to the life cycle scripts in the ServiceSample role. For example: parts/servicesample.scripts/scripts/ServiceSample/

if 'filesToLoad' in maestro.parms:
     filesToLoad = maestro.parms['filesToLoad']

Your script then needs to parse the user's input and download the files. You can test this functionality yourself while we move on with the client configuration.

Media service client details

Create the client-side plug-in to actually use the media service you've built. Start by making the following changes to the project.

  1. When the client is deployed, one of the first pieces that runs is the client provisioner In this file there are several examples of REST API calls to the linked shared service. Currently these calls don't do much, but you can modify it for the media service. The new call tests the new listRepository REST API and throws an exception if an error is returned. This exception immediately stops the deployment (before any VMs are created), and logs the exception details.

    You are only checking the HTTP return call, but you can check for specific data in the response as well. Note, this is optional code and can be completely removed, but detecting a missing prerequisite before starting the VM saves time for the deployer and system resources in the cloud.

    In the createService() method, just below the existing REST API calls, add one more call:

              // Make a call to the Shared Service, and throw an exception if a valid 
                 response is not returned.
              response = this.registrySvc.callOperationOnSharedService(serviceName,
                    clientCloudGroup, clientVersion, ip, "listRepository", "GET", null);
              logger.logp(Level.INFO, CLASS_NAME, METHOD_NAME, "Client Sample Service
                          Provisioner: Called example GET listRepository REST call to the
                          shared service: {0}  URL: {1}",
                        new Object[] { serviceName, "listRepository"});
              int statusCode = response.getStatusCode();
              JSONObject responseData = response.getOperationResponse();
              logger.logp(Level.INFO, CLASS_NAME, METHOD_NAME, "Client Sample Service
                       Provisioner: Response back from the REST call was response status
                          code: {0}  Data: {1}",
                   new Object[] { statusCode, responseData });
              if (statusCode!= HttpURLConnection.HTTP_OK) {
                // there was a problem with the REST call to the shared service. It may 
                      not be running.
                   // Throw an exception which will stop the deployment 
                   logger.logp(Level.SEVERE, CLASS_NAME, METHOD_NAME, "Client Service
                               Provisioner: There was a problem with the response.");
                   throw new Exception ("The required Shared Service did not return a
                                         valid response. Please ensure the Shared 
                                         Service is running.");
  2. Call the REST API listRepository in the client's life cycle scripts ( so the VM knows what files are on the media service. You need to create another to install the ServiceClient role, so create a new file called plug-in / parts / clientsample / scripts / ServiceClient /
  3. Add code that retrieves the shared service registry info:
    regInfo = maestro.registry.getRegistry("sample", "1.0")        
    ipAddr = regInfo['ip']
    mountPoint = regInfo['mountPoint']
  4. Add code that calls the REST API:
    # Drive pcurl method
    jsonResults = pcurlInvoke(ipAddr, "sample", method, sslOpts, url, str(json))
    # now use the results however you wish
    logger.debug('return value of listRepository = ' + str(jsonResults))
  5. Add code that mounts the shared repository from the media service and copies all the files:
    mountCommand = 'mount ' +ipAddr+":/"+mountPoint+" "+ localMountPoint
    logger.debug('mount command = ' + str(mountCommand))
    rc = maestro.trace_call(logger, mountCommand , shell=True)
    logger.debug('return value mount command = ' + str(rc))
    logger.debug('Copying all files')
    rc = maestro.trace_call(logger, 'cp -r '+ localMountPoint+"/* 
         " +localRepository, shell=True)
    logger.debug('return value from copy command = ' + str(rc))
  6. View the full source code for the full file implementation.

In this example, you query the shared service registry using the shared service name (in this case, "sample") that was registered in plug-in / applications / servicesample / appmodel.json of the shared service: "servicename": "sample". This returns the JSON object that was created in getRegistry method from In this case, the IP address and the mount point of the shared service is returned. Once you have that information, you can mount the file system and copy over your files. The script can then be modified to use the copied files in the virtual application; for example, unzip and launch an installer.

With all the modifications you've made, you have created a client plug-in to a media service that is ready to be built and deployed.

Now, you can build and test the client project. Follow the previous steps for building, reinstalling, and deploying the shared service and client virtual application.

After deploying the media service, use the Management Operations console to upload a file to it then deploy the client virtual application. Check the log files of both the shared service and the shared service client. You should see the client connect to the media service and download the file from it.

Ideas for improvement

We included some ideas for improvements in this process, but they are left for you to explore.

  • Backing up of media from shared service management VM to any service VMs.
  • Creating a scaling policy on the service VM of the media service and implementing data replication.
  • Adding more intelligence to the REST API for getting connection information (you can use round-robin routing to the various service VMs).
  • Using alternate or more secure connectivity:
    • Supply client IP addresses in the REST API call so that the media service only opens IP firewall ports to allowed IPs.
    • Use an alternate secure mounting and file copy other than NFS or HTTP.
  • Additional methods of media upload with file validation based on loaded metadata.
  • Additional filtering of file copy from the media service to the client.
  • Validate user input to improve security. Add user input and REST API parameter validation to prevent undesired commands from being run. In our code, the input parameter from the media service's import file operation is passed directly to the command line, allowing a user to potentially run a malicious command on our media service VM.
  • The code that connects the media service client to the media service is tightly coupled and fully integrated into the client. This works well if you only have one media service client pattern, but if you create multiple different client application patterns that all use the media service, you'll find yourself copying the same media service connection scripts into each plug-in. In this case, it is best to separate out the media service client logic into its own plug-in. This consists of a generic plug-in fragment that contains only the connection logic scripts to connect to the media service and download necessary files. For example, it has an or life cycle script that connect to the media service and downloads a file. Any new clients can be written without media service client logic. They only need to reference this media service client plug-in. On deployment of the new virtual app, the media service client plug-in scripts are pulled into your virtual machine and run along with your app.

In conclusion

In this article, we walked you through the sample shared service plug-ins provided by IBM to help demonstrate a shared service and how it provides a nice skeleton for future shared services. We showed you how to take that skeleton and create a media shared service that hosts a shared repository which can be loaded with files via the Management Operations console. Then we looked at customizing a virtual application to create a client to this shared service, connecting to the media service shared repository. On startup, the client VM NFS mounts the repository and copies over the files.

Now you have a simple shared repository in the cloud for virtual applications to use. You can modify this to be more complex by doing things like adding security, different repositories, etc. — whatever enhancement you can dream up.


Sample code for this articlesharedservice-workspace.zip86.9KB



Get products and technologies


  • Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.


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
ArticleTitle=Navigate a shared services workload in PureApplication System