Preparation Notes for Java Architect part I (CX-310-052)

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:

Oracle’s website with exam details:


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.

Application Design Concepts and Principals

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 use
d 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:
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 - re
qwired 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:

Design Patterns (a must)

Core J2EE patterns (a must)

Head First Design Patterns

Certified Enterprise Architect

Sun Certified J2EE Architect (for old exam, but still pretty good)

EJB 3 in Action (good for this one and SCBCD)

Mikhail Zaikins Notes (a must)

Code Ranch Architect Forum:

WhizLabs Mock Exams (very helpful)

DJ Chen notes (concise and helpful)
Reading on JSF:
Applet Security:
Security annotations:

Layers vs Tiers: