SCEA -- does anybody need it at all?

[Hitry Mitry]

In my company they just started an internal project directed at eliminating all EJB's from our software. They plan to replace all entity beans with DAO's within a month and then even the SLSB will follow, replaced by Spring instantiated objectes.

I know that in many other companies they are doing the same - EJBs have firmly won a reputation of evil to get rid of. It also appears to have become a fashion of some sort to badmouth EJBs. You are not "cool" unless you can say a couple of words about how Spring framework is so great and J2EE sucks.

I wonder why all of you are still doing this heavily bean-centered assignment? It looks like there will be nothing left of EJB within a year!
[ July 17, 2005: Message edited by: Hitry Mitry ]

[Jesus Angeles]

it will take time for spring to 'spring up', if ever it will,

so scea, can be useful still, for sometime, if ever ejb-centered thing would really be replaced somehow someday by spring, or any other framework that is

[David Follow]

As far as I remember in Cade's book he didn't use EJBs (EB) either, he used DAOs. So I guess you should be good with DAOs only.

D.

[Steven.xu xu]

EJB especially Entity Bean is only one part of an enterprise project. Using entity bean or other persistent framework like JDO or Hiberlate is based on the nature of your application. Choising a suitable persistence layer is the big challenge for an architect. You cannot say one technolgy is bad just because that it does not fit your application, in this case I only can say that the architect was not good enough to do his job.

[Hitry Mitry]

Originally posted by David Follow:
As far as I remember in Cade's book he didn't use EJBs (EB) either, he used DAOs. So I guess you should be good with DAOs only.

D.

Cade uses SLSBs

[Jeremy Hsu]

J2EE is still a more mature framework. There are more developers that know J2EE very well. When you are in a big project, it is better to use J2EE for the above 2 reasons. Although there are a lot of good things for Spring frameworks, it still requires TIME for it to catch up to the maturity of J2EE. Also, do not forgot J2EE also is known for communicating with CORBRA, and there are still places where few company is reluctant to migrate their legacy system. Furthermore, do not forget J2EE is still evolving, and therefore, I still do not see that is the end for J2EE.
[ July 18, 2005: Message edited by: Jeremy Hsu ]

[Dhiren Joshi]

And for Java 5 with annotations they change the concept of Entity beans totally. The presistent layer could be hibernate as well so the EJB framework with all it offerings still remain without the heavy beans..
I suggest u take a look at Java 5 and EJB 3.0

HTH
Dhiren

[Vinay Singh]

Before taking the exma , even I was contemplating whether its worth it as i was focussing on EJb and their versions etc!
But while taking part 1, you study a lot esp about patterns and if you are taking part 2 from learning point of view , you would end up understanding and designing domain model and learning UML.
Spring is just another framework like petstore and struts which makes life easier for you.But the actual problem is undersatnding and desiging the domain model which is actually the job of designer/acrhitect.
In one of my projects an architect had focussed on on J2EE patterns instead of requirements. SO the proejct looked nice on paper but after one year I know that its all screwed up.!!
Hence I would say this certification is more like learning experience than being pure J2EE.
Cheers!!

[Theodore Casser]

Originally posted by Hitry Mitry:
I wonder why all of you are still doing this heavily bean-centered assignment? It looks like there will be nothing left of EJB within a year!

Getting back to the original question..

I don't know that it really matters how you feel about EJBs or other portions of the SCEA assignment. I think the goal is wholly separate from the feelings on the matter. The goal is to see if you can carry out a design assignment within specific bounds, the same as any test.

One of the things that struck me while I was working on Part II was that I wouldn't be developing the system the way I was designing it (were it a real job for a client). A lot of that is personal preferences in the end, some experience, tricks of the trade, etc. I'd probably opt for another framework, or find other means to avoid using EJBs as well (pending what I think of EJB 3.0, to be honest).

The basic idea, IMHO, is to see if you can carry through an architecting assignment that uses Sun's own technologies, irregardless of whether you think they're the best fit for the solution, a lowest-common demoninator for using the Java EE structure. And that's a worthwhile challenge in itself.

[Rick O'Shay]

Originally posted by Hitry Mitry:
In my company they just started an internal project directed at eliminating all EJB's from our software. They plan to replace all entity beans with DAO's within a month and then even the SLSB will follow, replaced by Spring instantiated objectes.

I know that in many other companies they are doing the same - EJBs have firmly won a reputation of evil to get rid of. It also appears to have become a fashion of some sort to badmouth EJBs. You are not "cool" unless you can say a couple of words about how Spring framework is so great and J2EE sucks.

I wonder why all of you are still doing this heavily bean-centered assignment? It looks like there will be nothing left of EJB within a year!

[ July 17, 2005: Message edited by: Hitry Mitry ]

Ignorance is bliss and it sounds like you and your company are a very happy group. EJBs serve a vital purpose despite being difficult to manage. You're goal of removing EJBs is asinine. What you need to do is determine where it is causing you problems and fix the problems. Removing EJBs is not a objective unto itself.

How do you plan on persisting your data without entity beans? Spring? Then get somebody who has read the first paragraph of the Spring manual and fire the person who suggests it. Spring doesn't do persistence. If you are using EJBs entity beans then you probably need Hibernate as a replacement and that integrates with Spring. Surprise: EJB 3.0 is modeled after Hibernate. In other words use EJB 3.0 going forward unless you want to ignore that it's a widely excepted standard with massive tool support and that it addresses a wide range of vital scalability requirements.


Suggestion: use Spring as a beautiful framework around EJB 3.0 or Hibernate with EJB Stateless and Stateful session beans. Use your God given noggin rather than going off on a misguided EJB witch hunt. Most of the fubarred EJB installations were built by misgided and uninformed sheep.

[Robert Hayes]

http://www.neward.net/ted/weblog/index.jsp

"EJB Revisionist History... and a look forward "

[Hitry Mitry]

Originally posted by Rick O'Shay:


Ignorance is bliss and it sounds like you and your company are a very happy group. EJBs serve a vital purpose despite being difficult to manage. You're goal of removing EJBs is asinine. What you need to do is determine where it is causing you problems and fix the problems. Removing EJBs is not a objective unto itself.

How do you plan on persisting your data without entity beans? Spring? Then get somebody who has read the first paragraph of the Spring manual and fire the person who suggests it. Spring doesn't do persistence. If you are using EJBs entity beans then you probably need Hibernate as a replacement and that integrates with Spring. Surprise: EJB 3.0 is modeled after Hibernate. In other words use EJB 3.0 going forward unless you want to ignore that it's a widely excepted standard with massive tool support and that it addresses a wide range of vital scalability requirements.


Suggestion: use Spring as a beautiful framework around EJB 3.0 or Hibernate with EJB Stateless and Stateful session beans. Use your God given noggin rather than going off on a misguided EJB witch hunt. Most of the fubarred EJB installations were built by misgided and uninformed sheep.

Wow. An EJB bigot.
Gawd, who could think they exist!
[ July 23, 2005: Message edited by: Hitry Mitry ]