I think my fellow technologists know the feeling well. It's that feeling you get when emails, meetings, conference calls, and everything else that makes up the corporate world has completely worn you down. I hope that it is not something you deal with often, but if you are like me, there is only one remedy.
You have to get your geek on!
That's right. It's time to hang up the phone, close the browser on the web meeting, and use the delete button on your email inbox with extreme prejudice! It's time to do some coding, scripting, configuration, and integration! In other words, it's time to take the gloves off and get your hands dirty.
Here's a problem to solve
Not long ago, I was in need of just such a respite from the mundane and luckily, I got the chance to do a cool project with the WebSphere CloudBurst Appliance.
In support of some upcoming work with various clients, a group within IBM came to our team to ask assistance. They needed help in constructing a showcase enterprise application environment that they could use to host various client sessions. In addition to the initial construction of said environment, they also needed to be able to reconstruct the environment on demand to support many different instances of these client sessions.
Our team, eager to assist, immediately asked the obvious: What do you want in your enterprise application environment? Of course, the answer started with an application, specifically a Java™ web services application.
As they described the kind of application they wanted and the kind of user experience they wanted to provide, various needs became clear, including the following:
- The application needed the ability to read and write data from a back-end database.
- The application had a strong dependence on the use of HTTP sessions. As such, we needed to ensure these sessions were highly available.
- We needed to expose both SOAP and JSON interfaces for the application.
- Demand for the application would be inconsistent and experience peaks and valleys.
Defining the infrastructure
Our team then did two things. We set about developing the application and then deciding on the infrastructure that we would need to support the application. While the development of the application itself is interesting, touching on topics like JPA, JSON, jQuery, and of course, web services, I want to focus instead on the supporting infrastructure for the application.
It soon became clear to us that in order to support the application needs touched on by the clients, we would require several different application infrastructure components. After a couple of "hash out" meetings, we decided that we would use the following infrastructure to support the application:
- WebSphere Application Server: The WebSphere Application Server provided the runtime container for hosting our JEE web service and other related application components (like HTML files).
- DB2 Enterprise Edition: We used DB2 as the back-end data store for our web service application.
- WebSphere Virtual Enterprise: While there are quite a few different features one can exploit in WebSphere Virtual Enterprise, we leveraged dynamic clusters and application service level policies. We deployed our web services application in a dynamic cluster and that, in conjunction with service level policies, provided us the ability to accommodate the variable workload for our application.
- WebSphere DataPower XC10: We used the WebSphere DataPower XC10 appliance as a store for HTTP sessions. By utilizing a collective of just such appliances, we could assure the availability of HTTP sessions. In addition, since we stored the HTTP sessions on the appliance, we freed up the memory they would have otherwise occupied within the application's JVM.
- WebSphere DataPower XI50: Like all of the other components mentioned here, the WebSphere DataPower XI50 appliance provides a whole host of capabilities. For our case, we utilized the web service proxy and transformation capabilities of the appliance to enable a JSON interface to our web service application.
If you are familiar with enterprise middleware environments, you understand that simply deploying each of these components is a non-trivial task; however, in addition to simply installing each piece of the infrastructure, we needed to integrate them in order to achieve the outlined goals for the application. Further, we had to establish a means for others to harvest the work we produced so that they could consistently provision the environment in a timely manner and with a high degree of confidence that the configuration of the resulting environment was accurate.
Choosing the tool and the approach
Taking all of this into account, we arrived at a solution that met all of our needs: WebSphere CloudBurst.
More to the point, we decided to build a WebSphere CloudBurst pattern that allowed users to deploy the target application environment to a private cloud.
Specifically, we built the pattern to encapsulate the configuration of both the application and the application infrastructure we outlined earlier. Anyone that needed to set up this application environment could simply login to a WebSphere CloudBurst Appliance, deploy the pattern, and have an up and running environment in a matter of minutes.
The deployers did not need to know how to install, configure, and integrate the application and associated infrastructure since the pattern encapsulated these activities. In addition, the pattern ensured the correct configuration of the environment each time a user deployed it.
And here's the result
So then, what does this pattern look like? As shown in Figure 1, it consists of parts from the WebSphere Application Server, WebSphere Virtual Enterprise, and DB2 Enterprise Edition.
Figure 1. The WebSphere CloudBurst pattern
What does each component provide:
- WebSphere Application Server: The pattern includes a deployment manager and two custom nodes. The custom nodes host WebSphere Application Server instances and during deployment, WebSphere CloudBurst automatically federates them into the cell managed by the deployment manager node.
- WebSphere Virtual Enterprise: The pattern includes an On-Demand Router (ODR) instance. The ODR enables priority-based workflow management that enables the enforcement of service level policies for applications.
- DB2 Enterprise Edition: The pattern includes a single DB2 Enterprise Edition part that represents an instance of a database server.
It is important to note that we created a custom image using the WebSphere CloudBurst extend-and-capture mechanism. This custom image contains all of the bits present in the WebSphere Application Server Hypervisor Edition (with the Intelligent Management Pack option) shipped on the appliance and in addition, we installed WebSphere eXtreme Scale client binaries. We use these binaries during the configuration of the deployed environment.
Speaking of configuration, we provided all the necessary deploy-time configuration actions in our patterns via script packages included in our pattern. As you can see in Figure 1, the pattern contains many different script packages:
- Add IBM HTTP Server node: This script package creates an instance of an IBM HTTP Server running within the same virtual machine as the deployment manager node. WebSphere CloudBurst provides this script package for our use.
- Profile augmentation-WXS: This script package uses the WebSphere eXtreme Scale binaries present in the WebSphere Application Server virtual machines (via our custom image) to augment the profiles to be WebSphere eXtreme Scale profiles. The profiles must be WebSphere eXtreme Scale profiles in order to configure our application to use WebSphere DataPower XC10 as the HTTP session store.
- Create DB2 data source: This script package configures a WebSphere Application Server data source. The web service application uses this data source to read and write data to the DB2 database server instance.
- Create proxy: This script package creates a reverse HTTP proxy from our IBM HTTP Server instance to a WebSphere DataPower XI50 appliance. This enables us to overcome cross-domain scripting restrictions and send AJAX requests from our application running within the WebSphere Application Server domain to a WebSphere DataPower XI50 appliance in a different domain.
- Configure DataPower rewrite policy: This script package updates a defined WebSphere DataPower XI50 web service proxy to point to the location of our newly deployed web service application.
- Install DB2 client JARs: This script package installs the DB2 client JARs on the necessary WebSphere Application Server nodes.
- Dynamic cluster configuration: This script package creates the WebSphere Virtual Enterprise dynamic cluster during deployment. WebSphere CloudBurst provides this script package when we select the Define dynamic clusters option in the Advanced options for the pattern.
- XC10 configuration: This script package configures our web service application to use WebSphere DataPower XC10 as an HTTP session store.
- Install application: This script package installs our web services application to the WebSphere Virtual Enterprise dynamic cluster.
- Create DB2 database: This script package creates the necessary database and table for our application on the DB2 database server instance.
Taken as a whole, these script packages and parts add up to define a pattern that, when deployed, provides everything we need. We expose this pattern to multiple different users, they can deploy it when necessary, and the result of the deployment is a virtual system containing their configured, customized application environment, running in an on-premise cloud. Figure 2 shows the virtual system and its integration points created by deploying the pattern shown in Figure 1.
Figure 2. The deployed virtual system
Did it work?
In short, the pattern helped my team to accomplish each one of our goals and the goals of the users with which we were working. We were able to provide a directly deployable unit (pattern) that allowed various different users, with different levels of middleware skill, to provision a running, meaningful application environment.
Further, the clients could provision this environment in a matter of minutes (a little less than 60 on average) and they could faithfully recreate the environment whenever necessary. The fact that they were running this environment in a cloud was just icing on the cake!
To me, this proves two important things.
- First, a patterns-based approach to configuring and deploying applications and application infrastructure to a cloud holds real value and promise for both the administrators and users of such environments.
- Second, and more specifically to WebSphere CloudBurst, it definitively proves that you can use the appliance to construct any kind of cloud-based environment you need, from the very simple to the more complex.
If you routinely construct and deploy middleware application environments, I hope you seriously consider WebSphere CloudBurst and the value that its patterns-based approach to these environments can bring to you and your organization.
- Learn more about the WebSphere CloudBurst Appliance.
- In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
- In the developerWorks WebSphere developer resources, you'll find many technical resources for the WebSphere platform including quite a few discussing WebSphere in the cloud.
- Join a cloud computing group on My developerWorks.
- Read all the great cloud blogs on My developerWorks.
- Join the My developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.
Dig deeper into Cloud computing on developerWorks
Exclusive tools to build your next great app. Learn more.
Crazy about Cloud? Sign up for our monthly newsletter and the latest cloud news.
Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.