aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes EJB design Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "EJB design" Watch "EJB design" New topic
Author

EJB design

JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Greetings,
I would like to carry on with the conversation I had with Thomas and others about EJB design (fine-grained vs coarse grained).
Let's imagine you have an EJB application to design dealing with Orders.
Your client with manage Orders, and of course, OrderLines (relationship 1-->N).

Using EJB 1.1, how many EJB are you going to design ? One, two, more ?
What about EJB 2.0 ? same design ?


/ JeanLouis<br /><i>"software development has been, is, and will remain fundamentally hard" (Grady Booch)</i><br /> <br />Take a look at <a href="http://www.epfwiki.net/wikis/openup/" target="_blank" rel="nofollow">Agile OpenUP</a> in the Eclipse community
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
Depends... maybe none.


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Depends on what ?

My pointy of view is :
Using EJB 1.1, I will use only one EJB, which represents an Order and the OrderLines associated.
Thus, the Facade will do only 1 remote call to obtain the order details.
It seems I don't really have any other choice, 'cause if an order is associated to ,let's say, 50 order lines, I can't do 50 remote calls
But if I use EJB 2.0, then I can have a Local Interface.
So I can have 1 EJB for the Order and 1 EJB for the OrderLine.
The facade will perform 1 local call for the Order and 50 local calls for the order lines.
It is why EJB 2.0 seems to allow a fine-grained EJB while EJB 1.1 forced coarse-grained one.
Is that only a dream or can it be real ?
Please correct me and give me you point of view.
Thanks.
(In my example, I suppose that Order and OrderLine need some security or concurrency access or transaction... I mean they do need some stuffs EJB will privide without coding )
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
In most cases, I don't think it is a good idea to create that many entity beans. The creation of an entity bean takes a lot of overhead (this has nothing to do with any remote access). I would have to see some compelling reasons to go through the cost of entity bean creation.
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Originally posted by Thomas Paul:
In most cases, I don't think it is a good idea to create that many entity beans. The creation of an entity bean takes a lot of overhead (this has nothing to do with any remote access). I would have to see some compelling reasons to go through the cost of entity bean creation.


Ok thanks a lot Thomas.
I guess I understand better your point of view.
The local interface addresses the call problem, but not the object creation problem, so a Java class (Value Object)is still more efficient than a EJB.
I'm quite agree with it, and I was confused due to a couple of articles I've read. For instance, in an article from theServerSide.com : "With the coming of EJB 2.0 CMP enhancements including Local Interfaces, entity beans can now be used to model the domain objects in your designs, as fine-grained as you like"
Moreover, I've never read a book where it is explicitly written not to use the fine-grained approach even in EJB 2.0
Notice that I think the "Core J2EE Pattern (Sun)" does not refer to EJB 2.0 but only 1.1.(actually, I did not finish it yet, but the 187 first pages do refer to EJB 1.1).
Mike Yu
Ranch Hand

Joined: Nov 17, 2001
Posts: 175
Originally posted by Bill Bailey:

Ok thanks a lot Thomas.
I guess I understand better your point of view.
The local interface addresses the call problem, but not the object creation problem, so a Java class (Value Object)is still more efficient than a EJB.
I'm quite agree with it, and I was confused due to a couple of articles I've read. For instance, in an article from theServerSide.com : "With the coming of EJB 2.0 CMP enhancements including Local Interfaces, entity beans can now be used to model the domain objects in your designs, as fine-grained as you like"
Moreover, I've never read a book where it is explicitly written not to use the fine-grained approach even in EJB 2.0
Notice that I think the "Core J2EE Pattern (Sun)" does not refer to EJB 2.0 but only 1.1.(actually, I did not finish it yet, but the 187 first pages do refer to EJB 1.1).

Generally speaking, you should use one Entity bean and a helper class.
------------------
Thanks,
Mike


Thanks,<br />Mike
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Hogwash. Bill, go ahead and use two EJB's for your design (one for the order and one for the order lines). In 90% of all designes, INCLUDING in EJB 1.1, having two EJB's won't make a whit of difference. To quote from C.A.R. Hoare:
"Premature optimization is the root of all Evil"
Look, if you're using a tool that has decent CMP support, then it's well worth it to take the extra overhead bite. Granted, the overhead is a lot LESS on EJB 2.0 than it was on EJB 1.1, but in many applications it's still not a problem.
For instance, how many orders are you going to manipulate at once? How many order line items are there per order? If the answer is "1" and "less than 100" then you should notice NO problems with your above design.
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Well, it seems nobody can fully agree on that subject.
(Coarse-grained vs Fine-grained.)
kyle, do you mean WebSphere is that good it allows fine-grained in th EJB design ?
Wow, if that's true, I'm lucky 'cause that's the tool I use.
(on the other hand, I'm unlucky 'cause I can't do EJB 2.2 with it yet)
Jim Baiter
Ranch Hand

Joined: Jan 05, 2001
Posts: 532
Here's an interesting link on this subject. I would note that in 2.0 CMR, you still will create 2 entity beans, but the container will populate the parent with a Collection of the child. Outside of the network issue which Local interfaces address (which most servers in 1.1 are optimizing anyway), the intent is to reduce database access by internally consolidating the ejbLoad() & ejbStore() calls.
http://www.theserverside.com/home/thread.jsp?thread_id=6736
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
It all depends on how your system is going to be used and what kind of performance you require. Entity beans can have an enourmous overhead espcially if your database is being updated by applications not running under J2EE. The question comes down to, what are you going to do with that entity bean? Are you going to serialize it to display it on a JSP? Are you going to be doing a lot of accessing of the same rows or are you going to be accessing many different rows with few repeats?
I think ignoring performance and using entity beans for every occassion is a huge mistake. A Java application must be carefully architected from beginning to end. The right tools must be chosen for the right problems.
Jim Baiter
Ranch Hand

Joined: Jan 05, 2001
Posts: 532
I agree performance must be considered through all phases but I also would note that the first maxim of performance is testing. One aspect of Websphere that has impressed me is that they provided a "Trade" sample which contained most primitive calls to session and entity beans. Since it was invoked by URL we hooked up a free Microsoft load runner and stressed it. The results were quite decent. People working in shops that have the tools should generate some tests for their own scenarios.
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
I agree with you Thomas, but I'm not very happy about that.
The former answer you gave me about fine-grained was "IT DEPENDS"..
And actually, that is the only realistic answer
My understanding is that it's quite difficult to describe generic design rules for Entity EJBs.
Most of the time, the design should take into account the application needs, should consider the use cases etc..
Thus, I can't design full-proof Corporate EJB if I don't even know what they are going to be used for.
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
Originally posted by Bill Bailey:
Thus, I can't design full-proof Corporate EJB if I don't even know what they are going to be used for.
As any good architect will tell you, you can't design anything worthwhile unless you know what the thing is to be used for. You should design with the requirements in mind, as well as expected changes in the future, and then try to have a flexible design able to chnage for the unexpected. Good luck!
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
I will need a Good Luck Horse Shoe.
Does the Javaranch could provide it ?
Joke apart, my design problem only deals with a very few objects I know each application will use, but I can't forecast how..
For the others, it should be OK

[This message has been edited by Bill Bailey (edited December 18, 2001).]
 
wood burning stoves
 
subject: EJB design