Gemstone Jvs Ejb

I'm curious what advantages people perceive using the traditional Ejb architecture versus GemStonej purely as an OODB? As I see it, unless you have huge amounts of data (beyond 100Gb) or need distributed transactions into legacy databases, the are no advantages to using Ejb and there are distinct disadvantages.

One of the significant disadvantages of EJB is that you have to plan for distributing the state of your DomainObject(s). The typical scenario is that you have some clients (UIs, whatever) that need access to your DomainModel. So you have to decide whether to implement your domain model with EntityBeans or plain old domain objects. EntityBeans are pretty heavy-weight: they're intended to be remotable, and intented to manage their own persistence. Personally I don't think either of those things is necessarily a good thing for a domain object to do - so I prefer to implement my domain objects as plain old domain objects instead of entity beans. OK. So, now you have a layer of session beans implementing business logic. Chances are these session beans' method signatures need to involve domain object types. So the domain objects have to be serializable. But what if a domain object that you want to serialize is the tip of a big aggregation hierarchy of domain objects? What do you do? Serialize it with null instance variables and make the clients come back to the session beans to traverse every relationship in the domain model? Serialize the whole damned aggregation hierarchy? Serialize a DomainObjectStateHolder instead of the domain object? These are the choices that EJB forces you to make because session beans are inherently remotable. This whole headache goes away if you use an undistributed architecture, especially when using GemStonej's PCA - the whoile domain model looks seamless to client code. Now, I know there are sometimes business requirements for distributing domain object state, and then you're stuck. But that doesn't have to be the case just to serve a UI. --RandyStafford