EJB3: when should session beans be used?

[John King]

As they are not POJO and can only run in an application server, why should I
choose EJB3 session beans over other technologies that use POJO?

[Marco Ehrentreich]

Hi John,

with EJB version 3.0 session beans ARE POJOs. You don't really need large deployment descriptors etc. any longer. Session beans can be simple POJOs with a few annotations. The most important advantage over other frameworks is probably that EJB 3.0 is an official specification from Sun.

Marco

[Scott Selikoff]

Originally posted by John King:
why should I choose EJB3 session beans over other technologies that use POJO?

Good question, why do you think you are studying EJB3 in the first place then?

[John King]

Originally posted by Scott Selikoff:


Good question, why do you think you are studying EJB3 in the first place then?

It is because EJB3 still have some market.

[John King]

Originally posted by Marco Ehrentreich:
Hi John,
... Session beans can be simple POJOs with a few annotations. ...

Marco

But they still need a heavy application server to run.

[Marco Ehrentreich]

But they still need a heavy application server to run.

Of course this is true! For your session beans in the context of EJB you in fact need an application server.

But what exactly do you think is a session bean if you're not talking about EJB applications? I know, they usually contain the business logic of an application. So you have what we call here session beans in almost any application.

Session beans in the sense of EJB 3.0 really don't give you much more than a simple Java class if you can't use them in an application server to benefit from the enterprise architecture and things like transaction handling, security and so on. They're simply POJOs with annotations when used outside of a server.

So I'm not sure what you really looking for when you're searching for a technology like session beans but don't want to use an application server. Perhaps you could elaborate some more on this...

Marco

[Jimmy Clark]

But they still need a heavy application server to run.

The key reasons for using Session EJB technology are also the reasons why you may think an application server is "heavy". However, even these reasons are getting weaker as the JBI containers and engines mature.

[John King]

EJB3 entity beans can be used in standalone environment without an application server environment. It is why I'm asking if EJB3 session bean can be standalone.

[Marco Ehrentreich]

Hi John,

now I see what your question was

You can use entity beans without an application server because the Java persistence API with its entity manager and other parts also works for standalone application. If I remember correct the JPA specification and development was split from the EJB technology for these reasons and to be developed further separately.

But some things like dependency injection of an entity manager or transaction handling don't work the same way as in an application server. And not to forget: You MUST use an entity manager which would be part of your application server in an enterprise application. So you really don't use ONLY the entity POJOs but you need the JPA and entity manager.

It's nearly the same with session beans. Of course you can use them in standalone application because they are simple POJOs. But you need something like a framework or an application server to benefit from the functionality an application server would give your session beans.

Unfortunately I don't know of something smaller or less heavy-weight framework which uses the same annotations and provides you similar functionality like an application server. Perhaps you should use a totally different technology? The Spring framework or some dependency injection containers for example could provide some parts of the functionality of an application server. To get good advices for some framework you probably first should know what you'd really expect from a runtime environment for your kind of "session beans". Security management? Transaction handling? Dependency injection? Lifecycle management?

Despite this I'd like to know what problems do you have with application servers? As James pointed out current application servers like Glassfish, JBoss etc. are really mature and easy to run and not too much heavy-weight. If you want to support really many users you should of course use a powerful machine. But at least applications servers are very scalable and a standalone application would perhaps suffer from this problem. And for normal usage an ordinary desktop computer or small server will be absolutely sufficient.

So think about what you really want to achieve! Unfortunately I don't know of a good framework to use as an alternative without an application server. But perhaps someone other?!?

Marco

[Jeanne Boyarsky]

Originally posted by John King:
As they are not POJO and can only run in an application server, why should I
choose EJB3 session beans over other technologies that use POJO?

For another view on the original question: you would use session beans (EJB 2 or 3) if you want the container to provide services for you. If you want to provide the services via jars, you can use another framework.