Axis 2.0 is the next generation of the Apache Web service stack. Axis2 is built on a new architecture that was designed to be a much more flexible, efficient, and configurable version of Axis. Even though the architecture is new, some of the well-established concepts from Axis 1.x, such as handlers, are preserved in Axis 2.0. Axis 2.0 comes with lots of new features, enhancements, and new industry specification implementations. Among the new features and enhancements are AXIOM, Asynchronous Web service, MTOM, MEP support, and archive-based deployment architecture, which is considerably esteemed.
Axis2 Architecture
The Axis2 architecture has developed keeping a few principles in mind to preserve the uniformity of the architecture. The first one is the architecture that separates the logic and the states; the code that processes the logic is usually stateless. This allows the code to be executed freely by the parallel threads. The second one is that all the information is kept in one Information model; this allows the system to be stored and resumed. And finally, the architecture is modular; the architecture broke Axis2 into the following seven modules (as shown in Figure 1).
- Information Model
- XML processing Model
- SOAP Processing Model
- Deployment
- WSDL and Code Generation
- Client API
- Transports
Figure 1: Axis2 architecture components
Deployment Architecture
What is the difference between Axis 1.x and Axis2 deployment?
Previous versions of Axis failed to address the user friendliness factor involved in the deployment of a Web service, and it is due to the fact that Axis 1.x was created mainly to prove the Web service concepts. Therefore, in Axis 1.x, the user has to invoke the admin client manually and update the server classpath, and then restart the server to apply the changes. This burdensome deployment model was a definite barrier for beginners. Axis2 is engineered to overcome this drawback and provide a flexible, user-friendly, and easily configurable deployment model.
Axis2 deployment introduced the notion of a J2EE-like deployment mechanism, where the developer can bundle all his/her class files, library files, resources files, and configuration files together as an archive file, and drop it into a specified location in the file system.
The concept of hot deployment and hot update is not new terminology to the technical paradigm, particularly to a Web service platform, but for Apache Axis, it is a new feature. Therefore, Axis2 was developed by keeping room for "hot" deployment features.
Hot deployment: The capability of deploying service while system is up and running. In a real-time system or business environment, availability of the system is very important. If the system is down even for a moment, the loss might be substantial and it may affect the lifetime of the business. However, if it is necessary to add a new service to the system and if this can be done without shutting down the servers, that would be a great achievement. So, Axis2 addresses that and provides a Web service hot deployment ability, where you do not need shut down the system to deploy a new Web service. You merely need to drop the required Web service archive into the services directory in the repository. Then, the deployment model will automatically deploy the service and make it available to you.
Hot update: The capability of making changes to an existing Web service without shutting down the system. This is an important feature and is required in a testing environment. However, it is not advisable to use hot update in a real-time system because a hot update could result in the system leading to an unknown state. Additionally, there is the possibility of losing the existing service data of that service. To prevent this, Axis2 came with the hot update parameter set to FALSE by default.
Axis2 addresses hot deployment and hot update by using a scheduler and a file system listener, where the scheduler is scheduled in the way that will inform the listener to search the repository for updating and, depending on the configuration given by axis2.xml updates (adding new service or changing an existing service), will be made available to the system. The underlying architecture that provides "hot" deployment characteristics is as shown in Figure 2.
Figure 2: Deployment Architecture (Repository based deployment)
- Scheduler: This is scheduled in the way that periodically informs the Listener to search the repository.
- Listener: This searches the repository for updating.
- Descriptor Parser: A component to process the service and module descriptors (totally built on AXIOM).
- Deployment Engine: The centered component of the deployment, which does all the logic processing.
- Axis2 Core: In the Axis2 core system, deployment is totally independent from the core, and the core does not depend on the deployment.
- Repository: A directory in the file system where deployment has been configured to search. Inside the repository there could be two sub directories called "services" and "modules," where services and modules are going to be dropped in respectively. The pictorial representation of the repository looks like Figure3.
Figure 3: Axis2 repository
IE 7
Firefox 2.0
