Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Hi Ranchers, EJB 2.0 or EJB 3.0

 
Srinivasan Rengan
Ranch Hand
Posts: 122
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
I have just completed my SCWCD 1.4. I wish to take up SCBCD. I have started preparing for the exam. How long will it take for a person to complete the preparation?
And also, I heard that EJB 2.0 would be replaced with EJB 3.0 anytime. Should I have to wait till EJB 3.0 comes into being or should I just give this exam off!!

I am confused!! Friends, I need your suggestions...

Thanx in advance!!
Srini
[ October 19, 2005: Message edited by: Srinivasan R ]
 
Theodore Casser
Ranch Hand
Posts: 1902
Hibernate Netbeans IDE PHP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's going to be a while, I think, before Sun updates the SCBCD exam. Java EE 5's not out yet in general release (release should be in 1Q06 according to JSR 244, which covers Java EE 5), which includes EJB 3.0 and other technologies. So I'd not expect an announcement for the exam that includes EJB 3.0 before June 2006 at the earliest, and likely not until next fall.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Look for Bert Bates' comment in SCBCD 1.4 ??

And also How long until EJB 3.0?
 
Reza Rav.
Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I suggest you wait
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Keep in mind what happened from 310-080 to 310-081 (SCWCD 1.3 to 1.4); for example, the later exam still covers "classic tag handlers", even though the new "simple tag handlers" are preferred - it was kept around because the maintenance of the existing code base is a valid concern. So the next SCBCD may still deal with some pre-EJB 3.0 technology - unless Sun makes it an entirely new (Object Relational Modelling?) certification.

And despite the fact that 310-081 does not cover Java ServerFaces, Struts, or Velocity, you still decided to complete the SCWCD! So what is the issue here?
[ October 19, 2005: Message edited by: Peer Reynders ]
 
Reza Rav.
Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear Reynders
As I read some doc about EJB 3, the structure is change.For example entity bean isn't usefull now (many developer prefer Hibernate instead)and maybe it will have a huge change on it's structure,also I read that in Session bean there will be no Home interface or something like that(I'm not sure).
So it is not like SCWCD, for SCWCD core remain the same just some additional feature will added to new version but in EJB 3 core will change, I want to get both SCBCD,SCWCD but for SCBCD I prefer to wait until new version arrive.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Reza Ravasizadeh:
but for SCBCD I prefer to wait until new version arrive.


You are so utterly missing the point. I would be first in line waving the the Spring/Hibernate/iBatis banner - but that is just my preference and trying to shoehorn those technologies (or EJB 3.0 for that matter) into an existing system that is already providing business value is a Very Bad Idea. Even Rod Johnson in J2EE Development without EJB states:

EJB stands on the wrong side of the Pareto Principle. It imposes undue complexity on the majority of cases to support the special requirements of the minority. For example, perhaps 10% of applications need distributed business objects; EJB is an infrastructure closely associated with distribution. EJB 2.1 and earlier entity beans are designed to be independent of the data store; the great majority of J2EE applications use relational databases, and gain no benefit from this. (While it offers a portability between data stores that�s of more theoretical interest than practical value, it doesn�t shine with object databases either. They are best accessed using their own rich APIs, or using a solution such as JDO.)
EJB remains the best choice for applications that genuinely need object distribution, especially if they are implemented wholly in Java or need to use IIOP as the communication protocol. This type of application is rarer than might be imagined.
EJB is also a pretty good solution for applications that are heavily based around messaging, as message driven beans are relatively simple and effective components.
One of the best examples of an application type to which EJB may add real value is financial middleware.
Financial applications can involve processing that is so costly in time and computing power that the cost of remote invocation is (atypically) less than the cost of processing. For such applications, object distribution makes sense, and EJB is a good way of implementing it. Financial middleware is also heavily message-oriented, and suited to use of MDBs.

I believe that such applications are part of the 10%.
Of course there may be strong political, rather than technical, reasons that dictate the use of EJB. This is outside the scope of this book. In my experience, political battles can be much harder to win than technical battles, and you�ll need Machiavelli rather than me as your guide.
I believe that EJB is a declining technology, and within three years it will be relegated to legacy status, despite attempts to make it more relevant with EJB 3.0. But this book focuses on what you can do right now to build enterprise applications. So if you have a requirement that�s currently best addressed by EJB, I would advise you to use EJB�for now.

If you want to avoid financial institutions that actually may have enough cash to pay good salaries/fees - your choice. If you refuse to gain experience by working on systems that already exist and "only" use EJB 2.0/2.1 (for better or for worse) - your choice. If you refuse to work on projects that have to interact with existing systems using EJB 2.0/2.1 - your choice. However you are really narrowing your field of options, as only a minority of IT projects are "green-field", unconnected systems. And a large portion of people that will eventually get to "play" with EJB 3.0 are the ones with "experience" and some of that experience will come from maintaining systems that use EJB 2.0/2.1.
[ October 20, 2005: Message edited by: Peer Reynders ]
 
Reza Rav.
Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't mean that EJB 2.0 or 2.1 are unuseable. I also don't want to loose any of that things you explain.
Now I work in a project that is about 80% EJB(Telecom Network management) and I know that I will work with EJB 2 at least in next 2 year.

It is obvious for me:
When I want to study for certification I should consume lots of my time so I prefer to study something that is usefull for future not just for backward compatibility.
very simple answer:
Software have lifetime so I want to get things that don't die tommorow.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Reza Ravasizadeh:
I will work with EJB 2 at least in next 2 year.


Now we're getting somewhere. You personally probably have sufficient EJB 2.0/2.1 experience in the field to avoid the silly mistakes that were made in the dawn of EJB - making EJB 2.0/2.1 certification less valuable.

However you should consider the fact that many posters here lack that experience - they really could benefit from some exposure to the technology so that they can optimize an existing system without a total rewrite when they are set loose on it.

Also these new technologies usually don't take over in isolation. To draw a parallel from the MS world: when ASP.NET was introduced into the market the people with ASP/COM experience/knowledge were working with ASP.NET, not the ones that had only learned ASP.NET. This of course was done because most sites already had significant ASP/COM content that wasn't going to be tossed anytime soon - they needed the transition process to be as smooth as possible as it may be ongoing for years.

Similarly many systems that will start to use EJB 3.0 will already use EJB 2.0/2.1 and most cases the parts that "kind of work" won't be rewritten anytime soon.

You may also be underestimating the staying power of so-called "legacy technology" (2 years). The simple truth is that many existing production systems won't be rewritten unless someone can make a convincing business case that rewriting will save a lot more money than it costs (and doesn't cause the business to loose other opportunities) - but those same systems will probably require regular maintenance over the years to adapt to the world that is changing around them.
 
Will Lee
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OKOK, after read all your debate, I decide to study for this test from next week on. After all... my boss is gonna pay me.

One of my coworker came back from Java in Action conference and discussed this situation w/ us. The opinion from my boss was, EJB2.0/1 was there for many years. So many systems already use it. Therefore it's very likely that EJB3 has no good future. 'coz if anyone try to switch to EJB3, why not use Hibernate/iBatis/Spring?
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Will Lee:
'coz if anyone try to switch to EJB3, why not use Hibernate/iBatis/Spring?


The one thing EJB3 will have going for it is that it will be part of the future Java EE spec - Hibernate/iBatis/Spring will not. The server vendors will have to implement EJB 3 in order to claim compliance with the spec. Implementation of server features that benefit (performance or otherwise) Hibernate/iBatis/Spring will be entirely voluntary. Meanwhile Hibernate/iBatis/Spring has to constrain itself to general Java EE features to remain portable between all containers/servers.

So Hibernate/iBatis/Spring will always be an add-on, EJB will always be part of the "box". It remains to be seen whether EJB 3 will be judged as "good enough" by the development community to steal momentum from Hibernate/iBatis/Spring.
 
Srinivasan Rengan
Ranch Hand
Posts: 122
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow!!
Elevated to have started an interesting thread!!
Wish Kathy or Valentin could suppliment this thread with some inputs!

Thanx,
Srini
 
Reza Rav.
Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The opinion from my boss was, EJB2.0/1 was there for many years. So many systems already use it. Therefore it's very likely that EJB3 has no good future.


EJB3 will be newer version not a comptetor against EJB2
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic