<quote>
Now suppose that I want to move this model into the EJB world.
According to the EJB specification and the (probably sound) advice given
above, if PartTimeEmployee is a leaf class--which it is--and all the
classes I just handed over to my consultant are abstract--which it's
looking like they have to be--then all of the classes in my .jar should
themselves *NOT* be EJBs, since they cannot be extended directly, and
since in the ultimate class hierarchy they will be base classes.
</quote>
Exactly! What's wrong with handing off your partially implemented
domain, letting the consultant subclass some of the classes for
white-box reuse and then GENERATE THE ENTITY BEANS using a tool? From
my reading of this list, it seems that many people feel that the best
thing is for the Entity bean to wrapper the domain object anyway, so
this would lend itself to tool use. If your EJB server does not include
one, then your group could create one without too much trouble.
And then where EJB shines is for your group to create COMPONENTS that
the consultants can use without subclassing, that might provide for
common functionality that pops up.
The issues that you brought up exist in every component model.
Noah
S/MIME Cryptographic Signature
