I have a service layer which is calling a webservice. The number of requests generated by the service layer could potentially be very large and i want to build in some contingency in case the volume of requests becomes to much for the web service to handle. I know i can add some exception handling which can tell if the request failed or not however i don't want to keep hitting the service if its down or struggling to handle the requests.
How can i tell my service layer to stop making calls when the service is unavailable and then resume once its active again? I know this can be done manually using a file containing a flag which the service would check before making a call to the webservice. This flag could then be updated whenever the server goes dowm, however i would prefer something automatic.
Thanks,
I think it is easily could be done with interceptors. Just make your own interceptor and implement the logic in here.
Related
I am migrating a Spring2 SOAP service to Spring 5. in the old code, if I called https://server:port/myservice/services/myserviceendpoint from a browser, it would display a page stating "And now... Some Services"
The spring-ws doesn't do that. unfortunately one of the client apps uses that page to determine if the service is up.
How do I mimic that behavior?
It's a matter of handling HTTP requests the same way Axis does. Normally, you have to deal with three combinations:
GET /myserviceendpoint
GET /myserviceendpoint?wsdl
POST /myserviceendpoint
Your SOAP service works with POST, so you have that covered by the service itself. All you have to do is create an URL mapping for GET and return the response expected by your client. If it's a plain GET, you return HTML with the "And now... Some Services". If the GET has the ?wsdl parameter, you should return a WSDL for the service. Obviously, you will need to replicate whatever else content the client is expecting.
With that being said, is there a way for the client to stop doing that? They are using something dependent on the implementation. That Axis page is there just to test everything is set up properly. Normally, it shouldn't have been exposed to clients, let alone the clients using it to make sure the service is up.
If they want to make sure the service is up, then, while you are migrating this service to Spring 5, what you can do is add another operation in the service, something called <ping> that responds with a <pong> or something. Basically, to offer an operation on the service that can be called with no side effects to see if the service is up. Since this is a new operation, it's a non breaking change (for both the service and the WSDL) so it's safe to add. Then clients can have something to use instead of relying on other mechanisms offered by your code implementation .
I have a service that is dependent on several resources.
This service has a initialization logic that checks if these resources are up and running, and starts / stops the service accordingly.
The problem is, that other services are addressing my services via REST while it is loading. It then tries to reply (in a different thread), and when it does, it tries to connects to one of the not-yet-available resources and crashes.
Is there a way to 'lock' the service while it is loading so that any request coming to it from the outside will return 'Service not available' while it is in its loading process?
There are many requests to the service and I don't wan't to add a 'check resource status' logic to every method that handles an HTTP request. I want to be able to block all requests and the unblock them when all resources are up.
Any help will be great. (I'm not very familiar with Spring yet).
Assuming these resources get initialised asynchronously, you can write a Filter or an Interceptor to filter the request and retuen 503 if the resources are not loaded.
Here's an example of how to configure a filter. You can even write an Interceptor if you want to do handle/intercept the requests at resource level (example here), however, as you want to filter all the incoming requests, I would recommend going ahead with Filter.
I have a client application which accesses a web service api using apache axis.
My client is a service which calls the web service randomly. So I do not know when exactly the interaction happens.
I want to keep the session active betweeen the web service calls.
I am thinking of having a seperate thread which periodically calls a dummy method so that the session never times out? is this a right idea or does it have any draw backs?
Another way is to relogin when ever a "session timed out" exception is thrown while accessing the webservice. But since many objects can interact with the web service this will create new problems like synchronization to be handled.
I need to implement a Java web service (on websphere) that in turn calls N other web services. I don't want to make it blocking so I was thinking in implementing a thread for each WS it call. Are there any caveats being a web service the parent of the threads ? (The use of a queueing technology for this solution is not an option).
Thanks
it is certainly doable. the only real caveat is that you are going to have to
1) make sure that all the information the threads need gets passed in. Depending on the technologies you are using, information gets bound to the current thread via ThreadLocal, so you need to make sure the children have everything they need.
2) Coordinating the responses. Might not be an issue, but if you need to coordinate the responses you will need to do something. Also, when the original web service call gets invoked, can you return a response immediately or do you need to wait till the other webservices are invoked?
3) Error conditions. If one of the child web service calls fails, what do you need to do? That depends on your requirements.
Note that invoking N webservices calls shouldn't take too long if N is small. I would try it synchronously before going thru the pain of getting an asynchronous solution, unless you are sure up front that this is not an option.
Does anyone have any insight into transaction options available over web-service calls?
1.) There are two applications that we have that need transactional communication between them.
2.) App1 calls a web service on app 2 and then makes some changes to its own db. the call on app2 and the changes to it's own db need to be co-ordinated. How can we do this? what are the possible options ?
You make the webservice call and if its successful do change in your own DB. If changing your own DB fails then call the webservice to revert the changes done in earlier call. For this to happen the webservice must provide the revert functionality.
For example, the webservice have createUser function then they should have deleteUser function.
It depends what technology stack you are using. In .Net WCF offers transaction features, otherwise the only thing that you can do is minimize the timespan an error can occur.
In previous applications, I've given the service a token to the web service. When the service returns (sync or async) it returns the token. The token has an embedded timestamp. If the timestamp has expired then the transaction is aborted, if not I assume the web service call was successful.
After successful return of the webservice call, the NEXT method call is to record the transaction within your system. This creates a very small window where the system behind the web service and your system will be out of sync. It also lessens the chance that an unexpected error will occur that will prevent the update/insert on your side.
You could try Atomikos ExtremeTransactions. It includes support for WS/SOAP transactions whose rollback spans multiple sites.
Guy