A client connects to a JAX-RS Endpoint to retrieve data. This endpoint uses an EJB to access the database and perform logic then returns the data to the endpoint.
Client <----> Rest Endpoint <----> EJB
Before data can be returned to the Client, I need to pass data to another Endpoint instance (another Client that is connected to this Rest Endpoint). I would like to keep this a REST Service but I'm faced with two problems:
REST Endpoints are stateless. So no Sessions are linked with an endpoint. However, this could be fixed with context injection (not as efficient) or passing a userID as a parameter.
No Communication method. There's WebSockets but how would that help me communicate between Sessions on the server? There's JMS but from my understanding that works from application to application not Sessions.
What I'm asking: Is there a way to communicate between different REST (or EJB) instances/sessions? If so, how?
You would have to persist sessions to some external storage (like Redis) and pass the session identifier with each request between various system components. When such request is handled, you could load session state from the storage and proceed accordingly.
Most of the EJB/Servlet containers allow you to turn session persistence on.
Related
There are 2 web services A and B to communicate with each other and external system.
Information
A consumes many different data from external system periodically. (each data separately)
Also, clients send some data to A.
A is sending the data to B.
Communication is over the SOAP according to wsdl.
Written in Spring Boot/Java.
What I tried
Implemented micro services structure basically for load balancing such as Registry Service (Netflix Eureka) and API Gateway (Netflix Zool).
Integrated A service with registry service.
Created 2 A service for load balancing.
Tried some examples on it.
At this point;
How can I set up a Master/Slave for A and B services?
How can avoid the consuming request from A over multiple instances?
Every A service will request for consuming separately
In these scenarios, Every incoming request passing through Zuul then A instances. What about the outgoing requests on A over multiple instances? Should we pass the outgoing requests over Zuul or similar?
How can I set up a Zuul or similar implementation on B service?
Thank you for now.
If microservices are stateless , how can we manage session in JSP based projects .Assuming I am breaking age old monolith to microservices .
You can't manage session in a stateless server.
What you can do is that storage a unique token and its corresponding information into Redis/MemCache.
You need to storage the token instead of JSESSIONID in client.
The fact that most implementations of microservices in the industry communicate via HTTP does not mean that microservices are meant to be used as web servers.
A microservice:
does not have to communicate via HTTP (though most implementations do, for convenience)
is not meant to receive requests issued by a web browser (although you can use a web browser to issue requests to an HTTP-listening microservice to test it)
is certainly not meant to generate responses containing HTML that can be rendered in a browser.
For these reasons, microservices generally do not have a concept of a session.
If you absolutely must make your microservice session-aware, and retain it stateless (so that it can still be legitimately called a microservice) then you have to have it fetch all necessary session information from your persistence store each time a request arrives, and save whatever parts of it have changed back into the persistence store right before returning its response. But that's not how microservices are meant to work.
Generally, the way we use microservices on the web is as follows:
Either we have javascript running on the browser which maintains session state and issues sessionless requests to the microservice, containing authentication information if necessary, [*] or
We build a conventional web server which maintains session state the traditional way and is therefore not a microservice, and we have that web server internally issue sessionless requests to microservices in order to do its job.
Footnote:
[*] please note that my acknowledgement of the fact that many people do this does not in any way constitute an endorsement of this practice.
I have a web service which authenticates a user, and if successful gives them a JSON Web Token which they can use to persist their session.
Currently I only have one server, but would ideally like to increase that to two or more for the sake of performance, however I'm unsure as to how that'll work with different servers as they'll have different instances of maintaining who is currently logged in.
For example, my service will examine the JWT the client returns, and (assuming it's a good token), will take the user ID and session and check if there is a user logged in with that session ID.
However, if for example, the middleware that precedes the web service layer determines that the server the user was initially logged in is currently unavailable and routes the request to a different server instance of the web service, how is the authentication controller meant to evaluate if the request is valid?
A very basic version of my service can be found below, with the black arrows representing ordinary communication, and the red arrows representing communication in the event that Layer One decides to route the request to Instance Two.
Layer One, in essence is very basic and doesn't really do anything other than route traffic to the next layer dependent on the availability of the layer two instances.
One of the main advantages of JWT is that it does not need server storage because it is self-contained and stateless. If you need server sessions may be JWT it is not your best option to manage authentication. See Stop using JWT for sessions
Currently application servers use the SESSION ID to manage load balancing and redirection to the server that store the user session, including persistent storage and migration of session. Using a JWT you won't take profit of these characteristics.
Use JWT if you need a REST stateless endpoint with authentication or you need to exchange data securely between parties
I have a client - server application which uses cxf DOSGi [1]. Now I want to authenticate the clients from the server and create a session for the client. The client will have a cookie which is used to access the service once authenticated. I would like to know what is the best way for the server to access the HTTP session and the best way to store a cookie at the client end once authenticated.
I was thinking of making a custom Session object at application level once authenticated and send a Cookie object to the client. So when the client accesses the service methods, it will pass the cookie as an argument. The client will be validated in every service method. But I dont think this is the best way to handle this since every service method must have a separate argument to pass the Cookie.
I came across this when I was googling [2]. Is it possible to get "WebServiceContext" in the service in DOSGi? Even if I get it, how would I store the cookie at client end and make sure the client sends the cookie in every subsequent web service call?
[1] http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html
[2] How can I manage users' sessions when I use web services?
Any help is highly appreciated.
Thanks.
You can use a custom intent to control authentication. Basically an intent is a CXF feature that is applied to the webservice by DOSGi. You create the feature in a separate bundle and then publish it with a special property for its name: See the DOSGi reference guide.
In a project we created a feature that read a threadlocal containing the authentication context and used the credentials stored there to populate the CXF authentication. So you just have to store the credentials once into the threadlocal at the start of you application and all calls work.
Currently there is no simple documenation or example for this case but I plan to create it in the near future as authentication is a common problem. I plan to use shiro as an authentication framework and write a generic adapter for CXF. I will add a comment or another answer as soon as I got it ready. In the meantime you can try to do the same yourself.
I'm a Jersey / REST newbie and am trying to write a simple web service. The issue I have is the storage of data between requests.
Servlets can access sessions but I didn't believe Jersey / REST allows this.
I am currently writing this service so that an Android app will make RESTful requests to Tomcat.
Now I am not sure yet of the type of request these will be: should they be URLs with parameters, or simply an XML string? The type of data to be transmitted from the app will include addresses of RSS feeds and keywords and sundry metadata.
The XML responses from the server will again consist of RSS feed addresses, keywords, frequencies of the keywords and other metadata.
The idea at the moment is to use JAXB on both app and server to make up and break down the XML into Java objects.
JSON or GSON are not available alternatives here.
But what about storing data between requests? Is it enough to store all the relevant variables in XML if XML forms the request and response actions, where each request will have an ID number referring to the server's database.
Or is it better to use the session context for servlets via REST?
Apologies if the above sounds vague. I am a Jersey / REST newbie.
While as has been said it is generally recommended your WS calls to be stateless, Jersey does rely on Servlet, so you can inject the HttpServletRequest and get the session from there:
#GET
public String getMethod(#Context HttpServletRequest req) {
HttpSession session= req.getSession(true);
...
You can then configure your web server session storage to memory, cookie, cache, db, or whatever.
REST webservices are based on the HTTP protocol which is a stateless protocol.
In my opinion, saving state in your webservice is not a good idea.
You should use cookies to store user data.
JAX-RS services can either be singletons or per-request objects. A singleton
means that one and only one Java object services HTTP requests. Per-request means
that a Java object is created to process each incoming request and is thrown away at
the end of that request. Per-request also implies statelessness, as no service state is held
between requests.