Jan Groth

Many thanks from me as well!

Bart Kummel wrote:I was wondering what you think of using Entities: should we use them only in the "Model" layer and use DAO's (or something similar) in the "View/Controller"-layer? Or do you think it is okay to pass them through the service facade and just use the same Entity objects throughout the entire application? Or do you think this choice should depend on the size of the application or maybe some other metric?

If I may add my two cents:

I would not implement model transformations unless you have an explicit requirement which can only be fulfilled by it (Security might be such a thing). But if we are talking about "just" passing entities from the business layer to view, I would always use the same entities.

This

saves a lot of transformation glue code

makes your life easier in terms of debugging and future enhancements

allows to use concepts like lazy-loading in the UI layer

The often-heard argument that model transformations are required for a "good" decoupling of layers and as such are essential for "good" architectures is best answered by asking if there are any concrete plans to exchange any layers in the near future. If the answer is somehow vague, than make an official note that you'll start implementing the model transformation the day the layer exchange is requested... :-)

Being on JEE 6, it's actually possible to get a good step further and benefit from the combination of advantages of CDI and EJB 3.1:

You can use an extended persistence context and bind the entitymanager to a (long running) CDI-conversation. Thereby all entities are kept attached (and managed) for the whole unit of work. The persistence context will flush whenever a transaction commits - something you can easily control in your facade (SFSB). This not only saves the costs of re-attaching entities on each request (not possible without db-lookups), but also uses the persistence context as a native first level cache, and also allows lazy loading in the view.

I find this approach far superior than reusing patterns and best practices from the times when JEE still had a "2" in the middle (and concepts like extended persistence context had yet to be invented) ;-)

Jakiran,

I get you point, and of course you are right that the provided code snippet certainly fulfills its function. Full stop here.

But wait... What about... Hmm... Can't it be that @javax.ejb.Singleton runs into serialization / deserialization problems in distributed environments? Wouldn't it be better to use CDI @ApplicationScoped to avoid ending up with two caches???

Your point stays valid and true.

You know, I really liked Bill Burke's book on EJB 3.0. That was great stuff, and despite the title it dealt with more frameworks than just EJB (e.g. JPA). I guess that's when - for me - talking about EJBs became synonym to talking about business logic in general. Because at the end of the day I need to implement my customer's requirements - no matter which framework I choose (the customer almost never cares). That's why I'm kind of expecting that a book about EJBs should enable the reader to be able to develop state of the art business logic.

In the case of the EJB 3.1 cookbook, I would at the very least expect that the author mentions the tightly coupled concept of CDI. And I'm disappointed that he didn't - but we can certainly end the discussion at this point...

Pedro Kowalski wrote:
Does the CDI's @ApplicationScoped solve the problem of multi-node (multi-JVM) environment and preserves only one instance for all JVM's?

To my best knowledge it does, because all references to @ApplicationScoped are proxied, and therefore are correctly resolved by the CDI container, regardless on how many nodes the application is distributed.

Sure, this is a discussion, not a battle. As a non-native speaker, my English might sound more harsh that I intend to, sorry for that. I thought starting my last post with an apology is a good way to indicate my peaceful intentions ;-)

Pedro Kowalski wrote:

Jan Groth wrote:More and more voices are heard that EJB might completely drop out of future JEE specs.

Could you give any source of these voices?

Well, let me rephrase this to: In future versions of JEE, EJB will loose more and more weight. They'll probably stay there for compatibility reasons - but I see the situation more or less as you (started to) describe:

CDI will provide the foundation for business components.

Typical cross-cutting concerns (like transactions) can be added - if required - using the CDI extension mechanism. Seam 3 (JBoss) and OpenWebBeans (Apache) already have modules for that. This opens the door for even more lightweight environments than Glassfish (3.1) and JBoss AS 7.

Other classical JEE concepts - like passivation - seem to loose importance (I'm phrasing this really careful, this is my personal opinion covered by some blog-posts I read here and there.)

Regarding the sources of my (rephrased) information: I had the chance to chat with Adam Bien about this, and I follow the mailing lists around CDI / Weld / Seam. It also matches the experience I have gained after 18 months JEE 6 development. But it's certainly not an official JCP strategy

Pedro Kowalski wrote:
However, I am -- just like you -- quite interested how you can (if it's possible!) achieve the multi-node environment singleton...

True, handling singletons can get really (really!) tricky if serialization is involved. Josua Bloch brings up some interesting aspects in "Effective Java".

IMHO the problem is best addressed by the CDI spec, quote from there:

JSR 299 wrote:
There are several ways to ensure that the singleton bean remains a singleton when its client gets serialized:

have the singleton bean implement writeResolve() and readReplace() (as defined by the Java serialization specification),

make sure the client keeps only a transient reference to the singleton bean, or

give the client a reference of type Instance<X> where X is the bean type of the singleton bean.

A fourth, better solution is to instead use @ApplicationScoped, allowing the container to proxy the bean, and take care of serialization problems automatically.

Jaikiran, I must admit that I did not match you against that Jaikiran who is so amazingly helpful (and knowledgeable) at jboss.org. Instead I took it for granted that you might simply not be aware of JEE 6 and its various aspects. My bad - and my apologies.

I further have to admit that it surprises me that someone with your background makes his points towards "EJB 3.1 standalone" can be a better fit than "JEE fullstack". I'm more than willing to listen to your reasons to get to this point.

As I stated before: In my eyes any picture (aka: book) with just EJB in it misses serious parts and seems unfinished in my eyes. While I agree that it's technical possible to develop something working, I feel that serious and important aspects of EJB 3.1 can only be answered with CDI in mind. "Do I need an EJB or a Managed Bean?" "How does the lifecycle of a SFSB work?" "What's the best aproach to (de)couple my (EJB)-components?" - to name just a few typical questions a developer will have to answer. We have a saying in German: If the only tool you have is a hammer, than everything starts looking like a nail.

BTW: The book does not even mention CDI (as a matter of fact the acronym "CDI" is not used at all).

I think of CDI as the offspring of the decade-old EJB spec with all its historic payload. True, JSR-wise both are separate. But also true that one spec was developed with all the good and bad experiences of the other. More and more voices are heard that EJB might completely drop out of future JEE specs. So my point is: While it is possible to use CDI without EJB, it does not make sense to use EJB without CDI. At the very least it feels like driving with the handbrake put on...

My whole point is, you are complaining that a book, which says that it focuses on technology X, isn't covering technology Y.

... and I also say that X and Y are that closely related that is doesn't make sense to cover just one of them. Definitely no apples and oranges, it's rather like covering JSP, but not HTML (or Servlet, or CSS, ...)

Are you aware that both JCP/EGs, EJB and CDI, are discussing to extract common issues (esp. transactions and related topics) from both JSRs into a joined one?

Jayr Motta wrote:Totally +1, I agree with everything you said, I'm studying to the EJB exam and I've read the "Enterprise Java Beans" from Andrew Lee and Bill Burke, also read the "EJB3 in Action" from Debu, Reza and Derek and they're almost the same.

Despite the little new additions and modifications, there are no information about any of this that you've said (in fact, I would appreciate if you send me some links about it), neither on the specifications itself, that sounds more like improvements than the new "EE6 style".

Mr. Richard, how about some additions there to make your book the best and only on this that Jan quoted? I'll help to spread it if you add those and also buy a copy (even already having some goods about the theme).

As you say: "Enterprise Java Beans" from Andrew Lee and Bill Burke covers some ground about CDI, but not much. Bookwise, I haven't found anything better (just worse).

The best documentation about CDI that I am aware of can be found here at Weld.

Jaikiran Pai wrote:Remember that EJB3.1 can be used and is being used effectively, even without CDI in picture.

*... can be used...effectively...*
I doubt the part with 'effectively'. I also could drive to next supermarket without releasing the handbrake.. But: While I certainly could do so, I'd miss something important than. Can we agree that EJB 3.1 and CDI is more effective than EJB 3.1 without CDI?

*...is being used...without CDI...*
Actually I dont see where that should be the case (unless you provide more information). CDI is part of the JEE 6 spec (98% of EJB 3.1 development will take place on that stack). Should one not work with an app server, its hard to imagine that he/she would go all the way to port EJB 3.1 to some other environment, but disregard CDI in that process.

Actually, most times when I hear people argument like that, they simply did not have the time to have a look at CDI yet. That's certainly okay, but IMHO working with a technology stack (here: JEE 6) implies to be familiar with its core concepts. And CDI is certainly one of them...

Even though JEE 6 is final since almost two years, getting some literature about it is still not an easy task. Some volumes are out, but certainly the choice is not overwhelming. So, personally I was thrilled when I heard about the new "EJB 3.1 Cookbook", and quickly gathered some information :-)

The disappointment came when I had a closer look at the contents:

I cannot understand why (yet another) book about EJB 3.1 misses the complete story behind CDI ("Context and dependency injection"). I do understand that CDI (JSR 299) is not a part of EJB 3.1 (JSR 318), but in JEE 6 those two concepts are linked that tightly that it's certainly safe to say that one cannot take full benefit of EJB if one is unaware of scopes, lifecycles and the concept of typesafe dependency injection. How am I supposed to implement a professional EJB 3.1 application if I never heard about a SFSB living in the conversation scope (something the book does not even mention)? What about Managed Beans (JSR 316)?

While one might argue that those concepts do only extend EJB 3.1 (I don't follow that path), it's getting worse in the parts where CDI replaces EJB 3.1. Take chapter 8, dealing with interceptors, as an example. The (old) EJB 3.0 style of binding the interceptor implementation directly to the intercepted method is simply repeated. This ignores the new concept of loosely binding interceptor and intercepted method with @InterceptorBinding and qualifiers.

I really don't understand why the author left out all these details. Forgive me for sounding harsh, but in my opinion this book can hardly be used to learn about EJB 3.1, it only complements other literature / sources of information.

Cheers,
Jan

This Real World Java EE Patterns Rethinking Best Practices is by far the best covering JEE 5 / JEE 6 patterns I know about...

Hi there,

actually, I'm very interested in taking a SCEA certifcation - the only problem I have is that it feels quite obsolete to learn JEE 5 if JEE 6 is out since almost two years. So, why should one still go for the SCEA 5 certificate?

I asked this question before, and I got answers like "JEE did not change very much from JEE 5 to JEE 6".

With a background of having used JEE 6 (and especially CDI) for 15 months now, I strongly disagree. I feel that Java Enterprise - as a whole - has changed dramatically, and that many of the former J2EE patterns (DAO, Service-Locator, ...) became anti-patterns inbetween. Some of the technologies SCEA 5 requires knowledge about are on or beyond their path to deprecation (JSP, EJB 2.1 (CMP!!!), ... ), and what once was regarded a well-layered & decoupled architecture-layout seems like a huge, oversized monster from the dark ages today.

So, the question remains - why should one still go for the SCEA 5 certificate?

Cheers,
Jan

sorry to hear ;-)