Why do we use EJBs?

Hi all,
I am a student and trying my Hands on J2EE. The only question i have is why do we use EJBs when similar kind of functions can be done using Servlets also ...
I may be sounding dumb, but i really wanna know when to use EJBs and when not to use them.
Thanks,
Raghuveer

rags_raghuveer wrote:
Hi all,
I am a student and trying my Hands on J2EE. The only question i have is why do we use EJBs when similar kind of functions can be done using Servlets also ...
Wrong. Servlets handle HTTP requests. There are four flavors of EJBs. Are you saying that servlets duplicate all that functionality? You understand neither servlets nor EJBs.
I may be sounding dumb, Yes.
but i really wanna know when to use EJBs and when not to use them.That's actually a very good question. Here's one person's answer:
http://www.amazon.com/Expert-One-One-Development-without/dp/0764558315/ref=sr_1_1/104-2273680-6808730?ie=UTF8&s=books&qid=1192283013&sr=8-1
%

Similar Messages

Why should I use EJB

Hi,
My name is Gandharv Sirohi. I am a student, and new to EJB. I want to know why should I use EJB, before I can start learning it if every thing can be done using Java Servlets and JSP.
I tried to find out the answer to this question in books but there is no satisfactory answer.
Can some body help me understand this simple question. I will be thankfull

Hi gandharv,
It's true there are a lot of services available to both the web tier and the EJB tier. One of the
real strengths of EJB is support for transactional business logic. Web components can
explicitly demarcate transactions via UserTransaction, but container-managed transaction
support in EJB components at the business method level offers a much simpler approach
for developing and maintaining such applications. An example of some EJB services not available
in the web tier are : method-level security, RMI-IIOP access, message-driven beans,
transactional/persistent timer service, stateful components, extended container-managed
persistence contexts, guaranteed single-threaded execution, and interceptors.
Of course there are many services available to the web tier that are not in EJB. It's not
about picking one of the two that should always be used. Like any tool/technology, each has its strengths, weaknesses, and design center.
--ken

Why use EJB?

I am somewhat new to Enterprise Computing and I am a little unclear about these technologies.
Could someone please let me know why should we use EJB classes in web applications instead of normal classes for executing business logic?
Thanks and regards.
Soham

While I agree that most people using EJB's could have
built a better solution, I think both of the above
posters are completely wrong.
Not at all... You just don't get the point...
Most problems to which EJBs are applied are not problems to which EJBs should ever have been applied at all.
Before answering your question though, keep in mind
there are at least 3 types of EJB's, and all are
completely different. So I can only answer your
question at a high level. Here are the reasons people
might use EJB's:
And according to the specs you use them all or you don't use EJB...
They are container managed.Granted
They offer transactional awareness in your app.So can other solutions.
They are secure.Only as secure as you make them.
And you then tie yourself into a security system that may not be at all compatible with the ones you have already requiring expensive work to link several disparate systems together.
They are pooled, which makes them fast and eliminates
excessive object creation/deletion.There's many other things that are pooled.
They scale well in clustered/distributed environments
(as mentioned above).Clustered environments are indeed the only places where EJB have a definite advantage.
They abstract you from database access (yeah!).So do other technologies
They decouple you from the database so you can switch
from Oracle to MySQL with little or no impact and/or
changes to code (only driver changes).
That's exactly the same reason as above.
I've written my own abstraction layer once which worked faster and simpler than EJB.
We're now using another abstraction layer which does the same.
Use any ORM tool and you have an abstraction layer that's a lot easier to use than EJB, and a lot better performant.
I could go on and on, but don't have time. :-)You don't have a clue you mean. You're just spouting the party line as presented by the EJB priests.

Why using EJB when we have BC4J ?

Hello everybody
When I heared about EJB two years ago, I read couple of articles about it and found it useful. Now, when I read about BC4J and the ability they give us, a question pops up into my mind. Why should we use EJB ?
We can simple use BC4J and they are very good. I think there is something about EJBs that I dont know and thats why I think this way.
I'll appriciate any help.
Thanx in adnvace.

BC4J is a J2EE framework that lets you get down to business and focus on building your application.
It then gives you a choice of deploying your application using simple Java classes, or using an EJB Session Bean if you want to take advantage of EJB Session Bean's container-managed transaction (for example, to particpate in a transaction with another bean you didn't write), or method-level security.
The key points are that it saves J2EE developers tons of time by allowing them to not waste their time on writing application plumbing code to implement the many J2EE Design Patterns that all real-world applications need.
Around 800 Oracle Applications developers inside Oracle are using the BC4J framework to get their self-service web applications to market with better features in faster time than their competitors. The framework is filled with nuts-and-bolts application-building features that our own developers have told us are the boring, mundane, plumbing-kinda code that they don't WANT to write, debug, and test themselves.
It gives you a big advantage and allows you do decide whether or not to use EJB at deployment time instead of forcing you to make that decision up front.

Why to Use EJB rather then Direct Connection To Oracle Thru webDynpro?

Hi
Experts,
I want to know that why to use EJB to connect to oracle rather then direct connection via WebDynpro.
Please Give Me References to how to connect to oracle with EJB or WebDynpro.I want to tell you that i know JDBC,JAVA and basic web Dynpro.
Please Reply Me Dear Friends...ASAP.

EJB are better for a project beacuse the application is scalable, have less maintainence and have better performance.
Have you gone throght these:
Connect Oracle 9.2 DB to Web AS 6.40
web dynpro - database connection
web Dynpro application connecting to oracle
/people/ramesh.jandhyala/blog/2007/01/02/webdynpro-and-oracle-using-dtos
Regards,
Ashwani Kr Sharma

Why we use EJB

please tell me that , why we use EJB , i searched it on google but didn't find the answer .
Please help me out
Thanks in advance ...

http://en.wikipedia.org/wiki/Ejb
http://en.wikipedia.org/wiki/Enterprise_JavaBean
http://www.developer.com/java/ejb/article.php/1434371/Introduction-to-EJBs.htm
http://www.roseindia.net/ejb/
http://openejb.apache.org/hello-world.html

Why to use EJB Reference

hi all,
when i have an enterprise application with a session bean and a webapp,
i can access the session bean either over an ejb-reference in the webapp or directly access the jndi entry. what is the advantage of using ejb references? here an example of what i mean (both from within a webapp):
ctx.lookup("myBean"); // without ejb ref
ctx.lookup("java:comp/env/ejb/myRef"); // with ejb ref
I get back the same, so whats the difference?
rgds

With ejb-reference a container optimizes access to collocated beans. For example, say you have a deployment where beans A and B are both replicated in two different containers, for performance and/or availability reasons. For optimal use every instance of A in container would use instances of B also in container one. Likewise for container two. An EJB container can enforce this locality constraint using ejb-links, but not always using direct JNDI names.

Help needed - why we use ejb-ref element in ejb-jar.xml

hi all
can anyone tell me what is the purpose of this element in the ejb deploy descriptor? thanks

Suppose u have bean A, which needs to look up another bean B. Normally you wud need to use the jndi lookup using the initial context to access the bean B's home interface. If you use ejb-ref element you dont need to know the JNDI name of bean B. You can use ejb-ref-name instead. So you can say this is a short cut method of looking up and getting a reference to a bean's home object.

A Tip for using EJB 3.0 with WebLogic Ant Tasks

I started out writing this up as a problem, but then I found the answer so I'm, posting a tip instead.
When I tried to write an EJB [stateless] using EJB 3.0 in my legacy Weblogic ear project I started getting this error:
<pre>
No EJBs found in the ejb-jar file 'test'. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation.
</pre>
This is why: wlcompile will put the class files in the App-Inf/classes directory unless it finds an ejb-jar.xml file in the META-INF directory for the module it is working on. With EJB 3.0, I wasn't using an ejb-jar.xml file because it was unnecessary. Later, Appc runs and it complains because there are no classes module directory, they went into the shared ear folder instead.
Here's I how it working again: Use javac [not wlcompile] to compile the EJB 3.0 module and make sure that the class files go into the correct module directory. Then you can use wlappc to generate all the associated files for the EJB. I have sucessfully deployed an ear file that uses both EJB 2.x and EJB 3.0 with this approach.
I wish Weblogic's own ejb3.0 sample application used their split directory deployment.
Good Luck.
John Aronson

Hi John,
I am working on development an enterprise application using EJB 3.0 on Weblogic 10.
While developing, I am keeping all my classes (from ejb's as well as web) into APP-INF/classes directory. It is working fine for Web and ejb 2.0 packages, but ejb 3.0 packages, I get the following error when I keep my ejb 3.0 beans classes in APP-INF/classes directory.
No EJBs found in the ejb-jar file 'customer'. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation.
One solution is to keep the classes under customer ejb directory, but I wan tto keep all the classes in APP-INF/classes directory so that when using Eclipse IDE I can output all compiled sources into APP-INF/classes directory.
Has anyone faced this situation? Any suggestions to fix this issue?

Using EJBs in Web Dynpro

I have recently started to develop Web applications using the Web Dynpro framework. Coming from a pure J2EE world, I must admit that Web Dynpro has a few innovative features that I find interesting for user interface development. The use of component & view contexts, for example, is not unlike the ActionForms that one may find in a Struts application, but pushed a bit further. No complaints here.
What I do have some problems with is the whole CommandBean paradigm that is put forth by SAP (refer to the document <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webdynpro/using%20ejbs%20in%20web%20dynpro%20applications.pdf">Using EJBs in Web Dynpro</a>).
I do understand the usefulness of defining a model that will be used to generate and eventually bind to Context data structures. That's fine. What I do object to is the use of a so-called CommandBean to play that role. Again, coming from a J2EE world, I am familiar with the BusinessDelegate pattern - which would typically be used by a client application to invoke business logic on the server side. I would propose that a better, cleaner way of integrating EJBs with the Web Dynpro framework would be to use a BusinessDelegate for invoking business logic, and importing a separate and distinct ModelBean (instead of a CommandBean) to be used for defining and binding to Context data.
I have built one Web Dynpro application thus far. Instead of using a CommandBean, I created a ModelBean that extends my business object DTO (Data Transfer Object) (which is quite appropriate for that role, given that it implements all the get & set methods that are required for the business data that I need to model). My Web Dynpro application also makes use of an independant BusinessDelegate that is packaged with my EJB DC - this is a standard best practice on J2EE projects. I have been asked by the people working with me to modify this architecture to bring it more in line with the SAP way of doing things. I am open-minded and willing to learn and accept new ways of thinking and doing things. However, I fail to understand the usefulness of merging structure and behaviour by resorting to CommandBeans:
- It violates the MVC paradigm by having one object (the CommandBean) serve as both model AND controller as far as the Web Dynpro application is concerned. The CommandBean is obviously a model - since it is literally imported as such into the Web Dynpro application. It is ALSO a controller from the Web Dynpro's application perspective, since all calls to the back-end go thru the CommandBean via one or more of its execute_xxx methods. In contrast, the use of a business delegate by the Web Dynpro application clearly separates the model (the CommandBean... or rather, a more suitably named ModelBean) from the controller (BusinessDelegate).
- Doesn't carry its own weight. In other words, I haven't yet been provided with any valid justification for going thru the extra effort of coding the CommandBean's execute methods. It's been proposed to me that it somehow serves as an abstraction layer between the Web Dynpro application and the business logic. I would argue that it is the BusinessDelegate's role to abstract away the back-end logic from clients. If one does have a BusinessDelegate available, I would argue there's no need to code execute methods in a separate CommandBean. To prove my point, I would simply point out that all of the CommandBean examples that I have seen so far, either in How-To documents, or in production code, all follow the same pattern....
CommandBean.execute_doSomething() calls BusinessDelegate.doSomething()
Not a heck of an "abstraction" layer... I would in fact argue that it is worse than useless. If some major change occurs in the business logic that requires changing the doSomething() operation, we expect of course to modify the BusinessDelegate. The Web Dynpro client will also presumably need to be modified - that's to be expected, and unavoidable. But then, we'll also need to go about and change the CommandBean's execute_doSomething() method - again, extra work for no apparent benefit. Adding and removing business methods has the same implication. All this for an layer that simply adds the prefix execute_ in front of all business method calls... Is this "abstraction layer" worth the cost of creating and maintaining it ??
- Unnecessarily complicates error handling. I have been told that for technical reasons, it is recommended that all exceptions thrown by the CommandBean be of type WDException or WDRuntimException. But what if the client application needs to react differently to different failure scenarios ? When I create a business object, I might wish to provide the user with an error messages if connection is lost to the backend, and with a different error message if an object already exists in the database with the same attributes. In order to do that, I will have to catch the WDException, extract the cause, and continue processing from there... possible, yes, but clearly less standard and more labor intensive than the classical try/catch mechanism.
To say nothing about the fact that SAP's own API documentation clearly states that applications using Web Dynpro can reference and catch WDExceptions, but THEY MUST NOT THROW OR EXTEND IT !
- Produces unnecessary DCs. Page 6 of the aforementioned document presents an architectural view of a Web Dynpro project that uses a CommandBean. Why an extra DC for the CommandBean ?? I created my ModelBean class right inside the Web Dynpro project (in the Package view). That, to me, is where this class should reside, because it is created for no other reason that to be used by this particular Web Dynpro application. What is the benefit of placing it in its own independant DC ?
- Not a typical application of the Command pattern. The well-documented command pattern (Design Patterns - Gang of Four) has been devised mainly to enable encapsulation of request as objects, thereby making it possible to:
- specify, queue and execute requests at different times
- decouple execution of a command from its invoker
- support undo operations
- support logging changes so that they can be reapplied in case of system crash making it possible to assemble commands into composite commands (macros), thereby structuring a system around high-level operations built on primitive operations.
None of this applies to the way the SAP CommandBeans are being used. Not that much of an issue to people new to J2EE and/or OO development... but quite confusing for those already familiar with the classic Command pattern.
At this point, I fail to understand the advantage of merging structure (model) and behaviour (execute methods) through the use of a unique CommandBean object. Am I missing something ?

Thanks for your reply and your suggestion. I have posted in the Web Dynpro Java forum... and suggest those wishing to participate in this thread to refer to the Web Dynpro Java forum.
As for your answer, I'm afraid it doesn't satisfy me.
Reuse is hardly an issue, since the CommandBean is specifically tailor-made for the Web Dynpro application that needs to use it. I could hardly imagine building another application that would just happen to have the exact same needs as far as data structure and processing is concerned...
As for the right Eclipse environment... the CommandBean is not an EJB artifact - it is an EJB client. The aforementioned tutorial in fact suggests creating it in the Java perspective.
But thanks anyway for your time and suggestion

Using EJBs in Web Dynpro Applications

I have recently started to develop Web applications using the Web Dynpro framework. Coming from a pure J2EE world, I must admit that Web Dynpro has a few innovative features that I find interesting for user interface development. The use of component & view contexts, for example, is not unlike the ActionForms that one may find in a Struts application, but pushed a bit further. No complaints here.
What I do have some problems with is the whole CommandBean paradigm that is put forth by SAP (refer to the document <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webdynpro/using%20ejbs%20in%20web%20dynpro%20applications.pdf">Using EJBs in Web Dynpro Applications</a>).
I do understand the usefulness of defining a model that will be used to generate and eventually bind to Context data structures. That's fine. What I do object to is the use of a so-called CommandBean to play that role. Again, coming from a J2EE world, I am familiar with the BusinessDelegate pattern - which would typically be used by a client application to invoke business logic on the server side. I would propose that a better, cleaner way of integrating EJBs with the Web Dynpro framework would be to use a BusinessDelegate for invoking business logic, and importing a separate and distinct ModelBean (instead of a CommandBean) to be used for defining and binding to Context data.
I have built one Web Dynpro application thus far. Instead of using a CommandBean, I created a ModelBean that extends my business object DTO (Data Transfer Object) (which is quite appropriate for that role, given that it implements all the get & set methods that are required for the business data that I need to model). My Web Dynpro application also makes use of an independant BusinessDelegate that is packaged with my EJB DC - this is a standard best practice on J2EE projects. I have been asked by the people working with me to modify this architecture to bring it more in line with the SAP way of doing things. I am open-minded and willing to learn and accept new ways of thinking and doing things. However, I fail to understand the usefulness of merging structure and behaviour by resorting to CommandBeans:
- It violates the MVC paradigm by having one object (the CommandBean) serve as both model AND controller as far as the Web Dynpro application is concerned. The CommandBean is obviously a model - since it is literally imported as such into the Web Dynpro application. It is ALSO a controller from the Web Dynpro's application perspective, since all calls to the back-end go thru the CommandBean via one or more of its execute_xxx methods. In contrast, the use of a business delegate by the Web Dynpro application clearly separates the model (the CommandBean... or rather, a more suitably named ModelBean) from the controller (BusinessDelegate).
- Doesn't carry its own weight. In other words, I haven't yet been provided with any valid justification for going thru the extra effort of coding the CommandBean's execute methods. It's been proposed to me that it somehow serves as an abstraction layer between the Web Dynpro application and the business logic. I would argue that it is the BusinessDelegate's role to abstract away the back-end logic from clients. If one does have a BusinessDelegate available, I would argue there's no need to code execute methods in a separate CommandBean. To prove my point, I would simply point out that all of the CommandBean examples that I have seen so far, either in How-To documents, or in production code, all follow the same pattern....
CommandBean.execute_doSomething() calls BusinessDelegate.doSomething()
Not a heck of an "abstraction" layer... I would in fact argue that it is worse than useless. If some major change occurs in the business logic that requires changing the doSomething() operation, we expect of course to modify the BusinessDelegate. The Web Dynpro client will also presumably need to be modified - that's to be expected, and unavoidable. But then, we'll also need to go about and change the CommandBean's execute_doSomething() method - again, extra work for no apparent benefit. Adding and removing business methods has the same implication. All this for an layer that simply adds the prefix execute_ in front of all business method calls... Is this "abstraction layer" worth the cost of creating and maintaining it ??
- Unnecessarily complicates error handling. I have been told that for technical reasons, it is recommended that all exceptions thrown by the CommandBean be of type WDException or WDRuntimException. But what if the client application needs to react differently to different failure scenarios ? When I create a business object, I might wish to provide the user with an error messages if connection is lost to the backend, and with a different error message if an object already exists in the database with the same attributes. In order to do that, I will have to catch the WDException, extract the cause, and continue processing from there... possible, yes, but clearly less standard and more labor intensive than the classical try/catch mechanism.
To say nothing about the fact that SAP's own API documentation clearly states that applications using Web Dynpro can reference and catch WDExceptions, but THEY MUST NOT THROW OR EXTEND IT !
- Produces unnecessary DCs. Page 6 of the aforementioned document presents an architectural view of a Web Dynpro project that uses a CommandBean. Why an extra DC for the CommandBean ?? I created my ModelBean class right inside the Web Dynpro project (in the Package view). That, to me, is where this class should reside, because it is created for no other reason that to be used by this particular Web Dynpro application. What is the benefit of placing it in its own independant DC ?
- Not a typical application of the Command pattern. The well-documented command pattern (Design Patterns - Gang of Four) has been devised mainly to enable encapsulation of request as objects, thereby making it possible to:
- specify, queue and execute requests at different times
- decouple execution of a command from its invoker
- support undo operations
- support logging changes so that they can be reapplied in case of system crash making it possible to assemble commands into composite commands (macros), thereby structuring a system around high-level operations built on primitive operations.
None of this applies to the way the SAP CommandBeans are being used. Not that much of an issue to people new to J2EE and/or OO development... but quite confusing for those already familiar with the classic Command pattern.
At this point, I fail to understand the advantage of merging structure (model) and behaviour (execute methods) through the use of a unique CommandBean object. Am I missing something ?

Hi Romeo,
You would be disappointed, this reply ain't anywhere nearby to what you are talking about...
I wanted to mail you, but you have not mentioned your email in your profile.
I am really impressed by your flair for writing. It would be far better had you written a blog on this topic. Believe me, it would really be better. There is a much wider audience waiting out there to read your views rather than on the forums. This is what I believe. To top it, you would be rewarded for writing something like this from SDN. On the blogs too, people can comment and all, difference being there you would be rewarded by SDN, here people who reply to you would be rewarded by you. Doesn't make much a difference.
Anyways the ball is still in your court
As far as I am concerned, it has still not been much time since I have started working on Web Dynpro. So can't really comment on the issue...
Bye
Ankur

[J2EE:160167] uses ejb-links but no EJB modules

Dear All
Seeking support/assistance to resolve the below problem. I'm using laster Jdeveloper 11g software publish in 2011.
weblogic.deployment.EnvironmentException: [J2EE:160167]The module abc-ViewController-context-root in application abc_Project1_abc uses ejb-links but no EJB modules were found for this application
Please provide guidelines why this appears and how to resolve it.
Best Regards
Shahebaz Shaikh

The module abc-ViewController-context-root in application abc_Project1_abc uses ejb-links but no EJB modules were found for this application
Is the application deployed as an EAR application with web and ejb modules? If not, deploy as an EAR application.

How to use EJB Remote with Netbeans7.0 ?

I try to create Session Bean in Netbeans 7.0 but when I select Remote then I have to select Java Application in Netbeans. It different from Netbeans 6.8 ,6.9 which in Netbeans6.8, 6.9 not have dropdown for select Java Application when we choose Remote. So I don't know how to use EJB Remote in Netbeans7.0 then I click finish. After that, I create Project is Enterprise Application Client. but in Main.java at this line
BLSessionRemote obj = (BLSessionRemote)ctx.lookup("TestBean");
It can't find BLSessionRemote in Session Beans. How to use EJB Remote with Netbeans7.0 ?

Why don't you ask this question in the Netbeans mailing lists, where it belongs. Come here when you have problems with code you wrote yourself.

Could I use EJB in mission-critical task,like telecom realtime billing?

We will begin a project about telecom billing.The key point of the project is the realtime billing,which is must be processed with high speed and efficiency.We have a plan to use Tuxedo on which to run some services coded by c lanaguage.Other management facilities and interfaces with other system could be built by java(EJB).
Now ,I am wonder why couldn't we using EJB in billing task ? Is there any success story about using EJB model to build mission-citical system? or is EJB good for that?
thanks

Joy Wind,
AFAIK, The answer is NO. Java itself is not "currently" suitable for real time applications.
However, there is a community process going on at http://www.rtj.org/.
There is also a reference implementation available which you can check out.
http://www.timesys.com/prodserv/java/index.cfm
I guess you can use it for proto-types and demos. However, if you want to use it in some mission critical application then you have to wait till it becomes a part of standard java.
hope this helps.
regards,
Abhishek.

Web Dynpro using EJB to implement database access for MS SQL 2005 server

Hello,
For using EJB model in Java Web Dynpro, why do I need another dictionary project with all the required tables (there are 5 tables in my project), when the same database is already created in back end MS SQL 2005 Server.
Thanks
Srinivas

Thanks for your reply Charan,
I am fairly new to EJB. I have created only one session bean (called TrainingBean) and created all the business methods inside it.
Here is my database schema, with the following 5 tables
Courses
CourseSchedules
Students
Registrations
Competencies
Here are the session bean business methods:
changeCourse(String)
changeStartDate(String)
createCourse()
createCourseSchedule()
getCourses()
getCourseSchedules()
registerStudent(String)
unRegisterStudent(String)
Is this good way to implement EJB, or should I create multiple session beans and multiple corresponding Data access command beans ?
Thanks a lot
Srinivas

Why do we use EJBs?

Similar Messages

Maybe you are looking for