A virtual application is a customer designed entity that contains industry standard artifacts (that can be deployed on enterprise middleware components) and a set of policies that govern runtime behavior of the application once it is deployed.
A major feature of IBM® Workload Deployer 3.0 (a rebranding of WebSphere® CloudBurst) is the ability for a customer to focus on a logical view of the enterprise application and let the appliance figure out which middleware components to deploy and how to configure them.
This article demonstrates how to perform a virtual application pattern build out; in other words, how to assess your enterprise application's requirements and define those requirements so you can use the Virtual Application Builder feature in Workload Deployer.
The task scenario: Virtual application pattern build out
Let's say that your organization has quite a few applications in production and more coming down the pipeline. The typical process for the IT folks is to figure out the hardware and software requirements for each application, file requisitions for the same, followed by the tedious process of setting up, installing, configuring the hardware and software. Then comes the phase when you try to set up monitoring and failover as well as a way to collect and monitor logs. You may end up writing custom scripts for each application so that things are easier the next time around and end up building a huge disparate collection of hardware/software/applications and scripts etc.
Suppose you can standardize the needs of the applications and have enough head room to quickly grow the number of applications not just in production but as well as in development and testing, would you take it? This is exactly where Workload Deployer comes into picture. Say a typical application has some code deployed in a J2EE application server with some data in a relational database and there's a quick and easy way to set up logging, monitoring, failover etc. Wouldn't that be real handy? Yes, that's exactly what Workload Deployer offers in the WebApp pattern. Once you deploy Workload Deployer in your data center, you can quickly deploy applications, setup monitoring, scaling, and logging in a standardized fashion.
The typical artifacts for a WebApp pattern based virtual application includes:
- J2EE Enterprise Archive (EAR) or J2EE Web Application Archive (WAR) for deploying in an application server.
- Script for creating database schema/table/rows for initializing a database.
- List of users and groups as an LDIF file (LDAP Data Interchange Format).
Workload Deployer allows you to quickly design a virtual application, upload these artifacts, specify policies with respect to logging, monitoring, scaling... and deploy the virtual application in your private cloud.
The fast way to create a virtual application
Or you can use the Virtual Application Builder in the IBM Workload Deployer 3.0 to create a virtual application.
For example, you create a new virtual application, drag and drop the Enterprise Application component and a Database component and link them together. You upload a JEE-based Enterprise Archive (EAR) or Web Archive (WAR) that contains your code artifacts and a database schema that describes the table structure expected by the code. IBM Workload Deployer recognizes this application as something it can deploy using the WebApp pattern in an optimized fashion, hence the term "virtual application".
One of the main distinctions between the existing virtual system concept from legacy WebSphere Cloudburst is that you do not decide or need to know exactly how many virtual machines would end up getting started on the hypervisors to construct the running system. Delegate this responsibility to Workload Deployer which looks at the components, the links between them, and the associated policies to figure out the best fit in terms of number of virtual machines and what exactly runs on which virtual machine.
With a virtual system, pick the middleware component that is needed and how many of each. With virtual applications, you don't need to worry about that; you simply specify policies to govern say the scalability aspect of your application when they design the application.
Virtual application pattern build out with IWD
What does it mean to build a virtual application pattern? Quite simply, it means take an assessment of your enterprise application's requirements and define those requirements in IBM Workload Deployer. The hard part in the process is understanding your enterprise application's requirements, but once you understand, defining those requirements in Workload Deployer is as simple as a few drag-and-drop operations using the Virtual Application Builder tool.
In this section, we'll explore the Virtual Application Builder tool and look at:
- Building a virtual application pattern.
- Configuring components.
- Configuring links between components.
Background on the Virtual Application Builder tool
The Virtual Application Builder tool is an integrated graphical tool that allows you to build your virtual application graphically. The tool consists of three primary sections that work together as a cohesive whole to graphically build out your virtual application:
- Assets (or palette): Contains all available components that can be used to build your virtual application. The components are logically grouped (for example, the Database Components group contains all of the database components).
- Canvas: This is where you will graphically build your virtual application.
- Properties sheet: Each component has a properties sheet; the properties sheet contains the properties for a particular component, link, or policy that are configurable by you.
Figure 1 shows the Virtual Application Builder tool's user interface.
Figure 1. Virtual Application Builder tool interface
Now let's look at how to build a virtual app pattern.
Building a virtual application pattern
Now that you have a basic understanding of the Virtual Application Builder tool it's time to start building a virtual application pattern. But first, understand that a virtual application is a generic framework that allows you to build different types of workload patterns. The virtual application pattern example in this article has the following requirements:
- 1 dependency on an application server to host the enterprise application.
- 1 dependency on a database to persist data.
- 1 dependency on a user registry for authentication.
The first step in the process is to navigate to the Virtual Application Pattern panel located under Pattern > Virtual Applications. This view lists all virtual application patterns that you are authorized to view. Click the green plus icon to bring up the virtual application creation panel. This panel allows you to create a virtual application from scratch or start from an existing template. Select Blank application and click Start Building which brings you to the Virtual Application Builder tool, shown in Figure 2.
Figure 2. Virtual application creation panel
The sample enterprise application has three middleware requirements: application server, database, and user registry. To satisfy these requirements you need to drag the components from the palette and drop them onto the canvas as shown in Figure 3:
Figure 3. Building by drag and drop
- The application server requirement will be satisfied by the Enterprise Application (WebSphere Application Server) component located under the Application Components subsection.
- The Database requirement will be satisfied by the Database (DB2®>) component located under the Database components subsection.
- The user registry requirement will be satisfied by the User Registry (Tivoli Directory Server) component located under the User Registry Components subsection.
Once all the dependent components have been placed on the canvas you are ready for the next step which is to establish links between the components. Links do many things, most important of which are:
- Open ports in the virtual machine to allow traffic to flow in and out of the VM. All ports are locked down unless specifically opened using a link.
- Define additional properties.
In this case, the application has a requirement to communicate with the database and the user registry, but the user registry does not have requirement to communicate with the database and vice versa. To establish a link, click the blue ball on the edge of the source component, hold down the mouse and drag the link to the target component. Figure 4 shows the two links defined for this scenario.
Figure 4. Establish links between components
At this point you have established the structure of the virtual application. The next step, prior to deployment, is to configure the properties of each component and link. Each component and link has a unique set of properties (both optional and required) that are configurable by you.
There is no hard, set rule as to what you configure first and last, but it is highly recommended that you configure your Enterprise Application component first. The reason for this will become apparent when you configure the link properties.
- Configure the Enterprise Application component by uploading your enterprise application (Figure 5).
Figure 5. Configure Enterprise Application component properties
- Configure the Database component by specifying a name and size of the database. If your application is expecting the database to be pre-populated, also upload a schema file. An important piece of information worth pointing out is that this database's life cycle follows the same life cycle as the virtual application it belongs to: If the virtual application is terminated then your database and all of its state information is terminated.
- Configure the User Registry component by uploading a LDIF file and specifying the user and group filters.
Each link represents a communication path or an association between components. Just as with components, the properties of each link are unique.
- Configure the database link between the Enterprise Application and Database components. Click the link to bring up its properties. Besides opening a communication channel, this link allows you to map your enterprise application's datasource JNDI names. An example of this is shown in Figure 6.
Figure 6. Configure Enterprise Application to Database link
At deployment time the JNDI name you specified will be linked to the one WebSphere Application Server creates to support the Database component.
- Configure a link between the Enterprise Application and User Registry components. This link allows you to map roles defined in your enterprise application to concrete users and groups defined in your User Registry component. Figure 7 shows this mapping.
Figure 7. Configure Enterprise Application to User Registry link
If you haven't noticed, note that the Database component property Resource reference of Data Source and the User Registry component property Role Name have preconfigured options derived from your enterprise application. When you add a link to your virtual application, Workload Deployer inspects your enterprise application's deployment descriptors for the relevant information. In the case of JNDI references, it inspects the web.xml; for security roles, it inspects the application.xml. An example of this can be seen in Figure 8.
Figure 8. application.xml and web.xml inspection points
- Save your virtual application (Figure 9):
Figure 9. Save your virtual application
And that's all there is to it! Next up, deploying and monitoring your virtual application.
Deploying your application
This is where the fun begins! Once the application is modeled in the Virtual Application Builder, you are ready to deploy the application vAppArticle and it's very easy! To deploy your virtual application:
Click Patterns > Virtual Application and click vAppArticle. An example of this is shown in Figure 10.
Figure 10. Locating the virtual application
On the right side of the panel click Deploy the virtual application into the cloud to initiate the deployment as shown in Figure 11.
Figure 11. Virtual application deploymentClick to see larger image.
After you click Deploy the virtual application into the cloud, you have an option to select the cloud group as shown in Figure 12.
Figure 12. Virtual application deployment target
In Workload Deployer, virtual applications only support cloud groups as the deployment target. They do not support environment profiles as a deployment target.
The dialog box in Figure 12 also provides an Advanced option to configure secure SSH access to the deployed VMs. You can upload your own public key or have Workload Deployer generate a public/private key for you. The deployed VMs do not allow user/password access; instead, it requires user/private key access. If you do not configure secure SSH access you will be unable to directly access the VMs. You do have an option to add and change this key from the virtual application console after the application is deployed. Click OK.
- Workload Deployer initiates a virtual application deployment. A short time later, depending on your network configuration, the virtual application is deployed and ready to be used.
Workload Deployer translates the application deployment into infrastructure specific actions. It initiates the necessary VM deployments and configures the middleware and application.
To check your deployment status, click Instances > Virtual Application and then click your application vAppArticle as shown in Figure 13.
Figure 13. Virtual application instance
Virtual application deployment hides the infrastructure- and middleware-specific details. For example, it does not require you to specify the number of VMs or specify the version of WebSphere Application Server. This helps the application developer to focus on developing the application and leave the infrastructure and middleware details to the IBM Workload Deployer.
Figure 14 shows the status of the virtual application deployment.
Figure 14. Virtual application deployment statusClick to see larger image.
As the virtual application is getting deployed, the VM Status changes from Launching state to Running state. Once the VM is fully instantiated, the Workload Deployer-specific agent residing inside the VM initiates the action to configure the VM for the role it will play in this application deployment.
A role for a VM indicates the nature of middleware that a specific VM will have. For example, a role for a VM can be WebSphere Application Server, DB2, or a TDS. As the IBM Workload Deployer agent configures the VM for a specific role, the Role Status for that specific VM changes and eventually turns green when the role is fully configured. When all the roles are successfully configured and at green status, the virtual application is ready to be accessed.
Once the virtual application is deployed, it can be accessed directly by clicking the ENDPOINT hyperlink for the WAS VM as shown in Figure 15.
Figure 15. Access your enterprise applicationClick to see larger image.
The endpoint URL for database and user registry VMs indicates specific information to access that middleware. For example, the endpoint URL for database provides connection information to access the database using a DB2 client.
Monitoring your application
Once the virtual application is deployed, IBM Workload Deployer allows you to monitor and manage the virtual application deployment from the Virtual Application Console. It also provides capabilities to perform specific operations on the deployed virtual machines and view OS-specific, middleware-specific, and Workload Deployer agent-specific logs from this single centralized dashboard.
To access the Virtual Application Console click Instances > Virtual Applications and click vAppArticle. On the right panel, click More details and advanced options as shown in Figure 16. The Virtual Application Console opens in a new browser window.
Figure 16. Accessing the Virtual Application Console
The Virtual Application Console has four tabs:
- Virtual Machine Monitoring: This view displays the real-time virtual machine statistics in a graphical format. For example, if the deployed application is consuming a lot of CPU cycles, this view will show a high CPU usage for the specific VM.
- Middleware Monitoring: This view displays the real-time middleware-specific monitoring statistics in a graphical format. For example, during peak hours of your application usage you can track the request count for your application.
- Operation: This view provides the ability to perform middleware-specific operations on the target VMs. For example, you may want to update your installed application with a new version but you do not want to terminate the entire deployment. The Operation tab allows a user to update the application and perform other necessary operations.
- Logging: This view provides a centralized user interface with a collection of OS-specific, middleware-specific, and Workload Deployer agent-specific logs for each VM. Having all the logs at your finger tips is really useful to debug failures simultaneously across different subsystems on different VMs.
Example screen captures of the Operation and Logging tabs are shown in Figures 17-18.
Figure 17. Operation tab on Virtual Application Dashboard
Figure 18. Logging tab on Virtual Application Dashboard
Bonus: Configure your own database pattern
While not true for every configuration, it is often the case that the database is a separate entity from your application, following its own life cycle and managed by a completely different team with a unique set of skills. Workload Deployer recognizes this requirement and allows the database to be created and managed as a separate entity. Your virtual application can then connect to this existing database as opposed to creating its own.
In this section you are going to configure Workload Deployer's database pattern (called vAppDB) and augment the virtual application to use the Existing Database component to make use of the database we created. The focus of this article is to examine web application patterns, not database patterns, but it is an important supporting feature of Workload Deployer; in essence, this article demonstrates how to enable a Database as a Service model.
Configure and deploy vAppDB database pattern
- Navigate to Patterns > Database Patterns and click the green plus
icon. The Database Pattern panel is displayed. In this panel you can define the
database name, size of the database and upload any supporting scheme file, as shown in Figure 19.
Figure 19. Database Pattern creation panel
- Once you have defined all of your database properties, click Save and then deploy the database by highlighting it and clicking the Deploy icon. This process can take some time depending on your network. To monitor the status of your database deployment, navigate to Instances > Databases and highlight your database to bring up its information. After the deployment completes, note the Host, Port, User, and Password information as shown in Figure 20.
Figure 20. Database instance information (Host and Port)
This information is used when you augment the virtual application with the Existing Database component.
Augment with Existing Database component
Often there is a necessity to connect to existing middleware or legacy enterprise system within an organization or outside. Workload Deployer has an answer for this as well. It gives you the flexibility to access and continue to exploit systems outside your private cloud. Workload Deployer has components that allow you to connect into existing databases, user registries, CICS, IMS, etc.
This scenario highlights this ability by augmenting the virtual application with the Existing Database component. The only reason this component was chosen over, say, the Existing User Registry component is that it showcases the database pattern feature. Again, it is worth reiterating, there is much more to the database pattern feature than highlighted, but at least now you know it exists and can investigate further if this particular feature is of interest to you.
- Open up your virtual application in the Virtual Application Builder tool. Delete the Database component (this action will also remove the associated link), add the Existing Database (DB2) component and re-establish the link as shown in Figure 21.
Figure 21. Database component removed and restored
- Configure your Existing Database component. Use the host, port, username, and password information that you wrote down during the vAppDB creation and deployment steps to configure this component.
- Reconfigure the link's property sheet since this information does not exist for the newly created link. An example of this is shown in Figure 22.
Figure 22. Existing Database properties sheet
Other than saving your updates, your have finished setting up a database to be managed as a separate entity. You've augmented your virtual application to use an Existing Database component over a Database component.
Shared services (cache and proxy)
Shared services are services that are shared by one or more virtual application instances. Currently, there are two shared services:
- Caching as a Service.
- Proxy as a Service.
Configuring and starting the shared services is an administrative-level activity. This is done once and then can be used by all virtual application instances. You as the user never have to worry about starting a caching and proxy service and managing it for your specific deployment.
Two key benefits of sharing these services:
- Resources are better utilized; there is no need to have separate proxy and caching for each virtual application deployment.
- Failover support: Shared services are deployed with multiple VMs so if one VM goes down, the others pick up the workload while the failed VM is either recreated or restarted.
Enabling shared services (administrator)
- To start the shared services, login as an administrative level user.
Click Cloud > Shared Services as shown in Figure 23.
Figure 23. Shared services enablementClick to see larger image.
- You see 2 shared services: CachingService and PROXY. The services are pre-configured. Click the deployment icon for each service.
- Two pieces of information are required for deployment of each service: number of VMs
and target cloud group. That's it.
Click Deploy and a short time later your shared services are ready to be used. Figure 24 shows an example of what the running caching service looks like.
Figure 24. Shared Cache Service deploymentClick to see larger image.
Enabling web application pattern shared services (user)
The caching and proxy shared services were designed to be used by virtual applications in general. What is demonstrated here is one usage of shared services by way of the Web Application pattern.
The Web Application pattern uses the caching service to store HTTP session information. It uses in-memory persistence and is not database persisted, but this should not be an issue given the failover support provided by the caching service. Enable your Web Application pattern to use the cache service by first adding the Scaling policy and then checking the Enable session caching checkbox.
The Web Application pattern uses the proxy service to route requests to your virtual application. Enable your Web Application pattern to use the proxy service by adding the Scaling and Routing policies to the Enterprise Application component.
That's all there is to it for the basic functionality. Figure 25 shows an example of these services as enabled.
Figure 25. Web Application pattern shared services enablement
The next and final step is to deploy your virtual application with these new settings. The only real difference that you will notice is that you now access your application using the virtualhost name. Behind the scenes there is quite a bit more going on: Access to your application via the virtual hostname is first routed through the proxy service. In addition, your HTTP session information is persisted in the cache service and not locally on your VM.
One last point worth mentioning that completes this scenario, but that is outside the scope of this article is: You must configure your IP load balancers to route incoming requests for your virtualhost to the proxy service VM IP addresses.
Creating, deploying, and managing virtual applications and databases is an essential task in cloud computing and Workload Deployer is a turnkey solution that lets you do this quite easily.
- In Harness the power of the cloud with IBM Workload Deployer V3, learn about the application-centric improvements to IBM Workload Deployer over its predecessor, WebSphere CloudBurst.
- WebSphere evangelist Dustin Amrhein often discusses IBM Workload Deployer in his blog A view from the clouds: Cloud computing for the WebSphere developer.
- The three-part blog article, IBM Workload Deployer: Application-centric cloud platform, provides a lot of information on IWD.
- Visit the IBM Workload Deployer site. The document library contains webcasts and Redbooks and whitepapers on Workload Deployer.
- 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 resources, discover and share knowledge and experience of IBM Workload Deployer.
- The next steps: Find out how to access IBM SmartCloud Enterprise.
- For technical developer content and resources for cloud computing, see Cloud computing: Fundamentals.
- Follow developerWorks on Twitter.
Get products and technologies
- See the product images available for IBM SmartCloud Enterprise.
- Join a cloud computing group on developerWorks.
- Read all the great cloud blogs on developerWorks.
- Join the developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.