EJB

[EJT]

Why are people using EJBs as opposed to straight JDBC access to
databases from servlets and passing on to web pages? Why is the EJB
important and widely used today?

Are there any books that will tie in all these J2/5EE related
technologies to help make good decisions on what to use and not to use?

Thanks

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Why are people using EJBs as opposed to straight JDBC access to
databases from servlets and passing on to web pages? Why is the EJB
important and widely used today?

EJB and direct JDBC calls are not comparable items.

If you are really comparing entity beans and direct
JDBC calls, then entity beans are providing some
extra services including declarative transactions.

Probably very few people use direct JDBC calls for
business objects. Some use entity beans other use
O/R mappers like Hibernate.

Are there any books that will tie in all these J2/5EE related
technologies to help make good decisions on what to use and not to use?

Almost any J2EE book will probably provide you with
a lot of usefull information.

Arne

 

[Soren Kuula]

Why are people using EJBs as opposed to straight JDBC access to
databases from servlets and passing on to web pages? Why is the EJB
important and widely used today?

You CAN access a database directly from web service code. It will work
OK for very small projects, but quickly end up in a big mess in larger ones.

The reason for using something in between the database and the web code
is that it is often worthwhile to make an object-oriented model of the
things and events that you describe. If your web service is selling
fly-swatting equipment, then classes like Customer, Order and Price are
nice descriptions of the things you are working with.

It is usually worth the effort to separate MODEL,
PRESENTATION/MANIPULATION and PERSISTENCE: How things look on a web page
should have something to do with what is presented (and to whom maybe),
not how with it is stored in a database. If you do good abstraction and
separation, you will get better extensability, modifiability and
understandability than if mixing things that have do do with details of
the database, the details of what is modelled and the details of web
services.

Are there any books that will tie in all these J2/5EE related
technologies to help make good decisions on what to use and not to use?

You might want to find a good book on object oriented analysis and
design. As for which technologies to use, experience is probably the
only good guide (other peoples' experience, too!). Sometimes people
reading about some "silver bullet" technique (like when misunderstanding
design patterns) will want to stuff it into everything they see. The
result usually gets more complicated than it should be.

Experience is the word........


Søren

 

[EJT]

You CAN access a database directly from web service code. It will work
OK for very small projects, but quickly end up in a big mess in larger
ones.

The reason for using something in between the database and the web code
is that it is often worthwhile to make an object-oriented model of the
things and events that you describe. If your web service is selling
fly-swatting equipment, then classes like Customer, Order and Price are
nice descriptions of the things you are working with.

But why not just have JSP do the front end presentation layer and
servlets handle the database layer or database related work. Why is
there a another EJB layer before the database? Servlets are not enough?

 

[Rohit Kumbhar]

EJT wrote:

[..]

But why not just have JSP do the front end presentation layer and
servlets handle the database layer or database related work. Why is
there a another EJB layer before the database? Servlets are not enough?

Technically, servlets are enough! In fact, you can do direct jdbc calls
through your jsp pages. It depends on the size of the application and
the intent/use of a particular component/technology in a particular
pattern.

e.g. You could have your servlets/web container to do just the
controlling work i.e. which page is shown to what request considering
the privileges etc etc and the ejbs can do the `data` processing job.
aka MVC pattern. These can sit on two different machines maximising the
utilization of existing resources, having isolated security, mangeable
modification and deployment with having to touch less amount of code...
blah blah..

Bottomline, depends on the size and complexity of your application.

 

[EJT]

EJT wrote:

[..]

But why not just have JSP do the front end presentation layer and
servlets handle the database layer or database related work. Why is
there a another EJB layer before the database? Servlets are not enough?

Technically, servlets are enough! In fact, you can do direct jdbc calls
through your jsp pages. It depends on the size of the application and
the intent/use of a particular component/technology in a particular
pattern.

e.g. You could have your servlets/web container to do just the
controlling work i.e. which page is shown to what request considering
the privileges etc etc and the ejbs can do the `data` processing job.

Why should EJBs even be considered to do the data processing job when
servlets can do the job. You can delegate worker servlets to do the data
processing job. So why should one one consider EJBs when JSP to servlet
to DB is enough?

 

[ozgwei]

Why is the EJB important and widely used today?

No, I don't think EJB is widely used today. It was used a lot before
and it was a massive failure.

Are there any books that will tie in all these J2/5EE related
technologies to help make good decisions on what to use and not to use?

Look for Rod Johnson's "Expert One-on-One J2EE Design and Development
(Programmer to Programmer)" and his follow-up "Expert One-on-One J2EE
Development without EJB", in which he explained why EJB (excluding
EJB3) was a flop.

Rod Johnson is the founder of the Spring Framework and EJB3 is larged
based on the concept of Spring.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Why should EJBs even be considered to do the data processing job when
servlets can do the job. You can delegate worker servlets to do the data
processing job. So why should one one consider EJBs when JSP to servlet
to DB is enough?

Why not write the entire app in assemble. Surely assembler
is enough.

You choose the best tool for the job.

Servlets and JDBC is not always (actually almost never)
the best tool for the job.

Note that EJB is not the only alternative - several other
exist.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

No, I don't think EJB is widely used today.

That is wrong.

EJB's is widely used today.

A search at dice.com says:

java and ejb - 1565 jobs
java and spring - 837 jobs

(probably with a huge overlap)

It was used a lot before
and it was a massive failure.

EJB has its successes and its failures.

I do not understand where you get that massive failure idea from.

Look for Rod Johnson's "Expert One-on-One J2EE Design and Development
(Programmer to Programmer)" and his follow-up "Expert One-on-One J2EE
Development without EJB", in which he explained why EJB (excluding
EJB3) was a flop.

That was not really what the posted asked for.

Rod Johnson is the founder of the Spring Framework and EJB3 is larged
based on the concept of Spring.

I think that is not completely true. There are some overlaps, but they
also cover different areas. They have similarities but certainly also
differences.

Arne

 

[ozgwei]

java and ejb - 1565 jobs
java and spring - 837 jobs

Strangely, I just did the same look up in Australian's job seeking
website http://www.seek.com.au/ and found:

java and ejb - 186
java and spring - 189

And I assume that EJB is part of the requirements even if it is not
used in new development because there are many EJB failure hangovers to
look after...

 

[olle.sundblad]

Why are people using EJBs as opposed to straight JDBC access to
databases from servlets and passing on to web pages? Why is the EJB
important and widely used today?

Are there any books that will tie in all these J2/5EE related
technologies to help make good decisions on what to use and not to use?

Thanks

Why use EJB:
- Most EJB containers support transactions which is quite good when you
have do update several tables and keep the DB consistent (if not all
are updated all are rolled back to the previous state).
- Most EJB containers support caching (it keeps hopefully relevant
objects in memory for faster access)

Why not use EJB:
- It adds another layer to your app (it is easy to do MVC etc with just
JSP/Servlets/JDBC)
- It is usually a lot slower than direct JDBC

There are a lot of other factors as well, but I think you should read a
little more before going into to much detail.

And as a response to some other comments: EJB 1.1 and 2 are not
failures they are still used in a lot of places, but as with most
things later versions (2 and 3) are improved and recomended if you
start from scratch.
When using EJBs you can write your own SQL or use generated SQL. So EJB
is just a layer on top of JDBC with some more features.
In the projects I work in we use all three versions of EJB plus direct
JDBC for reads that EJB is just to slow to do.