HF EJB and SCBCD some overcomplicated
Vladas Razas
Ranch Hand
Posts: 385
posted 13 years ago
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".
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".
Andres Gonzalez
Ranch Hand
Posts: 1561
posted 13 years ago
You're right in most of your examples. Most of us are doing the job of the bean provider/app assembler at the same time. And most of the times our code is not portable between application servers, because we take all the capabilities that our application server offers to get the app faster, etc.
But you've got to understand one thing here, and keep it always in your head while studying: The exam is based 100% in the EJB specification, which all app servers that are certified must comply to. So, I'm expected to find many questions like the ones you posted, but only because the exam tries to test whether you have a thoroughly understanding of the specification. Whether you use it or not in your current application is another story. When you get to develop a new EJB application you will be able to show arguments on why you should/shouldn't do a particular task in ejbActivate/ejbPassivate method, and what the implications are.
I agree with you that all responsabilities are too much, and many people don't follow it. But that's the way it is in the spec, and we better study it!
my $0.02
But you've got to understand one thing here, and keep it always in your head while studying: The exam is based 100% in the EJB specification, which all app servers that are certified must comply to. So, I'm expected to find many questions like the ones you posted, but only because the exam tries to test whether you have a thoroughly understanding of the specification. Whether you use it or not in your current application is another story. When you get to develop a new EJB application you will be able to show arguments on why you should/shouldn't do a particular task in ejbActivate/ejbPassivate method, and what the implications are.
I agree with you that all responsabilities are too much, and many people don't follow it. But that's the way it is in the spec, and we better study it!
my $0.02
I'm not going to be a Rock Star. I'm going to be a LEGEND! --Freddie Mercury
Steve Agarwal
Ranch Hand
Posts: 51
posted 13 years ago
I am also new to this EJB but these things bring in the indept know how the transition from ejb1.0 to ejb 2.0 came in picture.
If studying for exam ( primary based on spec 2.0 ) then these scinearions are not even worth wasting time. But I believe the practical coding or migration to new version of ejb would have more realistic answers to teir problems.
steve
If studying for exam ( primary based on spec 2.0 ) then these scinearions are not even worth wasting time. But I believe the practical coding or migration to new version of ejb would have more realistic answers to teir problems.
steve
SCJP1.4,SCWCD, SCBCD, SCEA part 1<br />"Its feels good to know the stuff in detail."
