I need some stateful web service ( let's say tickets booking in 5 steps 1) select ...5) pay ) and want to implement it using Spring (boot) framework
googling
spring web service
tons of RESTful web services examples could be found... but according to REST manifest and many articles/answers (i.e. Sticky Session for Rest API Calls)
REST client is made to call REST API and REST APIs should be stateless
Statefulness harms scalability
It's very easy to create a RESTful web service in spring boot due to great embedded and autoconfigured libs, and I dont wanna refuse of it.
So I see some ways to overcome this:
Create RESTful web service in Spring Boot and add to there session and store state on it, and add sticky session load balancer to maintain scalability ( it's more difficult then stateless approach but doable). Yes it will not be true RESTful service, but it will work
Create true stateless RESTful service, keep state at
temporary 'temp_transaction' database table which your code can consult to determine if a user is in the process of booking, say, a particular seat.
state maintained on client side not on server. So one of the way that i will suggest is that you can use cookies to store your state and temp data
Use some rich client side framework like angular or react ( im not good in it but believe there is the possibility to keep state presents in these frameworks) though I think anyway cookie used for these purpose so it's almost the same as 3)
Use Spring + SOAP. Soap can maintain state but I think this way is obsolete and modern newly created applications from scratch shouldn't use SOAP
Don't use spring framework for this project but use Front end framework ( mentioned at 4) + Node.js ( anyway it will be stateful)
So which approach better to choose?
Because your REST service
could crash and will then be restarted
you want to scale and have multiple instances of your service
you should keep the state in a database or a distributed cache like Redis.
You will have to pass a session key or a booking reference in every request. For example in the header.
Related
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.
We have the following setup.
STM (Stingrey Traffic Manager) does load balancing + session stickiness
Weblogic 'cluster'
Auth handled by a third party tool
Therefore I do not have to worry about session with regards to horizontal scaling/ running multiple instances of the application. STM/ Weblogic cluster makes sure that the subsequent request come to same managed server.
What we currently have is a monolithic application and we are trying to move to microservices. Also we do not wan't to move out of current infrastructure (i.e. STM/ Weblogic cluster/ Auth tool). What we have planned is:
A Gateway WAR which routes requests to other microservices
N x Microservices (WAR) for each functional sub-domain
Only the API Gateway receives user requests and other microservices are not accessible from outside
So my question is
Should API Gateway be state-full while other microsevices are stateless?
If so, how should the user session data be shared between API Gateway and microservices?
Please suggest any better alternatives and resources/links as well. Thanks.
Let me share my opinion.
First of all, if you can keep your application stateless, by all means do so :)
It will be the best solution in terms of both performance and scalability.
Now, if its impossible, then you should maintain some distributed session management layer.
The gateway responsible for authentication could generate some unique session identifier which could later be used as a key.
This key could be propagated to all the microservices and be a part of the API or something.
In order to access the session, the microservice could 'get' value by key and work with it.
In terms of implementation: I would take a look on NoSQL solutions. Some of them that can suit your need are:
Redis. Take a look on ''hset'' there
Hazelcast. Its more a in-memory grid but if the solution is java only, you can also implement the required functionality
Memcache.d. It will give you an old good map, just distributed :)
There are also other solutions I believe.
Now, the performance is crucial here, otherwise the whole solution will be just too slow. So In my understanding, using an RDBMS would be not be good here, moreover potentially it would be harder to scale it out.
Hope this helps
1)Should API Gateway be state-full while other microservices are stateless?
Yes, As in 12 Factor App guide lines all the services should be stateless.
2)If so, how should the user session data be shared between API Gateway and microservices?
Your API should be stateless therefore do not share the session state to the microservices. The recommended approach is to set up a Redis cache to store session data.
I am trying to find a good way to implement Spring Security 3.1 across all my applications and my service bus.
Service Bus:
REST-services talking with the DB. This is also where all the user information is coming from.
Other applications (war's):
I want to be able to have multiple application stationed at different servers, all authenticating users and talking with the Service Bus through Spring's RestTemplate.
The problem is that the user SessionContext created by Spring Security on the Service Bus is useless when the login call is made via RestTemplate from another domain.
Also I dont want to keep sending the username and password for every call that I'm making to service bus, and then have that look it up in the DB every time.
One time per session should be enough.
I would love to hear your suggestions on how I could go about to implement this.
How do they do it in the Enterprice world?
I've been thinking about CAS, LDAP and even implementing it with Atlassian Crowd, but it seems like such an unnecessary effort.
I have Flex/AIR app that connects to a tomcat server via BlazeDS. I'm not finding that I have to integrate an old webapp (struts/jsp) and I'd like to keep that webapp untouched except for login, authentication and session handling. Also a 3rd java app that uses httpclient.
Currently I have some blazeDS remote objects to handle login/logout with a few RPC calls. In turn, FlexSession objects are created and handled. Is there a way to use httpclient and javascript to call those blazeds RPCs so I dont have to recode and have 3 different means to handle logins and sessions?
This is supposed to use single_sign_on for the 3 apps as well.
Yes, handle everything differently I'm afraid!
you should only use BlazeDS to (de)serliaise your Java objects to/from AMF. Once that's done, hand off to something else to do your business logic. This means you can add different entry points just by providing the API for your business logic.
From the Authentication / Login type stuff, you should be using something like spring security to handle this rather than writing your own. This decouples this type of logic from your business logic and transport mechanisms, and can be reused regardless of how you access your application.
For sessions, it depends on what you are storing, but using FlexSession isn't usually a good plan.
Scenario is how to cache on server if we have a page which show Categories Listing including no of items in it like this
CategoryA(40 posts) CategoryB(100 post) and so on when ever a visitor come to this page this information will be fetched from Database. That's what we don't want Actually what we want is to Cache this page for 15minutes so when ever next request come it will not hit Database and serve this cache. This cache can reside in RAM or on disk as file
This thing is pretty easy in asp.net but don't find a way to implement it in java/spring web mvc
Can anyone let us know how to implement this using Spring WEB MVC framework
Thanks In Advance!
I hope you haven't put all that logic in your web controllers. There ought to be a separate service tier that the web tier calls.
Put that cache in the service that the web tier talks to. Have it check the cache before calling the database.
I would recommend considering a caching server such as Ehcache to cache your data, instead of a home-brew solution.
Ehcache can be used in-process or made resident on your existing server. A separate project called ehcache-spring-annotations exists to integrate ehcache with the Spring Framework.