EJBs Calling Regular Java Classes

[Will Farquharson]

Hi,

I have a couple of small questions regarding EJB 3.0's Stateless Session Beans that I wondered if someone could help with...

I've seen applications where a Session Bean can sometimes call a mixture of other Session Beans, as well as regular Java classes (which themselves might call more Session Beans).

My question is... is there a disadvantage to getting the non-EJB classes involved here? Shouldn't these also be marked as EJBs? I'm sure that doing it this way they'd still be getting the transaction handling benefits of Session Beans, but am I right in thinking they're not getting full advantage of bean pooling and such performance related benefits on the regular classes? I know how bean pooling works, but I can't get my head round how it works if the beans call regular classes.

While I'm on the subject, I'd also like to ask...
In an application I'm involved in, we have a policy where we only create Session Beans in our application layer if we specifically need to contain everything we're doing in a transaction (updating several tables one after the other for example). Otherwise, we just implement our business logic in regular classes. The only other place we use Session Beans are to wrap up calls to the EntityManager in a DAO class way down in the persistence layer.
I guess it was decided at some point that creating Session Beans where we don't specifically need them (for wrapping everything in one transaction) is an unneeded overhead. However, I again wonder if we'd be missing out on the performance benefits of bean pools. Is this good practice? Or should we be marking everything as EJBs for the reason I mentioned?

I understand the answers to these questions are probably very specific to whatever the application is, but if anyone could offer an opinion or an explanation I'd much appreciate it.
Thanks =)

[Piotr Nowicki]

Howdy Will!

Well, the approach you said (to connect EJB's with POJO's) is, IMO, the easiest and cleanest.

My question is... is there a disadvantage to getting the non-EJB classes involved here? Shouldn't these also be marked as EJBs?

It depends. If your class needs transactions, timers, pooling, asynchronous calls or to be an endpoint for WS - then yes - it should be an EJB. In other cases - plain POJO will be enough. One thing I can think of is the thread-safety. In EJB you get this for free, but in POJO you would need to be sure that it's safe - this is where CDI's Context's part would come in the game.

I'm sure that doing it this way they'd still be getting the transaction handling benefits of Session Beans, but am I right in thinking they're not getting full advantage of bean pooling and such performance related benefits on the regular classes? I know how bean pooling works, but I can't get my head round how it works if the beans call regular classes.

In this case it would be natural to use the CDI which comes with Java EE 6 and is powerful as hell! You could then benefit from IoC and just inject bean you want to use from your EJB with specified context (Request, Session, Conversation, ... or even your own!).

In an application I'm involved in, we have a policy where we only create Session Beans in our application layer if we specifically need to contain everything we're doing in a transaction (updating several tables one after the other for example). Otherwise, we just implement our business logic in regular classes. The only other place we use Session Beans are to wrap up calls to the EntityManager in a DAO class way down in the persistence layer.

It's just like the first part of your post - in my opinion it's very valid approach. This is what the EJB's were for and this is what they'll probably be for in the future. They act as a facade to your business logic. I think that this EJB's role will be even clearer when CDI and EJB cleanup occur in Java EE 7.

I guess it was decided at some point that creating Session Beans where we don't specifically need them (for wrapping everything in one transaction) is an unneeded overhead. However, I again wonder if we'd be missing out on the performance benefits of bean pools. Is this good practice? Or should we be marking everything as EJBs for the reason I mentioned?

As a rule of thumb:
Implement your logic in POJO and use CDI to access it. If you realize that you need some of the EJB features (transactions, pooling, timers, asynchronous call, WS endpoint, access through remote interface, ...) don't implement it on your own, just add @Stateless/@Stateful to your POJO and there you have it - full flagged EJB which will work with @Inject annotations.

There are few resources you might want to read:

http://relation.to/13355.lace
http://www.adam-bien.com/roller/abien/entry/cdi_with_or_without_ejb
http://docs.jboss.org/weld/reference/latest/en-US/html/part-4.html

Hope that helps!

Cheers!

[Will Farquharson]

Thank you so much for taking the time to write that!

I will spend some time now reading up on CDI and the links you posted.

If you don't mind though, I still have a couple of niggling thoughts...

If you realize that you need some of the EJB features (transactions, pooling, timers, asynchronous call, WS endpoint, access through remote interface, ...)

When might you realise you need pooling? When might you not need it? If I understand correctly, it's a performance benefit with no drawbacks... so why wouldn't we just add @Stateless on all our POJOs?

On a slightly related note, I was making a start to study for SCBCD 5.0. However, from what you say, it seems Java EE 6 has more features which I really should know about, so perhaps I should consider studying OCPEJBD 6 instead. This means I'd have to study the persistence exam separately though. Would you have any advice on this? Which certification would you prefer to see a programmer with?

Thanks again!

[Piotr Nowicki]

Glad you liked it Will!
I really like the in.relation.to blog, as well as Adam Bien's weblog. A lot of useful stuff can be found there!

When might you realise you need pooling? When might you not need it? If I understand correctly, it's a performance benefit with no drawbacks... so why wouldn't we just add @Stateless on all our POJOs?

Hmm, I guess that you will need pooling if you have a lot of traffic and you need some smart resource managing. Each new service object for each new client would be a waste of resources and time if you have a hundreds of requests a minute.
On the other hand, there is a drawback. You need to initialize all those pooled objects during application startup (longer startup) or postpone it to the first request (longer first request service time).

On a slightly related note, I was making a start to study for SCBCD 5.0. However, from what you say, it seems Java EE 6 has more features which I really should know about, so perhaps I should consider studying OCPEJBD 6 instead. This means I'd have to study the persistence exam separately though. Would you have any advice on this?

Well, my answer will be sujective, as I'm actually learning for OCP EJBD 6 ;-) I really like a lot the Java EE 6 and I always want to be as most on-time as possible, therefore I've chosen the latest available certificate path. I found that pursuing a certificate is a great tool to learn new stuff, so that's also why I've chosen EJB 3.1 exam.

Personally, I don't mind that the JPA exam is on it's own since Java EE 6. I don't mind taking another exam and I feel that EJB exam can be cleaner without the ORM part. I like to split things into small pieces which can be achieved more easily, so I kinda like the EJB / JPA split that Oracle did.

Which certification would you prefer to see a programmer with?

Well, hard to say, as I'm not in a position to make such a choice :-) I'm on the other side of the table - I am this programmer who is a rookie and want to learn new stuff :-)
But in my opinion, the most important is knowledge of EJB 3.x. The biggest change was made with EJB 2.x -> EJB 3.x and if you know EJB 3.0 or EJB 3.1 doesn't make a big difference for me. The main POJO idea is the same.
On the other hand, the pragmatic side of me says that the newest certificate you achieve, the longer it will last.

Don't forget that the Java EE 7 Expert Group is currently working on the new version of the specification!

Cheers!

[Will Farquharson]

Perfect, thank you, that pretty much wraps this one up

I wish you luck for your OCPEJBD 6! Can I ask what you are using to study?

I'm reading an O'Reilly EJB3 book cover to cover, but it puts me to sleep at times. Maybe I should be creating test projects and playing around, but I worry I'd miss out a lot of theory if I spent time doing that... and after all, the exam is all theory.

[Piotr Nowicki]

Perfect, thank you, that pretty much wraps this one up

I wish you luck for your OCPEJBD 6! Can I ask what you are using to study?

Thanks! I use Enterprise JavaBeans 3.1 by AL Rubinger and B Burke. Right now I'm reading EJB 3.1 specification, then I'll move to Ivan Krizsan's study notes. In meantime I'm trying to refactor one of my projects at work to use EJB's.

Well, yeah the EJB 3.1 book is not like the Head First series where pages just runs in front of your eyes, but it's still fine for me. For the purpose of the EJB certificate, I've left the JPA chapters alone but I'll return to them during my study to JPA exam.

Maybe I should be creating test projects and playing around, but I worry I'd miss out a lot of theory if I spent time doing that...

I think that the golden ratio is important in this matter, so know the theory and code! :-)
I mean that by just learning the theory you can pass the exam, but it won't necessarily make you a good developer.
On the other hand, when you just jump in and start writing a code, it's very possible that you miss some of the important parts which are assumed to be known to developer working with EJB specification.

HTH!

Cheers!