It may be overkill. You do get inheritance in EJB, you just have to be clever about how you use it.
1) Make heavy use of interface inheritance
2) Use Class Based Inheritance for your Implemntation classes
3) Use sequences (we use Postgres, what ever they are called in your db) to make sure that the primary Keys are unique across two different sets of entity beans
You may want to create a factory object to wrap the Home interfaces.
You are right, inheritance is possible, but it is not as trivial as with normal Java classes. There are lot of aspects to take care of - e.g. inheritance of home interfaces does not work according to my experiences.
I do not understand what do you mean by "class based inheritance for implementation classes"?
Concerning the primary keys it may the best to use sequences. Nevertheless I will probably implement a service bean that controls primary key distribution because I want to achieve complete database independance and not every relational database supports sequences.
Go Jan Janke!
I've been using this approach more and more (it applies not only to j2ee but any implementation specifics lurking behind your business layer - I've actually only been j2ee'ing for a short while but have found the concept holds well within this technology also).
Over time I have come to realize how strange that we oo developers so often stop thinking objects once past the persistence layer. Our problem domain has shifted to the business layer and yet our objects still represent the persistence one?? Me get very confused!
I hope you'll find (or have found) - like me - that this approach has several design advantages, only one of which is hiding the imlementation specifics.
BTW If you have any good reading on this topic i'd love some URL's. I learnt my techniques from a "wise old man" (I'm very much an "on the job" learner) but we have since parted ways and I'm starving for more information on good design principles.
very lot responding I know :-)
Why have a separate layer between the session beans and entity beans (you can't anyway). In which case I assume you mean your session beans will be an aggregate of normal Java classes that implement your business logic with the session bean acting as a wrapper ? In which case, go for it, sounds perfect.
As to small CMP beans - don't do it ! There's an over-head for each ejb and for CMP beans it's the biggest. You'll have problems with scalability. I doubt it would be as bad with JBoss as it was when we try this with Weblogic - we broke the server with five users ;-) Good thing we knew performance/load would be an issue and tested out our architecture really early. Imagine what a disaster it would have been if we'd tried performance/load testing near the end of the project and found this problem with our initial architecture...
The only good reason to have many small CMP beans is ease of implementation - no or little work for the developer - but almost everything else will suffer.