J2EE: why use JavaBeans?

  • Thread starter www.douglassdavis.com
  • Start date
W

www.douglassdavis.com

I'm not quite sure why I would want to use JavaBeans... I can keep
sessions using the session object, and I can message using the
messaging API, and I can use JDBC to talk to the database...

Why would I want to use JavaBeans? I've heard "because they are easily
distributed" or some answer like that.... But, still... I don't get it.
What's the point?
 
H

HalcyonWild

www.douglassdavis.com said:
I'm not quite sure why I would want to use JavaBeans... I can keep
sessions using the session object, and I can message using the
messaging API, and I can use JDBC to talk to the database...
Click to expand...

I can give an example. If you want to store some objects in your
HttpSession, then you must make those objects javaBeans. Not exactly
javaBeans, but they must be Serializable, so that they can be sent over
the wire. For a class to be a javaBean, it must be Serializable is one
of the requirements (there are others too that I have never bothered
with).
If you are sending some java objects in a Message, the objects must be
Serializable. YOu will get a nullpointerexception otherwise, in both
the cases, session and message.

Apart from this, why the javabeans specifications is something I never
understood really. Where should it be used, and where is it really
needed, in what case no other class would work.
 
F

Fabien Bergeret

www.douglassdavis.com said:
I'm not quite sure why I would want to use JavaBeans... I can keep
sessions using the session object, and I can message using the
messaging API, and I can use JDBC to talk to the database...

Why would I want to use JavaBeans? I've heard "because they are easily
distributed" or some answer like that.... But, still... I don't get it.
What's the point?
Click to expand...
I guess you mean Enterprise Javabeans (EJB), not Javabeans.
EJBs are components that can be called from different applications ;
they handle the buisiness logic
I use them to manage the DB transaction management
 
S

sol

That's indeed an old dispute...
I'd strongly recommend reading the following interesting books:
- "Bitter EJB's"
- "J2EE Development without EJB"

Many people are not thrilled with EJB's, at least with the older EJB
2.1... some claim that in *some* aspects they're:
- too complicated / enforce and inconvenient architecture
- suffer from serious performance problems
- immature
Regarding your remark on distribution, the great Rod Johnson has
clamined that they're going for the wrong end of the "80:20" rule...
like 20% of the applications may need distributed services, but the
remaining 80% end up with an over-complex architecture they don't
need....

I've done some EJB programming, and what I liked about them is mainly
session beans, with the automated (declarative):
- security
- transactions
Both of these are *very* hard to implement without a container (you'll
probably need Aspect Oriented Programming). Otherwise, I have to do
code reviews for everybody, making sure they always do appropriate
transactions, close connections, and don't expose methods to people who
shouldn't be allowed to call them...
(Mind you, security features weren't strong enough for us, but we did
use it as a "safety net", with additional applicative checks).

Still, bottom line - I'm not crazy about EJB's either. When I do use
them, I'll try to stick with Stateless Session Beans (which give some
decent features), and i'll stay away from Entity Beans.

I can only suggest you try them out *very, very carefully* and form
your own opinion...
Also have a look at EJB 3.0, which is supposed to be a hugh improvement
(learning from the java community, and from accumulated experience)...
 
W

www.douglassdavis.com

Fabien said:
I guess you mean Enterprise Javabeans (EJB), not Javabeans.
EJBs are components that can be called from different applications ;
they handle the buisiness logic
I use them to manage the DB transaction management
Click to expand...

yest.. that's what i mean. thanks.
 
W

www.douglassdavis.com

sol said:
That's indeed an old dispute...
I'd strongly recommend reading the following interesting books:
- "Bitter EJB's"
- "J2EE Development without EJB"

Many people are not thrilled with EJB's, at least with the older EJB
2.1... some claim that in *some* aspects they're:
- too complicated / enforce and inconvenient architecture
- suffer from serious performance problems
- immature
Regarding your remark on distribution, the great Rod Johnson has
clamined that they're going for the wrong end of the "80:20" rule...
like 20% of the applications may need distributed services, but the
remaining 80% end up with an over-complex architecture they don't
need....

I've done some EJB programming, and what I liked about them is mainly
session beans, with the automated (declarative):
- security
- transactions
Both of these are *very* hard to implement without a container (you'll
probably need Aspect Oriented Programming). Otherwise, I have to do
code reviews for everybody, making sure they always do appropriate
transactions, close connections, and don't expose methods to people who
shouldn't be allowed to call them...
(Mind you, security features weren't strong enough for us, but we did
use it as a "safety net", with additional applicative checks).

Still, bottom line - I'm not crazy about EJB's either. When I do use
them, I'll try to stick with Stateless Session Beans (which give some
decent features), and i'll stay away from Entity Beans.

I can only suggest you try them out *very, very carefully* and form
your own opinion...
Also have a look at EJB 3.0, which is supposed to be a hugh improvement
(learning from the java community, and from accumulated experience)...
Click to expand...

thanks... i'll check out EJB 3.0.. i guess some things you see the
point of only when there is something you can't do any other way. I
agree about the 80/20 thing... It's ok if doing complicated things is
complicated, but doing simple things should be simple.
 
W

www.douglassdavis.com

Another thing... If some one can answer this please.. When should I
use a message driven bean?? I thought all Enterprise JavaBeans
supported RMI. Isn't that enough?

Perhaps I am not understanding the "Asynchronous interface" thing, and
why that is such a big deal over RMI.
 
R

Roedy Green

Apart from this, why the javabeans specifications is something I never
understood really. Where should it be used, and where is it really
needed, in what case no other class would work.
Click to expand...

I think the original idea was that it would be possible for
non-programmers to glue beans together using some generic tool (a
beanbox) that worked only with bean field names. You would be
manually able to modify the bean objects with a generic editor.

The idea never caught on.
 
T

Thomas Hawtin

HalcyonWild said:
For a class to be a javaBean, it must be Serializable is one
of the requirements (there are others too that I have never bothered
with).
Click to expand...

I was looking at the Java Beans spec (1.01) the other day. The initial
definition is

"A Java Bean is a reusable software component that can be
manipulated visually in a builder tool."

It doesn't given any hard requirements after that. It does say that Java
Beans will *typically* support introspection, customization, events,
properties and persistence.

The problem with Java Beans was just the amazing hype surrounding such a
nebulous concept. Not that that is unusual.

Tom Hawtin
 
F

Fabien Bergeret

www.douglassdavis.com said:
Another thing... If some one can answer this please.. When should I
use a message driven bean?? I thought all Enterprise JavaBeans
supported RMI. Isn't that enough?

Perhaps I am not understanding the "Asynchronous interface" thing, and
why that is such a big deal over RMI.
Click to expand...
Message driven beans can be used to manage aynchronous events such a EAI
messages. For instance, I've worked on a ATM management intranet
application, that handles EAI messages sent by ATMs. This handling could
be done by message driven beans (it's not been done this way, since
message driven beans didn't exist at that time :-( )
 
H

HalcyonWild

Roedy said:
I think the original idea was that it would be possible for
non-programmers to glue beans together using some generic tool (a
beanbox) that worked only with bean field names. You would be
manually able to modify the bean objects with a generic editor.
Click to expand...

Thanks Roedy Green and Thomas Hawtin.

All that hot air for something as trivial as this. Many classes we
write would then be JavaBeans, without us knowing about it, or
realizing it.Eg. such code is common
public class Employee implements Serializable
{
private String fName;
private String lName;

//getters and setters.
}

They just made it a spec, that every field should have get/set methods
and implement Serializable.
 
T

Thomas Hawtin

HalcyonWild said:
They just made it a spec, that every field should have get/set methods
and implement Serializable.
Click to expand...

To be fair the spec is mostly about the java.beans package, which is
real, tangible and even has bugs to prove it.

Tom Hawtin
 
W

www.douglassdavis.com

once again i meant to say "Enterprise JavaBeans"


I don't know why they named it that anyway, when they already had
JavaBeans... maybe they are running out of names.
 
T

Thomas Hawtin

www.douglassdavis.com said:
once again i meant to say "Enterprise JavaBeans"


I don't know why they named it that anyway, when they already had
JavaBeans... maybe they are running out of names.
Click to expand...

They named JavaScript after they had Java. Such is the miracles of
marketing and branding.

Tom Hawtin
 
B

Bryce

I'd strongly recommend reading the following interesting books:
- "Bitter EJB's"
- "J2EE Development without EJB"
Click to expand...

I second the "J2EE Development without EJB" title. Excellent book.
 
B

Bryce

Another thing... If some one can answer this please.. When should I
use a message driven bean?? I thought all Enterprise JavaBeans
supported RMI. Isn't that enough?
Click to expand...

Message Driven Beans are primarily for asychronous processing. Suppose
you have a process that takes a long time to execute. You probably
don't want to leave the user waiting minutes for this process to end.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

JavaBeans 12
Is JavaBeans able to store an array? 6
Newbie - basic questions about Javabeans 7
JavaBeans, Tomcat and deployment. 3
[J2EE] Which tools can [re]configure messaging at runtime? 1
JSP newbie - can I use JSP to access exiting java classes withoutre-write to javabeans 2
Download Java / J2EE Interview questions 0
GROUP BY for collection of javabeans 0

Members online

No members online now.
Total: 183 (members: 2, guests: 181)
Robots: 322

Forum statistics

Threads
474,432
Messages
2,571,681
Members
48,796
Latest member
Greg L.

Latest Threads

Top