Application pattern models
This chapter introduces the concept of virtual application patterns (VAPs), and provides guidance on VAP model design. This chapter includes the following main topics:
3.1 Virtual application pattern terminology
There are a lot of terms in IBM PureApplication System regarding VAPs. Some of these terms are similar, and can cause confusion. This section provides a clear definition and explanation of the terminology.
3.1.1 Virtual application
A virtual application is an application that runs on virtual infrastructure. The application software with Just Enough Operating System (JeOS) is combined inside a virtual machine (VM) container to maximize the application performance. Virtual applications focus the user on the application requirements versus the virtual images and topology.
3.1.2 Virtual application pattern
IBM PureApplication System provides a generic framework for designing, deploying, and managing virtual applications. A build modeled for a specific virtual application, with all of the application artifacts and quality of service levels, is called a virtual application pattern.
This kind of pattern is more application-centric, and usually describes all of the application artifacts and their relationships without showing any underlying middleware details. Users create this kind of pattern to focus more on their application. The framework describes the suitable infrastructure to host the application during deployment.
To see VAP details, follow these steps:
1. In the Workload console of PureApplication System, go to Pattern → Virtual Applications. All of the VAPs with a certain pattern type are listed in the left pane.
2. Select one pattern, and the generic pattern information, such as description, author, users, and a preview, displays in the pattern overview pane on the right.
3.1.3 Virtual application instance
A deployed virtual application is called a virtual application instance. Each virtual application instance is linked to a VAP. One VAP can have multiple instances when it is deployed multiple times.
To see virtual application instance details, follow these steps:
1. In the Workload console of PureApplication System, go to Instances → Virtual Applications. All of the virtual application instances display in the left pane.
2. Select one instance, and the linked VAP displays in the From Pattern Attribute pane on the right.
3.1.4 Virtual Application Builder
PureApplication System provides a web-based console, called Virtual Application Builder (VAB), for editing VAPs. In the VAB, you can connect pattern components and apply polices.
To edit a virtual application, follow these steps:
1. In the Workload console of PureApplication System, go to Pattern → Virtual Applications.
2. Select one pattern on the left pane, click Open in the toolbar, and the virtual application builder opens. You can also click New to create a new VAP to open the VAB.
3. There are three tab views of your VAP in VAB:
 – Diagram tab
 – List View tab
 – Source tab
On the Diagram tab shown in Figure 3-1, all of the available components for the current pattern type are listed by their application categories in the palette on the left. You can drag the component onto the canvas.
Figure 3-1 VAB Diagram view
4. You can create a link by clicking (and holding) a blue button on a component on the canvas, and dragging it to the other component to be linked. A directed link (a line with an arrowhead) appears on the canvas as you drag.
5. When you click a component, link, or policy, the predefined attributes are shown in the right pane. The available actions for a component are shown on the component itself:
a. Add policies to a component.
b. Switch to mini view.
c. Delete the component.
d. Get help information about the component.
6. You can add a pattern-level policy by clicking Add policy for application in the upper-left corner of the canvas. The policy is added to all applicable components in this pattern. If you later add the same policy with a different attribute value on a single component, that policy will overwrite the pattern-level policy.
7. On the List View tab shown in Figure 3-2, you can see your VAP and its components, links, and polices in a list. You cannot add or delete any pattern model elements in the List View. The predefined attributes are shown when you expand each item, and you can edit or change the attribute value there. The List View gives you a collected view of all of the pattern model element attributes.
Figure 3-2 VAB List view
8. On the Source tab shown in Figure 3-3, you see the source file for your VAP. This is the JavaScript Object Notation file (appmodel.json) that describes the elements included in this pattern. This file is the input for kernel services to start the transformation, and to generate the final deployment of your pattern. There is no editing action available in this view.
Figure 3-3 VAB Source view
3.1.5 Virtual application template
The virtual application template is a set of pre-configured components and links used to simplify and standardize the creation of a VAP. Every time you create a new VAP, you can select a blank application or an existing template to start with.
If you need to repeatedly create patterns and fill attributes, saving a template as a base is useful. If you have Create new catalog content permission, you can perform these actions:
1. In the Workload console of PureApplication System, go to Catalog → Virtual Application Templates. You can see all of the virtual application templates by pattern type.
2. You can create, delete, import, export, or edit a virtual application template.
3. In the VAB, after editing an application pattern, you can also save it as a template. Click Save As in the toolbar and select the Save as application template option.
4. You can deploy a virtual application template directly, and specify any required settings at deployment time.
3.1.6 Virtual application layer
The virtual application layer provides a way for you to control complexity, and to reuse virtual applications. By default, a VAP consists of one layer when you first create it. You can set up multiple layers by adding separate layers, or by importing other VAPs as a reference layer.
You cannot change anything for the imported pattern. Anything changed in the original pattern will be reflected in your created pattern.
To work with the virtual application layer, follow these steps:
1. In the VAB, expand Layers to view the layers of the VAP, as shown in Figure 3-4.
Figure 3-4 Virtual application layer management
2. The virtual application layer fits the requirement of typical development and operation scenarios, in which the developer creates and maintains the original VAP.
3. Testers import the original pattern as a reference layer, and add their layers for their specific non-functional requirements.
4. The functional changes developers make in the original pattern are automatically reflected in the pattern testers’ reference layer.
3.1.7 Virtual application pattern type
The virtual application pattern type is a collection of plug-ins that defines components, links, and policies. It is grouped with configuration files that are packaged in a compressed tape archive (TAR) file (.tgz), and used to build a set of VAPs. A pattern type defines a virtual application domain.
For example, a process automation pattern type defines a domain in which business process applications are deployed. It includes components for process application artifacts. These components have attributes for the appropriate archive file, to be specified during construction of the VAP.
The virtual application pattern type is similar to that shown in 1.3, “Patterns” on page 7. All VAPs, virtual application instances, and virtual application templates are grouped by pattern type. Each of them must have only one pattern type.
The available component for your VAP construction is constrained by the pattern type that you select:
1. In the Workload console of PureApplication System, go to Cloud → Pattern Types. You can see all of the pattern types installed in the current system, as shown in Figure 3-5.
2. The two-digit version pattern type is a higher-level version for a pattern type, and it can include multiple four-digit version pattern types as its sub-items. When you create your VAP, you must select a two-digit version pattern type. It uses the latest four-digit version pattern type and its plug-ins by default. If you lock all of the plug-ins in that pattern, it will always use the specified four-digit version pattern type and plug-ins.
Figure 3-5 Virtual application pattern types
3. Select a four-digit version pattern type in the left pane, and the detailed information for that pattern type displays. You can accept the license and enable this pattern type.
4. All of the prerequisite pattern types are listed in the Dependency section, but if any of those are not installed or enabled, this pattern type cannot be enabled.
5. Click the Show me all plug-ins in this pattern type link, and all of the plug-ins under this pattern type are shown.
6. You can install a new pattern type by clicking the plus sign (+) on the toolbar, and then specifying your pattern type .tgz file.
7. You can also delete the selected pattern type by clicking Delete on the toolbar.
When you delete a pattern type, all of the plug-ins that claim this pattern type as primary are also deleted. Also notice if the pattern type is in use, which means that you created some VAPs with that pattern type. You might not be able to delete that pattern type unless you install the unlock plug-in.
3.1.8 Virtual application pattern plug-in
A virtual application pattern plug-in is a plug-in project that defines the model parts of a VAP, in addition to the underlying implementation that makes the parts deployable in the cloud. Each plug-in project must contain a config.json file.
Components, links, and policies are the most user-visible parts a plug-in can contribute, but there are other capabilities that a plug-in includes (for example, the appropriate lifecycle scripts to manage the virtual application through its various lifecycle events after its deployment). Plug-ins are grouped into pattern type by claiming their primary pattern type.
To see all of the installed plug-ins for a specified pattern type in the current system, follow these steps:
1. In the Workload console of PureApplication System, go to Cloud → System Plug-ins, as shown in Figure 3-6.
Figure 3-6 Virtual application pattern plug-ins
2. Select a plug-in on the left pane, and all of the components, links, and policies defined in that plug-in are displayed.
3. Expand a component, and you can see its detailed information, including all of the attributes defined in that component.
4. You can install or delete a plug-in by clicking the corresponding button on the toolbar. You can also configure a plug-in if the plug-in developer defined any configurable parameters.
3.2 Virtual application pattern model design
The virtual application pattern model is composed of three major elements: components, links, and policies. The implementation of these elements is in plug-in projects, and is grouped into pattern types. Designing the virtual application pattern model is actually the process of identifying components, links, and polices for your virtual application, and organizing them into appropriate plug-in and pattern type projects.
The goal is to keep your model simple, flexible, and reusable. Figure 3-7 shows the relationship between these elements. This is a typical output of your model design.
Figure 3-7 Virtual application pattern model overview
3.2.1 Prerequisites
PureApplication System uses the unified default image for the VAP deployment. It supports 64-bit hypervisors and images. For PureApplication System on Power, the default image is IBM OS Image for AIX® Systems V2.0. For PureApplication System on x86, the default image is IBM OS image for Red Hat Linux Systems V2.0.0.1.
You can also build your own Microsoft Windows image on x86 as the default image for the VAP. To build an image, you need to use the IBM Image Construction and Composition Tool (ICCT). ICCT can be downloaded from the Download Tooling toolbar on the Workload console.
Before you design and build your virtual application pattern model, always check whether PureApplication System base OS images provide the capabilities required by your middleware and application.
3.2.2 Planning your virtual application
When you want to model your application as a VAP, you need to consider your application domain. Your application could be any of the following types:
•A simple web application
•A web application that needs database access
•A web application that talks with a business process
•A mobile application that calls a business process with embedded business rule invocation and analytics reports
You might need high-availability or auto-scaling capability for your application, and these factors affect the design of your virtual application model. Collect the functional and non-functional requirements for your application as early as possible, before you start your virtual application pattern model design.
Keep in mind that your virtual application pattern model design is not just for a single, specific application. When it is designed and implemented, it can fit any application in the same domain. Therefore, take variability into consideration to make your virtual application pattern model flexible enough for reuse.
Each application is composed of one or more application artifacts, which are the deployable pieces of your application. When planning your virtual application, perform the following activities:
•Identify all of your application artifacts.
•Identify any underlying middleware and OS requirements.
•Draw the relationship between artifacts.
•Describe the necessary quality of service level for your application and artifacts.
You can create a diagram to describe your application details, as shown in Figure 3-8 on page 41.
Figure 3-8 Virtual application planning
3.2.3 Identifying component and underlying middleware capabilities
A component represents an application artifact, such as a web archive (WAR) file, and its attributes, such as a maximum transaction timeout.
During your virtual application planning, you already identified all of the application artifacts, so you have a list of candidate components. For application artifacts of the same type, such as the two process applications shown in Figure 3-8, use the same component to represent them.
If there is another type of process application with an enterprise archive (.ear) file, think about whether you need to identify another component, or use the same component and handle the file type difference inside your component implementation code.
The implementation of a component in a plug-in project transforms the component into a deployable template that the pattern engine can recognize, and deploy to the cloud. One component can be transformed into multiple VMs, or multiple components can be transformed into one VM.
Usually, the component implementation includes these elements:
•The definition of operating system (OS) and resource information
•The installation of middleware
•The deployment of application artifacts
If there is no specific requirement, do not show the middleware topology at the component level.
3.2.4 Identifying links
A link is a connection (or relationship) between two components. For example, if a web application starts a database query, an outgoing link from the web application component to the database component defines this dependency.
The implementation of a link in a plug-in project is comparable to a configuration. The web application-to-database link is the data source configuration, and the process application-to-rule service link is the environment variable configuration.
The link between the process application and the rule service adds the target information, such as IP address and port number, into the source configuration. To use the link, your application implementation needs to follow some standard, so that the configuring can take effect during application run time.
3.2.5 Identifying policy
A policy represents a quality of service level for application artifacts in the virtual application. Policies can be applied globally, at the pattern level, or specified for individual components. For example, a logging policy defines logging settings, and a scaling policy defines criteria for dynamically adding or removing resources from the virtual application.
Defining the application non-functional requirements (NFR) as a policy is possible. Usually, a policy cannot change the application artifacts, but it can change the underlying topology of middleware.
3.2.6 Classifying pattern type and plug-in
After you identified components, links, and policies, you need to organize these elements in appropriate plug-in and pattern type projects. You can put everything in one plug-in and one pattern type, but you can also host each element in a separate plug-in project and a pattern type. Understanding the packaging of pattern type and plug-ins, and their relationship in PureApplication System, will help you make the correct decisions about classifying your model elements.
Plug-in projects claim one primary pattern type, and zero-to-many secondary pattern types, in their config.json files. Model elements defined in this plug-in are visible to those pattern types.
As shown in Example 3-1, the plugin.com.ibm.test plug-in claims patterntypeA as the primary pattern type, and patterntypeB and patterntypeC as secondary pattern types. When you create a VAP with patterntypeA, patterntypeB, or patterntypeC, you can use all of the components, links, and policies defined in this plug-in.
If you want the model elements in a plug-in visible to all of the pattern types, you can specify asterisk-colon-asterisk ("*":"*") as the secondary pattern type, with the asterisks enclosed in double quotation marks.
Example 3-1 Plug-in project config.json file
{
"name": "plugin.com.ibm.test",
"version": "1.0.0.0",
"patterntypes": {
"primary": {
"patterntypeA": "1.0"
},
"secondary": {
"patterntypeB": "1.0"
"patterntypeC": "1.0"
}
},
"packages": {
"TEST": [
{
"parts": [
{
"part": "parts/test.scripts.tgz"
}
]
}
]
},
"parms": {
},
"files": [
"/test/test.zip"
]
}
If you separate your model elements with different plug-in and pattern types, make sure that you have one pattern type that contains all of the elements required for you to create your composite application pattern.
A plug-in project is packaged with its primary pattern type, and all of the files defined in the plug-in are also packaged into the pattern type. As shown in Example 3-1 on page 42, the test.zip compressed file is packaged into the patterntype.tgz file.
Usually, the files put into patterntype.tgz are the software installation binary files, which can be large. Therefore, when you have multiple plug-in projects that claim the same primary pattern type, you also need to think about the size of your pattern type, and the resources required to upload it. For more information about file packaging in plug-in projects, see 8.4, “How to manage binary files” on page 169.
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset