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!)
Example mock exam question for Section 5, security:
5.x.y - When creating a <login-config> element in a web application's deployment descriptor, if a <form-login-page> sub-element is present, which two other sub-elements must also be present? (Choose two.)
a). <realm-name>
b). <auth-method>
c). <form-error-page>
d). <form-login-config>
e). <transport-guarantee>
=========
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, or
BodyTag 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 <%=...%>
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.
Answers to mock questions:
Section 5 Answer: c, d spec 13.4.18 (page 145?)
Section 6 Answer: a
Section 10 answer: b, e
Section 11 answer: a, d Reference core j2ee patterns - T.O. and B.D.