I am studying HF
EJB and preparing for SCBCD. I have a strong feeling that the book and probably the exam are made more complicated than they have to be. The EJB developer (bean provider) doesn't have to know at least some information what is in there. While it is nice that authors try to present view of EJB both from provider and the container vendor standpoint but it's ... not really necessary. Furthermore there are assumptions that can't be used without compromising your code scalability because the real implementation is in container vendor domain.
I need to present example to prove my point. I read about CMP entity beans. The book contains sequence diagrams that show how and when everything is created: bean, db record, EJBObject, when ejbActivate and ejbPassivate are called. Then the book says what you can do in ejbActivate and ejbPassivate but it states "you don't want to do that here". Further 3 different Commit models are explained. And now and only now the book says: "you can't rely on when your ejbActivate or ejbPassivate will be called in regard of business method calls. that depends on commit model which is domain of vendor". That means..., you don't put anything into ejbActivate or ejbPassive because you can't make any assumptions about them (except that when they will be called... they will wrap ejbLoad and ejbStore calls... if they will be called for every business object method invocation.. maybe not).
Another example is CMP entity bean's EJBObject creation... There are diagrams that shows when the EJBObject is created. Then later on it is said, that provider does not know when they are really created, what is in them and when they will go. It all depends on vendor.
This is very nice of course. But if we cant really know it then this information is not really useful. It complicates the technology. Every implementation based on such assumption may work with some containers and may not work with others (or work different way causing efficiency problems). My point is if SCBCD exam contains any of these assumptions it must get rid of them. Bean provider needs only know what is responsibilities implementing beans to make the code 100% scalable across every EJB 2.0 compliant container. Bean providers don't have to know how container is implemented (this is encapsulation on human level). And after all I believe that real production app servers/containers are much more sophisticated than we can make safe assumptions about.
I want to add that this is really good book. Probably one of the best I ever read. Honestly. I love it. Just I think EJB could have been made little easier on us "providers".
