Hey there Jean!! Long time since I've seen you in person, but it's fun to have you here at the ranch! Yes, CMR *is* on the exam. It doesn't explicitly say CMR in the objectives (that's probably MY fault -- we'll update that next time) but it *does* mention it under the objective for: Component Contract for Container-Managed Persistence (CMP)
*Identify correct and incorrect statements or examples about persistent relationships, remove protocols, and about the abstract schema type, of a CMP entity bean. *Identify correct and incorrect statements or examples about the rules and semantics for relationship assignment, and relationship updating,in a CMP bean. *Match the name with a description of purpose or functionality, for each of the following deployment descriptor elements: ejb-name, abstract-schema-name, ejb-relation, ejb-relationship-role, cmr-field, cmr-field-type, and relationship-role-source.
*Identify correctly-implemented deployment descriptor elements for a CMP bean (including container-managed relationships). So, there's good news and bad news about CMR: Bad news (well, as far as studying goes): YES you'll have a fair number of CMR questions on the exam. Good news: They are not extremely complex questions about CMR. You are expected to know that a relationship consists of these things: * Define a "virtual field" (getters/setters) in one bean, for a reference to a local component interface for another bean. (If it is a one-to-many relationship, then the type of virtual field will be a Collection rather than the local interface of the other bean). * Set-up a relationship in the DD by defining a <ejb-relation> that describes both partners in the relationship -- including multiplicity. THIS is where you state the CMR field, and -- only if it is a Collection -- the CMR field *type*. This part seems weird at first -- by CMR field *type* you would THINK that you're supposed to define, say, the class type for the CMR interface, But that tag is really JUST to specify the type of Collection. If the multiplicity is ONE rather than MANY, then you don't specify the type of the CMR field, just the NAME (like you do with CMP field). * You do NOT specify the CMR field in the place where you specify your CMP fields. You just leave it out and put it *only* in the relationship section of the DD. * The Container maintains referential integrity, in such a way that if you have a one-to-one relationship, for example, you cannot EVER have a scenario where an entity is assigned to more than one other entity. For example, in a relationship between a Movie and a Trailer (this is from the book), where you've defined it as one-to-one, if you take a trailer and say, "Oops, I assigned it to the wrong Movie" so you assign that trailer to a *different* movie, the previous Movie will suddenly have a null value in his CMR field for the trailer. In other words, the trailer can belong to only ONE movie, not two. And you didn't have to do *anything* to make this happen other than assign the trailer to another movie. The Container sees that it is a one-to-one relationship, and automatically takes the trailer *away* from the other movie to which the trailer had been previously assigned. Very cool! So, you do need to understand the effect of relationship assignment on relationship partners. But it's pretty straightforward -- if the multiplicity is *one* -- the entity can exist as a reference for only ONE of its partner type. (eg. a trailer can be referenced by only ONE movie). But if the relationship is MANY, the entity can be referenced by more than one entity of the partner type (eg. a single Director entity can be referenced by many different Movies). * You also need to understand how EJB-QL can be used to navigate through relationships. But again, nothing particularly advanced or tricky! Let's see... there's got to be a Barnes and Noble near you -- go there and try out the mock exams in our book from the entity chapters (there's a specific chapter on relationships and EJB-QL) to get a feel for the kinds of CMR questions that will be on the exam. cheers, Kathy p.s. Jean, how is your soccer star son?
Hi all, yup kids are both professional Volleyball players. 1 in Belgium and 1 in Italy. hey, will studying the 2.1 specs cause me any problems with the exam. can't see reading the 2.0 specs with the 2.1 so close to finality. thanks.
Soccer, volleyball -- OK, at least I knew it was something that uses a BALL I would definitely NOT study the 2.1 specs for this exam, although most of the EJB stuff hasn't changed. The exam is on 2.0, and it's going to stay that way for probably at least a year. It won't change until J2EE 1.4 has been out and in use for a minimum of six months. And that clock won't start ticking on the day the specs are made final (which will be soon...), but instead the six-month countdown will start once J2EE 1.4 starts to hit critical mass in use. Sun is adamant about keeping this particular exam focused on what people are actually *using* rather than the latest and greatest. (As opposed to the SCJP exam, where the Tiger update will probably happen VERY near the final release of Tiger). So that's kind of good news. You don't have to know a darn thing about Web Services. cheers, Kathy