By Henry Naftulin (SCBCD, SCWCD, SCJD, SCJP, SCEA Part I)
Note: These notes are not enough
for one to pass the exam – these are only review notes. The information here is
not guaranteed to be right, I tried to make it correct, but I cannot guarantee
it. What helped me pass the exam, might not help other people. This document is still somewhat
disorganized. Please e-mail me with suggestions or corrections: henryn73@gmail.com
Oracle’s website with exam details: http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=41&p_exam_id=1Z0_864
Confidentiality – ensure that the system data and function are protected from unauthorized access. Integrity – ensure that the system data has not been modified or interfered with by the 3rd party. Authentication – ensure that the user or system has appropriate rights to access system data or execute system functions. Authorization – ensure that the is of the user or remote system is valid and has not been impersonated. Non-repudiation – ensure that all actions, once performed, cannot be denied by user or the system itself.
Client security: both webstart and applets run inside the sandbox environment. Security manager for these clients is installed automatically. Compiled code must be signed before it can access client-side resources. By default following are the resources guarded by the resource manager: File, Socket, Property, Runtime, Basic, All Permissions, Net, AWT. No permission control for CPU usage, thread spinning, and memory. Unsigned applet can only connect back to the host they were downloaded from. Signed applet after asking for permissions can use the permitted operations: connect to different host, read files, etc. Unsigned applet might or might not be able to read system properties - some systems require applets to be signed to read the properties.
Unsigned jar for webstart also live in a sandbox and remain running in that sandbox. It cannot perform malicious operations. Signed jar can be configured to use security extra privileges as per JNPL security settings.
Server Side security: EJB: @RunAs, @DenyAll, @RolesAllowed, @PermitAll, @DeclaredRoels; Servlets: @RunsAs. @DeclaredRoles. Roles are configured in the deployment descriptor. Programmatically use context. isCallerInRole, getCallerPrincipal. Web: servlet request isUserInRole, getUserPrincipal.. The urls are configured per role, like /admin/* - those rules are in web.xml.
Web security: WS-Security standard is still in flux. Can do basic authentication and transport level encryption but not message level encryption.
Topologies: single firewall – internal systems communicate freely between themselves, outside → inside, inside →outside through the firewall. Breach of that firewall and all systems are affected. Usually not sufficient. 2 Firewalls and DMZ: first firewall, web servers (in DMZ), second firewall. in this case you might want to provide some service to the outside (web pages) - little or not traffic is permitted between inner region and Internet. - has to go though 2 firewalls - only through proxy server in DMZ. More complex: a firewall between rest of the system and HR. Messages should not be passed directly from any system behind firewall, but rather using proxy server. To go through DMZ or firewall, one either opens port or tunnels request/ response through existing protocol allowed: + no tunneling setup for firewalls - no special rules, no monitoring.
Common threats: man-in-the-middle: party intercepts and reads messages - encrypt traffic with strong SSL. session hijacking: (aka session theft) attacker to create or reuse existing session (forge or guess session id) - invalidate session after logout, encrypt session info, use SSL. Password cracking: guessing password - shut user down after # of attempts. Data injection: (or sql injection) weakness in data validation - need to validate data, user prepared statements. Phishing: user misdirected to a incorrect service and tricks to release password. Social attack, make users more aware(?). Cross-site-scripting: attacker injects malicious code or link into the target web server - input validation and logging would help. network sniffing: encrypt the data going over the wire. Denial of service: extremely difficult to prevent, hostname verification, router filtering to drop connections from untrusted hosts, server might add intercepting validator.
Java Authorization and Authentication Service (JAAS) enabling authentication and authorization plug-gable mechanism. Authenticating could be used as Kerberos, RSA. JCA: java cryptography architecture provides cryptographic services and algorithms, includes DSA (digital signature algorithm), message digest, MD5 and SHA1, DSA key pairs, X.509 certificate. Crypto keys are done by either DSA, RSEA or Diffie-Hellman. JCE: java crypto extension - added crypto services subject to US export laws (ciphers, pwd based encryption, etc.) Cert-path: java certification path API checks, verifies, validates authenticity of certificates claims. JSSE: Java secure socket extension - secure communication to protect confidentiality and integrity of the message. Symmetric keys: DES, IDEA, twofish, blowfish. Asymmetric keys: RSA, Elgamal, ECC.
Encapsulation: enclosed data and behavior in programming module - information hiding and implementation hiding. Both needed for high level of decoupling. Inheritance: defines one entity in terms of another (interface inheritance and implementation inheritance) - to extends behavior of base entity. Polymorphism: ability of different objects to respond differently to the same message (both through subclassing or direct parameter passing). Single responsibility principal: a class has only one reason to change (e.g one responsibility). Open/ Close principle: software entities should be open to extension and close to modification. OO facilitates modular design, reuse, faster development times, better mapping of problem domain, increased quality. Tier- vertical separation of system: app client, web client → web tier → business tier → eis tier. 3 tier app is placing a powerful multithreaded app server between client application and back end. Tiers: Client, Web, EJB, EIS Integrations, EIS. Layer - os horizontal or vertical view of the system: each layer build on top of existing layer. JSF - java server faces, JMS - java message server; JTA - java transaction api, JAF - java bean activation framework; JAXP - java api for XML processing (supports DOM and SAX), JAX-WS java API for XML web services - client API for accessing the web service and technology to implement Web Service end point. Uses JAXB. JAXB - java api for XML binding; SAAJ - soap with attachment API for Java; JAXR - Java API for XML registries; JCA - java connector api; JPA - java persistence api; JAAS - java authentication and authorization service. JRMP - Java remote method protocol.
Service Level Requirements: performance - response time for a given screen transaction for user; transaction throughput (# of transactions in a given time). scalability - is the ability to support the requirements quality for the service as the system load increases without changing the system. Vertically scaling - additional processors, memory, or disks to the current environment. Horizontal scaling - adding more machines to the environment. Vertical scaling of a software architecture is easier than the horizontal. Reliability - ability to ensure that the product is trustworthy and dependable for all of its transactions. Availability - ability to ensure the system the system is always accessible. Extensibility - ability to add or modify additional functionality without impacting existing system. To ensure extensibility - low coupling and encapsulation. Maintainability - ability to correct flaws in existing functionality without impacting other components of the system. low coupling, modularity, documentation. manageability - ability to ensure system has continued health with respect to other quality of service requirements. such as performance, scalability, reliability, availability, security. security - ensure that system cannot be compromised.
Improving service level requirements: + redundancy. load balancing, fail over, clustering. improving performance - increase capacity by adding raw processing power; increase comp efficiency by using better algorithms; introduced cached copies of data, concurrent computation, intermediate responses to improve performance as perceived by users. improve availability - through replication - archive requests sent to all components, passive requests sent to primary states of secodaries synchronized with primary. improve extensibility - anticipate change and design high quality object model. Improving scalability - vertical is transparent to the system architecture, horizontal - make architecture so that components don't depend on physical location of other components. One tier system – poor extensibility (one layer all aspects are tightly coupled), poor scalability (only vertically), poor maintainability. Two tier system - client - server thick client (UI + biz) + server (biz + persistence + db). Presentation and biz logic is tightly coupled; web ui → db + biz logic on same server. + Advantages ease of app development, centralization, faster time to market, small user base minimal maintenance => 2 tier architecture. Disadvantages: availability if server is down everything is down; scalability - each user has connection to db, so only component you can increase is db - more clients db processing power has to grow. manageability - with clients installs on PC it is hard to maintain. It is difficult to administer, batch jobs are harder to run.
Three tier applications: UI - biz logic - data storage; PC thin client - app server - db. Advantages scalability app server shields db from per client connection requirement, and you can load balance between app servers. improved data integrity - since all updates go through middle tier, middle tier ensures data integrity. availability - redundant app server, redundant db, extensibility reliability, security. Disadvantages: increase complexity and effort, fewer tools, separation of concerns.
More tiers: ++ better scalability, high fault tolerance, higher throughput -- too much middleware, redundant functionality, difficulty and cost of development. with additional tiers flexibility functionality possibilities for distribution; but communication cost, complexity, higher complexity of management and tuning.
Rich Client vs browser based client: browser thin client - deployment perspective, minimal updating. browsers are ubiquitous, they offer familiar environment, browser clients can be easily implemented. the big thing is input validation is limited, potentially low responsiveness, no network no functionality, somehow need to keep state. Fat client: if not communicating over http then need hole in a firewall, hard to implement, need to be deployed to the client (JNLP?) and managed on the client. + richer user experience, less bandwidth, better user validation can be designed to work off-line.
Uses of Web Services: heterogeneous integration, consolidates view, managing legacy assets by introducing a layer in the middle with web services. Reduce some functionality by developing a single shared service, software as a service (using API or licensing content). Web services can be RPC or document/literal. Web service can be called asynchronously via polling or callback handler. Not to user web services: when bandwidth is expensive - xml is not compact, not for real time performance, not where message delivery is a must. Web service can replace messaging infrastructure but cannot replace application adapters, message brokers, data extraction and transformation tools, rule engine - no guarantee of message delivery, no GUI.
Integration
And Messaging
integration with EIS could be done via: JNI & RMI - JNI is used to write native method calls
that cannot be written in Java. It does not provide support for J2EE
transaction, security and scalability. The developer has to deal with
complexity of managing these systems level services. Java connector
architecture (JCA) attempts to standardize the resource adapter interfaces. By
defining a set of scalable, secure and transactional mechanisms, the JCA
enables the integration of EIS with application servers and enterprise
applications. JCA components are called resource adapters - implementing
interfaces of javax.resource.cci (common
client interface) and javax.resource.spi (service provider interface)
including connection management, transaction management and security. The
client API can implement common client
interface (CCI) or an API specific resource adapter for the EIS. For the mainframes,
screen scraping technologies could be used. JCA (again) - transaction,
security, connection management. two types of contracts: system level and
application level. Advantages of application level contract is that tools could
be build to user it. System level contract defines plugability standard between
app server and EIS. Connection management contract - to pool connection.
Transaction management contract - to manage transactions accross multiple EIS
resource managers; security contract - to secure EIS resources. If the JCA adapter supports transactions but does not
support2-phase commit it is called to support local transactions, if it
supports 2-phase commit it is called to support distributed transactions.
Corba - language independent
distributed object model specified by OMG. Corba relies on IIIOP for
communication. By using IIOP, EJBs can interoperate with native language
clients. RMI - only for Java services / HTTP - stateless, difficult to secure
state, DCOM - only windows. From Corba to Java use IIOP, from Java to Corba use
Java IDL (who initiates conversation).
Web Services: is a service oriented architecture with allows for
creating an abstract definition of service, providing a concrete implementation
of service, publishing and finding service, service instance selection and
interoperable service use. It allows system to system communication over
network. Check the following link for exam:
http://java.sun.com/j2se/1.3/docs/guide/idl/jidlFAQ.html#java%20idl%20vs%20rmi-iiop
Soap: simple object access protocol - XML based extensible method to
represent data. Has more info than raw xml - envelope, encoding rules, data
representation conventions, but more overhead. WSDL: description of web
services (tools friendly). Jax-RPC:java api for xml based remote
procedure call - was created initially to add web services support to J2EE but
now replaced by JAX-WS. JAX-WS: primary Java API for XML based web
services, both soap based and restful. Preferred way in J2EE @Webservice
@Webmethod. - it uses lower level API JAXB, SAAJ, JAXP, StaX. JAXB:
standard for Java API for XML binding - java object to their xml equivalent and
back. JAXR: standard API for XML registries. SAAJ - soap with attachment
API for JAva. JAXP: java api for XML parsing, StaX: streaming API
for XML (bi directional pull parser). JMS - publish subscribe or point to
point; message delivery ack, message encryption, distributed transactions. Web
Services - designed to facilitate integration with heterogeneous systems. JMS
optimize for java producers and consumers. SOAP - steeper learning curve,
verbose, higher runtime overhead; Just xml - not self describing.
Key questions: synchronous vs asynch, security, transactions, guaranteed
delivery, need for interoperability.
Soap - reqwired
envelope, optional header, required body, optional fault eliminate, optional attachments.
Authentication and Authorization are usually passed in soap header.
Business
Tier Technologies:
EJB - distribute components that can be
accessed locally or remotely. Implemented by Java classes. Managed at runtime
by EJB container + important services such as transaction, security,
concurrency. Configured by meta-data annotations, deployment descriptor, and
container supplied variables. If written to EJB spec should be portable to other
containers. Types: stateless (with ability to become web services), stateful,
MDB -asynch, entity (via JPA). Session
beans - mostly for workflow or process, can be and are pooled. Stateless session beans can
register with timer services to get notification with @Timeout annotation.
States: don't exist - prep by container (dependency injection, post
construction call-backs) - in service - destroyed (predestroy callbacks).
Stateless session beans are good candidates for web services. Stateful session beans - maintains
conversational state with client. Not as scalable as stateless bean. Does not
survive container crash. It could be activated and passivated by container
while servicing requests. they can implement session synchronization interface
so that their state can participate in a well defined transaction. They cannot
be Web Services and cannot register with the Timer Services. States are: don't
exist - prep by container ( dependency injection, post construct) - in service
- passivated /post passivate post activate/ - destroyed (pre-destroy). Both
stateful and stateless beans support transactions, security services, RMI. Both
can be accessed by clients. Entity Beans
long lived objects, in older version of J2EE we had entity bean cmp/bmp. Now
entity classes with JPA. (Old entity beans were passivated and activated, JPA
classes don’t have that). CMP entity bean - delegate
persistence to container + improve developer productivity - control is lost to
container. Harder for performance tuning. BMP entity beans - developer
explicitly codes how the internal state is saved to db. - every single aspect
of persistence must be coded + better for performance since developer controls
the SQL. Entity classes (JPA - Java Persistence API) - POJO with annotation(or
xml) on how to update persistence store
with values stored in the instance variables. Entity manager plays key a role
of container for entity beans. JPA supports relationships between entities
(1-1, 1-*, *-1, *-*). lifecycle is: not instantiated - new (no persistence
context) → managed ↔ detached - removed. Annotations allow certain
degree of sql tuning, language is JPQL. Message
driven beans (MDB) receives and processes messages from a JMS destination -
asynch message processing. have only one method onMessage. clients cannot call
MDB, no conversational state, can be pooled, single MDB can process messages
from multiple clients, transaction aware.
(Deployers can overwrite all information created by
application assemblers /in deployment descriptors/, application assemblers can
overwrite only some information created by developers).
Benefits of EJB are transaction, security - biggest once. Scalability too, pool
EJB. Stateless session beans are best in that regard. Security and transaction
control are primary reasons to go with EJB centric architecture.
Contrasting persistence strategies: Ease of development - JPA + ORM tools vs
directly rolling SQL by hand. Performance: ORM, JPA, CMP runtime penalty is
paid for productivity gains in dev phase. Maintenance
- a bit easier with JPA. Extensibility
- no data persistence approaches is better than other one. BMP could be done
better performance wise than CMP. Maintainability
- CMP is db independent, BMP/SQL are not. JDO provides developers with
enhancers - no superclasses. JDO also hides the details of data storage,
relationships and retrieval, handles concurrency, transaction, scalability,
security. JDO can run in managed environment.
JDO is not JDBS - cannot give that level of access over db and db cache
management. JDO can be a provider for BMP = somewhat parallel to CMP. JPA
targets relational DBs, JDO is datastore agnostic. JPA supports lazy/ eager loading, EJB 2 don’t.
Web services: J2EE 5- user call put
@Webservice annotation and the platform uses JAXB 2.0 to map XML to the classes
properties. Classes and EJBs can access web services wth JAX-WS API
(replacement for jAX-RPC) + developer productivity, rapidly consume web
services to meet new req. rapidly, expose biz services for external web
applications. - potential security concerns; performance is unknown, network
bandwidth; asynch web service cannot be build as of now.
J2EE ad EJB 3 -- ease of development, simpler programming model than prior
versions. So development productivity is a main driver.
Web Tier
Technologies:
model 1 and model 2 architectures. Model 2 has
a servlet processing request: view (JSP) → controller (servlet) →
handler (action) → page to forward. Web container provides services to
presentation and control components provided by developer: JSP, JSF, Servlets,
Filters, Web event listeners, pojos, concurrency control, access to user
managed transaction, configuration, security. Multiple threads use servlet
unless a single threaded model tag interface is implemented. Lifecycle of servlet: container loads it
→ one instance instantiated → install called → request,
response → destroy called, servlet destroyed. Filters; listeners:
servers side components that are notified if something happens in servlet
life-cycle. EL - introduced in JSP
2.0 spec, and JSF introduced it's own EL - but in J2EE 5 they are united.
${exp} immediate, #{exp} - deferred. JSF:
UI framework based on J2EE apps designed to be easily used by developers and to
use user/system generated event model. JSF components are reusable improving developers
productivity, software quality, system maintainability. Web Frameworks: fill gaps between JSP/Servlet/JSF and what is
needed to build a consistent, high quality web app in UI platform - such
features as action handling, client-server validation, integrate security,
manage session state, build maintainable and understandable web UI.
Web Centric Implementation: does not
use EJB. Scenarios with strong messaging, transaction or security management
components are candidates for EJB centric implementation. Yet scenarios where
ease of development, where existing apps are already web centric, transaction
are not key to business (read only, read mostly) use web centric architecture.
For example CRUD app might use Struts + Hibernate + DAO. If no JMS in previous
example then container gives good concurrency control, security and session
management. # of transactions requirements → EJB centric ↑;
security requirements ↑ → EJB centric ↑; messaging
requirements use JMS↑ → EJB centric ↑; performance, ease of
development, scalability existing team skills are points to consider.
Web centric: web interface
(HTML/XML) accessible from internet, simple biz logic, firewall friendly; EJB
container not available, mostly read operations, and avoid EJB performance
overhead. communication over http, https, possibly with xml. EJB centric: support fat clients,
thread safety, security, complexity, distributed apps, transaction - data
integrity, support variety of clients, persistence management. Communication
JMS, RMI-IIOP, http...
Applicability of J2EE technologies:
browser
uses applets, html, xml, java script, ajax; stand
alone client swing, webstart; web
container jsp, servlets, xml, java mail, JSF; ejb container EJB, JTA, JMS, JDBC, Java Mail, etc; EIS - RDBMS, legacy system. Java EE
architecture: multi tier (scalability, flexibility) stand alone
java
enables service oriented architecture: discoverable services, interoperable
services, loose coupling, heterogeneous platform, standard soap communication,
wsdl for service definition, uddi. J2EE technology for SOA: JAX-WS (java api
for xml web services) -create soap and restful web services, generate wsdl
description or classes from WSDL. It could be used for restful web services,
but is better user for Soap. Restful service does not have WSDL. JAXP java api
for xml processing to validate and process xml data. JAXB - java architecture
for xml binding map xml to classes and vice versa, used by JAX-WS. JAXR - java
api for xml registry provides API for xml registries (ebXml/UDDI). SAX - simple
parser for XML. StaX streaming API for XML data. SAAJ - soap wtih attachment
api for Java. for producing and processing xml messages. JAX-RPC java api for
xml base rpc - object stabs calling web services, was done before JAX-WS.
When replacing PHP/ASP technologies we need at least JSP/Servlets (since PHP
has both UI and processing logic). If PHP solution was also transactional, we
might need EJB to go with the JSP/Servlets.
Enterprise Service Bus is a set of infrastructure capabilities implemented by
middleware technology that enables SOA (service oriented architecture).
Measuring: performance log start - end times (can be done with filter
interceptors) external application can be used as well. scalability use performance measurement and user count and check if
user ↑ perf ¯
and by how much. availability use web
bot or some custom app request within intervals and measure performance, availability; bring computer/component
down. extensibility measure time
developer needs to add new requirements by functionality and component.
Estimate and then measure actual, trend increase for the same complexity fixes
over time to see deterioration of extensibility. interoperability log failures or errors in invocation from other
systems and determine % of requests not successfully processed. security use loosely coupled checkpoints
or filters to see if user is allowed to invoke methods and if the invocation
successeeds; log violations.
Other helpful links:
Books:
Design
Patterns (a must) http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?ie=UTF8&s=books&qid=1277442551&sr=1-1&tag=flamchipcasi-20
Core J2EE patterns (a must) http://www.amazon.com/Core-J2EE-Patterns-Practices-Strategies/dp/0131422464/ref=sr_1_1?ie=UTF8&s=books&qid=1277442485&sr=1-1&tag=flamchipcasi-20
Head First Design Patterns http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124/ref=pd_sim_b_4&tag=flamchipcasi-20
Certified Enterprise Architect http://www.amazon.com/Certified-Enterprise-Architect-Study-Guide/dp/0131482033/ref=sr_1_2?ie=UTF8&s=books&qid=1277442606&sr=1-2&tag=flamchipcasi-20
Sun Certified J2EE Architect (for old exam, but still pretty good) http://www.amazon.com/Certified-Enterprise-Architect-310-051-Certification/dp/0071488618/ref=pd_sim_b_2&tag=flamchipcasi-20
EJB 3 in Action (good for this one and SCBCD) http://www.amazon.com/EJB-3-Action-Debu-Panda/dp/1933988347/ref=sr_1_1?ie=UTF8&s=books&qid=1277442805&sr=1-1&tag=flamchipcasi-20
Mikhail Zaikins Notes (a must) http://www.scribd.com/doc/25297376/J2EE-5-Architect-Exam-Study-Guide
Code Ranch Architect Forum: http://www.coderanch.com/forums/f-26/java-Architect-SCEA
WhizLabs Mock Exams (very helpful) http://www.whizlabs.com/scea/mock-exam.html
DJ
Chen notes (concise and helpful) http://scea.djcheng.com/
Reading on JSF: http://www.jsftutorials.net/jsf-reading-guide/articles-and-presentations.html
Applet Security: http://java.sun.com/docs/books/tutorial/deployment/applet/security.html
Security annotations: http://java.sun.com/developer/technicalArticles/J2EE/security_annotation/
Layers
vs Tiers: http://www.coderanch.com/t/489489/java-Architect-SCEA/certification/layers-vs-tiers#2201273