Win a copy of Classic Computer Science Problems in Swift this week in the iOS forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Webservices Client Retry Mechanism  RSS feed

Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a general design question ,we have some webservices and their clients which post some data to webservices. This whole process is triggered when user clicks somebuttons during screen flow. But the whole thing is asynchronous ie we just need to trigger the clients and after that the flow doesnt bother about message delivered to webservices immediately or not.(but eventually it must be delivered at some point of time)
If the services is up and running posting this client request to webservice is stright forward, however if the webservice is not available some reason then the ideal mechanism is kind of generate the soap request message and que them and post them to the webservices when it is available , and for obvious reasons we need to make sure that we keep trying theoritically forever till the service is available again.
We are just trying to come with some common frame work which we can use across all our applications which talk to webservices. One idea is to use a JMS server and as soon as we generate soap message we que them in JMS server and a local client which is polling on to this JMS server que tries to post messages (if available)to the webservices if it is successful it will clear the message from JMS server otherwise it will not clear and this process repeats for ever.
Is there any other simple model/framework/mechanism is alreay in place to asynchronously sending soap requests ? and at the same time ensuring that eventually the message gets delivered.?
I heard some message servers even allow us to configure to post to a http client so that we can directly configure the server to post to the end webservices leaving the posting business to the jms server it self , but at the same time ability to post to http clients it is not mandated by JMS specification ? so we may loose the ability to port our code to other jms servers ?
Any ideas comments ?
Thanks in advance.
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!