Hello, I took the exam on July 2nd. I'm glad that I had the opportunity to take the exam even that I was late registering. The exam was very loong. I don't know if it's only the beta that was so long or also the real exam. If you're not a native english, you have to concentrate very well on the question texts. Some are very long and sometimes hard to understand. You have to read very carefully and don't miss a word like "not". After 3 hours the concentration on the texts gets even more painfull. The only things you are able to see after the 4h exam is (and the only things I can remember from the exam): ejb-jar, bean-managed, container-managed, transactions, Deployer, Bean Provider, ejb-ql, deployment descriptor, persistence, Object(o), Order, lineItem, Required, Supported, Application Assembler, Container, responsibility, RequiresNew, NotSupported, Entity, Session, Statefull, Stateless, MessageDriven, Context, passivation, activation, ejbCreate, ejbRemove, UserTransaction, getRollbackOnly, setRollbackOnly, 'Harry' .......
From my point of view there is too much weight put on the EJB Roles (BeanProvider, Application Assembler, Deployer, ...). I don't think this is that relevant for a good Business Component Developer. Instead he or she should now the ejb-jar xml tags and what the container can do for you. But I think it's not that important to know who is responsible for what tag in the ejb-jar.xml. I think these roles are not that important in real life projects. There you usually have to wear more than one hat and you don't think about "oh, I'm currently writing this xml tag, now I have to wear this hat".
Does it really take 6-8 weeks to get the results? This will get a very looong time for me, too. I was a little bit disapointed that I even didn't got a score at the end. Now I don't have a feeling about the result. Passing the exam can be 50/50 in my case.
Good luck for the rest of us. Peter
PS: Thanks for alle the cheat sheets and hints in this forum. [ July 02, 2003: Message edited by: Peter Storch ]
was this from an example or is it part of the EJB-QL questions. To me, at first, sounded STOCK related. Oh ,ok, found the references in the spec as when to define coarse-grained objects and when fine-grained. And 'Harry' ?
From my point of view there is too much weight put on the EJB Roles (BeanProvider, Application Assembler, Deployer, ...).
I think this is really important if you want to develop re-usable components. regards P.S. - Good luck with the results [ July 03, 2003: Message edited by: HS Thomas ]
I sat the exam on the 3rd, and thought it was quite hard. I found I had to read the questions at least a couple of times in order to understand them, due to the way they were written. I feel sorry for the guys who do not have english as their first language. Ray Gill SCJP, SCWCD
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
Co-Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0596007124/ref=jranch-20" target="_blank" rel="nofollow">"Head First Design Patterns"</a><br /> <br />Just a Jini girl living in a J2EE world.
Joined: Jun 12, 2003
Originally posted by Kathy Sierra: The separation of roles is an extremely important part of the specification, because at its heart, EJB is a component-based development model.
Althought the component marketplace is still emerging for EJB, this is cleary the direction that the industry is at least *trying* to move to.
Yes, you're right. I'm just a little bit disapointed about how the industry is *trying* to move in that direction. I recongnized that even within one company the reuse of components is not working very well. Maybe we don't have the appropriet skills, but we try to change that, e.g. with the SCBCD The fact is, that I see a lot of discussions and visions of component based development, but If I look at current projects only little is done yet.
Cowgirl and Author
Joined: Oct 10, 2002
Howdy, Oh Peter, how right you are... the word "trying" is still where it's at. There are more glimmers of hope here and there, however. And a little tool news that might help somewhat -- the new J2EE 1.4 finally has a standard deployment API which means that any development tool will deploy to any server. So, component-based development is coming along slowly, but it *is* moving in the right direction, and there are folks in the industry who are really pushing for it. Check out: Flashline.com cheers, kathy