jQuery in Action, 3rd edition
The moose likes EJB and other Java EE Technologies and the fly likes Why we need EJB ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Why we need EJB ?" Watch "Why we need EJB ?" New topic

Why we need EJB ?

Nakata kokuyo
Ranch Hand

Joined: Apr 13, 2005
Posts: 465
hi, good day , can i know why we need EJb? when we should use and not ? is there any sample site to use EJB ? thank you
Mike Keith
Ranch Hand

Joined: Jul 14, 2005
Posts: 304
Hi Nakata,

EJB is a server-side component standard that also now includes lightwieght persistence in the form of JPA. You should use EJB and JPA whenever you are developing server-based Java applications and standards are important to you.


Pro JPA 2: Mastering the Java Persistence API
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
I disagree. You should use EJB when you need the scalabillity and clustering that a well executed EJB system will provide.
You should not use it (or anything for that matter) simply because it's there and it's a nice sounding acronym/buzzword (which is what caused many EJB projects in the past to get into serious trouble).

Christophe Verré

Joined: Nov 24, 2005
Posts: 14688

And you should use when you know what you're doing !

[My Blog]
All roads lead to JavaRanch
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968

<a href="http://www.technicalfacilitation.com/get.php?link=usingejbsWhen" target="_blank">http://www.technicalfacilitation.com/get.php?link=usingejbs[URL=http://www.technicalfacilitation.com/get.php?link=usingejbs]When to Use EJBs</a>

EJBs are incredibly powerful components that allow developers to easily take advantage of the application server�s security, transaction, naming and distribution services. However, EJBs are also incredibly resource intensive. If you use EJBs excessively, you�ve just bought yourself a one-way ticket to performance problemville.

Before committing to using an EJB, ask yourself the following questions:

F Do I need to manage some serious database transactions?

EJBs are great for managing transactions, and if you have a largely transactional system, EJBs just may be your saving grace.

F Do I need object distribution?
F Are users calling my components remotely?

This is a good case for using EJBs, as EJBs are inherently distributed objects. However, this alone is not a compelling reason to employ an EJB centric solution.

There are many mechanisms for implementing remote distribution including remote method invocation (RMI) and network socket programming, both of which are more efficient than using an EJB.

Needing object distribution is a good reason for using an EJB, but I�d look for another reason or two before committing to an EJB based solution.

F Do I need security down to the method level?

EJBs provide the ability to interact with the security service of the application server, and you can lock EJBs right down to the method level. This type of security would be relatively difficult to implement with regular JavaBeans.

Needing this type of security is a good reason to use an EJB, but it shouldn�t be a reason on its own.

If security is the problem you need addressed, you could probably avoid using EJBs and lock down your applications by securing Servlets and JSPs instead. The Java Authentication and Authorization Service (JAAS) could also be used to facilitate a secure system without using EJBs, but even JAAS introduces an extra level of complexity.

EJBs do indeed provide secure access right down to the method level, and if this is the type of security you need, EJBs might be a viable solution.

F Do I need to make sure that the data my application receives is completely and totally in sync with the data in the database?
F Do I need a persistence model?

CMPs and BMPs address the many difficulties associated with communicating with a database, as they provide a persistent object model that makes sure the data obtained by your application is completely and totally in sync with the database.

Again, if this type of persistence modeling is what you need, go ahead and use EJBs. However, if your application is largely reading data from a database, and data collisions are rare and not likely to be detrimental when the do happen, I wouldn�t use an entity bean framework. In that scenario, I�d look at Java Data Objects (JDO) or Hibernate. Remember, entity beans are incredibly resource intensive. Use them only if you need them.

F Do I need multithreaded access with large workloads

EJBs are inherently multithreaded, and application servers, especially WebSphere, are highly scaleable. This is a good peripheral reason for using EJBs, but I wouldn�t base my decision on multithreading support alone. After all, you can always synchronize methods in a regular POJO (plain ordinary java object.).
Use EJBs Sparingly

The point is, EJBs are incredibly powerful, but they are also incredibly resource intensive. Use them when they make sense, but use them sparingly.

Unnecessary EJBs will slow down your applications and performance will quickly become an issue. There is a good reason why many of the J2EE design patterns demonstrate how you can achieve many of the benefits of using EJBs while minimizing their actually use.

If you choose to use EJBs, choose to use them wisely.

Here's a good link on ejbs:

[ August 27, 2006: Message edited by: Bear Bibeault ]
I agree. Here's the link: http://aspose.com/file-tools
subject: Why we need EJB ?
It's not a secret anymore!