Introduction
Think of the word "layers" and it could conjure up any number of thoughts about cakes, clothing on a cold day or even cars! Yes, if you think about, even cars have layers. When I was younger I could only afford the base models, and watched jealously as others had "Sport" models. The Sport model was a base model with larger wheels, better sound system and tinted windows. In other words extra layers were placed on to the base model. And keeping with the car analogy, remember how the car brochure was easy to read, and used tables to indicate different options? It was fairly easy to spot which options you would get with your model of car.
And finally, what if there was a design improvement on the car's door locks? Since the change would happen at the base model, all other models would be changed too.
The layered approach is, perhaps, more common than we first thought and is available when designing virtual applications.
What are virtual applications?
Virtual applications are a Platform as a Service solution in which your application takes center stage. Looking at the diagram below we can see that IBM Workload Deployer is capable of supporting three deployment models: Images, Topologies and Workloads. There are benefits and trade-offs with each one, of course, and they are discussed elsewhere, but
we are interested in the Workloads model - or virtual applications.
With virtual applications we are essentially delegating the hassles of creating the topology to the IBM Workload Deployer - in short, the appliance configures the environment.
Although we bid farewell to a certain degree of flexibility, we enjoy great simplicity and the quickest Time to Value. If the pattern consists of nothing more than :
- Your application (EAR or WAR)
- Dependent assets (for example, WebSphere Application Server, DB2, LDAP)
- Policies (QoS)
then potentially the virtual application pattern allows you take advantage of a reduction in the need for middleware skill requirements.
There is no doubt that, today, options are a little limited. For example, there is no support for the SIBus or remote EJBs. However, if you can fit your application into the virtual application pattern, you stand to reap massive rewards.
Virtual application layersLayers are available within the virtual application pattern, and offer a way to incrementally build out a virtual application. Each virtual application has one layer by default, and you don't necessarily have to add more. So, if you decide that your virtual application fits nicely into a single layer then that's just fine, but let's take a closer look at layers anyway.
There are two approaches to using virtual application layers : the "create your own" and the "re-use". Each one can save you time and help you to better understand your virtual application pattern.
The "create your own" approach to virtual application layers
This approach is, as the name suggests, a way to build your own layers to create a pattern. Let's look at a simple example.
In this example I have created a very simple virtual application which comprises of an enterprise application, a database and a link to an existing LDAP.
There is no mention of the layer on the canvas because I am only using one layer. I can view all layers by clicking towards the bottom left of the palette on the "up arrow" to expose
the layers.
The only layer here is "layer_1". I can add a new layer by clicking on the left icon :

As soon as I add a new layer, not only is it shown in the Layers section, but the three components on the canvas are designated as being in "layer_1".
I can rename the layers by clicking on them in the left pane. In this example I have renamed layer_1 as "Base" and the second layer as "QoS".
Clicking on the blue "+" I have added a scaling policy. By default it is assigned to the QoS layer. You can change the assigned layer of a component or policy by clicking on the layer name within the component itself.
Finally, by clicking on the eyes next to the names of the layers in the palette you can enable or disable the layers. When disabling a layer the canvas view will alter and grey out all components in the disabled layer.
However, be aware that the enable/disable feature does NOT affect the deployment. When the virtual application is deployed ALL layers are deployed as well. Therefore the enable/disable feature is only for editing, to allow you to breakdown and review complex deployments more easily. I would suggest that "enable/disable" is perhaps not the best wording, and that "show/hide" is probably more accurate.
So, in this example above, you can see how to create your virtual application pattern and add layers to reduce complexity. As already mentioned, upon deployment all layers are used, e.g. you cannot only deploy baseline and internal QoS....... we would use a different technique for that..... Reference Layering.
Reference layers - the art of reusing
As you saw above, you can create your own virtual application and add layers on top. You can, however, use the concept of reference layers.
This is where you can "import" an existing virtual application pattern as a layer and build on it. What makes this neat is that :
A) The virtual application pattern already exists and you are just going to tweak it for your purposes, and
B) In the event that the "referenced" virtual application pattern is changed, this change is reflected in your own pattern.
To demonstrate this, I can create a new virtual application pattern and first specify a blank application. Although the canvas will be clear, there will still be a "layer1" and anything
created will be placed on that layer.
Now, let's add a reference layer by clicking on the following icon :
and import a virtual application as a reference layer
If I add the virtual application that I created earlier example, you can see that there is a new layer created and all the components are specified as being in that layer.
I can rename "layer" to something different and add, for example, a scaling policy.

Bear in mind that the reference layer is "Read Only" so you will not be able to move the scaling policy into the Default Application Pattern layer, nor will you be able to move any components out of that layer.
This could now be saved, and subsequently deployed as a Development/Test version of the Default Application Pattern virtual application. Furthermore, you could create yet another new blank virtual application, use the same reference layer but add a different scaling policy and perhaps a JVM policy. That could form a production-ready version of this virtual application pattern.
And finally, if the Default Application Pattern changes, any patterns that use it as a reference layer will automatically be changed too.
Conclusions
Virtual application layers help you to build out your virtual application - adding layers of complexity to ensure it meets your requirements.
Enabling/disabling the layers will help you to understand the components of your virtual application, but will not affect deployment.
Reference layers are a way of using an initial pre-built virtual application for your needs, and adding your own layers on top of it. The reference layer is "read only".
Any changes to the "referenced " virtual application used as a reference layer will be reflected in the new layered pattern.