Invoking a WS asynchronously implies that both sides need to run a WS server. Since the connection between the original client and the server is not maintained in an asynch call, the server needs to have someplace where it can send the response (which is then a WS call in its own, separate from the original one). This can only be achieved if the client also acts as a WS server.
So, a standalone clinet can very well send an asynch WS call, but it needs to run a WS server to receive the response (e.g. an embedded Tomcat with Axis). Since many desktop computers are behind firewalls that don't route incoming HTTP requests to them, that's often not possible in practice (although it is very much possible in theory, especially in intranet settings where no firewall is involved).
Originally posted by Raj Kumar Bindal: But why does server need that place,it can send the response directly to client also.I am not totally clear??
It's a consequence of using HTTP as a transport. HTTP is a simple request-response protocol - it does not support asynchronous operations directly. An HTTP-client simply opens a connection to the HTTP-server and submits its HTTP-request and waits for the HTTP-response after which the connection is dropped. An HTTP-client can only send HTTP-requests and receive the corresponding HTTP-response - it cannot receive HTTP-requests. In order to receive HTTP-requests you have to be an HTTP-server. This convention allows HTTP-clients to be relatively simple. Usually HTTP-servers "want" to serve requests fairly quickly so that they can free up the resources that were involved in serving the HTTP-request.
A web service always involves some kind of HTTP-server because it needs to receive HTTP-requests. A normal web service client can only send HTTP-requests (which contains the SOAP request) to a web service and await the HTTP-response (because the web service client is based on an HTTP-client). For asynchronous operation a web service has be able to send an HTTP-request (which initiates the "asynchronous response") somewhere. A normal web service client is not equipped to handle incoming HTTP-requests - its based on an HTTP-client, not an HTTP-server. Therefore a web service can only send an "asynchronous response" to another web service (which is based on an HTTP-server and therefore can handle incoming HTTP-requests).