A few study aids for the beta!!

Hello SCWCD candidates! In preparation for the SCWCD Beta, Bert and I thought it would be nice to send out a few notes to help you understand what the beta is for and what topics you might want to study in more depth. We will first talk about the Beta itself and then we will have a short blurb for several sections of the exam. Good luck, Bryan and Bert p.s. Starting in a few days we hope to be posting sample pages from Head First Servlets. We know many of you are anxious for additional study materials, and we will post materials as soon as we can!

======== Overview ======== Sun's process for creating a certification exam is: (a) create the vision for the exam The vision for SCWCD has not changed. The point of the exam is to test a developer's capabilities in developing Java-based web applications (webapps). This measures one's knowledge of the APIs, language features (JSP, EL, etc), development best practices, and patterns. This test is a multiple choice test, but we strive for performance-based questions over knowledge- (or memory-) based questions. (b) design the objectives The objectives are grouped into sections in a two-tier hierarchy. The objec- tives are written to give you as much guidance for study as possible. (c) perform a SME (subject matter expert) review of the objectives Over 100 SMEs from around the world reviewed the objectives and provided an indication of the importance of each section and objective. Based on the results of this review, the sections are weighted to determine how many items (questions) need to be written in each section; furthermore, each objective within a section is also weighted to determine how many items per objective need to be written. (d) item writing workshop The workshop brings together several SMEs to write test items based on the results of the SME review. Kathy, Bert, and I were three of the nine SMEs. We also had two Sun SMEs: Greg Murray from the J2EE BluePrints team and Mark Roth from the JSP Expert Group. We created over 270 items during this one-week workshop. Not every question will make the final "forms" as some questions will not perform well during the Beta. Each question goes through several reviews including a technical review that involves *all* of the item writers. (e) Beta test of the items The Beta has two parts: borderline survey and the actual test. The border- line survey is a simple survey which is a self-assessment on the test-takers skill in the 11 major sections of the exam. The purpose of this survey is to coorelate ability versus how to perform on the test. For example, if many candidate with little knowledge of servlets are able to answer Item #47 correctly, then that item is too easy. On the other hand, if several expert candidates all miss Item #42, then that item is too hard. Also, the candidate may also make a comment on any question; for example, if the candidate believes that the question is ambiguous, misleading, or just plain inaccurate. All such comments are reviewed by the certification manager (Evelyn) and the technical comments are reviewed by the cert. developer (Bryan). Remember, the point of the certification is to measure the "minimally qualified candidate" (MQC). That is why certs are pass/fail exams. The Beta is designed to measure the MQC and how well individual items perform relative to the MQC. (f) final item review based on Beta results After the Beta, two things happen: psychometric review and technical review. The psychometric review is the statistical analysis of the borderline surveys and the tests. The result of this process is a measure of how well each item performed during the Beta relative to the experience of the Beta part- icipants. The technical review occurs for items that have been flagged by the Beta candidate with comments. It is my job to make sure that the items are technically accurate; as I will have the onerous task of justifying the items after the exam is released.

========= Section 5 -- Webapp Security ========= - As stated in the objectives, four fundamental security concepts (the Big 4), are important for the exam: - authentication - authorization - data integrity - confidentiality Note: As these terms are in wide spread use, refer to chapter 12 of the Servlet 2.4 specification for the definitions that will be used in the exam. - You should understand the Big 4 from a conceptual level and be able to recognize which concept is appropriate for a given situation. - You should understand how the Big 4 relate to programmatic versus declarative security in the context of Servlets and JSPs. For instance, you should understand how the Big 4 CAN and CANNOT be represented in the deployment descriptor. You should also understand how the HttpServletRequest interface applies to security. - Of the three security oriented objectives, the objective that focuses on the deployment descriptor is by far the most detail oriented. - You should understand in detail the structure and use of the following elements of the deployment descriptor: - <security-constraint> - <login-config> - <security-role> In addition, you should understand these elements' sub-elements. - You should understand the concept of "security constraints" as it applies to Servlets. Understand the following elements: - <web-resource-collection> - <auth-constraint> - <user-data-constrint> *** Pay special attention to the following elements, and the combining rules related to these elements: - <url-pattern> - <http method> - You should understand how the "transport guarantee" concept is applied to servlets. - You should understand how to use programmatic and declarative security-related code fragments together. Objective 5.3 is focused on authentication, which is not that complex a subject from the Servlets perspective. Because this objective is not so heavy-duty, the related questions tend to be a bit more detail oriented (some might even say "trivia oriented".) - If you understand the following sections from the Servlet 2.4 spec, you'll be in good shape for this objective: - 12.5, 12.5.1, 12.5.2, 12.5.3, 12.5.3.1, 12.5.4, 12.6, 12.7 (We're not passing the buck here, these sections are small the the exam covers them in detail!)

========= Section 6 -- The JSP Model ========= This is a grab-bag section. You need to know *everything* about JSPs. ;-) OK, maybe not everything, but pretty damn close to it. If you have been working with JSPs for a while, then you will not have much trouble with this section. Objective 6.1 asks you to identify or write JSP code. The table below provides a view into the four fundamental aspects of JSP syntax:

For Obj6.2 you must understand the syntax and semantics of the JSP directives. In general, JSP directives affect the translation of the JSP file into a servlet class (Java code) that executes the JSP page at runtime. The fundamental syntax is:

For Obj 6.3 you must understand the basic syntax of a JSP "Document", which is a JSP page that adhers to the XML syntax. For Obj 6.4 you must understand the life-cycle of a JSP page. This lifecycle is listed in the objective. For Obj 6.5 you must be able to write JSP scripting code that uses any of the JSP "implicit variables" which are listed in the objective. For Obj 6.6 you must be able to write or analysis the deployment descriptor structure that configures aspects of JSP's within the webapp. The basic structure of this is:

Here is a mock question for section 6: 6.x.y What is the result of the JSP code:

a). An HTML 'h1' tag is specified by the 'appTitle' context parameter. b). An HTML 'h1' tag is specified by the 'appTitle' servlet init parameter. c). The 'h1' custom tag is executed on the value of the 'appTitle' context parameter. d). The 'h1' custom tag is executed on the value of the 'appTitle' servlet init parameter.

========= Section 10 -- Tag Library Development ========= This section is likely to cause the most trouble because the JSP v2.0 spec now includes not one but three tag development technologies: * Classic tag handlers (from JSP v1.2) A classic tag is a Java class that implements either the Tag, IterationTag, orBodyTag interface, but usually you will extend either TagSupport (which implements Tag *and* IterationTag) or BodyTagSupport (which implements BodyTag). * Simple tag handlers A simple tag is a Java class that implements the SimpleTag interface. [Or you can extend the SimpleTagSupport class.] * Tag Files A tag file is a special JSP file that includes additional directives to define the tag itself (no TLD necessary). For Classic tag handlers you need to know about the following event methods: * doStartTag -- called once to process the start tag Return values are: SKIP_BODY if you want to skip the tag body EVAL_BODY_INCLUDE if you want to process the body EVAL_BODY_BUFFERED if you want to process and buffer the body * doAfterBody -- called after the body of the tag has been processed Return values are: SKIP_BODY if you want to stop iterating EVAL_BODY_AGAIN if you want to keep iterating * doEndTag -- called once to process the end tag Return values are: SKIP_PAGE if you want to skip the rest of the JSP page EVAL_PAGE if you want to process the rest of the page For Simple tag handlers there is only one event method: * doTag -- called once to process the whole tag The body of a simple tag is converted into a Java object (of type JspFragment). The body may be processed as many times as you want by using the 'invoke' method on the JspFragment object. Therefore, you can perform an iteration just be invoking the fragment more than once. The doTag method may throw a SkipPageException which tells the JSP page to skip executing the rest of the page. Limitations of Simple tag handlers and Tag Files: * the body of the tag may NOT use JSP scripting code (<%...%> or <%=...%&gt Here is a mock question for section 10: 10.x.y Given:

Which two are true about this JSP code? (Choose two)

a). The 'method' attribute CANNOT contain scripting code. b). The body of the callEJB CANNOT contain scripting code. c). The callEJB tag may NOT contain any content, it must be empty. d). This tag handler class must use the naming convention that puts all hanlder classes in a 'tags' package. e). The tag handler must be a Classic tag handler implementation. ========= Section 11 -- J2EE Patterns ========= - The questions are in fact focused on the six patterns listed in the objectives. - These questions will usually be conceptually based as opposed to other sections that might focus more on analyzing code samples. - You should understand how and where these patterns fit into large scale, high volume web server applications. - The use of patterns is an inexact science, and not everyone always agrees on which patterns to use when. The book Core J2EE Patterns was used as a reference for the exam, and the related website www.corej2eepatterns.com can be used as a resource for studying for the exam. - In situations where an application has used several patterns, you should understand when these patterns interact with each other, and when they don't. - Several of these patterns, such as Front Controller and MVC overlap with each other to some degree, conceptually and in practice. You should understand the distinctions between patterns that may have similarities. - You should understand that all of these patterns have strengths and weaknesses in general, and you should understand the strengths and weaknesses of each specific pattern.

Example mock exam question for Section 11, patterns: 11.x.y When deciding whether to use the Transfer Object pattern, which two considerations are relevant? (Choose two.) a). You want to reduce the number of round trips made on the network. b). You want to invoke only those remote services that are absolutely necessary. c). You want to wrap low level exceptions in user exceptions. d). You want to allow users to update data that resides in other tiers. e). You want to make the creation of services transparent to the user.

with regard to the question about tag, the answer "e" says that it must be a classic tag implementation ... why can't it be a SimpleTag ??? btw, scriptless means no scriptlet, right? other things like runtime expression ("<%= ...%>") and declarations("<%! ...%>") do not matter, right? [ January 18, 2004: Message edited by: Yi Meng ]

Originally posted by Yi Meng: with regard to the question about tag, the answer "e" says that it must be a classic tag implementation ... why can't it be a SimpleTag ??? btw, scriptless means no scriptlet, right? other things like runtime expression ("<%= ...%>") and declarations("<%! ...%>") do not matter, right?

Let's take the second question first. "Scriptless" primarily means no scriptlet <%...%> or expression <%=...%> tags, but in practice it should mean *all* scripting elements. In other words, it does not make sense to include directives <%@...%> or declarations <%!...%> within custom tags of any sort; because these are *not* part of the runtime evaluation of the JSP page and the custom tag in particular. As for the sample question for Section 10... After more careful review, this item would not pass technical review. I wrote it too quickly and did not notice that I introduced an inconsistency. [Oh yeah, the typo should be fixed on line 21 of the TLD code snippet; it should only be 'method' not 'methodName'.] The inconsistency is that I have defined the body-content as scriptless, this is what I was testing in option 'B', but doing so allows the tag handler to be a SimpleTag; it does not have to be a ClassicTag as I stated in option 'E'. See how hard these questions are to write? :-) -Bryan

Ali Ragi
Ranch Hand

Joined: Dec 10, 2003
Posts: 60

posted Jan 19, 2004 13:06:00

0

... See how hard these questions are to write? :-) -Bryan

Yes, Bryan. We understand! Writting a question is much more difficult than answering it by us. You have to try to be perfect with the question. I guess that it spend 30 or more minuts to develop a question, and couple time to review it. We just spend 1-2 min to answer, click ,click... in the exam. We appreciate you answering our questions, and giving us some tips!! Thanks [ January 19, 2004: Message edited by: Ali Ragi ]

Yi Meng
Ranch Hand

Joined: May 07, 2003
Posts: 270

posted Jan 20, 2004 09:20:00

0

Originally posted by Bryan Basham:

The inconsistency is that I have defined the body-content as scriptless, this is what I was testing in option 'B', but doing so allows the tag handler to be a SimpleTag; it does not have to be a ClassicTag as I stated in option 'E'.

How to tell whether it is a SimpleTag implementation or ClassicTag from DD and/or jsp sample code? I suppose from DD's point of view, there is no way to distinguish them, right? So then, how abt from jsp sample code?

I suppose from DD's point of view, there is no way to distinguish them, right?

I guess there is still a narrow way from TLD: if the <body-content> element has a JSP value, and it is still valid, then it's a classic one, because "JSP" is not a valid body-content value for Simple handler.

SCJP 91% SCJD 94% SCBCD 98% SCWCD1.4 86%<p>XML141 SCDWJS -- in progress<br />If you don't retreat, you are mostly among those who can surmount it.

Originally posted by Bert Bates: Objective 5.3 is focused on authentication, which is not that complex a subject from the Servlets perspective. Because this objective is not so heavy-duty, the related questions tend to be a bit more detail oriented (some might even say "trivia oriented".) - If you understand the following sections from the Servlet 2.4 spec, you'll be in good shape for this objective: - 12.5, 12.5.1, 12.5.2, 12.5.3, 12.5.3.1, 12.5.4, 12.6, 12.7

Mr.Bryan, I think the SRV.12.6 and 12.7 are not included in the exam objectives... Those sections are not related to the exam objectives... Could u please explain why we need to read those sections? Or are some parts of them included in the real exam... Thank u very much for your guide...