Introduction:

FireAnt is designed to facilitate the role of a deployment planner, who determines the
allocation of components to physical application nodes. A deployment planner also
determines the software installation and configuration process that must be performed to
deploy each component on its target node. This basis installation and configuration
includes setting up an application server (such as JBoss) on the target environment and
editing its configuration files to establish needed database connections.

FireAnt was developed using the Generic Eclipse Modeling System (GEMS)
[http://www.sf.net/projects/gems] created by the Distributed Object Computing (DOC)
Group at the Institute for Software Integrated Systems (ISIS) at Vanderbilt University.
GEMS is an model-driven environment built using Eclipse. A GEMS-based metamodel
describing the problem domain was constructed and interpreted to create the FireAnt
DSML for deployment and configuration of EJB systems. FireAnt models constructed in
the domain are interpreted to produce FireAnt build scripts.

Tutorial:

This tutorial introduces the basics of using FireAnt to deploy and configure a J2EE
application to a group of nodes. In this tutorial we will be deploying one EAR files, each
with several beans, to an application server.

We will be deploying:

1. demo.ear - This EAR contains one set of our components.

2. Support.zip – This contains additional XML files that must be installed on the
node containing the demo.ear.

1. Create a new deployment plan in Eclipse [File->New->Other->FireAnt->FireAnt

Deployment Model]
2. Give the new model the name “foo.anthill” and select a project for the model to
reside in
3. Click Finish
4. Open the properties view if it is not already open [window->show view->other-
>basic->properties]
5. Right Click in the Model canvas area and select Interpret->Import EAR(s)
6. Type the path of the EAR file you would like to import
7. Click Finish
8. You will see the EAR file that you have imported, by clicking on the expand
button in the upper left hand corner of the EAR, we can see the JAR files
contained within it
9. By clicking the expand button on each JAR file, we can see the EJBs contained
within each JAR
10. In order to deploy the ear to an application server, we need to model the target
node. We start by clicking on the “Node” icon in the palette on the right hand
side. After clicking on “Node,” click again inside the model to add a Node.
11. Give the node a name in the properties pane beneath the model
12. Click on the expansion button in the upper left of the Node
13. Click on AppServer in the palette and then click again within the Node to add the
AppServer as a child
14. We now need to specify that we want our EAR file to be deployed to the node we
have just modeled. To do so, we need to make a connection between the EAR and
node. Click on the “Connection” tool in the palette.
15. Click on the EAR
16. Click on the Node
17. We now have specified the deployment of the EAR file to one node. We could
stop and execute the deployment plan at this point. However, to make things more
interesting, let’s assume that we want a particular ANT script to run after the EAR
is deployed. Click on “PostDeployScript” in the palette.
18. Now click on the EAR to add it as part of the payload being deployed to the node
19. Click on the PostDeploymentScript and adjust its properties. Set the URI to point
to the ANT build file that you want to run after the EAR is deployed
20. Let’s assume that we want to deploy an extra zip file to the target as well. Let’s
also assume that it is a file needed by our PostDeploymentScript. To specify the
extra resource to deploy, we first click on the “Archive” icon in the palette.
21. Now click on the EAR file to add it as part of the payload going to the Node
22. Now set the URI in the properties pane to point to the file you want deployed to
the node
23. At this point, we are ready to run our deployment plan. Right click on the model,
Interpret->Package and Deploy Egg
24. At this point, the deployment wizard will pop up allowing you to bind the Nodes
to actual targets. For each node in your model, you will be asked for:
a. Node Address – the IP address or network name of the target node (it must
have a JVM installed and a SSH server)
b. User – the user name to log in and run the deployment with
c. Pass – the password for that user
d. Staging Directory – the directory where all temporary files will be placed
(this directory must exist)
e. Deployment Directory – the hot deploy directory of the application server
 25. Click Finish, the FireAnt runtime will begin SSHing into each target and running
the deployment you have modeled (see the next section for a detailed description
of how the FireAnt runtime works)

This is just a basic example of a very simple deployment plan. Each bundle or assembly
can be deployed to multiple nodes in a model. Also, there can be multiple nodes in each
model and each can have multiple assemblies deployed to it. You could even send the
application server you want to deploy to along as an extra archive and use a
predeployment ANT script to install it (this had been done). Good luck.

Runtime Deployment Overview:

Fire Ant uses a package format called an EGG, which contains all the artifacts required
for a deployment and the Fire Ant deployment plan. The Fire Ant deployment plan is an
XML file that orchestrates the deployment of one or more assemblies of EJBs to their
target locations. The Fire Ant deployment plan specifies what artifacts in an EGG to
deploy on each node. The deployment plan also specifies additional ANT build scripts
that run on each target node to perform special pre- and post-assembly deployment
configuration.
A Fire Ant deployment proceeds in the following steps shown in Figure 5:
1. Fire Ant is launched.
2. Fire Ant then parses the deployment plan and verifies that all required resources are
present in the EGG.
3. Fire ANT copies an ANT installation to the target using SCP.
4. Fire ANT copies the EGG to the target using SCP
5. Fire ANT executes any required pre-deployment configuration ANT scripts.
6. Fire ANT executes an ANT build, which deploys the components in the Assembly
to the application server residing on that node.
7. Fire ANT executes any post-deployment configuration ANT scripts.
8. Fire ANT deletes the ANT installation and EGG.
9. Fire ANT closes the SSH connection to the target
10. Steps 4-10 are repeated for each deployment target.

Fire Ant uses SSH for its remote deployment, which provides significant advantages in
terms of security, target pre-configuration, and manual intervention. SSH is an
established secure standard for communicating with remote systems. Communicating
over another protocol would require opening additional ports in an organization’s firewall
and the implementation of a secure authentication system. The secure authentication
system itself would need to be installed on the target node and would increase the target
node’s public points of malicious attack. SSH also allows Fire Ant a trusted, well tested,
and accepted framework for doing remote deployment. Moreover, SSH access is
integrated into ANT and does not require extra development work.
The only initial configuration that a target node needs to receive a deployment is a
working Java Runtime Environment (JRE). Although it is possible to push one to the
client using Fire Ant, this is not an advised practice, so we recommend that a JRE be
installed and tested before deploying components. It is also unlikely that a target node for
an EJB application would not already have a functioning JRE installation and require one
to be pushed through by Fire Ant. Requiring only a functioning JRE alleviates developers
from having to correctly deploy and install a custom deployment base. JREs are well
understood and much more likely to be properly deployed and configured, which is key
to execution correctness and reproducibility, than a custom deployment solution.
 4. Egg
EJBs
3. ANT
Local ANT
Configuration
Installation
Scripts

Supporting
Artifacts

Node 1

SCP
Remote Execution
5. Execute Pre-
configuration
6. Deploy Components
7. Execute Post-
SSH configuration
8. Remove EGG and Ant
Installation

9. Close SSH Connection

Deployment Node

Figure 1: Fire Ant Deployment Process