I'm writing an API in WCF 4.6.1. The client(s) will not be written by me, and will not necessarily be in .NET (they could be in any language/platform).
There is a web method which does something that can take a long time, so I want to encourage the client to call it asynchronously. I know that the client can be written to treat the web method as async (threading, etc), but is there a way of "enforcing" the actual web service as an async operation? i.e. Does WSDL have a way to saying "this is an async method"?
Does WSDL have a way to saying "this is an async method"?
No it doesn't. The communication between the client and the service is synchronous even if the client thread does not block while that call is taking place. This is to say the invocation is asynchronous not that the web service method is asynchronous.
If you provide good documentation to say that for a particular operation it's advisable to use a separate thread because the response is slow to be generated you should be OK. Clients need to be built and the integration with the web service tested. The developers will notice the slow response and they will decide if they need to make the call in a non blocking way. Even blocking might be a solution for them, you never know, what you consider slow other might have no issue with.
If you want to "force" clients to not block for the response you could use for example WS-Addressing (I'm assuming here that you are using WCF for a SOAP web service) where your client provides a callback endpoint that you can invoke when the response is ready. This complicates a bit the client since it needs to have a receiving endpoint now. But a client developer might prefer to chose how she invokes the service (in a blocking/non blocking way) as opposed to having to implement the WS-Addressing spec.
Related
This is surely a weird one ... I'm doing some extreme integration style testing on a custom Java HTTP client for a backend service I'm working with. For reasons which don't matter here, the client has some specific quirks and a custom solution was the only real option.
For automated testing, I've built a "fake" version of the backend service by spinning up a Jetty server locally and having it behave in different ways e.g. return 500, wait e.g. 4 seconds before giving a response to simulate latency etc and firing off a battery of tests against it with the client on build time.
Given the nature of this client, there is an usual and specific scenario which I need to test and I'm trying to find a way to make my Jetty serve behave in the correct fashion. Basically, when returning HTTP response, I need to immediately return the HTTP Headers and the first few bytes of the HTTP body and then sleep. The goal is to trigger a socket timeout in the client specifically when reading the HTTP body.
Anyone know where in Jetty I could plug something in to force this behaviour? Was looking at the Connector interface but not so sure thats the right place.
Thanks for any suggestions.
Write a few bytes to the HttpServletResponse.getOutputStream(), then call HttpServletResponse.flushBuffer() to immediately commit the response.
Bonus tip: use HttpServletResponse.sendError(-1) to terminate the connection abruptly.
In restful web service I read something like below ,
"The constraint to the client-server interaction is that communication must be stateless. The server should not be relied upon to maintain application state by storing session objects."
so does it mean in SOAP web services the server saves the session with them ? I have used soap user interface tool for testing the soap services in which i will be sending the request XML with all the parameters and will be getting the response, In which way restful web services differed in terms of statelessness from Soap ?
No it does not mean SOAP is stateful in all cases. Typically you design all services as stateless. Having stateful services either in SOAP or REST introduces complexity which creates all sort of problems.
However some people implement both SOAP/REST services with state and they normally aren't very successful. Maintaining state requires both the server and client to be aware of and track the current state.
So in short the principle remains never store state in a service. When calling an operation it should either return a success or failed code, it should not remember that the last operation for this client did not succeed.
Also while REST says services should be stateless you can implement it in a stateful method. Never ever go stateful it creates a lot of confusion for service consumers i.e. the client. Think about it this way if an operation is stateless you can call it and get repeatable results however if it is stateful an operation might change the results based on the state.
Also stateful operations limits scalability as it has to remember more.
I am doing some research on SOAP, for a personal project, and I came across a website with a list of pros and cons for using SOAP, and I understood what most of them meant, except for this one under disadvantages:
SOAP is typically limited to pooling, and not event notifications, when leveraging HTTP for transport. What's more, only one client can use the services of one server in typical situations.
From my understanding of pooling, there should be no issue pooling a SOAP Object for re usability. Pooling is simply a way to use the same resources over and over again, like a connection to a database. Also not entirely certain on the context of Event Notifications.
So my two questions here are, what does the above block quoted text actually mean, and is this information correct?
Website: http://searchsoa.techtarget.com/definition/SOAP
SOAP is RPC, and in RPC some local client invokes a method on some remote target and receives a result. That's how it works, so SOAP works that way too. A client invokes a service asking for something and the service just responds.
If you want "events" in this type of communication the most simple approach is to invoke the service more often (i.e. polling). This has the advantage that nothing changes for the server or the client. It's the same RPC call but done more frequently.
These days everyone is connected to the web and everyone is subscribed to all sorts of services. They want to get notified as soon as something happens to the world around them. Pooling becomes inefficient in this sea of users and services because you are wasting resources. You might poll a service a hundred times just to get back one notification. For this reason technology is evolving so that resource use is minimized. And the direction this is moving to is push services.
Now almost everything happens in the browser. Every browser manufacturer rushes to implement the latest technology changes and HTML5 spec. This means actual pages that push notifications to users instead of faking it with Ajax, comet, etc.
SOAP has been around since 1998 and it's not moving as fast as the rest of the web, mainly because SOAP is mostly an enterprise player and because it's a protocol. Because it's a protocol you have to make new technology available to it without breaking that protocol. Things move slower so people have abandoned SOAP in favor of other ways of doing server-client communication.
SOAP is typically limited to pooling, and not event notifications...
That is correct. But be aware that "typically" does not mean "always".
You can have events, but it's harder. It involves using WS-* specifications like WS-Eventing and WS-Addressing. This is a change in the way SOAP clients operate because a client now becomes some sort of a service too because it needs to receive calls too, not just initiate them. If your technology stack implements these specifications then good for you, but if it doesn't, then you have to build it yourself and it's a real pain.
So for these reasons, if you don't have blocking performance or resource usage issues, you "typically" chose doing polling with SOAP and not event notifications.
I need to invoke a long running task via a SOAP web service, using JAXWS on both ends, specifically, Apache CXF 2.6 on both ends.
I see that I can enable async methods in the CXF code generator, which creates two async methods per operation. Because of NAT issues, I cannot use WS-Addressing and callbacks. So I may want to use the other polling method.
I need to be sure that there will be no socket read timeouts using this mechanism, so I want to understand how it works.
Is it the case that a SOAP request is made to the server in a background thread which keeps the same, single, HTTP connection open, and the Future#isDone() checks to see if that thread has received a response?
If so, is there not a risk that a proxy server in between may define its own timeout, and cause an error if the server takes to long to respond?
What do other people do for invoking long running tasks via SOAP?
Yes, it would just keep checking the connection until a response is received. If something occurs between the client and server and the connection is lost, the response would not be retrievable.
For really long running things, the better approach would be to split the long running into two methods. One that would take the input and launch the work on a background thread and just return some sort of unique identifier. A second method would take that identifier and return the result. The client could call that method to kind of poll the server. That could be long running, and block or use the async methods or similar. If THAT requests times out, it could just call it again.
I am a total newbie in CORBA. I have written a simple c++ CORBA CLIENT and a CORBA SERVER. I would like the client to ask a status from time to time from the server. However, I have no idea how to do that and my google searches give me no luck. Can anybody tell me how to perform polling of client to server? or perhaps how to catch notifications from server
The ability for a CORBA client to call/poll a method on a server is about as simple as CORBA development gets, and it's usually covered by the "Getting Started" section of an ORB's documentation. Here's a C++ Hello World example online for both a client and a server.
If you want the client to call the same method periodically, it's up to you as the client programmer to make that happen. You can put the client calling thread to sleep for some time between calls, set the client process to be launched on a regular basis by cron, whatever you prefer. CORBA won't initiate remote calls automatically for you. You have to instruct the CORBA layer to call the server on your behalf.
In addition to the answers above, you could also use the CORBA event or notification services to receive asynchronous notifications from a remote server to avoid polling.
And aside from polling, much more often client would provide object reference to one of its objects, and server would invoke a call on that object when something happens. That way polling could be completely avoided.