• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

EJB design

 
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?
 
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Depends... maybe none.
 
JeanLouis Marechaux
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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).
 
Ranch Hand
Posts: 175
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
JeanLouis Marechaux
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)
 
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 532
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).]
 
reply
    Bookmark Topic Watch Topic
  • New Topic