EJB design: when to use what
I am trying to understand when to use:
2)servlets and session beans
3)servlets, session beans and CMP EJB
4)servlets, session beans and BMP EJB
that should be considered during the design/architecure.
It would be nice if some one could refer me to sites/books that does give a good idea on the pros and cons of the same.
thanks in advance for taking your precious time.
- when to use what by Jesper Hvid on April 18 2002 05:10 EDT
- when to use what by James Walker on April 18 2002 14:47 EDT
- when to use what by JaganRao Mani on April 18 2002 23:52 EDT
Mastering EJB II chapter 12 has a lot of thought in that direction. I recommend you buy the book, it's the best one I own!
but not necessarily the best one out there..... :-)
Ha haa...if only the best ones are honestly talking about EJBs, I would have been programming peacefully...
It's as much of a business requirement as a technical one.
EJB is a component-based architecture. A good book that discusses the component-based approach is "Business Component Factory" from OMG Press.
If you want an argument against EJB just find a group of programmers and throw a rock...
Well, i dont want to find an argument. I want to find out how could i tell my team or anyone else for that matter who wants to make a decision on wether servlets is sufficient or do they need to have ejb layer if so what would be the pro's and con's of that approach.
I do agree to certain extent that its related to business, but that does not mean that we jump into any technology when same thing can be achived with less resources.
hope i am makeing myself clear.
When I say that it's a business decision what I mean is that EJB are more difficult to use, but they provide much of the foundation for a component-based solution.
If you have a large team of people or want to promote reuse then component-based development is a good way of doing that. If you're a small group of developers and you're priority is speedy delivery then EJB is probably not for you.
If you use EJB like a database server or to implement a non-layered design, you're going to loose out.
<grin>Here is one programmer!</grin>
I would like to know what you mean by a 'business component'. What's wrong with a straight normal Java class that properly models a domain object?
<grin>Here is one programmer!</grin>
...see what I mean? :-)
> I would like to know what you mean by a 'business
"Business Component" is not my term. It's part of the title of the book. The book defines a business component as "the Software implementation of an autonomous business concept or business process. It consists of all the software artifacts necessary to represent, implement, and deploy a given business concept as an autonomous, reusable element of a larger distributed information system."
> What's wrong with a straight normal Java class that
> properly models a domain object?
Nothing. I was very careful not to say "EJB is the only way to do component-based development." All I said was that it offers alot of the framework that you'll need. You can also use straight normal JavaBeans or provide your own straighter normaller framework.
It was implied in Rao's original post that he was trying to decide whether or not to use EJB's. All I'm saying is that it's an easy option to rule out if you don't need to do component-based development.
Once you've decided that you *do* want to do component-based development *and* you feel that the down-side of EJB is worth the up-side, then "Mastering EJB II" and books like it will help you make a decision between entity beans and session beans and between CMP and BMP.
I would also take a look at
I just started to go through it. It goes through basic architecture and some of the design decisions on when to choose EJBs and when not to.
I remember a few month ago there was discussions in some of the IT firms about the costs of EJB development v the cost of non EJB development. If I remember correctly a lot of the talk centered around people using EJBs regardless of the functional/non functional requirements of the system they were designing.
Application servers are also expensive (unless you use JBoss). Some vendors I beleive where thinking of releasing versions of their products that did not contain an EJB server. Haven't heard recently if that is still anyones plan.