The concept of Asynchronous Web Service is a web service where the client does not have to wait to receive a response from the server. in AJAX this is implemented by having a callback function to process the response. So the server indeed still sends the response to the client.
Is it possible to have an Asynchronous Web Service without response? Is there any platform that provide this?
Thank you.
I have done asynch web services in the past. They are very useful. YOu do not need a detailed response but you at least need an HTTP response, like 200 OK. If the client that makes the request provides some sort of ID or key for that request, then the client can use the same ID/key to later on query for the result/response of the request.
As far as frameworks that provide this, I do not know of any. In the past I would just have a shared memory store, like Memcache, to store the state and result of the request. As long as the state is shared across all nodes, any node can then process the call back request.
EDIT: Providing a key in the request can be done in either REST or SOAP environment. HTTP provides multiple places where a key can be communicated.
GET query param (REST)
HTTP header (SOAP/REST)
Added to the message body of a POST request. This can be done through two ways.
param in the message body (REST)
variable or attribute in serialized object (SOAP/REST))
Related
I will be happy to get advice from more experienced developers about adding Web Sockets into my HTTP-based project.
That’s the thing. I have developed the REST API based service. Everything works well enough, but… In some special cases my server needs a long time to serve client requests. It may be from 1 minute to several hours (and even days)! I implement some not-so-good algorithm to address this issue:
Client sends HTTP request
Server replies about registering request
Client starts sending HTTP requests to get necessary data (if response does not have needed information the client sends another request and so on)
That is all in a nutshell.
And it seems to be a bad scenario and I am trying to integrate web sockets for adding duplex-channels in this architecture. I hope that my API will be able to send info about updated data as soon as possible without the necessity of many requests from the client.
But I am a bit confused in choosing one of two ways to use web socket (WS).
Variant A.
The server only tells the client via WS that data is ready. And the client gets data by standard request-response HTTP method from REST API.
Variant B.
The server sends all data to the client via WS without HTTP at all.
What variant is more suitable? Or maybe some other variants?
I do not want to remove HTTP at all. I just try to implement WS for a particular kind of end-points.
Variant A would be more suitable and easy to implement. You can send message to the client after the data is ready, and he can then send request for the data. It will be like a simple chat websocket, and will serve your purpose.
I am working on an application that I want to use to catch a SOAP request when it goes into the CXFServlet. There is some processing I need to do to the SOAP envelope on the server side, before the CXFServlet processes it.
I have been presuming that the SOAP envelope, once it reaches the server side, is one of the parameters in the HTTPServletRequest object. But looking at what comes in (using a debugger, of course), I cannot find it.
Can someone tell me where the SOAP request goes when a client sends it to the server? I know that the client is sending the request using an HTTP POST, and I know that the server is using information in the request in order to access the appropriate web service method, then placing any return values from the method into a SOAP response and returning it to the client. What I need to know is where where does the CXFServlet (or one of its filters) look in order to get the SOAP information? Is it somewhere in the parameters? In the servlet context? Does a filter process the SOAP information before it gets to the CXFServlet? How can I get that envelope and do things to it before the web service method is called?
Someone please advise...
Do you want to access the original request ? If yes the actual request or response object itself can be accessed using the WebServiceContext object.
First, declare a private field for the WebServiceContext in your service implementation, and annotate it as a resource
#Resource
private WebServiceContext context;
Then, within your implementing methods, you can access the MessageContext, HttpServletRequest, and HttpServletResponse as follows:
MessageContext ctx = context.getMessageContext();
HttpServletRequest request = (HttpServletRequest)ctx.get(AbstractHTTPDestination.HTTP_REQUEST);
For more info about WebServiceContext see the following url :
http://docs.oracle.com/javase/6/docs/api/javax/xml/ws/WebServiceContext.html
If you need to intercept the request before it is ever processed by the CXFServlet, you should look at developing a Servlet Filter.
If you just want to process the SOAP message before CXF does, you can likely use a CXF Interceptor. The phases noted in the documentation indicate the points you can intercept the message. Depending on what you want to do/change, you may need to play around with the phases.
The source for CXF's SoapHeaderInterceptor or SoapActionInInterceptor would be good places to start looking at how to work with the SOAP message.
Suppose that I have Apache/lighttpd or whatever to receive http requests. Now I want the web servers to act as a proxy for my web services running on internal servers written in Java/Clojure/Erlang?
What I want is to separate the layer that handles client connections and the server that handle application logic. These two should be separated and language independent. Is JSON or XML the format for communicating? If so, how do I perform it from the web servers?
Note: May be I missed the point of your question in this response. Pls do let me know if that is the case.
I dont think you should consider this as "forwarding" of the original request.
If your web-tier that receives the original request makes a call to one/more underlying services (thru HTTP or otherwise) it is part of the "processing" of the original request.
So, there is nothing different here than what you are already familiar with.
i.e You make a HTTP request in place where you would make a SOAP/XML request or a DB call or post a message.
When you say or think in terms of "forwarding", it is misleading.
Also, the data exchanged between your controller and services is solely based on your convenience.
It could be XML or JSON or regular POST parameters that gets sent over HTTP transport
I am just getting started with SOAP web services and stumbled across WS-Addressing.
I have read the Wikipedia page, but I'm having a hard time understanding just what the point of WS-Addressing is.
According to Wikipedia and various sources on the web, WS-Addressing allows to put "addressing information" or "routing information" into the header of a SOAP request.
Why is this useful? If I send a request via HTTP (or even via SMTP or UDP), then the address I send to is the address of the server which will process my request, and the server can simply reply by the same channel. So why is addressing/routing information needed?
I'd be particularly interested in some real-world (more or less) example where WS-Addressing is helpful.
I've found WS-Addressing particularly useful in situations where the SOAP response can't be served immediately. Either the resources to form the response are not available right away or the result itself takes a long time to be generated.
That can happen when your business process involves "a human touch" for example (processes like the ones WS-HumanTask is targeting). You can stick web services in front of your business, but sometimes business takes time. It might be a subscription that must be manually verified, something to be approved, whatever, but it takes days to do it. Are you going to keep the connection opened all that time? Are you going to do nothing else than wait for the response? No! That is inefficient.
What you need is a notification process. The client makes a requests but does not wait for the response. It instead instructs the server where to send the response by use of a "reply to" address. Once the response is available, the server connects to that address and sends the response.
And voila... asynchronous interactions between web services, decoupling the lifetime of the communication process from the lifetime of the HTTP connection. Very useful...
But wait... HTTP connection? Why should I care about that? What if I want the response sent back on another type of protocol? (which SOAP kindly provides as it is not tied to any protocol).
With normal request/response flow, the response comes on the same channel as the request 'cose it's a connection you know.... So for example you have a HTTP connection... that means HTTP in and HTTP out.
But with WS-Addressing you are not tied to that. You can demand the response on another type of channel. Request comes on HTTP for example, but you can instruct the server to send the response back over SMTP, for example.
In this way WS-Addressing defines standard ways
to route a message over multiple transports. As the wiki page is saying:
instead of relying on network-level transport to convey routing information,
a message utilizing WS-Addressing may contain its own dispatch metadata in a standardized SOAP header.
and as for your observation:
and the server can simply reply by the same channel
... what works for some, might not work for others, and for others we have WS-Addressing :D.
I am a new to Axis2 and SOAP. I recently working on a Axis2 SOAP project, I have create a SOAP server and SOAP client by using java and axis2 implementing session scope. The problem is when I send a request, it returns response back only once. I am unable to make web service keep publishing data periodically untill the session end. Can any body help me...
Thanks in advance
I might be wrong, but I think since you work with HTTP you can't make the
response permanent until you make your client perform calls permanently / periodically.
Permanent Requests --> Permanent Responses
I echo KB22's response - HTTP has a request-response flow, so your service is receiving a single request and sending back a single response. Implementing session scope means that you have a logical session for multiple request/responses to be tied together. You have a few options here:
Make the client wait until you have all the data to send back in one response. However, if this takes too long you may well get timeout issues on the client.
Change your model, so that you send in multiple requests and get back the data in pieces.
Change your model to a polling style, where you keep sending requests (and receive empty responses) until all the data is ready to be sent back.
Change your protocol to something that is asynchronous (e.g. JMS) so that you send in a request to a queue and at some later time the response turns up on the queue for your client to read.