Virtual application lifecycle

Plug-ins are involved in the creation, deployment, and management of a virtual application.

Creating the application model

To create or update a virtual application, you use the Pattern Builder in Cloud Pak System Software for Power® to define the application model. The virtual application model is defined by the user with components, links, and policies that are available within the selected pattern type and any secondary pattern types that are associated with the selected pattern type.

Components are fundamental building blocks used to construct your virtual application model. Select components on the Pattern Builder canvas and provide values for the component attributes. Then, you can add policies and links between components, and then configure values for their attributes.

When you are building your virtual application, the back-end of the Pattern Builder does a background scan of the user artifacts to help guide the modeling of the connections between the components, links, and policies. For example, the EAR file in the WebSphere® Application Server enterprise application component scans the EAR file for a list of required resources.

A plug-in controls the end-to-end handling of its capabilities, starting with the components, links, and policies that are used to model the artifacts that are associated with the plug-in. The appmodel/metadata.json file specifies these components, links, and policies, and the corresponding property sheets for user customization.

A plug-in provides components, links, and policies to the user for attributes that can be configured in the Pattern Builder. Displaying a specific subset of configuration options guides the user to model and construct virtual applications in the manner that is supported by the plug-in developer. These artifacts might not correspond to deployed virtual machines, but rather reflect the logical model that the plug-in shows to the user.

Deploying the application

Kernel services store the application that you created with the Pattern Builder and the next step is deploying the application.

Plug-ins can provide implementations of Java™ interfaces like TopologyProvider, TopologyProcessor, SerivceProvisioner, and PostProvisioner to provide function for the successful deployment of the virtual application. These implementations are packaged as OSGi Declarative Services (DS).

When you deploy an application from the Instance Console to your target cloud, the component transforms are started and then the link transforms are started.

Specifically, kernel services are started to convert the application model from a logical description into a topology document or physical description by using the TopologyProvider and TopologyProcessor transformers. The component transforms must detect applicable policies and transform them. Required resources are provisioned with the ServiceProvisioner and PostProvisioner provisioners, and the Infrastructure as a Service (IaaS) is started to start the virtual machines that are used to realize the application.

The transformers and provisioners are in the plug-in bundles/{name}.jar file. The plug-in nodeparts/{name}.tgz file contains the node parts that are downloaded and installed with the activation script on the virtual machine. The parts/{name}.tgz file contains the parts that are downloaded and installed with the workload agent on the virtual machine.

The following diagram shows more details of the end-to-end process.

Plug-ins use implementations of TopologyProvider to convert instances of their components, links, and policies from the application model into an unresolved topology. The unresolved topology is generic; the transformers specify abstract package names rather than specific node parts and parts, and the images and instance types are not yet specified. A package represents a specific function, for example, DB2®. A plug-in might provide various implementations of that function, like DB2 for Linux® or DB2 for AIX®, therefore, transformers are not required to be aware of cloud-specific details like what operating system images are available.

A TopologyProvider transforms a component, link, or policy in the application model into a topology document fragment (both the application model and the topology document fragment are JSON objects). Cloud Pak System Software for Power merges these fragments into the unresolved topology document. TopologyProcessors then process this unresolved topology document and can further change it.

Cloud Pak System Software for Power provides a TemplateTransform class to ease development. The TemplateTransform class provides you with the capability to write a transform as a JSON object directly by using the Apache Velocity templating engine. If more function is required, you can include JSON code, Velocity macros, and Java method invocation.
After the unresolved topology document is complete, the next step resolves the specific node parts and parts, and images and instance types, according to the best fit for the cloud details and plug-in configuration, as specified in the config.json file. For example, the best supported operating system, machine size, including processor, memory, and disk, and 32 versus 62-bit architecture are chosen. The resolved topology is passed to a provisioning phase where resources are provisioned from shared services. Plug-ins provide the specific provisioners and the results are inserted into the topology to create the final topology document. The final plug-in developer exit point is the PostProvisionier, which is started after all services are provisioned and after the topology document is finalized and written to the storehouse. The topology document is written only once to the storehouse, and is never updated. A separate deployment document is written to the storehouse to represent the deployed virtual application. This document is written and updated many times, and reflects the current state and status of the deployed virtual application.
Deployment culminates in virtual machines that are deployed in the target IaaS cloud.
1. As a part of the activation process, a script on each virtual machine downloads and parses the topology document; the required node parts that are specified in the topology are downloaded and installed.
2. The workload agent is a node part. The workload agent parses the topology document, and downloads and installs the required parts. Finally, the workload agent initiates the lifecycle scripts for the specified roles and dependencies. The natural progress of the lifecycle scripts start and maintain the application through failure recovery.

Example deployment process

Consider deploying an application on WebSphere Application Server that uses a DB2 database. See the section, Application model and topology document examples, in the topic, Plug-in development guide, for the detailed documents.

Cloud Pak System Software for Power includes a WebSphere Application Server plug-in that installs a WebSphere Application Server image on an IaaS node or virtual machine, a DB2 plug-in that installs a DB2 image on a virtual machine, and a WebSphere Application Server DB2 plug-in that connects the two.

The WebSphere Application Server and DB2 plug-ins each provide a component in the Pattern Builder. You can drag each component to the canvas to create a virtual application. The Web Application component has two attributes: the application WAR file and its context root. The context root is a URL in a web browser to access the application.

The DB2 component has attributes like database name, disk size, and, optionally, the .sql or .ddl file that describes the database schema.

The DB2 plug-in in the Web Application Pattern pattern type provides the link to connect these two components. Using the Pattern Builder, you can connect these two components with a link. The link also has parameters, like the Java Naming and Directory Interface (JNDI) name of the data source and resource references that the application uses. You must complete these attribute values in the Pattern Builder. The WAR file is scanned and populates the list of JNDI data source names and resource references that are found in the WAR file. All three plug-ins provide parts with lifecycle scripts as parts. The WebSphere Application Server and DB2 plug-ins also both provide WebSphere Application Server and DB2 execution images (binary files) as parts. Installation of these parts is done during the deployment process. The WebSphere Application Server and DB2 plug-ins transform each of their components into virtual machine image templates for which IaaS instantiates a virtual machine node.

The WebSphere Application Server plug-in also provides a policy for setting Java virtual machine (JVM) parameters, like heap size, for all WebSphere Application Server nodes in the deployment. The lifecycle scripts use the attributes that are set in the topology document during the transform and deploy process to start the nodes. The WebSphere Application Server plug-in adds a WebSphere Application Server role to the WebSphere Application Server virtual machine that is used to start and configure WebSphere Application Server on the virtual machine.

Similarly, the DB2 plug-in adds a DB2 role to the DB2 virtual machine. The WebSphere Application Server DB2 plug-in implements the dependent DB2 role that links from the WebSphere Application Server role to the linked DB2 instance. When the DB2 instance comes up, it exports parameters like database name, host name, port, user ID, and password. The WebSphere Application Server DB2 changed.py script runs when both WebSphere Application Server and DB2 are started. It imports the DB2 parameters, and, by using its own attributes, configures WebSphere Application Server to use the wanted DB2 instance.

Managing the deployed application

When the virtual application is deployed, the application becomes a virtual application instance. The plug-ins that make up the application continue to work behind the scenes even after the virtual application is deployed.

You can use the Cloud Pak System Software for Power user interface to view the virtual machines on which your applications are deployed. You can use the deployment panel of the user interface to view the monitoring data and logs. The plug-in appmodel/tweak.json and operation.json files contain the mutable configuration for the deployed virtual application instance, while the node parts and parts, such as the workload agent, help manage the application through failure recovery.

For information about the details of these phases, see "Plug-in development guide."