I have a cpp based soap application which supports multiple sessions. It follows this sequence
Create a new session. This returns a new session ID.
Make further requests on this same client to do some work which uses same process but unique thread assigned to this client will intercept these calls.
Close Session by providing the session ID. This will clean up the thread.
Now this is working fine when I'm using a cpp based client which creates a soap client like this
soap_init2(&soap, SOAP_IO_KEEPALIVE | SOAP_C_UTFSTRING, SOAP_IO_KEEPALIVE | SOAP_C_UTFSTRING);
Creats a session does some work on it and ends the session and finally calls
soap_destroy(&soap); soap_end (&soap); soap_done (&soap); // Cleanup soap context
to perform the cleanup of the client. But I want to achieve same thing using a node-js server/application for that I used node's soap module. Basic things seems to be working as well. For example I was able to make soap requests to the server for create session and some other tasks. But when I try to use the same session again my cpp application's worker thread is not intercepting these calls but every-time these calls to go my root session(the thread that initiated the soap server/or which initiates new sessions). Hence I'm not able to use the session management provided by the soap server.
Here is how I creates soap client.
const wsdlOptions = {
"envelopeKey": 'soapenv',
"disableCache": true,
connection: 'keep-alive'
};
soap.createClient(url, wsdlOptions, function (err, client) {
if (err) {
// Return job failure. As this is due to an SOAP client error, let us restart.
logUtils.log('SOAP Client creation failed.')
messenger.jobError(sessionID, jobID, true, Errors.CLIENT_CREATE_ERROR)
return
}
Basic communication is fine. My main problem is that post create all the function calls I make on this client should be treated like they are coming from same soap client so that cpp server can serve them on right session. Any suggestion how to mimic the client support provided by cpp-soap api's
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 have a CPP client application. As part of client application, I will send a message in encrypt format to http server which will available as part of another server application.
Currently, server application is not yet implemented. But I want to test the client application by running it and I want to verify the response.
What are different ways to run the client application to verify the response without having server? Please help me.
Thanks.
Create a small server in local that returns the value who received it.
If you are verifying the response from the server it sounds more like you are unit testing the server instead of the client. Or like an end-to-end test.
If you do want to unit test your client application and you have a separate class that handles the communication, you can mock this communication class and return a hard-coded response. Use this to test if your client handles this response correctly.
If this is not possible you can run a mock HTTP server, as #yumetodo suggests, in a separate process or thread. httpmockserver seems to provide such a server.
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))
I have a standalone web-service client. When invoking any of the web-methods an additional "cookie" string must be implicitly(not as a web-method parameter) passed to the WS. The WS on the other end must be able to obtain the string and use it. How can this be achieved?
I invoke the service in the following way:
Service srv = Service.create(new URL(WSDL), QNAME);
myClassPort = srv.getPort(MyClass.class);
What I need is to put some code before the first line, which would make the client send this "cookie" string every time I invoke some remote method via myClassPort. Thx.
By default JAX-WS web services and clients are stateless. When a client makes a request, the server responds and sets a cookie on the connection, if it participates in a session. But, the JAX-WS client ignores that cookie and the server treats subsequent requests as new interaction. When the session is enabled, JAX-WS client sends the same cookie with each subsequent request so that server can keep track of the client session.
So you should not be using either cookies or HTTP sessions with web services. Return a token ID as part of the response; then the client can send that along with the next request.
Anyway:
JAX-WS web service clients must be configured to maintain session information (such as cookies), using the javax.xml.ws.session.maintain property.
Other web service stacks may have similar mechanisms.
On the Server Side
JAX-WS uses some handy annotations defined by Common Annotations for the Java Platform (JSR 250), to inject the web service context and declaring lifecycle methods.
WebServiceContext holds the context information pertaining to a request being served.
You don't need to implement javax.xml.rpc.server.ServiceLifecycle. With JAX-WS Web Service all you need to do is mark a field or method with #Resource. The type element MUST be either java.lang.Object or javax.xml.ws.WebServiceContext.
#WebService
public class HelloWorld {
#Resource
private WebServiceContext wsContext;
public void sayHello(){
MessageContext mc = wsContext.getMessageContext();
HttpSession session = ((javax.servlet.http.HttpServletRequest)mc.get(MessageContext.SERVLET_REQUEST)).getSession();
}
}
There are some misleading answers to this question, so I will attempt to highlight current best practices. Most of these suggestions are part of the OWASP security guidelines, which I strongly recommend anyone working on web development to review.
1) ALWAYS use temporary (session scoped) cookies.
2) All cookies should be protected and encrypted.
3) Do not pass tokens in request payloads
4) For any requests which return data that may be sent back to the server, include a nonce (single use token) in your responses.
5) later requests should (must) include the nonce and the cookie
Again, my recommendation is to review the OWASP guidelines and proceed accordingly.
You may want to look into using a service provider for authentication - this is much smarter than brewing your own solution as there are literally a million details that all must be correct. Auth0.com is one of these.
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.