EJB is Scalable . EJB has persistence. EJB has Deploy Time Customization. EJB has Transaction Management.
These are all the things given in Head First Ejb.But Please explain it with example and justify me with code and scenario for all of the points, So that I can say boldly the advantages to anyone,as I dont have real time exp in EJB.
IF anyone help me I expect kathy my java god himself to help me [ September 01, 2006: Message edited by: Mark Spritzler ]
Let us establish one undeniable fact: enterprise programming is hard.
Sure, Servlets are superb at handling client requests, and Java Server Pages are fabulous at generating markup for a client, but request-response programming is not where Java developers earn their salt.
Java developers earn their salt by implementing some seriously complicated business logic. Fiddling with a Servlet�s request and response objects all day long won�t impress anybody.
Enterprise programming is hard, but EJBs make some of the toughest parts of enterprise programming just a little bit easier.
What are the common challenges enterprise developers encounter?
Enterprise programming is hard. In an enterprise environment, there are a number of mission critical challenges that must be addressed and implemented properly, otherwise applications will fail.
Some of the typical challenges that enterprise developers encounter include: Database Access:
How do we ensure that that data in our application is completely, totally, 100% in sync with what is in the database? This is a requirement of almost every enterprise application, but without an intimate knowledge of how a database works, implementing database synchronization properly is a significant challenge. Transactional Updates:
If I'm updating three different databases in an �all or nothing� type of scenario, and one of those database writes fails, how do I roll back writes to the other two databases?
What if one of those databases is in Kalamazoo and two of them are in Tuktoyaktuk? How do you maintain the transactional integrity of your updates? Distributed Programming:
I'm in Gun Barrel, Texas, but I want users in Antigonish, Nova Scotia to remotely invoke the methods in my Java components. How do I make a local component accessible to remote applications? Multithreading:
Multithreading remotely accessible components that must handle a gargantuan load is a difficult and onerous task. How are you going to do it? Secure Access:
You only want Double Agents to call one method of your JavaBean, and only Secret Agents can call the other method. How ya gonna do it? With a typical Java application, it�s almost impossible.
Database concurrency, distributed transactions, multithreading, distributed programming and secure accesses are all issues our enterprise applications must deal with.
If we have to deal with these issues alone, we�re going to be in an ugly world of hurt. The good news is that EJBs deal with these issues, and by dealing with them, they make enterprise programming much, much easier.
Kameron, Thanks for the nice description. However, EJB's entity bean and CMP's failure over the past few years, have earned such a degree of disrespect that many companies think many times before jumping on the EJB bandwagon. The only components that are used are MDB and SLSB. SLSB's importance is fairly low - can be developed easily in-house. So the only thing that remains is MDB, and I agree that many companies do use only MDBs extensively. With frameworks like spring/POJO and with stable frontends with struts/JSF, I don't see a great need of EJBs in general, in most apps.
What he is saying is that it is such an open ended question that there isn't a simple short answer and could take forever to really answer that question. It is actually kind of like a troll question, in this case he is really wanting to know, but others might ask just to get people to spend all their time trying to answer. It is better if you read a good book on the subjec tot answer such questions.
Jeroen T Wenting
Joined: Apr 21, 2006
especially in the light of the rather inflamatory title.
Joined: Oct 23, 2002
I didn't say SLSB is not useful. What I meant is that with struts like strategy pattern mechanism where the complete transaction is managed at the framework level, and using POJO in the backend with the help of the HttpSession features for session data retention and DTOs/HashMap for moving data around, there is not much need of SLSB or SFSB. The persistence layer can be managed by Hibernate kind of stuffs - eliminating the need of Entity beans. So my only point is, with the maturing J2EE based technology along with a lot of eye opening by other framework authors (Struts, Shale, Spring, JSF, etc), one can easily see the point.
EJB 3.0 may be totally different - in terms of simplicity, etc.., but didn't it arrive a little too late?