Beginning EJB

[Nagu]

Hello All,

I have interests to pursue career in components development (EJB ).
Where do I start. I have good knowledge about JAVA language but not on
any other J2EE or J2Se technologies? What are the prerequisites to
learn EJB?

Thanks Much

Nagendra

 

[Ann]

Hello All,

I have interests to pursue career in components development (EJB ).
Where do I start. I have good knowledge about JAVA language but not on
any other J2EE or J2Se technologies? What are the prerequisites to
learn EJB?

Thanks Much

Nagendra

I heard a rumor that EJB is now "old hat." Can anyone confirm?

 

[Michael Borgwardt]

I heard a rumor that EJB is now "old hat." Can anyone confirm?

As in "nobody cares for it anymore"? Definitely not. There isn't
really anything that supersedes it.

Quite, the opposite, actually: the new EJB 3.0 spec is considered
a big improvement. The thing is that EJBs are not for everyone: they
add a lot of overhead (both in development and performance-wise),
and most applications don't actually need the "value added" they
provide. This has become more common knowledge than it used to
be, when EJBs were hyped relentlessly. There are a lot of people
who bought into the hpye and were disappointed with the results
because EJBs were simply not the right tool for their problem.

 

[Darryl L. Pierce]

I have interests to pursue career in components development (EJB ).
Where do I start. I have good knowledge about JAVA language but not on
any other J2EE or J2Se technologies? What are the prerequisites to
learn EJB?

Start off by using a good text reference. I recommend _Enterprise Java
Beans_ from O'Reilly, along with a copy of Eclipse, JBoss and JBoss-IDE.
Those together make for an excellent learning environment.

 

[Darryl L. Pierce]

I heard a rumor that EJB is now "old hat." Can anyone confirm?

I heard that FUD in Java newsgroups is now "old hat". Can anyone confirm?

 

[Collin VanDyck]

I heard a rumor that EJB is now "old hat." Can anyone confirm?

EJB 2.x is certainly awful in a lot of ways. As has been mentioned, 3.0
should take away a lot of the pain, and I'm really looking forward to it!

 

[Ann]

I heard that FUD in Java newsgroups is now "old hat". Can anyone confirm?

Good one, made me smile ;-)

 

[Darryl L. Pierce]

Good one, made me smile ;-)

Right back atcha, missus.

 

[Darryl L. Pierce]

EJB 2.x is certainly awful in a lot of ways. As has been mentioned, 3.0
should take away a lot of the pain, and I'm really looking forward to it!

What, specifically, would you consider to be painful about 2.x?
Especially with 2.1, I find it to be a breath of very useful fresh air.
1.x was painful, sure, but 2.x has been quite useful and IMO powerful a
tool to use.

 

[Don Conrad]

Start off by using a good text reference. I recommend _Enterprise Java
Beans_ from O'Reilly, along with a copy of Eclipse, JBoss and JBoss-IDE.
Those together make for an excellent learning environment.

What about using MyEclipse to get the J2EE support?

 

[Darryl L. Pierce]

What about using MyEclipse to get the J2EE support?

I've never used it. What does it offer the JBoss-IDE doesn't?

 

[Nagu]

Thanks everyone for the advice.

Nagendra

 

[Collin VanDyck]

What, specifically, would you consider to be painful about 2.x?
Especially with 2.1, I find it to be a breath of very useful fresh air.
1.x was painful, sure, but 2.x has been quite useful and IMO powerful a
tool to use.

I was not around for 1.x, and with regards to 2.x the home/remote stubs,
interface implementation, etc.. In other words, I think working with a
Hibernate-esque solution for persistence seems like a lot easier way of
working with EJB.

 

[Darryl L. Pierce]

I was not around for 1.x, and with regards to 2.x the home/remote stubs,
interface implementation, etc..

What way would you define, then, for working with a remote object?

 

[Collin VanDyck]

What way would you define, then, for working with a remote object?

I did not say that I know of a better way. From what I understand 3.0
will be much simpler.

 

[Darryl L. Pierce]

I did not say that I know of a better way. From what I understand 3.0
will be much simpler.

How will 3.0 make working with remote objects easier? Sorry to ask so
many questions, but from where I stand the way the EJB 2.x specification
works is quite nice and efficient. It hides the actual creation of the
EJB reference while giving a clean representation of the business
methods of the remote object to the client. From the client's
perspective, you cannot tell that you're dealing with a remote object.
So, when I hear someone calling that "painful" it makes me wonder how
they would do things differently to alleviate that pain...

 

[Michael Borgwardt]

How will 3.0 make working with remote objects easier? Sorry to ask so
many questions, but from where I stand the way the EJB 2.x specification
works is quite nice and efficient. It hides the actual creation of the
EJB reference while giving a clean representation of the business
methods of the remote object to the client. From the client's
perspective, you cannot tell that you're dealing with a remote object.
So, when I hear someone calling that "painful" it makes me wonder how
they would do things differently to alleviate that pain...

The pain is not in the client code, but in the bean code. EJB 3.0 removes most
of the horrible redundancies by making use of the metadata annotation introduced
in Java 1.5:

http://www.caucho.com/resin-3.0/ejb3/tutorial/cmp-basic-field/index.xtp

------------------
The EJB 3.0 draft is primarily a process of removing features superfluous to supporting
persistent objects.

* No home interfaces
* No local interfaces
* No instance pooling
* No special create or remove methods
* No special find or select methods
* Deployment descriptor is optional

EJB 3.0 relies on JDK 1.5 annotations to configure entities in a maintainable,
self-documenting way.

* Only one Java class needed per table (no interface needed)
* Annotation per field
* Annotation directly in Java class
* Direct java instance (no proxy or stub needed)
------------------