Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Are Entity Beans REALLY only for Low performance applications

 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Posts: 98
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 3404
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 263
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 8791
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    HS Thomas
    Ranch Hand
    Posts: 3404
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 3404
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 18304
    56
    Android Eclipse IDE Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Avianu Sud
    Ranch Hand
    Posts: 55
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic