What is the difference between aar and war file?

Question

I don't know what are aar archive files and how they differ from war. I read that they are somewhat convertible. When to use which one? What are pros and cons and limitations.

Durden

Answer 1

A .war is a web archive that you can deploy to any Java EE application server.

A .aar is a specific axis2 artifact that you can deploy in an application server where you have Axis2 standard web application deployed already.

You can still deploy an Axis2 application, including multiple services, in a standard web application, using the 'embedded' mode, as described here: http://wso2.com/library/90. Converting from .aar mode to embedded mode consists of extracting all files and carefully putting them in the right place for the embedded mode.

Pro's for the .aar is the hot deployment as @renat-gilmanov answered.

Pro's for the .war (embedded) is

1. easier to deploy and manage in a production environment: just deploy one .war on any application server instead of having to follow a complex deployment procedure.
2. you can include more servlets in the same .war, such as e.g. the client application.

Genie

Answer 2

Axis Archive (.aar)

Axis 2 services are packaged as Axis Archive (.aar). This is a JAR file (created using jar or zip utilities) with the services.xml file packaged in META-INF dir of the archive.

Example,The StockQuoteService when packaged as StockQuoteService.aar will have the following structures:

./stock/StockQuoteService.class 
./META-INF/services.xml

Deployment of the service in Axis2 is quite simple; just copy the .aar file to the axis2/WEB-INF/services directory in the axis2 Web application in your servlet container. In case of Tomcat, it will be $TOMCAT_HOME/webapps/axis2/WEB-INF/services.

Rationale

Service is quite a small piece of software. Please think about the following:

• service life-cycle, because you need to deploy/redeploy/undeploy a service or services you are developing
• container overhead related to every single deployed application
• overhead caused by several Axis2 instances deployed in parallel
• loosely coupled architecture
• ...

Basically, Axis2 suggests to treat *.aar as a lightweight application. It shares same Axis2 instance, can be easily managed and redeployed without stopping the whole business.

Let's imagine you develop a complex system. As a good developer and architect you decided to build loosely coupled system using services as a smallest piece of functionality. Decomposition went well, so you have ~100 services. Which is, by the way, good, because you will be able to:

• simplify the development
• develop some services in parallel
• simplify testing
• ...

The question is will you prefer to develop all these services as a separate applications (wars)? I hope you won't. It will be much easier and more efficient to use such a lightweight approach as Axis Archives.

Please note, Axis allows you do manage service life-cycle as Tomcat does for application.

Availability is a big concern when it comes to enterprise-level applications. Even a short amount of downtime can be highly detrimental, so restarting a server is not a good option. You need to update your system without shutting it down. This is where hot deployment and hot update come in.

Hot deployment is the capability of deploying new services while the system is up and running. As an example, let's say that you have two services -- service1 and service2 -- up and running, and you deploy a new service called service3 without shutting down the system. Deploying service3 is a hot deployment scenario.

Hot update is the ability to make changes to an existing web service without shutting down the system. This is an important feature and required in a testing environment.

The Axis2 Deployment model, Part 1: Six ways the Axis2 deployment model is more user friendly

Manny