Since its inception, IBM Workload Deployer (formerly IBM WebSphere® CloudBurst™ Appliance) has been state-of-the-art in terms of cloud computing for middleware and middleware applications. The latest release of IBM Workload Deployer, version 3.1, continues to build on this strong foundation by expanding its capabilities and platform support. But before looking at what's new, let's put a little context around the IBM Workload Deployer solution to help you understand and appreciate the new capabilities described here.
Looking back to 2009, WebSphere CloudBurst was a solution targeted at improving three major inefficiencies in modern organizations:
- It takes too long to set up middleware and middleware application environments. Statistics show us that, on average, the act of standing up one of these environments can take anywhere from four to six months. In today’s world, where the whim of the constantly-connected consumer has serious and near-instant implications on IT, companies cannot afford to measure anything in months.
- Middleware environments are complex just by their very nature. This infrastructure is there to support applications that have many needs in terms of performance, capability, integration, and more. This complexity often surfaces in the form of a phenomenon known as configuration drift; perhaps you have firsthand experience of this yourself. For example, have you ever deployed what you thought were two identical application environments only to find that the application behaves very differently in each place? Your reflex is to look for a change in the application that causes the different behavior, but in fact, statistics say that 30% of “application bugs” are actually the result of inconsistent configurations. Ultimately, configuration drift can have a bottom line impact in terms of increased IT delivery times and costs.
- If it takes a long time to set up an environment and it’s hard to ensure the consistency of environments across installations, the inevitable result is that your IT infrastructure will begin to host a lot of "just in case" environments. In other words, developers will stand up middleware environments, leverage them for some temporary purpose (such as new code development), and then leave them around even after the work is completed. One reason for this is that it’s easier to use an existing environment rather than wait for a new environment to be created if they happen to need one again in a few days or weeks, plus it might be difficult to faithfully recreate the environment again. While some might feel this is an efficient way of working, it’s a terribly inefficient use of organizational resources because IT ends up hosting environments that are only sporadically in use. This contributes to the extremely low average utilization rates of between 6-10% often observed in many IT development and test environments, and is also a significant factor in resource sprawl and waste, which is caused by procuring new hardware for every new project.
Today, the pattern models coupled with IBM Workload Deployer management capabilities cover the spectrum of Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS), and most importantly, equip you to eliminate the three main inefficiencies listed above. Whether you need to quickly deploy workloads consisting of predefined, individual system images (virtual appliances), complete configurations of integrated middleware solutions (virtual system patterns), or fully automated, optimized, and managed application environments (virtual application patterns), IBM Workload Deployer has you covered.
This article discusses the new capabilities and enhancements in IBM Workload Deployer V3.1 particular to virtual application patterns, looks at those things that are new for virtual system patterns, and then concludes by noting the new management and administrative capabilities present in the IBM Workload Deployer appliance.
This article assumes some level of familiarity with the capabilities and features of IBM Workload Deployer. See Resources for more introductory level material.
Virtual applications were first introduced in IBM Workload Deployer V3.0. The primary tenant of a virtual application is that it frees you to focus on the things that really matter to your business – your application and characteristics of how you want it to be supported – while enabling the appliance to create and manage the necessary infrastructure to support your application. IBM Workload Deployer inspects your standards-based application elements, such as enterprise archives, web archives, schema definitions, user registry files, and others, so that it can understand the requirements of your application. You also provide criteria policies that you want to have enforced for the application. IBM Workload Deployer takes care of the rest, which includes:
- Creating the required configuration in your private cloud with all of the necessary virtual machines configured for their specific purposes.
- Monitoring your running application to ensure that it remains available.
- Managing the application, based upon the criteria that you specify for your service level requirements to elastically scale both up and down.
Virtual applications are true PaaS offerings where you provide your application elements and IBM Workload Deployer builds and manages the necessary platform to host your application. (See Easy virtual app automation using Workload Deployer.)
Virtual application patterns are built from components within a pattern type. Pattern types are created for specific types of applications. often including functionality from multiple traditional middleware products to form a complete solution for a specific type of application. IBM Workload Deployer introduced two initial pattern types:
- A web application pattern created specifically for on-line transaction processing web-based applications
- A Database-as-a-Service (DBaaS) pattern type that is well suited for database applications.
The database pattern type can be used in conjunction with the web application pattern type. You deploy instances of your applications using a pattern-based deployment model. The web application pattern type solution includes capabilities from IBM WebSphere Application Server, IBM Tivoli® Directory Server, IBM HTTP Server, and IBM WebSphere eXtreme Scale, among others. These work together in a seamless fashion to provide a complete solution for your web-based application. IBM Workload Deployer V3.1 includes new releases of both the web application and DBaaS pattern types have been released.
Whenever you obtain new releases and fixpacks for your environments, you must be able to apply that maintenance to previously deployed systems. Therefore, IBM Workload Deployer V3.1 adds a new capability to easily upgrade deployed virtual application instances to the most recent maintenance installed. For example, IBM Workload Deployer V3.1 includes an update for the web application 1.0 pattern type from version 188.8.131.52 to 184.108.40.206. After you install and enable the newest version of the web application pattern type, any subsequent deployments of virtual application patterns that use the selected version and release will deploy with the latest version of the plugins.
It is important to note that existing virtual web application deployed instances will continue to use the former 220.127.116.11 web application pattern type plugins until you choose to upgrade them. From the user interface you can view the deployed virtual application instance and simply select the Upgrade button to move to the latest version of the plugins for the pattern type. When you perform an upgrade on a deployed virtual application instance, you are actually updating all of the pattern types included in that instance. All plugins move to the latest maintenance that you have installed and are enabled within the same version and release. This might include updates to the foundation pattern type, the web application pattern type, the database pattern type, or any other pattern types leveraged by your deployed virtual application instance. Upgrading involves running automated scripts to update the virtual machines associated with the selected instance (see the IBM Workload Plugin Development Kit for details on the various lifecycle scripts for plugins and the scripts that are run for upgrades).
While IBM Workload Deployer V3.1 brings several enhancements to virtual application pattern deployments, perhaps the most notable is the ability to deploy virtual application patterns for AIX® environments on the PowerVM® hypervisor infrastructure. Prior to this release, IBM Workload Deployer supported virtual applications for Linux® environments leveraging a VMWare ESX hypervisor infrastructure. IBM Workload Deployer now supports virtual application deployments to both VMware and IBM PowerVM virtualization platforms.
Figure 1. Supported virtualization platforms
The inclusion of support for virtual application patterns on AIX comes with an added benefit. You can also use the base image provided for virtual application deployments with virtual system deployments and customize clones of this image to meet your specific needs. This new AIX image joins the x86 base image included with Workload Deployer V3.0, called the IBM Workload Deployer Image for x86 systems. With the introduction of support for virtual applications on AIX, you gain the new base image, the IBM OS Image for AIX Systems. This opens up an entirely new set of systems for customization and deployment in your private cloud. You can use these images as is, but it is more likely that you will want to customize them for your specific purposes using the Clone and Extend function built into Workload Deployer or the IBM Image Construction and Composition Tool (more about this later).
As you would expect, both the web application and the DBaaS pattern types are updated to support AIX/PowerVM deployments. However, this is only one of several enhancements that have been delivered for these pattern types with IBM Workload Deployer V3.1.
Let's start with the web application pattern type. The Web Application Pattern Type 2.0 (formerly called the WebApp Pattern Type) has been upgraded to leverage the solid foundation of IBM WebSphere Application Server V8 when building middleware configurations for web applications. In one sense, this is hidden from you. In general, you should not really be concerned about the middleware that hosts a virtual application if it meets the specific tenants of the pattern type. However, the current reality is that many users are still moving to this new paradigm and care very much about the middleware engine even if they don't have to manage it. Knowing that you are getting the latest WebSphere Application Server functionality with all of the security, performance, and functional improvements provides a good level of comfort. Of course, if there is still some particular reason you want to ensure your virtual application runs on WebSphere Application Server V7 (perhaps you are dependent upon some deprecated capability or feature) you can continue to utilize the WebApp Pattern Type 1.0 (the new 18.104.22.168 version including the latest fixpack).
There are a number of enhancements to the DBaaS solution as well. The first version of the DBaaS pattern type was delivered with Workload Deployer V3.0 as the DBaaS Pattern Type. In V3.1, it is renamed to the IBM Database Patterns 1.1 and actually includes several elements that represent the expanded configurations it automatically supports: the IBM Transactional Database Pattern and the IBM Data Mart Pattern.
Figure 2. Database patterns
When constructing a database pattern (Figure 2), you now choose a Source to provision the configuration of the instance. You can choose to clone an existing image configuration or use one of two predefined workload standards. When cloning an existing image configuration, you select an existing database image backup as a model for the new database pattern. Metadata from the backup is retrieved and an IBM DB2® restore command is used to set the same configuration for the new database instance. If you prefer to use one of the predefined workload standards as the source, you can choose from two predefined, optimized database configurations. The selected standard will result in a set of scripts run to tune the operating system and instance configuration for the database. The Departmental Transactional standard is optimized for online transaction processing applications, while the Data Mart standard is optimized for data mining purposes, and therefore more suited to reporting applications.
Another new parameter when constructing a database pattern is the Purpose field. The purpose defines the intended use of the database for either production or non-production (development and test). Your selection will optimize license management for deployed instances of this pattern type.
When it comes time to deploy your DBaaS pattern, you can choose to either deploy to a cloud group or an environment profile. The ability to deploy a database pattern to an environment profile is also new in IBM Workload Deployer V3.1.
Finally, management capabilities for database patterns have been enhanced with the ability to configure automated database backups. IBM Workload Deployer makes use of IBM Tivoli Storage Manager to automate backups in V3.1, just as it did for the manual backups in V3.0. Tivoli Storage Manager, therefore, must first be configured before you can create any backups. The backup scheduler will backup the database daily with the seven most recent backups retained.
The IBM Workload Plugin Development Kit was first introduced for IBM Workload Deployer as an independent download shortly after V3.0 was released. However, with the introduction of IBM Workload Deployer V3.1 an updated version of the plugin development kit (22.214.171.124) is now available for direct download from the appliance dashboard (Figure 3).
Figure 3. Downloading the IBM Workload Plugin Development Kit
With the plugin development kit, you create your own custom plugins for use with virtual application patterns and pattern deployments. Plugins, basically, are the fundamental building blocks of virtual applications. At a very high level, think of a plugin as being the functionality necessary to support a component, link, or policy that you use to build a virtual application pattern. IBM Workload Deployer utilizes the functionality provided by the plugin when deploying instances of the specific application type. IBM Workload Deployer also uses the capability provided by the plugin to monitor and manage the virtual application instance. In fact, the operations that you perform on a virtual application instance are exclusively provided by the plugins for that application type.
Figure 4. Virtual application operations provided by plugins
You can create plugins and associate them to predefined pattern types. You can also create entirely new pattern types composed of your custom plugins. A pattern type is a collection of plugins designed for a specific type of workload. For example, the web application pattern type is a collection of plugins used to support web applications. The web application pattern type consists of plugins such as the WebSphere Application Server plugin for WAR or EAR components, and the WebSphere Application Serer database plugin that provides the necessary capabilities to connect a WebSphere Application Server instance with a database component.
The IBM Workload Plugin Development Kit contains the plugin and pattern type build environment, samples, and a tool to create new plugin projects. The build files can be run from the command line or from within Eclipse. The kit also includes a sample user’s guide that explains the concepts quite well and walks through a simple hello example.
Several updates have been made to extend and enhance the capabilities of shared services used with virtual application patterns. The first thing that you might notice is that there are now more types of shared services listed under the Cloud > Shared Services tab on the web user interface (Figure 5).
Figure 5. Shared Services
In addition to the familiar Caching Service and ELB Proxy Service (formerly just Proxy Service), there are now additional entries for an external caching service and an external application monitoring service. These new external services make it possible to leverage existing environments for caching or monitoring that you might already have in your enterprise. For example, you might already have an IBM WebSphere DataPower® XC10 Appliance or collective in your environment that you use for other purposes. With this new feature, you can leverage your existing caching solution instead of launching a dedicated caching service in your private cloud. Simply deploy an instance of the external caching service and point it to your existing XC10 solution. All deployments of virtual application patterns that utilize session caching within that cloud group will then leverage the external caching solution, preserving cloud resources for other purposes, while continuing to provide necessary function for virtual applications to share.
In a similar manner, you can deploy an external application monitoring service within a cloud group that includes a reference to an IBM Tivoli Enterprise Monitoring Server installation at Version 6.2.2 fix pack 5 or later. Once created, the UNIX® or Linux OS monitoring agent and the workload monitoring agent for virtual application workloads are automatically connected to the defined instance of the Tivoli server using the supplied primary and failover Tivoli Enterprise Management server, protocol, and port. This is especially useful if you want to consolidate all of your monitoring to a common console.
Another thing that you will notice is that you can deploy multiple instances of each shared service, one per cloud group. In the previous release of Workload Deployer, each shared service was a singleton with just one deployed instance for the appliance. Virtual applications that required the shared service had to be deployed to the same cloud group as the shared service, which limited your flexibility. In Workload Deployer V3.1 the function is extended to permit the deployment of a shared service instance per cloud group. This is why the instances of shared services are now displayed under Instances > Shared Services, rather than being included with the Cloud > Shared Services definition, as in the previous release. For example, you can choose to deploy either a caching service or external caching service to cloud group A and another caching service or external caching service to cloud group B, each of which will be utilized by virtual application instances within the same cloud group. You can also deploy multiple instances of an external caching service that point to the same physical XC10 appliance or collective to consolidate all your caching needs in the common solution.
The cache service, which leverages the technology of IBM WebSphere eXtreme Scale to store and manage session data as the web application pattern scales, can now also be elastically scaled to increase the number of containers. You simply specify the number of initial containers, the scaling rules, and the maximum number of containers. The cache service will take care of the rest and automatically scale up and down container services as necessary to service your applications.
Figure 6. Configure and deploy a shared service
One other substantial enhancement to the shared caching service is that the caching service has been enhanced with new operations to list, create, and delete various types of object grids. Prior to IBM Workload Deployer V3.1, the shared caching service only provided support to store HTTP sessions in a persistent manner outside of a specific application instance. Now, you can use WebSphere eXtreme Scale ObjectGrid APIs to persist and manage content in the grids within the shared caching service directly from your application code in both virtual application and virtual system instances; you can use the shared caching service to cache data used by your applications in both virtual system and virtual application instances. This saves you the trouble of creating and configuring your own caching tier outside of the IBM Workload Deployer cloud, plus it means you can take advantage of the automatic scale out and in capabilities of the shared caching service.
As you can see, there are many updates to the capabilities associated with virtual application patterns, some of which have direct implications for virtual system patterns. But virtual system patterns have also received a number of improvements in this release.
You might recall that virtual system patterns are sometimes called topology patterns because they are used to define a topology middleware configuration to meet your application requirements. With a virtual system pattern, you define exactly the type of middleware configuration that you need for your application environment, and IBM Workload Deployer provisions exactly that configuration when the pattern is deployed to your private cloud.
To use an automotive analogy, you might compare virtual systems to building your own hot rod from a molded frame, while virtual applications are more like purchasing a complete vehicle from a dealer. When you purchase a vehicle from a dealer you receive a fully functional automobile. Sure, you can choose the color and some options, but you don't necessarily know the details of all of the components that make your vehicle functional. Just add a driver (you) and off you go. This saves you substantial time and money while freeing you from the need to be an automotive engineer. As with the production vehicle, virtual applications are optimized for a specific purpose and are extremely effective when used for that purpose. All you need to do is add your application and its run time requirements (the driver).
Virtual system patterns are like the hot rod approach. You start with a modeled frame of sorts (hypervisor edition images), thereby saving time and effort so you don't have a start from scratch. However, you still have the responsibility and flexibility to create a very unique custom vehicle. Doing so requires more expertise and greater time investment when compared to a production vehicle (virtual application), but you get to decide all of the details. With virtual systems, you specify the exact vehicle you need for your application. This provides substantial flexibility but requires a deep knowledge of the middleware and an investment of time building necessary scripts and other elements to support your application environment.
Now, let's move on to improvements in IBM Workload Deployer V3.1 for virtual system deployments.
With the introduction of IBM Workload Deployer V3.1, updated Hypervisor Edition images are delivered for many of the building blocks that you use to create your virtual system patterns.
The foundation of many of these middleware application environments is WebSphere Application Server. This release includes two new sets of WebSphere Application Server images; an updated V126.96.36.199 image and a new V188.8.131.52 image.
- WebSphere Application Server V184.108.40.206 is the latest fixpack and, as you would expect, it includes all of the latest fixes, enabling you to easily upgrade your existing WebSphere Application Server V7.x pattern deployments to this level of maintenance.
- The WebSphere Application Server V220.127.116.11 image gives you the tools to build patterns with the integrated features and programming models supported of this feature rich release. You can now build virtual system patterns based upon the full capabilities included in WebSphere Application Server V8 such as Java™ EE 6, OSGi, JPA, and many other programming models that are integrated directly into the WebSphere Application Server base image.
Both of the WebSphere Application Server Hypervisor Edition versions provide a number of combinations of operating system, hypervisor infrastructure, and bit architecture (32 or 64 bit) support, so check the product offerings for details on those that are available. Also included are images with the Intelligent Management Pack that deliver the full capabilities of IBM WebSphere Virtual Enterprise and autonomic elasticity.
There are also new Hypervisor Edition images for other products, such as the latest levels of:
- IBM DB2 Enterprise and Express
- IBM WebSphere Portal
- IBM WebSphere MQ
- IBM WebSphere Message Broker
All of these images provide a great foundation upon which you can build your specific middleware configurations.
As you can see, quite a few Hypervisor Edition images are ready "out of the box" for various IBM products with different combinations of operating systems, bit architectures, and supported hypervisor infrastructures. However, what if these images don't exactly match your system requirements? What if you require specific agents to be included, specific maintenance levels, or if your application requires some non-IBM product to be fully functional? The answer, described in the next section, offers you more flexibility to customize the provided images or to create entirely new images for your specific needs.
The IBM Image Construction and Composition Tool (ICCT) was first made available as an IBM alphaWorks project in mid-2011. With IBM Workload Deployer V3.1, this tool is generally available, fully supported, and can be downloaded directly from the IBM Workload Deployer dashboard (Figure 7).
Figure 7. Download Image Construction and Composition Tool
The ICCT is an image creation and editing utility that enables you to enhance an existing image or build a completely new image to meet the needs of your particular environment. It basically lets you build something very similar to the hypervisor edition images that are delivered with IBM Workload Deployer. Furthermore, you can create images with any software to which you have entitlements, not just IBM software.
The approach greatly simplifies the process of building custom images and also facilitates efficient reuse and management of virtual images and the software packages included in those images. It provides the capability to build and collaborate on shared virtual images that are self-descriptive, customizable, and easily managed. You can then deploy these images to several cloud providers, one of which is IBM Workload Deployer. With IBM Workload Deployer you can deploy both VMWare ESX and PowerVM images generated from the ICCT. The tool also makes it easy to make subsequent enhancements, simplifying what was typically a long and error prone process by introducing structure and consistency. You can then import your custom images into IBM Workload Deployer for use in virtual system patterns.
Figure 8. Image Construction and Composition Tool
Figure 8 shows the basic flow when working with a custom virtual image and the interaction with IBM Workload Deployer. You begin by connecting to a cloud provider to assist with building your custom image. Next, you import the metadata for images that you want to customize or extend into the ICCT; only the metadata is actually copied, not the entire image content. Imported images can be one of the base OS images mentioned earlier, IBM Hypervisor Edition images, or a custom image that you may have acquired, built, and imported into Workload Deployer. With the image in the ICCT, you can then create and add bundles representing the individual software bundles that you want to include. Bundles include scripts and binaries necessary to install and manage the software at various stages of the lifecycle from installation to pattern deployment.
After you have defined the image content, the next step is to synchronize it. In this step, Workload Deployer uses its clone and capture mechanism to deploy an instance of the base image you defined in the ICCT. When the virtual machine image is ready, the process of installing the software bundles that you defined begins. The ICCT copies all of the configuration scripts to the virtual machine and utilizes an activation engine included in the image to drive them. At this point, you can validate the system and, when satisfied, initiate a capture. IBM Workload Deployer captures your new custom image, storing it directly in its catalog.
The image is now ready to use in the construction of completely custom virtual system patterns.
In addition to updates for both virtual system and virtual application patterns, IBM Workload Deployer V3.1 also includes enhancements to the appliance’s management and administrative capabilities.
With the introduction of virtual applications in Workload Deployer and additional features for virtual systems, such as autonomic elasticity, the role of the Workload Deployer appliance itself is now even more important in the run time management of certain workloads. It is important, therefore, to consider high availability of the appliance itself to ensure uninterrupted capabilities for the workloads that it deploys.
It was already possible in the prior versions to create backups and leverage those backups by a secondary appliance in the event of a failure on the primary appliance. However, that approach requires manual intervention, careful backup planning, and does not fully account for the more dynamic nature of virtual applications. An improved solution has been provided in V3.1 with the introduction of a new high availability feature for the appliance: You can now leverage two appliances and configure them for automatic failover in the event that one of the appliances becomes unavailable.
You begin by installing and configuring each appliance as a standalone
appliance. You then configure each appliance for its role, either primary
or secondary, using the
startHA command. The solution makes use of a floating IP address that is always associated with the primary appliance. In the event of a failure of the primary appliance, the secondary appliance will become the new primary and continue in a standalone mode until the original primary appliance can be restored to function as the new secondary.
Figure 9. High availability using primary and secondary appliances
Monitoring the primary appliance for failures is the responsibility of the secondary appliance using a special communication channel. As part of the configuration, you set a ping interval to validate the health of the primary appliance. A second communication channel utilizes a dedicated crossover Ethernet channel between the two appliances to synchronize all data from the primary to the secondary appliance. When the secondary appliance is first connected to the primary, all disk partitions are synchronized. Any subsequent changes in the primary appliance disk partitions are written to the secondary appliance disk partitions using this same channel.
In the event of a problem with the primary appliance, the secondary appliance detects the problem when it notices a missing response to a ping, based upon the specified interval. The secondary appliance will then assume the role of primary and begin servicing new requests using the floating IP address but in a standalone mode. After the issue with the former primary appliance is resolved, it can be reconfigured as the new secondary appliance, once more restoring a highly available environment. You can also manually cause a primary appliance to failover to the secondary appliance using the failover command. This is helpful when you want to apply service to upgrade your primary and secondary appliances. Both the primary and secondary appliances must be co-located.
Prior to version 3.1, the default cbadmin role in Workload Deployer has been an all-powerful administrator. As such, it can take any action in the system. The introduction of a new audit role in V3.1 provides a separation of duties. Audit capabilities can monitor and ensure the appropriate use of system resources. Once the audit role has been assigned to a user other than cbadmin, you can remove this role from the cbadmin user to prevent any potential abuse of power.
Figure 10. Assigning audit role
Auditing provides the capability to retrieve and process audit logs. Audit records are created to track many events in the private cloud environment as managed by IBM Workload Deployer. Audit records are created for successful or failed attempts to login, actions by privileged users (such as creating or modifying user accounts and groups), setting permissions, changing configuration, successful or failed attempts to access protected resources, and other such events. Only the user with the audit role can retrieve and eventually clear audit records.
This article provided a brief overview of the various new functions and features available with IBM Workload Deployer V3.1 and their value. New features related to shared services, customization using the plugin development kit, additional functionality in the web application and database pattern, and many other smaller features not mentioned here all contribute to make virtual applications an even more compelling solution. For those who need more control over the configuration and integration of the middleware stack, IBM Workload Deployer V3.1 delivers new IBM Hypervisor Edition images, as well as the Image Construction and Composition Tool for building your own completely custom images. IBM Workload Deployer continues to be the best solution for deploying middleware application environments to the cloud.
Easy virtual app automation using Workload Deployer
Deployer product information
Cloud computing with a pattern-based approach
Redbook: IBM Workload Deployer: Pattern based application and middleware deployments in a private cloud
WebSphere Application Server Provisioning with IBM Workload Deployer and WebSphere Application Server Hypervisor Edition
IBM developerWorks WebSphere
Get products and technologies
Joseph Bohn is a senior software architect at IBM. He is currently serving as a technical evangelist. Before becoming a technical evangelist, he represented IBM on OSGi Alliance specifications and open source projects including Apache Aries and Apache Geronimo. Prior to these activities he worked in several product areas within IBM as architect, designer, team lead, and developer on a variety of IBM products including the Integrated Solutions Console, Tivoli Presentation Services, and multiple Tivoli solutions.
Dustin Amrhein joined IBM as a member of the development team for the WebSphere Application Server. While in that position, Dustin worked primarily on web services infrastructure and web services programming models. In addition, Dustin worked on the development of a RESTful services framework for Java runtimes. In his current role Dustin is a WebSphere Client Technical Professional.