Working With Deployment Plans


In my overview blog entry ‘From Dev to Test to Production‘, I already mentioned AIA Deployment Plans as key elements for transferring integration code from environment to another. So what is a Deployment Plan then?

Main Article

Primarily it is a set of declarative instructions describing what needs to be deployed as part of your solution. It is not – as you might think – a set of scripts (e.g. ant) that you wrote in long, tiring sessions so that you have something you can pass to the guy responsible to deploy to your test environment. I guess a snippet from a real example (AIA Demo) will make this clearer:

<DeploymentPlan component="AIADemo" version="3.0">
<JMSResource wlserver="fp jmsResourceType="Queue" 
      action="create" jmsModuleName="AIAJMSModule" 
    <JMSResource wlserver="fp" jmsResourceType="ConnectionFactory" 
      jmsResourceName="AIADemoCF" jmsresourcejndi="jms/aia/AIADemoCF" 
      action="create" jmsModuleName="AIAJMSModule" 
   <JmsAdapter wlserver="fp" action="create" jndi-name="eis/jms/AIADemoCF" 
      connection-fac-Location="jms/aia/AIADemoCF" isTopic="false"
    <Composite compositeName="AIADemoBatchJMSAdapter" 
      revision="1.0" wlserver="fp" action="deploy"/>

In this AIA Deployment Plan – it’s basically just an XML file – you see a couple of related instructions, that are responsible for not only deploying a SOA 11g composite, but also to fulfill all required prerequisites for this composite to execute successfully.

The purpose of this composite called ‘AIADemoBatchJMSAdapter’ is simply to accept a message of a certain structure and then put this message on a JMS queue for further consumption by some other component. Therefore, the Deployment Plan includes the following:

  • Creation of a JMS queue on the middleware
  • Creation of a JMS connection factory
  • Configuration of the JCA Adapter for JMS in order to register the new JMS connection factory
  • Deployment of the actual SOA composite

I would like to highlight two significant things here:

  • The Deployment Plan includes no code/scripting. As mentioned, it is entirely declarative and you don’t bother about how this plan is going to be executed. The great news is that the ‘how’ has already been provided by AIA Foundation Pack 11g: it includes the AIA Installation Driver (AID) that just takes such a deployment plan and execute it. You don’t write a single line of deployment scripts!
  • The second highlight is that this deployment plan has no environment details. So to figure out where to deploy the solution, the AID will take all environment details from a configuration file that was created with the AIA Foundation Pack installation. It’s called AIAInstallProperties.xml and includes all details such as server names, ports, users, passwords, etc. to fully describe a particular installation.

In summary, all you need to have is an AIA Deployment Plan along with all your code that you pass to the guy taking care of your test environment. He will simply execute the AID tool against your Deployment Plan while making sure to refer to the AIAInstallProperties.xml from the test environment. With that, you have transferred your code to another environment in a repeatable fashion and – guess what? – without writing a single line of code.

But AIA Deployment Plans can do even more:

  • Phased execution as you can even see in the snippet above (Configurations, Deployments)
  • Extensibility through a Supplemental Deployment Plan
  • Conditional Execution

We are planning to also go into these details in subsequent posts.

So these Deployment Plans are clearly highly useful assets. In yet another post we will soon explain how you generate these Deployment Plans. It might not be a surprise anymore, but you don’t even have to write them from hand. AIA also provides tools to let you generate your Deployment Plan! So check out our next posts.

Add Your Comment