Your first question concerns the advantage of 3-tier systems. There's already a lot of materials stating the benifits of multi-tier systems, and I can imagine people yawning if I say that all over again here :) Multi-tier concepts are proposed long long before the appearence of EJB. The [browser]-[web server]-[database] is a three-tier architecture example, even without EJB components. If you think the seperating presentation/problem domain/data model is important, choose 3-tier designs. Using a 3-tier architecture, is is possible to implement a different client presentation or change the backend information systems without changing the underneath logical operations. Surely carefully designed 2-tier systems may have the same benifits. However I believe that in achieving such seperation, some implicit layering designs must be applied, and in fact it's a multi-tier architecture. J2EE proposes a well-defined architecture for the layering: [jsp/java applications]-[servlet/EJB/other server-side components]-[database].

So it's not really about EJB philosophy. :)

And why is a bean different than a class. Maybe you are asking how a "component" differ from a class. Components are "things" that have some protocols defined on it. Protocols include how such components are located and how the services are exposed to the outter world. It's already there, and if you can find it and talk to it, it will respond. If you are asking the difference between an EJB and common java instances, you may think this way: EJBs are java instances that live in remote machines. However, you may locate the instances via EJB home interfaces and interact with them via EJB remote interfaces.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.