Howdy,
I just wanted to agree with the words from HS Thomas about the questions involving 'roles'. The separation of roles is an extremely important part of the specification, because at its heart, EJB is a component-based development model.
Without this clear focus on roles, it will not be as easy and clean to exploit the reusability of components. Althought the component marketplace is still emerging for EJB, this is cleary the direction that the industry is at least *trying* to move to. Check out ComponentSource.com and Flashline.com to see what's happening with the component market.
Another important thing about all the role questions, is that they help prove that you understand what belongs to the EJB spec, and what is vendor-specific. Because the *other* key benefit of EJB, and part of the reason it exists at all, is to prevent vendor lock-in. Whereas *before* EJB you would have to learn a different, proprietary API for each app/transaction server, with EJB, the promise is WODA (write once deploy anywhere). In reality, as most of us know
, it is not that easy, but if you've ever witnessed a J2EE "Deployathon", you have seen this work. A Deployathon is where they take a J2EE-compliant app and deploy it over and over on different servers, with the goal of making NO changes to the beans.
So, we know that for most of us, we just have to do everything anyway, it really doesn't seem to matter as long as the whole thing gets done, the exam DOES want to encourage and promote good practices.
I'll give you an example: say you write a bean that uses an environment entry. If you are writing it for yourself, you might not worry about what you put in the DD -- YOU know it's there and YOU know what it is for, so you supply the value at deploytime, and everything works. But... if someone *else* might be reusing the component later, in another app, if you did not provide a clear description, then that deployer will not know exactly what the value is really supposed to represent. Unless he goes through your source code!
Or, a bean developer who is not thinking about component reuse may use BMT when BMT clearly hurts reuse and should be used only when ABSOLUTELY necessary. (And I haven't thought of too many good reasons to use BMT except for preventing 'poison messages' in a message-driven bean.)
Now, the questions I do NOT think should be on the exam would be those
testing whether you know that the tag is <ejb-ref> vs. <ejb-reference> --
you should not have to have memorized the exact name of the tag, but you MUST know what the tag is! So if you really looked carefully on the exam questions, they were asking whether you understood WHAT must be provided in the DD, and which things are related (and how they are related) rather than looking at whether you memorized the exact tag name.
In virtually every question like that, we took GREAT care to make sure that if you understood exactly what had to be in the DD, then even if you do NOT know the exact tag syntax, you can figure it out from the available list and answer the question correctly.
I do not expect beta testers to have really looked at the questions from that perspective, but we were very careful about this.
Some people have complained that we do not have design
patterns on the exam (we probably will in some future version), because they think that testing for best practices is important in certification. We agree! And testing for a solid understanding of the component-based development model is the way we have tried to do this.
In fact, component-based development is the reason why javabeans and enterprise javabeans both share the term 'javabeans'. A bean is reusable component, rather than a reusable *class*, and a bean can be customized *without* touching any code (which includes not having to make a subclass).
OK, I'll step off the soapbox now
But remember, the real exam will have only 1/3 of the questions! So the beta testers had to answer every possible variation of questions where on the real exam you might have only a small handful of questions on any particular topic.
Cheers,
Kathy
