Tutorials Axis2We can deploy a service in many ways. We could deploy a service as an archive file (Axis2 default), by creating a service using a database, or by creating a Web Service using a text file. The idea of custom deployers is to open avenues to support any kind of deployment mechanisms. Axis2 has in-built support for:
But if someone wants to deploy a service, or a module, then he or she can achieve that goal with the use of custom deployers. We will discuss more about custom deployers in Chapter 5.
As we have discussed, the Axis2 execution chain is a collection of phases wherein each phase is a logical group of handlers. The Message Receiver, in itself, is a handler. However, it is different from other handlers because Axis2 treats the Message Receiever in a different manner. If the message has gone through the inflow with no issues, or in other words, no exceptions have occurred in the middle of the chain, then the engine hands over the message to the message receiver so as to invoke the associated business logic.
Message receivers interact directly with both the actual service implementation class and the AxisEngine. However, there can be some instances wherein there are no service implementation classes and all the logic is handed inside the Message Receiver. The message receiver is the last component in the inflow process. Axis2 has got nothing to do with it once the message is handled over to the message receiver.
Axis2 is enterprise-ready. Its Web Service engine provides a better SOAP processing model, with considerable increase in performance for both speed and memory usage with respect to Axis 1.x and other existing Web Service engines.
In addition, it provides the user with a convenient API for service deployment, extending the core functionality, and thus acting as a new client programming model. In this chapter, we have learned about the internals and architecture of Axis2. Thus, we have learned that Axis2 architecture helps in attaining a more flexible and extensible Axis2.
