Typically, the web server is what receives the request... it then determines what type of resouce is being served, and if its something that the app server needs to handle (a servlet for instance), it passes the request along. So in a very real sense it's "in front" of the app server.
Now, take something like Tomcat for instance... it essentially has a web server built in. I've never seen one, but if someone drew a Tomcat architecture diagram, I'd expect to see the web server component in front of the servlet container component, acting something like a proxy (having said that, someone will inevitably tell me I'm wrong!). Probably the primary benefit to this is that you offload work from the app server and let the web server serve resources that it generally can more efficiently. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Wed, June 13, 2007 11:36 am, robinbajaj wrote: > > thanks for your input Frank. > When I mentioned about taking out the webserver, I only meant not to have > it > do the login. > It can still serve the static content. But I suggested merging the login > piece and the actual web-app, > and running them both on the weblogic app server. what I don't understand > is > then why do I hear people (including you) mention that their webserver is > in > front of their appserver. What kind of functionality does a webserver > provide by being in "front" of the app server. I mean, having it for > serving > the static content does not put it architecturally in "front" of the app > server. > Please help me understand, > robin > > > Frank W. Zammetti wrote: >> >> We have web servers in front of the app servers, and this isn't an >> evolution of old apps, I'm talking newly developed apps. There's >> nothing >> unusual about that setup at all, it's pretty typical in an enterprise >> setting. >> >> -- >> Frank W. Zammetti >> Founder and Chief Software Architect >> Omnytex Technologies >> http://www.omnytex.com >> AIM/Yahoo: fzammetti >> MSN: [EMAIL PROTECTED] >> Author of "Practical Ajax Projects With Java Technology" >> (2006, Apress, ISBN 1-59059-695-1) >> and "JavaScript, DOM Scripting and Ajax Projects" >> (2007, Apress, ISBN 1-59059-816-4) >> Java Web Parts - http://javawebparts.sourceforge.net >> Supplying the wheel, so you don't have to reinvent it! >> >> On Wed, June 13, 2007 1:17 am, robinbajaj wrote: >>> >>> thanks for your input. >>> I will evaluate it tomorrow morning. >>> By the way, what do you think of the idea of having a web-server in >>> front >>> of >>> an app-server >>> for login purposes. Isn't that unnecessary. I am sure our current >>> architecture is because the >>> way things evolved for this 5-6 year old webapp. But I think I can also >>> consider just taking out >>> the webserver and letting weblogic app server handle the initial login >>> and >>> use some security filter (may be acegi or regular custom written >>> filters) >>> to >>> make sure the user is still entitled to access any specific resources. >>> We >>> can still have the webserver for the static content, but login piece >>> should >>> get moved entirely to the app-server. >>> what do you think ??? >>> thanks again for any helpful pointers in advance, >>> robin >>> >>> >>> Frank W. Zammetti wrote: >>>> >>>> All of our security is LDAP-based, but we simply use the built-in >>>> mechanisms that Websphere provides... you can easily tell it, in >>>> conjunction with plain old J2EE security, to validate users against >>>> LDAP. This works very similar to the steps you outline. >>>> >>>> Now, on top of that we've build our own security framework to handle >>>> the >>>> things that J2EE security and/or Websphere doesn't, things like >>>> cross-site scripting, password policy adherence, extended timeout >>>> capabilities, and so forth. >>>> >>>> The other nice thing about it is that we essentially get single >>>> sign-on >>>> for free... the LPTA token that is used can be used across >>>> applications, >>>> so long as Websphere is configured properly (has to do with being in >>>> the >>>> same cell, or making cells aware of each others' tokens, details I'm >>>> frankly not as familiar with). Note that this is different than the >>>> session cookie your familiar with... it's a token created by Websphere >>>> when a user has been authenticated. >>>> >>>> In your shoes, I think my gut reaction would be to explore using J2EE >>>> security with whatever container your going to use, see how far you >>>> can >>>> get with just that. I suspect you can get most of the way... then see >>>> if you can fill the gaps with simple filters and such... obviously you >>>> don't want to take that exercise too far though or your just inventing >>>> things that already exist somewhere, but if its not a huge amount it >>>> might be worth it (and you may find you don't need to do anything at >>>> all >>>> beyond the standard stuff). >>>> >>>> HTH, >>>> Frank >>>> >>>> -- >>>> Frank W. Zammetti >>>> Founder and Chief Software Architect >>>> Omnytex Technologies >>>> http://www.omnytex.com >>>> AIM/Yahoo: fzammetti >>>> MSN: [EMAIL PROTECTED] >>>> Author of "Practical Ajax Projects With Java Technology" >>>> (2006, Apress, ISBN 1-59059-695-1) >>>> and "JavaScript, DOM Scripting and Ajax Projects" >>>> (2007, Apress, ISBN 1-59059-816-4) >>>> Java Web Parts - http://javawebparts.sourceforge.net >>>> Supplying the wheel, so you don't have to reinvent it! >>>> >>>> robinbajaj wrote: >>>>> Hi All, >>>>> I am working on a production web application written in Struts 1.2.x >>>>> . >>>>> Recently we undertook an effort to redesign our login architecture. >>>>> Currently our architecture is that >>>>> 1) user is presented with a login page served by IIS server (ASP >>>>> pages) >>>>> 2) user's provided username/password is validated against LDAP >>>>> server, >>>>> and a >>>>> token is returned. That token is stored in the database as well. >>>>> 3) That security token is put in the session scope and then the >>>>> control >>>>> is >>>>> passed on the weblogic server, where the security token from the >>>>> session >>>>> is >>>>> compared with the one stored in the database to verify its the same >>>>> user >>>>> who >>>>> logged in at step (1). >>>>> 4) the struts web flows are selected and user selects and runs >>>>> through >>>>> the >>>>> appropriate web flows. >>>>> >>>>> I am working on redesigning this login scheme. The IIS is only there >>>>> since >>>>> the login front-end was originally designed in ASP and either way its >>>>> a >>>>> good >>>>> practice to have a web server to serve the static pages and an app >>>>> server >>>>> for dynamic content. (we don't mind replacing IIS with Apache tomcat >>>>> etc..if >>>>> we have to..) >>>>> I am looking for any suggestions that any experienced web developers >>>>> have >>>>> implemented to implement a login scheme (*using LDAP repositories). >>>>> I recently evaluated Spring's ACEGI framework and found it to be >>>>> pretty >>>>> promising. I am not sure, if >>>>> there's anything else that I should/can consider. >>>>> Moreover, my question for this forum is whether the above >>>>> architecture >>>>> is >>>>> a >>>>> good one or is there some scope of improvement in it, that we can >>>>> implement >>>>> using ACEGI framework .... or some other login/security framework >>>>> that >>>>> you >>>>> folks can suggest... >>>>> thanks a lot for any input in advance, >>>>> robbby >>>> >>>> -- >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/suggestions-for-login-scheme-using-struts-1.x-tf3912491.html#a11092918 >>> Sent from the Struts - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- > View this message in context: > http://www.nabble.com/suggestions-for-login-scheme-using-struts-1.x-tf3912491.html#a11102261 > Sent from the Struts - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
