It should be obvious that Axis is nicely designed to handle a request/response message processing pattern. However, it is not limited to this single message-flow pattern. As we stated earlier, each handler and service has available to it a MessageContext object that will contain both the request and response message; however, you don't have to use both of these messages. It is possible to configure chains of handlers that process the request message but produce no response message. In the HTTP transport environment, doing so might seem strange; but in a non-request/response transport (such as SMTP), this is a much more likely scenario. In this one-way message pattern, the Axis engine can be configured to use only handlers that examine the request message and do not use the response message at all. Note that if a handler is invoked that does generate a response SOAP message, but the transport listener chooses not to do anything with the response SOAP message inside the MessageContext object, then the response will be ignored. Axis assumes that the transport listener knows how to deal with the response message, and if it ignores any response, then that must be the correct behavior.
At the time of this writing, Axis does not yet support the notion of asynchronous message processing, but it should by the time of its first release. In this model, Axis will allow the client to asynchronously invoke a Web service and at some later point in time request the response, thus allowing the client to perform other actions while the Web service is doing its job.