Hi Andy - I do, I just haven't had the time - I'm kinda slammed at work today, so I was hoping to try to answer this weekend :)
Best, Les On Fri, Jul 31, 2009 at 10:45 AM, Andy Tripp<[email protected]> wrote: > Les, > > Do you have any thoughts on what I said below? I now have Terracotta > "web sessions" working directly with Tomcat, and it seems like that's > all I really need. > > Andy > >> I'm now thinking that we really should do a "federated" approach, such > as >> using Terracotta. My objection to this was that having individual >> applications all sharing session data in memory was a huge waste of >> memory. But it turns out that Terracotta only keeps "local session > data" >> in memory. In other words, each machine really does only keep the > session >> data that it really needs in memory, not ALL session data. When it > needs >> session data that's not "local", it gets it from a centralized server. >> >> Architecturally, Terracotta looks like essentially an already-built >> version of the "centralized" approach. We've been talking about me > writing >> a Shiro CentralizedAuthenticationRealm that always sends a message to > an >> authentication server. Well, that's what Terracotta already does, it's >> just that it keeps local session data in a local cache so that it > doesn't >> always have to hit the authentication server. >> >> There are several advantages of using Terracotta (or similar tool): >> 1) We can start using authorization without a lot of work - the shared >> session state would contain authorization info in addtion to >> authentication info. With my own hand-coded Shiro >> CentralizedAuthenticationRealm, I'd have to do extra work to get >> authorization info. >> 2) We get other shared session info, such as a "shopping cart", "for >> free". With a Shiro CentralizedAuthenticationRealm, I'd have to build > this >> functionality. Having such a "shopping cart" is not a requirement for > me >> yet, but I can certainly see it coming down the road. We have > telephony >> applications, and one webapp might start a conference call while > another >> starts a normal call. The "normal call" web service would want to know >> that you're already in the midst of a conference call that you > initiated >> via the "conference call" web service. >> 3) Load balancing - say we are using some load balancing scheme where > you >> make a request from a web service, and then when you make a second > request >> to that same service, a load balancer redirects you to a different > server. >> Those two servers should share your session info. >> >> I'm now investigating Terracotta Web Sessions. The question is "do I > need >> Shiro on top of it?" I suspect the answer is "no, unless you're doing >> something 'custom', Shiro doesn't help you". >> >> So now after looking into it a bit, I'm starting to see why is seems > that >> most large apps seem to be using things like Terracotta and Coherence >> rather than CAS. >> >> I have two specific suggestions for Shiro: >> 1) Go ahead and build a TerracottaRealm class and let me use it via >> ShiroFilter configuration in web.xml. >> 2) Create a lot more and better documentation. For example, I should > be >> able to get an authentication server and a couple of application > servers >> up and running in under an hour. Take a look at the Terracotta Web >> Sessions tutorial, for example: >> http://www.terracotta.org/web/display/orgsite/Sessions+Tutorial >> Following that, I was able to get two "Jpetstore" web apps running and >> sharing sessions within about 20 minutes. The shiro QuickStart > application >> is pretty good. Create a similar writeup for the 'webapp' version of > it. >> >> Thanks again for your time. Sorry for the long email. >> Andy > >
