J2EE: why use JavaBeans?

[Chris Uppal]

I take it you are referring to Expert One-on-One J2EE Development
without EJB
by Rod Johnson, Juergen Hoeller

[...]
If you happen to be an ACM member, you can read it online for free.
It's one of the books included in the Professional Development Center's
online books program.

That's worth knowing, thanks.

Now if I can only remember my acm password...

-- chris

 

[Bryce]

I take it you are referring to Expert One-on-One J2EE Development
without EJB
by Rod Johnson, Juergen Hoeller

http://www.amazon.com/exec/obidos/ASIN/0764558315/canadianmindprod

It is $26 new $19 used

That would be correct my good Sir.

 

[Raymond DeCampo]

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 would point out that most of the issues you have mentioned are usually
associated with entity beans. Most EJB critics do not have problems
with stateless session beans. Message driven beans can be quite nice
also and are simple.

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)...

Ray

 

[Raymond DeCampo]

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.

First, JMS allows for the possibility of integration with other
messaging systems which allows for integration with other applications,
legacy or otherwise.

Second, asynchronous process is useful in cases where the client doesn't
care for a result from the server or if the server completes the task.
A simple example of this would be cache management. The client may have
changed the state of some resource requiring others to reload it and
discard the entry from their caches. So the client posts a message to a
JMS topic and interested parties are notified.

Third, the genesis of MDB (message driven beans) was the fact that the
EJB specification prohibited implementations from listening on JMS.
(They could post to JMS; they could probe a JMS queue or topic in
non-blocking mode; but you could not have an EJB respond to a JMS
message without also having a traditional EJB call.) The community
obviously found many uses for this and asked Sun to add MDBs.

HTH,
Ray

 

[www.douglassdavis.com]

I would point out that most of the issues you have mentioned are usually
associated with entity beans. Most EJB critics do not have problems
with stateless session beans. Message driven beans can be quite nice
also and are simple.

Actually, I'm still not really sure what a stateless session bean can
do? If it's stateless, what does it really have to do with a session?
To me, a session is inherently stateful.

It seems as if the only thing significant that's left really is remote
procedure calls, which can be done without a stateless session bean.

Sorry, I still don't get it.

 

[Raymond DeCampo]

Raymond DeCampo wrote:




Actually, I'm still not really sure what a stateless session bean can
do? If it's stateless, what does it really have to do with a session?
To me, a session is inherently stateful.

Just another example of poor naming.

It seems as if the only thing significant that's left really is remote
procedure calls, which can be done without a stateless session bean.

You can play that game with any technology. There are always alternate
ways of doing things. Why bother with servlets? I can do the same
thing with perl and CGI.

Sorry, I still don't get it.

Ray

 

[www.douglassdavis.com]

You can play that game with any technology. There are always alternate
ways of doing things. Why bother with servlets? I can do the same
thing with perl and CGI.

That's a legitimate question to me... Ultimately it's a question every
consumer will ask... If people can find no compelling reason to use
servlets over Perl... they will not use it. "Because they have Java in
the title" isn't a good enough reason for me.

Same thing with stateless session beans. To me, the first hurdle is
just figuring out what the heck they are, and what they are used for.
And so far, unfortunately, it hasn't been easy. Stateless session
beans are not used for sessions. But, they are used for RPC, why not
just call them RPC beans? It seems, there must be something else that
they are good for?

 

[Bryce]

Same thing with stateless session beans. To me, the first hurdle is
just figuring out what the heck they are, and what they are used for.
And so far, unfortunately, it hasn't been easy. Stateless session
beans are not used for sessions. But, they are used for RPC, why not
just call them RPC beans? It seems, there must be something else that
they are good for?

While the name "Session" is confusing, there are several reasons to
use them.

For one, the container can manage a pool of reusable beans, usable by
the client

Another: declarative transactions. Write a session bean, you can
declare a method to be wrapped in a transaction. Its a nice way to
keep transactional logic out of your business classes.

As for the name "Session" beans, I dunno. I guess its never really
bothered me, and I just accepted the name. I don't lose much sleep
over it. Kind of like Javascript. Its got "Java" in it, but its not
very similar to Java... But I don't obsess over it.

 

[www.douglassdavis.com]

While the name "Session" is confusing, there are several reasons to
use them.

For one, the container can manage a pool of reusable beans, usable by
the client

Another: declarative transactions. Write a session bean, you can
declare a method to be wrapped in a transaction. Its a nice way to
keep transactional logic out of your business classes.

As for the name "Session" beans, I dunno. I guess its never really
bothered me, and I just accepted the name. I don't lose much sleep
over it. Kind of like Javascript. Its got "Java" in it, but its not
very similar to Java... But I don't obsess over it.

thanks.

 

[Jon Martin Solaas]

Raymond DeCampo wrote:




Actually, I'm still not really sure what a stateless session bean can
do? If it's stateless, what does it really have to do with a session?
To me, a session is inherently stateful.

Good question

It seems as if the only thing significant that's left really is remote
procedure calls, which can be done without a stateless session bean.

Sorry, I still don't get it.

SLSB have access to EJB container services like trx-handling, the
ejb-container may support clustering and so on. That's nice if you need
it. Also it's nice not to need to resort to other technologies if you
already are using EJB in your project, and suddenly want to make some
stateless components.