I have created a Rest based web service Using jersey. I want to make it Asynchronous web service using polling mechanism. I want to know the service side implementation.
Requirements on the web service side:
Create request tokens and send it to client
Manage the tokens
Send response when client requests for the response using this token
Run the the service business logic in different thread
I am not finding useful posts and code snippets. Everywhere the mechanism is discussed but how can we implement this?
Related
I am developing banking mobile apps using html5 for client as communicate back-end system they provided soap based xml services.
To make a soap request, i doesn't want to write code in ".js" file because of code complexity and not found request and response logs in production phases.
now i want to make separate project to maintain the web-service request and response business logic using java?
from .js, I want to make a http request to call the web service as a response i want to get json an object?.
Please correct me if i was wrong, Please help me how to separate web service logic into a single project?
Note: I doesn't want to configure my soap request through js file.
Regards,
nag
Write a servlet or httphandler(if IIS) that interacts with SOAP services and parses the information and creates a json response for the JS client.
You JS client interacts with servlet/httphandler and handles when it json response when it receives it.
I know that there are two types of web services called asynchronous web services and synchronous web services. What I want to know are
1.
Can I identify whether a web service is asynchronous or synchronous by inspecting the WSDL of the service? Or is there any other way such as inspecting the generated stub etc?
2.
Can I develop an asynchronous client for a synchronous web service? Does it make sense?
Thank you.
I'm not an expert, but I'll give my two cents and hope that you find this useful.
Well I assume that it depends. You can have an asynchronous architecture with no signs of it. Someone could implement the following
The client makes a request to the service.
The service responds with a success or error message just to indicate the status of the request.
The service begins to process the request.
The service makes a request to another endpoint. This request is the actual response for the first request.
The service get a response, that the message was received successfully.
This is an asynchronous architecture. The service (actual service) when finished sends the actual response to an endpoint. This endpoint is actually the client that sent the first request.
This endpoint, the one that the client is listening to, for the actual response can be predefined (hard coded), or can be included as a parameter (callback) in the first response. If the case is the latter, then I guess you could deduce that this is an asynchronous web service.
For the second part of your question. Yes you can. Check this Asynchronous web services calls with JAX-WS: Use wsimport support for asynchrony or roll my own? and this http://cxf.apache.org/docs/asynchronous-client-http-transport.html
Can someone please let me know if we can use Restful web services or something similar to that to service HTTP requests without using a web server
All the Http requests are processed or identified by the servlet or ejb component in java.
1.We must deploy restful services server side code in webserver otherwise we cannot expose our functionality over the network
2.To access the rest resource we can use normal java program or any servlet or other.
3.Without using webserver you cannot expose your rest resource over the network at serverside.
I'm not completely clear on one thing and am hoping some one here will probably answer this.
I worked on an enterprise application where we had a Java app consuming services with a WSDL interface in between and a .NET application on the other side producing the services.
I have been reading RESTful webservices where jersey API is used to route a request through a jersey servlet to an URI that eventually talks to a Java class to send the data back.
I'm not able to understand the point where diverse applications like .NET and Java can talk through a REST interface and how for this particular scenario Rest is useful.How does Rest work in this case?. for SOAP there is WSDL, what about for REST assuming a Java app is consuming from a .NET through a Restful service. Please explain how it works.
Thanks in advance!
Both REST and SOAP use HTTP for communication. Requests are sent over the wire using the HTTP protocol from client to server. The server replies using the same protocol. As long as the client and the server both send information using HTTP, it doesn't matter what language the client or server are written in.
RESTful APIs may use some combination of WADL, HATEOAS, and documentation to reveal their API to clients.
Currently I'm doing the integration work of one project. In this project, we need to expose a restful api with java framework Wink. Since we have several other components to integrate, we put a message queue(activemq) between the api layer and other service parts.But this time the api layer will communicate to the lower level in an asynchronous way. In my understanding, the restful api should run in a synchronous way. For example, in the api layer, if one thread received a request, the response will get returned in the same thread. So there is a internal mismatch between these 2 communication styles. My question is how can we integrate these 2 parts to make the api layer work without sacrificing the features in message queue like reliability and performance?
Any suggestions will be apprciated here.
Thanks
Asynchronous callback is possible in REST communication, see this JERSEY framework example:
https://jersey.java.net/documentation/latest/async.html
But yes the latency should be controlled as your client would be waiting for server to respond, and would be good if client calls it in AJAX way.
Simplest way would be to fork a new process through "executor service", which sends a message in a channel to lower level api and listens back for response in another channel(MQ communication). And on process completion return a response, which then the higher API will push back to client.