> In the honest opinion of the highly clued people here, is it ever going to > amount to a hill of beans? Is it going to die like OpenDoc? Or take 10 > years to mature, like CORBA? > Well, it might be a giant (slow moving) "hill of beans" but it probably won't be very functional unless the do a serious re-write of the spec... (I asked Craig Federighi a similar question a while back and I will paraphrase (and at times quote verbatim) his answer here) In the Microsoft / Sun API turf war, this is how the parts line up: ActiveX Control is roughly equivalent to a JavaBean COM + DCOM + Microsoft Transaction Server is roughly equivalent to Java + RMI + Enterprise JavaBeans Reading the spec, one comes away with the understanding that Enterprise JavaBeans defines a component model for server-side objects. The goal in this case is to support object-based transaction processing (TP monitor) applications. The model and the objects involved are extremely heavy weight. To get your basic bearings, think: Sun NEO in Java. Within Enterprise Java Beans we have two distinct flavors of beans: (1) The Session Enterprise Bean which the WebObjects developer could think of as WOSession; and (2) The Entity Enterprise Bean which is like a very crippled EO. One will also note that support for Entity Beans in not required until EJB 2.0 (presumably because Sun won't have an implementation until then. A WebObjects developer's terminology guide to EJB: Session Enterprise Beans ~= WOSession Session Container ~= WOApplication passivation/activation ~= External session stores (state archiving) Entity Enterprise Beans ~= EOs Session EJB Container ~= EOControl Entity Context ~= EOEditingContext Object Handle ~= EOGlobalID containerManagedFields ~= EOModel deployment descriptor Home Interfaces ~= Class method API And now a functional comparison: --- EJB v.s. EOF --- The Entity Enterprise Bean support is only sketched in rough strokes in the current spec. It's not clear if transparent foreign-key to object pointer mapping is included (let alone prefetching, batch faulting, inheritance mapping, etc). Several limitations of their model, however, are already evident: - incredibly heavy weight - for each Entity Bean class (EB) the developer must write one class and two interfaces - the "container" must then *generate* 2-3 classes to implement the Home Interface, the Remote Interface, and perhaps a mutated version of the bean itself. - all references between client and EB, and between EBs is indirect (through the client interface and the container implementation) - EJB spec suggests that for each EB the container might generate a mutant hybrid of the class that does one or more of the following: wraps every method with additional logic, adds implementation (to make up for the lack of multiple inheritance or categories) - not tuned for interactive applications - no optimistic locking (pessimistic locking on all fetches!) - creating an EB *immediately* inserts a row in the database - EBs must be extremely large granularity! - EJB virtually prohibits a loop in calls between EBs (e.g. employee EB calls method on department which in turn messages the employee). With these kinds of limitations, fine grained EBs would be impractical. --- Performance --- Both Kiva and NetDynamics have said the next version of their products will be EJB conformant. We look forward to benchmarking against them! :-) Alex ---- Alex Horovitz Senior Systems Engineer Apple Enterprise Software & Solutions Boston, Massachusetts
