File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Are Entity Beans REALLY only for Low performance applications Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Are Entity Beans REALLY only for Low performance applications" Watch "Are Entity Beans REALLY only for Low performance applications" New topic
Author

Are Entity Beans REALLY only for Low performance applications

HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Are EJBs ( i.e. (Entity Beans) REALLY only for low-performance applications ? i.e EJB 2.0 applications.
Can't ,say, a CICs application (high-volume , highly-transactional , high performance ) application be transformed into a single EJB application ?

regards
[ July 01, 2003: Message edited by: HS Thomas ]
Siva Jagadeesan
Ranch Hand

Joined: Oct 31, 2000
Posts: 160
Thomas:
Not really Thomas. I am currently working in a project where we are replacing the old CICs application with J2EE application. There are many advantages like easy integration with other vendors, easy maintainablilty etc


Rgds<p>--Siva Jagadeesan<br /><a href="http://java2simple.blog-city.com" target="_blank" rel="nofollow">http://java2simple.blog-city.com</a><br />Sun Certified Java2 Programmer<br />Sun Certified Web Component Developer<br />BEA Certified Weblogic Server 7 Enterprise Developer
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Thanks .
Does 1 CICS application get written as many EJBs
many , because EJBs are only for low-performance applications. Probably get more re-use as well.
regards
Paulo Salgado
Ranch Hand

Joined: Jan 18, 2002
Posts: 98
Most likely Thomas, as you will have classes to handle object persistence, workflow logic and maybe application integration, for instance if you want to replace an MQSeries/CICS application. But some (and maybe most) of the EJB's will be reusable to other applications.
Consider reading about Object-Oriented concepts, UML and then about Design Patterns. It can be very painful and costly to maintain poorly designed applications. I'd say learning that first will accelerate your learning of Java and J2EE.
Regards.
-Paulo
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Thanks , PAulo.
I think I've started learning OO concepts. I passed SCJP2 a while back in 1999. I am trying to do the other things you mentioned .
Looking at EJBs from a design perspective I think it's possible to over-engineer the design especially if you start with a mind-set that EJBs are for low-performance applications.
I'm looking for a middleground where it is easy to maintain the many EJBs (fewer interfaces, etc, a relatively higher performing EJB) without losing the benfits of re-use.
Can you re-factor EJBs from one to many only if you need to ?
PS I have this problem with ordinary classes too.
regards
[ July 01, 2003: Message edited by: HS Thomas ]
Paulo Salgado
Ranch Hand

Joined: Jan 18, 2002
Posts: 98
Thomas, I'm sorry about that. For some reason I understood you were starting to think about migrating mainframe applications to the J2EE. Regarding your question, can you post an example of the problem you are experiencing ?
Regards.
-Paulo
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Well , if you can throw any light on Entity Beans being for low-performance applications that might help.
I heard it, not for the first time, here...
a Scott Ambler transcript.
UML China
Entity beans really aren't all that useful in real applications. Most people use session beans and normal business objects.(2002/03/11 10:37)
and the future of Entity Beans ?
scottambler对dejol说: I think that they'll stick with entity beans for quite a long time because they are good for low-performance applications and for prototyping.(2002/03/11 10:44)

There must be a rule of thumb in converting a legacy high performance application to Entitiy Beans and other EJBs.
Where the high performance is essential there must be other alternatives ?
What is it about Entity Beans that make them suitable for low-performance applications only.
regards
[ July 02, 2003: Message edited by: HS Thomas ]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Oh ! Ok I've come across Performance-Tuning Entity Beans tips to make them high performing.
like :
  • use local interface , not remote interfaces to call them
  • cache as often as possible
  • use short transactions and batch JDBC updates etc..


  • Seems like a lot of trouble.
    What other alternatives are there to Entity Beans ? And do you have to work with these alternatives outside the EJB architecture and link them in somehow or within it ?
    regards
    [ July 02, 2003: Message edited by: HS Thomas ]
    Paulo Salgado
    Ranch Hand

    Joined: Jan 18, 2002
    Posts: 98
    You know, I hear about caching and I always wonder how these implementations take care of data consistency, which is a job the application server would take care of. Besides, most of the databases cache rows themselves in memory, so what is really the benefit of coding it?
    But I've heard of (never used) two things which seems to be what you are looking for: DAO and JDO.
    Regards.
    -Paulo
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    although it might be integrated with an EJB Container that provides these services. CMP is for persisting distributed components built specifically to the entity bean component API. JDO is geared towards local, rich object models not tied to any particular API. Developers can choose between these technologies by evaluating their requirements (persistent components or persistent objects).

    Thanks Paolo. Following the link you supplied , this is what I was looking for.
    The Question is how do you combine JDO with the EJB container? Probably the same way you do JDBC, huh?
    regards
    James Ward
    Ranch Hand

    Joined: Apr 27, 2003
    Posts: 263
    HS Thomas >
    You said it. I would go with the statement that 'Entity Beans are really suitable for low performance or simple apps'.
    If you do not design your entity beans well, you are left with a lot of maintenance and performance problems...
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    You have an advantage coming from CICS to this area - you've been doing stateless servers and thin clients for years! Learn the new stuff, but don't ignore the value of your experience!
    Make a list of the services provided by the J2EE container: remote objects, session state, transaction management, CMP, security, etc. Check off which ones are vital to you, and use as few EJBs as possible to get those benefits. I've seen a couple good architectures with exactly one stateless session bean who's only purpose was to provide access for remote Java clients. And others that took advantage of more container features with more beans.


    A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Thanks Jitender.
    I needed someone to concur.
    Thanks Stan. As usual, sound advice. EJBs don't seem appropriate a lot of the time. Unless, you are in the business of selling COTS re-usable components. And even then, there is the question of security.
    But still, there are lessons to be learnt from studying the roles and re-usable aspects of EJBs .
    In the same way that you would modularise exception handling,security, transactions why not "modularise" data access and treat it as a cross-cutting concern ? Or simply another concern .
    regards
    [ July 25, 2003: Message edited by: HS Thomas ]
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    While on the subject ,looks like someone has taken the initiative:

    The MVCSoft Persistence Manager provides many advantages over your EJB container's native CMP 2.0 implementation.
    Use MVCSoft's innovative lightweight entities to bypass your EJB container's services stack when the only service you want is persistence. Never worry about the costs of implementing your model with "heavy weight" entity beans again!

    EJB Inheritance
    regards
    Tim Holloway
    Saloon Keeper

    Joined: Jun 25, 2001
    Posts: 15632
        
      15

    Word of advice. Whenever someone tells you to distort your design for performance reasons, don't blindly accept it as immutable fact. Entity EJBs are a very good - though hardly the only - example. Originally Entity EJBs were known to make 2 database hits per reference (no such thing as a read-only bean). This was just one of numerous offences that implementors encountered and resolved. Most of the really bad ones have been addressed by EJB 2.0. Time has moved on and the rules have changed.
    I personally like to go the EJB route because, since they're components, they keep the initial design clean, but are fairly easy to tune and/or plug-replace if they prove inefficient for the task at hand.
    Actually, in many cases I'm using a blended approach these days. I use the Fast-Path Browse J2EE design pattern for multi-row read access (browses), and an EJB for actual row mod/insert/delete operations. The two work well together, so long as you allow for the possibilities of stale browses. I also use Transfer Objects with my EJBs to cut down on the RMI overhead you get when changing many fields at once. Since I use tools that generate all the requisite model code automatically, it allws me to be both productive and to generate solutions that are efficient for my most-frequently-encountered cases.


    Customer surveys are for companies who didn't pay proper attention to begin with.
    Avianu Sud
    Ranch Hand

    Joined: Jan 20, 2002
    Posts: 55
    For me, ENTITY beans are SLOW. I would not use them, and find other persistence alternatives like JDO, JDBC.
    EJB's still gives many features, such as transaction support, remote access, security, layered software, etc.
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: Are Entity Beans REALLY only for Low performance applications
     
    Similar Threads
    mock questions doubt?
    Using entity beans in project
    Entity beans wrapped by Session beans
    Which is faster?
    Design Decision on EJB