ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button
Head First EJB

"Head First EJB" Author Interview
The Authors Discuss the SCBCD Exam

by Daniel H. Steinberg
11/05/2003

Editor's note: Kathy Sierra and Bert Bates have just completed the second title in O'Reilly's Head First series, the recently released Head First EJB, a certification book as unique as the series itself. In this interview, the authors discuss why the Head First series now includes a certification book, why the book is essential even if you're not planning to take the exam, how they've used their unique teaching style to help Java candidates pass the EJB exam, and more.

Q: After Head First Java, I was surprised to see a certification book as your second offering. Are you now doing certification books?

A: Believe me, it wasn't an easy or quick decision on anyone's part. But it's not a question of "do we or don't we do certification books," because not all certifications can be lumped into one big category of "you got certified but couldn't program your way out of a bathroom" category. Many, if not most, industry certifications have a reputation for being somewhat easy to pass even without any practical experience or real-world knowledge.

But Sun's programming exams have been among the most challenging to pass. One of my roles with the Sun certifications is to review (and usually respond to) the customer complaints we get when someone doesn't pass one of the Java exams. It's shocking how many people assume that, "I've been programming in Java for two years, so there's no way I could have failed this test." This happens even more with people who've taken other industry certification exams. They just never expect it to be this hard or this subtle. But the original developer of the first two Java exams, Programmer and Developer, wanted the Java exams to have real value, and they wanted it to mean something when you pass the exam. Even if what it means is that you're smart and capable of studying and learning and making subtle distinctions. (The EJB exam, officially named Sun Certified Business Component Developer, or SCBCD, has practical value and meaning, and is technically difficult.)

Related Reading

Head First EJB
Passing the Sun Certified Business Component Developer Exam
By Kathy Sierra, Bert Bates

Q: What if someone isn't planning to take the exam? Should they still read this book to learn EJB?

A: The reason the book is called Head First EJB (and not Head First SCBCD Exam) is because when we first designed what we would put in an EJB "learning book," the content was not related to the exam. However, the content in the exam, and the content we'd planned to include in an introductory learning EJB book, were almost identical. So yes, the book is great for people who want a Head-First-style introduction to really understanding the core concepts of EJB. This book is not for hard-core enterprise developers already familiar with EJB and just looking for power tricks and tips or real-world cookbook examples or patterns. This is about learning, and really understanding, everything about the way that Enterprise JavaBeans work. But since it's Head First, that means in the quickest, and most entertaining way. : )

But while it takes a lot more time to hammer the core concepts into your brain, it does not, for example, cover as much ground as Richard Monson-Haefel's Enterprise JavaBeans, 3rd Edition book. In the ideal world, EJB newbies would start with our book and follow it with Richard's. If they're taking the exam, they should also download the free EJB 2.0 specification.

Q: Does this mean that the Head First series is going to be for certification books?

A: No, it doesn't. It just made sense to do the study guide for this exam as a Head First book. For one thing, the Head First format is more geared towards understanding, retaining, and recalling information than many of the other formats, so it's well suited as a learning tool and as a study guide. A reference book or a cookbook or a power tools book can be your most valuable tool when you're programming, but it isn't designed to help you explicitly retain and recall what you need when the book isn't around.

Q: Well then, that brings up one of the arguments people have about exams: that nobody should have to remember this stuff, when in the real world you'd use a reference book!

A: Ahhh ... this is really getting to the heart of it. Yes, we often hear, "Why should I remember this when that's what reference books are for?" And it's a valid comment, but it's too broad a statement. Obviously, if you take that to the extreme, then it means nobody should have to remember anything, as long as they have a reference book. And that's ridiculous. The job of the exam team and the subject-matter experts in the industry who participate in designing the objectives, is to decide which things should be learned, understood, and remembered, and which things should be left to reference books.

Q: How do you decide what those things are?

A: Every exam starts with a job role description, which has to be agreed on by more than a dozen industry experts and subject-matter specialists. That job role, in the case of the SCBCD, is someone who has been working with EJB 2.0 technology for a minimum of six months. And it's really about what we would expect someone to know, at a minimum, with six months' experience in the field developing with this technology.

But it's not that simple, because the exam is constrained to multiple choice and drag-and-drop formats. In other words, it would be great if we could say, "OK, here's a spec, go build and deploy an EJB application." But that's not practical for most industry exams (although Sun does have some project-based exams). Most people don't have the time or money to spend developing an entire project in order to get certified. So we try to design questions that don't just look at whether the examinees have the knowledge, but whether or not they know the implications of that knowledge. In other words, we ask questions to see if they understand how that knowledge affects their design or implementation choices.

For example, rather than ask a question like, "Do you need to cast and narrow the result of a Remote home lookup in JNDI?" (which would have an obvious answer of "yes"), we show a code fragment that does not include a narrow, and then ask questions about what that code really means. In that example, they'd have to recognize, say, that this code can be only within a local client, since it does not include the narrow. And they would also have to recognize that the object returned from the lookup must be of a type that extends EJBLocalHome. And they also have to recognize that what they'll get back from that object will be something that extends EJBLocalObject, and not EJBObject.

In other words, do they really understand the core concepts and differences between local and remote client views? But we don't put the choices right in front of their face; they have to work out the meaning from the code. They have to think, and they have to know the implications.

Another example might be to show them a series of methods, and we show the transactions those methods run in. The exam candidate has to determine which transaction attributes each of those methods must have, in order to produce that behavior. So the question is based on the examinee knowing how things really interact in order to produce a certain behavior. This is exactly what you'd need to know in order to make the right transaction choices in your application.

Another question might describe a design scenario that shows, "Given this goal, here's what we decided to do and here's why." And then the question asks if there's anything fundamentally flawed in that design. Candidates will not be able to answer correctly unless they understand exactly how the Container behaves, and what aspects of a bean lifecycle are guaranteed. For example, they have to recognize the scenarios in which the bean might not get an ejbRemove() call before being killed. Or that a transaction won't automatically roll back unless you tell it to, if such and such an exception is thrown ... things like that. But we tried to ask as many questions as possible from a practical standpoint. More about what you would have to do rather than just what you know.

(I won't say we were always successful, though, and in this first version, there is certainly a lot of knowledge you need for the SCBCD exam.)

Q: So there's not a lot of rote API memorization then?

A: Actually, there is a fair amount of API knowledge that candidates have to have. We expect them to know which methods they can call on their EJBContext, for example, which methods live in the UserTransaction interface, exactly which methods are in the EntityBean interface, and so forth. They really need to know all of the core interfaces, because we believe that if they don't have those memorized -- and these are considered the core, most basic parts of the EJB API -- then as a developer they are wasting a lot of time looking things up, and they may not really understand what's happening. If I show someone the UserTransaction interface and the SessionBean interface, and they complain, "Why should I have to remember which methods are in which interface?", then that means they really don't understand EJB, or the answers would be dead obvious. In fact, if you really understand how it works, you can pretty easily figure out which methods are in which interface without having to memorize the method signatures.

What we don't do is test people on trivia. In other words, we don't expect you to know, for example, every exact XML tag used in an EJB deployment descriptor. You have to know the kinds of tags that exist in specific parts of the DD, and there are a few that we expect you to memorize, but most of the time, you're being tested on whether you know how the tags are organized, and if you know how they really work; you can figure that out without having memorized most of it. It might be 90 percent memorizing how it really works, and 10 percent memorizing a few specific tags.

But some people complain that we're asking them to memorize things, when really, common sense will tell them the answer! For example, if you have a setter method, it should be pretty obvious that it takes an argument, and in most cases, the type of the argument is given away by the name. So, if someone has to ask, "How the hell should I know the argument to the setSessionContext() method?", they're just not thinking at all.

Q: Let's get to the real question: why should someone take a Java exam and get certified?

A: There are a bunch of reasons, and it really depends on the goal. Perhaps the least important reason is "to make more money." There isn't a lot of hard evidence that passing the exam will automatically lead to more money. But, we do have a ton of anecdotal evidence from people who claim that, for a variety of reasons, they were able to either get a new job or move into a better position as a result of taking the exam. But that doesn't mean that the hiring manager necessarily used the certification as a criteria. In fact, the manager might not even care or know. It means that the certified candidate was able to get the job or a new position simply because he or she knew more, and if the certification wasn't used as proof, the ability to answer questions in an interview was the proof.

Of course, in the bubble days, if you could spell "Java," you were hired, with a signing bonus. But today, that's obviously not the case, so a lot of programmers today are using certification as just one more thing to help differentiate themselves from equally qualified candidates. We see a lot of people in our certification-prep workshops coming in because their employers have sent them. Some consulting firms just want to be able to say, "They're all certified."

For me, in 1998, I was told that to even interview for the particular job I wanted at Sun, I had to pass the programmer's exam first. I took it in the airport, literally, right before my flight out to Colorado where my job interview was. They said, "If you don't pass the exam, don't bother getting on the plane." And I just barely passed, even though I'd been using Java for more than a year at that time, and had developed several applications for customers. I was one of those who thought I knew Java, and was horrified to find out just how little I really did know. Or how much I had misunderstood and was using, sure, but using incorrectly.

Q: Then what's the most important benefit people say they get from being certified?

A: The main reason we hear over and over again is this: "Normally, I learn things only when I must, just in time, to do whatever project it is I'm working on at the moment." To pass the exam, you have to really learn it all, in advance, and it forces you to see how it all works and fits together. Plus, it forces you to learn things correctly, rather than just because "This is how Fred, whose project I just inherited, was doing it." Once we're out of school, most of us simply don't take the time to learn more than we need to work on our current project.

So the exam is a way to force you into learning something at a deep -- and broad -- level, and in the case of EJBs, at the level of the specification, rather than just learning the ins and outs of your particular vendor's tool. A lot of people become an expert in, say, WebLogic, but not necessarily in the programming model of enterprise JavaBeans. Many developers aren't even sure which parts of their system are specific to their particular Container implementation and which are really part of the EJB specification.

Q: Why does that matter?

A: For one thing, a key benefit of the EJB spec is that it's vendor-neutral. In theory (although sometimes it's hard, in practice), you can avoid vendor lock-in by developing an EJB application that can be deployed to any vendor's server, as long as it is EJB-2.0-compliant. But if you don't know where the portable EJB specification ends and your vendor-specific unique features begin, you could end up defeating some of the purpose of EJB by writing code that depends upon a vendor-specific implementation. You might, in practice, still want to take advantage of some vendor-specific capability, but you should at least know when you're doing that, and make the decision carefully, trying to encapsulate the places in your application where you are going beyond the specification and doing things in a non-portable way.

Q: Back to your earlier point, though, how is learning more than you need a benefit? Couldn't that just be a waste of time?

A: For a lot of people, they don't even know most of what's in an API, or what's possible. So each new project tends to be influenced by the things you did on the previous project. You can often make better choices about design and implementation if you know and understand more of the API and the programming model in depth, instead of just the parts you've used in the past. It means you have more tools available.

And we can't believe how many times we see people making really stupid choices when they write their bean code or assemble their applications. Usually, it's not because they're not skilled developers, but simply because they didn't understand how it really works, so they couldn't necessarily use their previous knowledge and apply it in a novel situation. They had a folklore view of how things must work.

Q: Does the exam include best practices and patterns?

A: No, not in this version. Or at least not directly. For one thing, we're going on the assumption that if you really understand it enough to pass the exam, you'll naturally make much better choices in your design and implementations than if you don't. A lot of best practices are dead-obvious common sense, but only if you really understand how things really work. But the main reason we don't have much of this on the exam, is that in a first version of any new exam we try to keep it as absolutely objective as possible. With best practices, we'll often hear that one person's "best practice" is another person's "inefficient nightmare." So we're very careful about putting things like that into an exam. But I would guess that in the next revision of the exam, there will be some of that.

Q: Why is the exam on EJB 2.0 and not the new EJB 2.1? Why is there a brand-new certification, but it's not on the new specification? Aren't they certifying on out-of-date technology?

A: Remember, these exams are supposed to reflect real industry experience. It doesn't do anyone any good, for example, to go to an employer and say, "Hey, I'm certified in this latest and greatest technology, even though virtually nobody in the industry is using it yet ...."

There is no way that most people will have six months experience with EJB 2.1 for a long time, probably at least a year from now. Migrating an EJB application to EJB 2.1 is not something we expect many enterprises to do, unless they specifically want the new features. Besides, most of the new features in J2EE 1.4 (which encompasses EJB 2.1) are related to web services, rather than being significant changes and enhancements to the EJB specification. EJB 2.0 was a major change in the EJB spec, but EJB 2.1 is not. If you're certified in EJB 2.0, you are -- for all practical purposes -- certified in the latest and greatest EJB technology, as far as what people are actually using today.

When the EJB 2.1 hits some critical mass, the exam will be updated. But I wouldn't expect that for a year.

Q: Can you give us a few more details about the EJB (SCBCD) exam? How much does it cost, how long it takes, etc.?

A: The SCBCD exam has 70 questions and you have two hours in which to take it. Nobody finds the time limit a problem for this exam ... two hours seems to be plenty. It costs $150, and you register by purchasing an exam voucher from Sun Educational Services, and then using that voucher to register with a Prometric testing center. You take the exam at a computer, in a simple multiple-choice format (with some drag and drop questions) and you find out immediately if you pass. You can get more info from the SunEd web site.

Q: What does it take to pass?

A: You have to get 45 questions out of 70 (64%) correct.

Q: That seems a little low.

A: Yeah, it is. This means that the beta testers found the exam fairly difficult. We have to make sure that at least somebody can pass it ; )

Q: What do they get for passing the exam and becoming certified? And does the certificate mention their score?

A: When you finish the exam, right there in the testing center, you get a printout that proves you passed. That's your proof, until your final certification arrives in the mail a few weeks later. You'll get a printed certificate and a lovely lapel pin. Bert says it's a "chick magnet", but I just don't know ... ; )

Q: Tell us how the book works as a study guide.

A: Bert and I were on the exam development team, so of course we know what's expected of the exam candidate. We focus on really helping you deeply "get" the topics and learn and understand the core concepts, and in a way that will be memorable. There's no getting around the fact that come test-time, retention and recall are important. But our approach is that the more you deeply understand the way things work, the less you have to use rote memorization.

We want you to be able to look at a question/scenario you've never seen and think, "Well, based on how I know this works, it seems like answer B could be the only possible choice," rather than thinking, "I memorized this. I have no idea what it means, but I remember that answer B was the right method." That's just pointless, not to mention difficult. And if you do it by rote memorization, what have you gained? Just the lapel pin. We want you to understand how it works so that you can make good choices in design and implementation, both on the exam and in your development!

The book is in the unusual Head First format, which you can read all about the learning theory behind Head First on the Head First series page, but it includes a couple of things not found in a regular Head First book -- more than 200 mock exam questions (which very closely match the real exam in tone, difficulty, and topics), and indicators in the book when an area is particular tricky on the exam, as well as when you can relax because such and such a topic is not on the exam. We find it helps people focus when they know a little more about what is not on the exam, so they don't have to go too far down a path that really isn't important to their understanding. We want all of their brain matter focused on what's really important, and it's our job to help guide that.

Daniel H. Steinberg is the editor for the new series of Mac Developer titles for the Pragmatic Programmers. He writes feature articles for Apple's ADC web site and is a regular contributor to Mac Devcenter. He has presented at Apple's Worldwide Developer Conference, MacWorld, MacHack and other Mac developer conferences.


Return to ONJava.com.