I am trying to develop a B2B integration using soap rpc where the client sends a soap request and waits for response on the same https session.
I process the request and send the response on the same session.
I want to handle the situation where the session timesout. What happens in such cases? And how should I handle it? How do I even know that the session has timedout. I need to handle it because if the session has timedout I have the persist the response and try sending it later.
Why do you think your session might time out? In a typical synchronous web service interaction the client would just try again on timeout and not expect the service to attempt to deliver the results later.
If you want to build an ansynchronous web service, you would return an acknowledgement containing a unique request id on the initial call and then allow the service consumer to use that request to poll for results or push the results to them using an outbound post.
I do some transactional processing on each client request. Now if on timeout the client retries, my processing for that requst is already done in the timed out call and it would fail now.
And why shoudl’nt i use soap-rpc. Are there any downsides??
The downsides of soap-rpc vs. soap document/literal or soap-msg have been discussed at length here. Use the Advanced Search to search the Web Services forum.