Object oriented business logic layer between entity and sess

[janjanke]

Hallo,

I am currently planning a new EJB 2.0 based application. I want to use fine-grained CMP entity beans that exactly represent the relational database structure to ensure database independence. There won't be any stored procedures or triggers in the database. Everything is handled within the application server.

Between the session beans layer with processes client requests and the data layer which consists of the entity beans I want to include an object oriented business logic layer built with normal Java classes. I want to do so because of the lack of entity bean component inheritance. I also want to avoid exposing operations like JNDI lookup etc. to the session beans that will use the business logic layer classes to process client requests.

Concerning this idea, I have several questions:
1. What do you think of my proposed architecture?

2. I want to access the entity beans from the business logic layer classes using local interfaces. When I deploy the classes together with the beans in one jar-file it works fine. Can I access business logic layer classes also using local interfaces when I simply put my business logic classes in the JBoss classpath or can I deploy them in a separate jar-file?

3. Should I use remote interfaces? I think this would be a significant loss of performance, right?

Thank you for your opinion!
Have a nice day!
Jan

[admiyo]

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.

[janjanke]

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.

[timdeboer]

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.

[edwardkenworthy]

Hi

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.