I'm new to writing web services. Since web services are generally stateless I'm having trouble understanding how to keep an open connection to a system I'm trying to expose. This system requires a persistent connect to be created and this connection sequence takes approximately 10 secs . By creating a separate connection to the system for each call to the web service causes each call to perform badly.
I'm trying to find a way to keep a pool of connections to this system open. The only way I can think to do this is by standing up a RMI server and making the web services an interface to the RMI services.
I know this will work but I’m not sure it’s the best solution so I would appreciate any suggestions.
First of all, stateful web services are seldom a good idea. I am sure you have heard that before, so now on to your problem.
Secondly, your question lacks important details, but here is an attempt at some hints which hopefully will help you.
The second option is to use a stateless web service which receives requests and transform them into messages. The messages are passed on to a message queue from which a worker, who keeps a constant connection to whatever backend system it talks to open. The messages are processed one by one and, using the same connection, sent to the backed system.
If one wish to scale the solution, simply add more workers listening to one and the same queue. Each message will only be delivered to one worker.
This approach can be unsuitable if the clients require synchronous responses.
@Kevin:What framework are you using? If each message is send over HTTP 1.1, I would expect that the connections are persistent and reused. So to establish connection you would see HTTP request1 (reply), HTTP request2 over the same tcp connection. Is this your problem?
This approach can be unsuitable if the clients require synchronous responses
Just wondering why it couldn't be synchronous. In my previous company we used a mechanism where client sends requests in the form of web service to WAS server where stateless session ejbs are running through JMS messaging as interface (again on WAS). But, I think the only catch is that the entire business logic + back end processing must be done within Webservice timeout (I remember we had 30 secs of time interval).
@Kevin: I think the above approach would work even if we don't use JMS messaging interface by just exposing stateless EJBs as webservices as long as the job is done within timeout interval.
(OCEEJBD6, SCWCD5, SCDJWS, SCJP1.4 and Oracle SQL 1Z0-051)
Wow, thank you for your suggestions. I'm still pretty new at the web based technologies so I'll have to spend some time translating and researching the suggestions. I do appreciate the suggestion and will put some serious time into investigating the options purposed.
I've read over the responses and I think you guys have pointed out my biggest issue. These requests must have synchronous responses. The foreign system calls the web services and expects an immediate response.
Ivan's suggestion is very close to my original design except without the message queue. My original thought was the RMI service would maintain a pool of open connections. When a web service is called it performs an immediate lookup and call to a RMI method. The RMI Server would choose an open connection to our system and use that connection to complete the transaction and return the result.
This would save the lag time of establishing the connection to our system with every call to the web service. I’m just not sure if this is the normal way of handling such a transaction. I was thinking this might be the wrong approach because I believe EJBs can perform the same function as the RMI Service but I’m not very familiar with EJBs.
I just want to say that I have been part of developing a system that kept RMI connections open for a long periods of time and it worked well.
We did have a mechanism for re-establishing lost connections, which you may want to consider.