Hello EJB gurus,
EJBs are suppose to be distributed components. If you know that your component will not be in a distributed environment does it make sense at all to model them as EJBs. Take, for example, the Pet Store demo in the Sun blueprint. The shopping cart is a stateful session bean. To me, the shopping cart is not a distributed component. It should run on the same server as the pet store web app and no other client is going to access it. So why make it a session bean? What does making it a session bean buy you that making it a regular plain old java class in the http session doesn't. Object instance pooling is one advantage of ejbs, but is the activation/passivation overhead worth it? security and transactions support are the other two services I often heard about ejbs...but in this case the blueprint is not making any use of ejb declarative security and the shopping cart doesn't seem to have any need for declarative transaction support either. So why make this simple shopping cart a session bean? Any comments are appreciated. tinou
Don't be too down on the example, it would be next to useless to a newbie EJB developer if it threw in everything you mention. It would be overload for the person trying to learn this stuff.
Your argument that the shopping cart could be an HttpSession object is not invalid (it could be) but the example is not showing you where you must use a session bean, it's just showing where you could use one.
In reality, the way your apps server implements session sharing between servers in a cluster will tend to determine how you do this sort of thing. There are many other threads on this site which discuss HttpSession and session beans so I won't go into a long diatribe on the pros and cons here.
Declarative transactions and security are very useful in the right places. It's not that you couldn't do these things programatically, it's just that making them declarative puts them into someone elses hands (if you go along with the roles and responsibilities Sun defines in the EJB spec) and allows the developer to concentrate on writing the business value added code.
However, you do imply a point that I definitely agree with. Over the last year or two people have made very silly statements like "All development going forward will be EJB" and such like. It has become the Mount Everest of technology (It's used because it's there) in situations that either didn't warrant it, or were totally inappropriate for it. I actually think XML is guilty of the same in a lot of ways. How many times have you heard people say "We should use XML/EJB for that" without even letting you get more than 2 sentences into defining the problem? ;-)
The situation looks set to improve here, as the economy softens the applications servers start to look expensive so people are thinking a bit more about things. That's where sites such as this one are really useful, they let you ask people who've played the game before.
That's the long answer.
Short answer: Yes we need them, in some places, but not everywhere.
first of all EJB are not supposed to be distributed components, but yes they can be distributed components. thats the beauty of EJB that they can made to run inside a single box as well in a distributed environment.
EJB in a nutshell is a frame-work for writing componentised application, encapsulating ur business logic/functionality and putting them into components for re-use. u can deploy these components in one box (single point of failure) or distribute them in more boxes and extracting such benefits as fault-tolerant, fail-over n load balancing.
but yes as u mentioned use of EJB has to be very judicious and not use EJB for the sake of it. the right problem and the right solution can give u a true EJB scalable application.
true, you can run all your ejbs in a single vm and your server will optimize your non remote calls but this is not part of the spec. it just seems that we are writing ejbs with all these patterns to get around the problems that we should not deal with in the first place.
EJBs are not just for distributed components. They also address issues of concurrency, transactions, object pooling, persistence (well, kinda =) ), security, etc. Do you need them? Well, technically no. But I sure like their ability to make my job easier.