The SOAP payload is carried in HTTP so you are limited to a request/response pattern. That is, the response is carried in the same connection as the request, but each request is a separate connection. That is why we have a problem at the moment with secure, long transactions in Web Services.
So your proposal has a few problems in that respect. You cannot keep a connection open as per a telnet session and send multiple request/responses over it. Such a scheme would also not be very resource friendly for large numbers of clients. You are getting back to the old dedicated client-server type environment.
You might be able to build into your client some buffering so for each connection, you could bundle in greater information in your request and in your content assembler for the WebService you create more response information. The gain would be questionable though because of the extra processing work you will be doing on the client side.
I suppose you could also expose your bean container (JBoss) so your client directly connects to a stateful session bean, or similar. You would have to deal with security issues of exposing the bean container, as well as the limiting scalability of a stateful session beans - 1 dedicated bean per client session.
As the architect, you need to make the decision on load and environment you expect in production conditions to make a reasonable guess as to the best architecture.
Hope that helps.