Options 1) No session. Everything is in DB or Window.localStorage. Authentication via a token validation endpoint. (We keep the token in a front end cookie) 2) Session as a service 3) The session is local, works with session affinity 4) The session is distributed
My personal order of preference - 1, 2, 3, 4 Azeez says 2 (or 1? ) Sanjiva says 3, with 4 being plug-able I think 1 is doable. Yes, there will be some development overhead. But it'll be scalable/simpler at run time. On Wed, Mar 9, 2016 at 6:59 PM, Sanjiva Weerawarana <[email protected]> wrote: > Not practical Azeez - you're massively complicating the deployment and > second its far less performant than replication. Earlier we did global > replication which we really shouldn't do. > > I'm not suggesting replication .. I'm saying we support non-HA sessions by > default but make that part pluggable so we can plug in a replicating model > (or even a DB model) if needed. > > On Wed, Mar 9, 2016 at 6:43 PM, Afkham Azeez <[email protected]> wrote: > >> What if we follow an approach of persisting the session to a datastore, >> like we've done in the petstore sample, that way you don't need to worry >> about affinity or the node having the session failing. In memory session >> replication is costly & leads to a whole lot of other issues, like the ones >> we've seen with replicated caches, so it best to avoid it. >> >> On Wed, Mar 9, 2016 at 6:32 PM, Sanjiva Weerawarana <[email protected]> >> wrote: >> >>> Manu's question is in the context of the reusable UI framework stuff >>> we're working on. >>> >>> Fundamentally, is it necessary to have sessions to write a UI? Can we >>> use HATEOS for some stuff, browser local storage for some stuff etc. and >>> not have sessions at all?? >>> >>> I feel we need sessions as a lot of simple things become hard without >>> them. >>> >>> Then comes the question of how do we do sessions and whether we do some >>> kind of replication or rely on affinity based routing. >>> >>> On Wed, Mar 9, 2016 at 5:23 PM, Afkham Azeez <[email protected]> wrote: >>> >>>> With such a model, you don't have to worry about things like session >>>> replication in order to achieve HA. >>>> >>>> On Wed, Mar 9, 2016 at 3:32 PM, Manuranga Perera <[email protected]> wrote: >>>> >>>>> Should we aim to do the same in the UIs we ship, such as products ES? >>>>> There will be some extra effort. >>>>> >>>>> On Wed, Mar 9, 2016 at 2:12 PM, Afkham Azeez <[email protected]> wrote: >>>>> >>>>>> In the petstore sample, the sessions of the frontend apps are stored >>>>>> in Redis. >>>>>> >>>>>> On Wed, Mar 9, 2016 at 1:57 PM, Imesh Gunaratne <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Manuranga, >>>>>>> >>>>>>> Yes, what you are saying it true! We should only use session aware >>>>>>> load balancing for existing applications which has session management >>>>>>> features built into them. >>>>>>> >>>>>>> Ideally when implementing new applications those should be designed >>>>>>> in a way to store their sessions outside the application (irrespective >>>>>>> of >>>>>>> they run on containers or not). This can be done with either using a >>>>>>> database or a service (ex: Redis). In that way we can scale the >>>>>>> application >>>>>>> and session management service separately and also route request without >>>>>>> handling sessions at the load balancer level. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> On Wed, Mar 9, 2016 at 1:12 PM, Manuranga Perera <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> We are currently using sessions and session affinity in our apps. >>>>>>>> But going forward, especially in Micro Services/Docker model does it >>>>>>>> make >>>>>>>> scene? >>>>>>>> >>>>>>>> Eg: If we bring up a new container due to high load, requests will >>>>>>>> still route to old continents due to the session. If we kill a >>>>>>>> container >>>>>>>> that is associated with some session where should the request go? >>>>>>>> >>>>>>>> We have written (I think) a session aware router for Docker. It's >>>>>>>> ok for external apps, but I think it defeats the purpose of >>>>>>>> containerization, due to about reasons. >>>>>>>> >>>>>>>> I think the correct way to do this in our apps is to, have >>>>>>>> authentication as a service. A micro service will translate the >>>>>>>> session-id >>>>>>>> to a token. App depends fully on the token. >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> -- >>>>>>>> With regards, >>>>>>>> *Manu*ranga Perera. >>>>>>>> >>>>>>>> phone : 071 7 70 20 50 >>>>>>>> mail : [email protected] >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Imesh Gunaratne* >>>>>>> Senior Technical Lead >>>>>>> WSO2 Inc: http://wso2.com >>>>>>> T: +94 11 214 5345 M: +94 77 374 2057 >>>>>>> W: http://imesh.io >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Afkham Azeez* >>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>> * <http://www.apache.org/>* >>>>>> *email: **[email protected]* <[email protected]> >>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>>> <http://twitter.com/afkham_azeez> >>>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>> >>>>>> *Lean . Enterprise . Middleware* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> With regards, >>>>> *Manu*ranga Perera. >>>>> >>>>> phone : 071 7 70 20 50 >>>>> mail : [email protected] >>>>> >>>> >>>> >>>> >>>> -- >>>> *Afkham Azeez* >>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>> Member; Apache Software Foundation; http://www.apache.org/ >>>> * <http://www.apache.org/>* >>>> *email: **[email protected]* <[email protected]> >>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>> *twitter: **http://twitter.com/afkham_azeez* >>>> <http://twitter.com/afkham_azeez> >>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>> >>>> *Lean . Enterprise . Middleware* >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Sanjiva Weerawarana, Ph.D. >>> Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ >>> email: [email protected]; office: (+1 650 745 4499 | +94 11 214 5345) >>> x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311 >>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >>> Lean . Enterprise . Middleware >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>* >> *email: **[email protected]* <[email protected]> >> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >> *http://blog.afkham.org* <http://blog.afkham.org> >> *twitter: **http://twitter.com/afkham_azeez* >> <http://twitter.com/afkham_azeez> >> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >> <http://lk.linkedin.com/in/afkhamazeez>* >> >> *Lean . Enterprise . Middleware* >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Sanjiva Weerawarana, Ph.D. > Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ > email: [email protected]; office: (+1 650 745 4499 | +94 11 214 5345) > x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311 > blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva > Lean . Enterprise . Middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- With regards, *Manu*ranga Perera. phone : 071 7 70 20 50 mail : [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
