Can I put the business logic in Servlets and bypass EJB?

[jmDesktop]

The more I read from I find that EJB are not favored by many. And
it's not something I want to do unless I have to anyway. Is it
somehow wrong to to put my business logic in my servlet or a javabean
and not use Enterprise JavaBeans at all? That still looks like good
separation to me. I think it's MVC, but not sure. Still learning.
Thanks.

 

[Tom Anderson]

The more I read from I find that EJB are not favored by many. And it's
not something I want to do unless I have to anyway. Is it somehow wrong
to to put my business logic in my servlet or a javabean and not use
Enterprise JavaBeans at all? That still looks like good separation to
me. I think it's MVC, but not sure.

The business logic should be in business objects. Those can be EJBs, but
they can also be plain old java objects (POJOs). In the latter case, they
would be created and manipulated directly by the servlet, within its own
process, rather than living in a separate process or container as EJBs
would. So, the answer to your question is definitely no, it's not wrong.

The advantage of EJBs over POJOs is that you get transactionality,
lifecycle management, persistence, distribution and searchability for free
(although TANSTAAFL). However, if you don't need those things (and man,
perhaps most, people don't), then they bring you no benefits. And, since
they're more work to write, configure, and execute, they're a net loss.

I think a sensible engineering decision would be to apply the You Aren't
Gonna Need It rule, and build your system with POJOs for now. However, try
to structure it so that a transition to EJBs later, if you decide to make
one, would be as painless as possible. That's pretty simple: define your
business objects with interfaces, and manipulate them exclusively through
those, and encapsulate creation of business objects (including searching
the database to make them) in a factory object (possibly using the Facade
pattern to hide a bunch of classes which do the creation work behind a
simple interface).

Then, if you want to go EJB, all you have to do is upgrade the interfaces
to EJB interfaces, fix up your client code to deal with RemoteExceptions
all over the place, and rewrite the factory object to use the EJB finders.
Oh, and then implement the actual EJBs. But at least the changes to the
servlet will be minimal.

Huge caveat: i did a lot of work with EJBs, but quite a while ago -
specifically, before EJB 3, which i understand has changed things a lot.
Like, there are no entity beans any more, so all the above advice is
worthless. Eh. Maybe it still applies to session beans.

If you don't get a good answer on this topic here, i suggest trying The
Server Side:

http://www.theserverside.com/

Which certainly used to be a really good place for this kind of
discussion. Don't know if it still is!

tom

 

[Arved Sandstrom]

The business logic should be in business objects. Those can be EJBs, but
they can also be plain old java objects (POJOs). In the latter case, they
would be created and manipulated directly by the servlet, within its own
process, rather than living in a separate process or container as EJBs
would. So, the answer to your question is definitely no, it's not wrong.

The advantage of EJBs over POJOs is that you get transactionality,
lifecycle management, persistence, distribution and searchability for free
(although TANSTAAFL). However, if you don't need those things (and man,
perhaps most, people don't), then they bring you no benefits. And, since
they're more work to write, configure, and execute, they're a net loss.

I think a sensible engineering decision would be to apply the You Aren't
Gonna Need It rule, and build your system with POJOs for now. However, try
to structure it so that a transition to EJBs later, if you decide to make
one, would be as painless as possible. That's pretty simple: define your
business objects with interfaces, and manipulate them exclusively through
those, and encapsulate creation of business objects (including searching
the database to make them) in a factory object (possibly using the Facade
pattern to hide a bunch of classes which do the creation work behind a
simple interface).

Then, if you want to go EJB, all you have to do is upgrade the interfaces
to EJB interfaces, fix up your client code to deal with RemoteExceptions
all over the place, and rewrite the factory object to use the EJB finders.
Oh, and then implement the actual EJBs. But at least the changes to the
servlet will be minimal.

Huge caveat: i did a lot of work with EJBs, but quite a while ago -
specifically, before EJB 3, which i understand has changed things a lot.
Like, there are no entity beans any more, so all the above advice is
worthless. Eh. Maybe it still applies to session beans.

If you don't get a good answer on this topic here, i suggest trying The
Server Side:

http://www.theserverside.com/

Which certainly used to be a really good place for this kind of
discussion. Don't know if it still is!

tom

You're more or less on track re the EJBs. I myself have done most of my paid
J2EE work with EJB 1.x/2.x, so based on just that I'd recommend avoiding
EJBs too, unless they are absolutely necessary. I've used EJB3 on my own
enough to understand that it is pretty sweet, so I'd consider that a lot
faster than EJB 2.x. You're correct - only the session beans are still EJBs
(very typically implementing a facade as you mention), the entities are now
POJOs (albeit more or less heavily annotated). And the interfaces are now a
lot more lightweight. Of course nothing stops a masochist from using EJB 2.x
entity beans in Java EE 5...

AHS

 

[Arne Vajhøj]

I think a sensible engineering decision would be to apply the You Aren't
Gonna Need It rule, and build your system with POJOs for now. However,
try to structure it so that a transition to EJBs later, if you decide to
make one, would be as painless as possible. That's pretty simple: define
your business objects with interfaces, and manipulate them exclusively
through those, and encapsulate creation of business objects (including
searching the database to make them) in a factory object (possibly using
the Facade pattern to hide a bunch of classes which do the creation work
behind a simple interface).

Then, if you want to go EJB, all you have to do is upgrade the
interfaces to EJB interfaces, fix up your client code to deal with
RemoteExceptions all over the place, and rewrite the factory object to
use the EJB finders. Oh, and then implement the actual EJBs. But at
least the changes to the servlet will be minimal.

Many would do the EJB's not as a replacement for the POJO's but
as a frontend for them to enable reuse of the business logic
in both high end (full Java EE with EJB's) and low end (just
Tomcat) solutions.

Huge caveat: i did a lot of work with EJBs, but quite a while ago -
specifically, before EJB 3, which i understand has changed things a lot.
Like, there are no entity beans any more, so all the above advice is
worthless. Eh. Maybe it still applies to session beans.

An EJB3 session bean should be POJO compatible.

Arne

 

[Arne Vajhøj]

You're more or less on track re the EJBs. I myself have done most of my paid
J2EE work with EJB 1.x/2.x, so based on just that I'd recommend avoiding
EJBs too, unless they are absolutely necessary. I've used EJB3 on my own
enough to understand that it is pretty sweet, so I'd consider that a lot
faster than EJB 2.x.

That is said often.

But:
- if all the extra files was generated by the IDE or XDoclet
then who cares about them
- considering the complexity of the typical problem requiring
EJB's, then even typing in all the interfaces manually
should have practically no impact

Arne