Whats the point of EJBs?

[David]

I have been looking at EJBs for quite some time now and really am
struggling to see what all the fuss is about as I cant seem to think
of a killer reason for using them.

Could someone please tell me a situation where an EJB would be miles
better than a plane old Java bean?

- Our EJBs would live on the same server as the servlets and so any
distributed advantage is gone.
- Managing transactions with JTA is easy
- Method level security is handy, but hardly a killer reason.
- (Ignore MDBs for the time being)


Alternatives to EJBs... (Im sure a must be over simplifying this so
please feel free to tell me im wrong!)

1) A Stateless session bean can surely just be replaced with a normal
java bean and then just make calls to MyBean.myMethod() - ie no state
is preserved, just small bits of business logic are called.

2) A Stateful session bean can be replaced in a similar way except it
has to be dumped on and off the session object each time.

3) A BMP Entity bean can also be a normal java bean where the
constructor fetches the relevant row and sets all the values, then
each set method could update the db via JDBC. OK, so the SQL would
need to be written, but then its hardly rocket science is it?

4) A Bean managed entity bean has SQL etc burried in it anyway and so
could be rewritten as a java bean.


....Im sure Ive got something wrong here, there must be something that
can only be done with an EJB, but Im struggling to see what all the
fuss is about?

Thanks

David Bevan
http://www.davidbevan.co.uk
http://www.websphereusergroup.org.uk

 

[Bryce]

Could someone please tell me a situation where an EJB would be miles
better than a plane old Java bean?

- Our EJBs would live on the same server as the servlets and so any
distributed advantage is gone.

If you need a distributed app. Since you don't, I generally wouldn't
recommend EJBs.

Personally, I've been using Spring + Hibernate + Struts.

EJB's have their use I suppose, but I'm not a huge fan of them. But
then again, I haven't come across an instance where I needed a
distributed app...

 

[kjc]

Along with the distribution aspects, EJB gives you transactional
capabilities as well as method level secuity based on roles. Most
people use StatelessSession EJBS, with back end Business Delegate
patterns coupled with numerous DAO's.

 

[Michael Borgwardt]

I have been looking at EJBs for quite some time now and really am
struggling to see what all the fuss is about as I cant seem to think
of a killer reason for using them.

Could someone please tell me a situation where an EJB would be miles
better than a plane old Java bean?

- Our EJBs would live on the same server as the servlets and so any
distributed advantage is gone.

Will it stay that way? Underestimating performance requirements and
then being forced to redevelop for a cluster solution later
on is a common horror story. If you use EJBs, this scenario loses
most of its scare factor.

- Managing transactions with JTA is easy

Probably not as easy as you think, definitely MUCH more difficult
as soon as you have to go distributed.

 

[Brian J. Sayatovic]

EJBs in general offer these four advantages. Some types of EJBs do not use
all of these, and sometimes, you don't need these. In general, these
services could be hand-coded in POJO (plain-old Java objects), but the point
of the container doing ti for you is that you don't have to write it and
manage it.

1. Security
2. Remoteness
3. Transaction
4. Persistence

Each of these can invoke a lot of overhead. Local EJBs were devised to get
around the overhead of #3. Good containers would not have any noticeble
overhead if you're not using certain features. But, as you said, if you
don't need any of that, why use them? At the very least, though, you
remakred that you do use #3. Is that enough to warrant it?

Regards,
Brian.

 

[Bryce]

Along with the distribution aspects, EJB gives you transactional
capabilities as well as method level secuity based on roles. Most
people use StatelessSession EJBS, with back end Business Delegate
patterns coupled with numerous DAO's.

True, but so does Spring, with a more lightweight framework. YMMV
though.

 

[Bryce]

1. Security
2. Remoteness
3. Transaction
4. Persistence

Each of these can invoke a lot of overhead. Local EJBs were devised to get
around the overhead of #3.

I think you meant #2...

 

[IJF]

I have been looking at EJBs for quite some time now and really am
struggling to see what all the fuss is about as I cant seem to think
of a killer reason for using them.

Have you ever seen a huge web application like hotmail, ebay, google, yahoo,
msn, slashdot, friendster, orkut..., using this stuff???


i.j.

 

[Robert Klemme]

I think you meant #2...

I think he meant #3 because David (OP) talked about transactions being
easy with JTA.

robert

 

[Bryce]

I think he meant #3 because David (OP) talked about transactions being
easy with JTA.

No, read again.

Local EJB's were devised to get around theoverhead of #3

Correct me if I'm wrong, but Local EJB's have the same overhead when
it comes to transactions as do Remote. But they do get around the
overhead of Remoteness, which was #2 on the list.

 

[Bryce]

Have you ever seen a huge web application like hotmail, ebay, google, yahoo,
msn, slashdot, friendster, orkut..., using this stuff???

Yes:

ebay http://www.theserverside.com/news/thread.tss?thread_id=8906

msn, and hotmail I wouldn't expect them to...

 

[Brian J. Sayatovic]

Yes, that was a typo on my part. Sorry for the controversy

Regards,
Brian.

 

[Shane Mingins]

Personally, I've been using Spring + Hibernate + Struts.

Which I am hearing is that using Spring and Hibernate is closer to EJB 3.0
than EJB 2.1

Shane

 

[IJF]

Yes:

ebay http://www.theserverside.com/news/thread.tss?thread_id=8906

This news was from 2001. It seams they switched back to
microsoft

look at www.ebay.com 's http response header:

HEAD HTTP/1.0
...
Server: Microsoft-IIS/6.0
...


And what about those URL's http://cgi.ebay.com/ws/eBayISAPI.dll

I know a couple of sites running on websphere but none
of them use EJB's

ijf.

 

[W.Guerlich]

Could someone please tell me a situation where an EJB would be miles

better than a plane old Java bean?

EJB is all about *components* vs. mere object classes. A component is
a piece of software living in your server and has all dependencies
(e.g. database connections, other EJBs, configuration parameters)
already resolved and is waiting to be used.
It helps a lot in decoupling various parts of your application and
promotes reuse of ready-made modules.

Example:
I need to maintain various e-commerce applications. Some of them use
the same functionality to check for correctness of credit card and
bank routing numbers with a database behind it. Instead of duplicating
code and database configuration by including the same library in each
application I simply offer that service as a Stateless Session EJB.
This way I can change and reconfigure that component without even
disrupting service for one second.
The only dependencies between two components should be their
JNDI-location and their interfaces.

1) A Stateless session bean can surely just be replaced with a normal
java bean and then just make calls to MyBean.myMethod() - ie no state
is preserved, just small bits of business logic are called.

That doesn't hold true if the service offered by the session bean is
developed and maintained by a different group of programmers. In this
case you only need to know the interface but you never need to get in
contact with the actual library implementing that service. They only
need to deploy their component in your application server and
everything should be fine.

2) A Stateful session bean can be replaced in a similar way except it
has to be dumped on and off the session object each time.

The same applies as to stateles session beans.

3) A BMP Entity bean can also be a normal java bean where the
constructor fetches the relevant row and sets all the values, then
each set method could update the db via JDBC. OK, so the SQL would
need to be written, but then its hardly rocket science is it?

BMP entity beans allow (and force!) you to provide clean interfaces in
cases where the type of persistence store may change.
For example, I use BMP for user management because I know I may need
to support different user stores in the future (now it's a database
but it may change to LDAP).

4) A Bean managed entity bean has SQL etc burried in it anyway and so
could be rewritten as a java bean.

I agree that in most practical cases it is o.k. to have SQL databases
as the only persistence store supported (by using Hibernate for
instance).
But at least I recommend using an O/R mapping tool to avoid coding
your beans against a specific DBMS (MySQL,Oracle...)

...Im sure Ive got something wrong here, there must be something that
can only be done with an EJB, but Im struggling to see what all the
fuss is about?

In developing large applications it is a huge advantage to maintain
certain modules separately by different teams. It's just not feasable
to reassemble or redeploy the entire set of applications living in the
application server just because a bug in one library was fixed.

For small application however (e.g. a simple web shop) EJBs may be
plain overengineering and you're better off sticking with what
servlets and PJOs have to offer.

 

[Robert Klemme]

No, read again.


Correct me if I'm wrong, but Local EJB's have the same overhead when
it comes to transactions as do Remote. But they do get around the
overhead of Remoteness, which was #2 on the list.

Oh yes, you're right. I'm sorry.

Regards

robert

 

[dave artus]

This is an interesting question. I believe that there are a few more
benefits to using EJBs than you indicate below, and I also disagree
with your evaluation of some of the benefits you list. However, as has
already been noted we're really in the realm of engineering trades-off
and so we need to evaluate costs and benefits in specific situations.

One thing to factor in is that the intended use of EJBs is for building
Enterprise applicaitions. To me that implies problems of scale: scale
in complexity of what is to be built, scale in numbers of users,
scale in terms of longevity of the appication - it may be extended and
maintained for very many years, and scale in terms of the size of
development team. Yes, any given Enterprise app will not scale in all
those dimensions, but some will probably apply. I think that the
benefits of EJBs become more significant as these scaling issues become
more significant.

Also we need to be clear about the other side of the cost-benefit
analysis, what are the costs of using EJBs? There is clearly some
complexity cost, some significant learning to do as well. There's also
the issue that you need to have an EJB container running to test your
EJBs, so developers will spend some time waiting for their container
to start. Pragmatically, you also need appropriate tooling, developing
EJBs in Notepad is what I think of as a productive way to work.

So to get specific:

I have been looking at EJBs for quite some time now and really am
struggling to see what all the fuss is about as I cant seem to think
of a killer reason for using them.

Could someone please tell me a situation where an EJB would be miles
better than a plane old Java bean?

- Our EJBs would live on the same server as the servlets and so any
distributed advantage is gone.

This is a large assumption about the future. All your business logic is
always best located in the same server as your servlets? As things scale
you may find that some back-end connectivity requirements are better
satisfied by concentrating access from a smaller number of business servers.

Also suppose you decide to use a different presentation mechanism? Thick
client? If you have Remotely accessible EJBs, you're all set.

- Managing transactions with JTA is easy

Not quite so easy if you want to write components that can be put
together in different transaction contexts. You tend to end up with
"Am I already in a transaction, if not let's start one" fragments
polluting your code.

The declarative transactional appraoch is a win.

- Method level security is handy, but hardly a killer reason.

Very much depends on the kind of apps you are writing. If you need
security then you really need it, and rollinbg your own equivalent of
J2EE role-based security is a real pain.

Again consider the possibility that your business logic will not be used
only by servlets.

- (Ignore MDBs for the time being)

Well, they are pretty handy if you do need them

Additionally. Many of these items may elicit the response "well with a
few lines of code I can roll my own ..." I prefer off-the-shelf if we
can use it.

1). Look at EJB packaging. If you don't have this then you will find
that you need to evolve something similar for externalising
configuration information and packaging up your deliverables. Or, what's
worse, each development team will devise their own solutions to these
problems.

2). CMP. If your applications can use CMP then you can save very
significant development effort. Increasingly the CMP containers are
doing some pretty smart optimisations.

3). Object pooling. Having the EJB lifecycle controlled by the container
can yield significant performance benefits.

4). Performance monitoring. EJB containers such as WebSphere have useful
performance monitoring hooks and tools that exploit them.
Enterprise-level apps tend to need this stuff, and here rolling your own
is work you don't want to be doing.