Thank you everyone for the excellent and truly helpful responses. I'm
certainly getting a much better feel for this stuff.
I think I'm still missing a little something though. As Anne said:
>An app server is like an object-oriented variant of a TP monitor. People use
>them because they increase the top-end performance and scalability of your
>system.
Now, I probably come from a different background than many of you in that
I'm not entirely sure exactly what kind of scalability we're talking about.
I do have a fair amount of experience designing high-traffic
high-performance web sites. In my web-centric view, an appserver provides
services such as database connection pooling, templating, result set
caching, and distributed session management.
Now, I'm trying to build a "scalable" application. What if I simply run a
bunch of discrete servers running on separate machines. Each is serving a
portion of our user base, with each user pinned to a particular server.
Each server maintains its own session layer, connection pool, and cache. I
understand there's a fail-over issue here, but what else am I losing?
It seems that such a scenario scales pretty cleanly. If I throw in a
distributed session mechanism, failover is solved as well. What kind of
problem does either an Entity Bean or Session Bean address?
-Ben
--
Ben Engber
Software Engineer
The New York Times
[EMAIL PROTECTED]
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
