To say that OR mapping is the only purpose of EJBs is way off the mark, but a common misconception among those who haven't used them. In fact, there are two main types of EJBs: session beans and entity beans (there are now message-driven beans as well). Entity beans are the things that map (usually) to a database or any other persistence mechanism. There are two types of mapping strategies used for entity beans: CMP, for Container Managed Persistence, and BMP, versus Bean Managed Persistence. It's the former that's used in drag-and-drop and automated mapping tools, while the latter is used these days mostly for finer control over persistence logic (it came before CMP). Session beans are the ones that tend to contain business logic. The closest thing to session beans in .NET are COM+ services that you write yourself, but COM+ is a poorer technology for this use than session beans. Why? Because EJB servers contain things like automatic clustering support, portability between servers/OSes, etc. not supported by COM+, together with a much better programming model. Microsoft keeps calling Windows server OSes 'application servers' even though they don't compete well with actual application server software on features or performance. It's like this: EJBs make it possible to write a true distributed object. The EJB server takes care of all application servers, clustering, transactions, etc. To write distributed programs in .NET, I've seen many people wind up depending on locking and clustering in the database instead, then write Web services or other components that call the database directly. This is a much different approach. I've seen lots of articles that talk about 'layers' of this and that in .NET, but it's the lack of actual middle-tier services in .NET that seems to differentiate the two platforms the most. Does this mean that .NET sucks? Nope. It just means that to write an application that does the same thing as a J2EE app, you have to approach it in a different way, putting more of your scalability-related design approach into the database (and sometimes more of your business logic). I believe that it's also true (as is supported by many third-party studies) that J2EE applications scale to a higher total limit before replication strategies must be employed. But this doesn't matter AT ALL to most companies, since the great bulk of business applications don't have to support really gigantic processing loads. ObjectSpaces sounds like it is comparable to things like JDO (Java Data Obje