I haven't tried this technique on the client, but it works on the server, so it may be worth a try. The best place to use it is probably in a handler.
Joined: Jan 11, 2001
Unfortunately both the solutions did not work out. Using the getProperty on the client simply returns null. hence cant derive any status code from the response.
In the meantime I have been also muling with WSRM protocol using Sandesha2 on top of Axis. This seems like a solution on the basis that that web service I will be consumed is developed to support WSRM but unfortunately this is not the case. So back to the drawing board on this one
Originally posted by jack nick: I need to write a client in JAVA calling an async web service and all I need to capture is the HTTP response status.
Given that you are using SOAP what information is in the HTTP response status code that can't get out of the SOAP response?
i.e. what is the actual problem that you are trying to solve, rather than your current solution that is running into a problem. [ April 29, 2008: Message edited by: Peer Reynders ]
Joined: Jan 11, 2001
thanks for you post. The problem I am facing is since I am making an async call I do not get a response. using the following axis execute call on the operation client object
As a result I do not get a SOAP response back (I do not know whether this is meant to send a response back). I am assuming this call is made over HTTP and hence need to capture the response code (either 200 or 202 to tell the client that the message being sent across was accepted by the server or a 500 where it was not).
would help stop the graying of my hair should I get his answered.
Joined: Aug 19, 2005
is only half of the story. It simply states that you want a non-blocking call (OperationClient). Depending on configuration the SOAP call may still happen synchronously - in a separate thread. In that case there isn't an HTTP response code because the HTTP request hasn't completed yet.
To support true asynchronous SOAP, both server and client must support the WS-Addressing specification which means that the client must provide an endpoint URL that the server can deliver the asynchronous result to (i.e. the client must be a web service itself).
Thanks for that Peer, those docs were sure helpful which brings me to a conclusion I am a total novice at web services and in particular how the axis configuration works.
perhaps you could guild my direction a bit further.
my project requirements are for me to publish a few of our process as web services. for the most part a client would get a call, our service does a bit of processing and we send back a response. standard sync all. no probs here.
one of the process though is for the client to sent a file as a SOAP attachment. This file is used to trigger off an end of day process (which takes about 45 mins). so we are not sending any response back (at all). But would like the client to be sent an acknowledgment to the effect that their SOAP message was received at our end. (Would I be calling this async???)
Would need to create a test client as well to consume this.
Wouldn't it be simpler to define the service as sending a simple response - perhaps the byte count, checksum, or similar confirmation that the attachment was intact?
Joined: Aug 19, 2005
Originally posted by jack nick: ...so we are not sending any response back (at all). But would like the client to be sent an acknowledgment to the effect that their SOAP message was received at our end. (Would I be calling this async???)
As Bill has already pointed out it seems a bit peculiar that you don't simply accept the request and immediately return a reply to the client acknowledging receipt of the "document". I hope that the lack of response isn't due to the fact that the web service is running the ~45 min process itself without completing the request because that would be an anti-pattern in itself.
Basically you should be implementing a Producer/Consumer (Blocking Queue shows a simple Java version). The service instance created by the arrival of the SOAP request should act as a "Producer" and simply place all the request information on the "Queue" and then simply complete the request by responding with an "accepted" response document. It is the (separate) "consumer" that then takes the information off the queue to initiate or run the actual "process".
So maybe this wasn't a problem related to HTTP response codes at all?
If you need to send a response after the process has completed then WS-Addressing is certainly one option - however this is basically server to server communication as the service provider has to expose a public HTTP endpoint for the service consumer to send the initial request to AND the service consumer has to expose a public HTTP endpoint so that the service provider can return the asynchronous result back to the service consumer. Inside the same firewall this isn't a big issue - however when both systems have to hide behind their respective firewalls the networking department of the service consumer may not be all that thrilled if they have to move a separate public HTTP endpoint into their DMZ - effectively increasing the organizations attack surface. This then leads to situations where some organizations will expose one single endpoint URI for all possible service consumers behind the firewall - additional information in the addressing headers will be required in order to route the result to the correct recipient.
One option is to send a completion response through a separate communication channel. 8.4.3 Refactoring Synchronous to Asynchronous interactions shows the use of JMS. You can just as easily use SMTP (email) - as long as you realize that email is neither reliable nor secure (by itself). In that case you can give your client in your "SubmitEndOfDay" request document the option of specifying an email address for the completion response. Furthermore that completion response could be human readable (e.g. plain text) or machine readable (e.g. XML, XML-in-SOAP, etc.), again selectable in the "SubmitEndOfDay" request document.
A more conventional approach is to fake asynchronous communication through synchronous calls from the client with "Pattern 3: Request/reply operations with polling" as described in Asynchronous operations and Web services, Part 2. This approach requires that you include a correlation identifier in your response to their initial "SubmitEndOfDay" request document. The client can then include the correlation identifier in a "EndOfDayResultQuery" request document - for a valid correlation identifier your response document will simply indicate that the results are not available yet or it will return the results of the completed process. You will just have to get to some kind of agreement with your clients that they won't be banging away at your endpoint with "EndOfDayResultQuery" documents at every second.