1 Reply Latest reply on Apr 27, 2003 12:14 PM by Jon Barnett

    Can I keep a SOAP socket open for a long time

    Nick Ganju Newbie


      I have an applet which needs to make SOAP requests every few minutes to the server, and occasionally needs to make requests more frequently as the user is typing in data. I want to cut down the request time by permanently keeping the socket open between the applet and JBoss.

      Is there some mechanism by which I can maintain an open socket, and then occasionally send a SOAP request which will be deserialized by JBoss and sent to a servlet or EJB that I've written to handle the request? Also, (obviously) JBoss should not close the socket after sending the response.

      Thanks,
      Nick

        • 1. Re: Can I keep a SOAP socket open for a long time
          Jon Barnett Master

          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.