Java Arch

1 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

Java Arch

Oracle Certified Master, Java EE 6 Enterprise

Architect 1Z0-807
Application Design Concepts and Principles

Identify the effects of an object-oriented approach to system design including the effect of
encapsulation, inheritance, and use of interfaces.
Encapsulation enforces modularity.
Inheritance passes "knowledge" down. Classes are created in hierarchies, and inheritance
allows the structure and methods in one class to be passed down the hierarchy.
Polymorphism: Allows procedures about objects to be created whose exact type is not known
until runtime.
Open Closed Principle (OCP): Classes should be open for extension but closed for modification.
Liskov Substitution Principle (LSP): Subclasses should be substitutable for their base classes. If
the precondition is not met, the method shouldn't be invoked, and if the postcondition is not met,
the method shouldn't return.
Dependency Inversion Principle (DIP): Depend upon abstractions. Do not depend upon
concretions.
Interface Segregation Principle (ISP): Many specific interfaces are better than a single, general
interface.
Composite Reuse Principle (CRP): Favor polymorphic composition of objects over inheritance.
Principle of Least Knowledge (PLK): For an operation O on a class C, only operations on the
following objects should be called: itself, its parameters, objects it creates, or its contained
instance objects.
Acyclic Dependencies Principle (ADP): The dependencies between packages must form no
cycles.

Identify how the Separation of Concerns principle applies to the component model of a
Java EE application; including client, the web and business component containers, and
the integration and resource layers.
Two tier: (Presentation/Logic) (Data)
Advantages
Security (behind firewall)
Good performance (unless older hardware)
Disadvantages
Availability since one component failure makes the system unavailable.
Scalability (only the db can be upgraded)
Manageability (too many clients to manage)
Maintainability and extensibility (changes will affect other components)
Three tier: (Presentation) (Logic) (Data)
Avantages
Scalability and availability (servers can be clustered)
Extensibility (more tiers means that changes can be made without affecting other
parts)
Maintainability (less nodes to manage)
Performance (assuming no large data transfer is required)
Disadvantages
More complex

5-12-2014 14:52

Java Arch

2 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

Does not mean a good architecture just on its own

More tiers mean better
J2EE Platform:
Client-tier components run on the client machine.
Web-tier components run on the Java EE server.
Business-tier components run on the Java EE server.
Enterprise information system (EIS)-tier software runs on the EIS server.
Web components: Servlets / JSPs / JSF
Business components: EJB, MDB, etc.
Web-Centric implementation: no EJBs, only web container/profile
No async messaging requirements, no JMS
Security / concurrency / session management enough in web container.
Existing team skills or existing project implementation

Identify the correct interpretation of Separation of Concerns as it applies to the Java EE

service layers, including component APIs, run-time containers, the operating system, and
hardware resources.
A Java EE application is packaged and contains:
Functional component or components (enterprise bean, JSP page, servlet, applet, etc.)
An optional deployment descriptor that describes its content
EJB modules, enterprise beans and an EJB deployment descriptor JAR
Web modules, servlets, JSP, supporting class files, GIF and HTML files, web application
deployment descriptor WAR
Application client modules, which contain class files and an application client deployment
descriptor JAR
Resource adapter modules, which contain all Java interfaces, classes, native libraries,
resource adapter deployment descriptor for JCA adapter RAR
APIs
EJB. Session and message driven beans
Servlets / JSP / JSTL
Java Server Faces (JSF)
Gui component library
A flexible model for rendering components in different kinds of HTML or different
markup languages and technologies. A Renderer object generates the markup to
render the component and converts the data stored in a model object to types that
can be represented in a view.
A standard RenderKit for HTML/4.0.1 rendering
The following features support the GUI components:
Input validation
Event handling
Data conversion
Managed object creation
Page navigation configuration
Expression Language EL
Provides: Converters, Listeners, Validators
Lifecycle:
Restore View Phase
Apply Request Values Phase
Process Validations Phase
Update Model Values Phase
Invoke Application Phase
Render Response Phase
Events:
(Application event) Action events: Buttons / hyperlinks
(Application event) Value change events: Changes the value of a UI
component (if validation is successful)

5-12-2014 14:52

Java Arch

3 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

(System event) System events: Generated by Objects. Apply to whole

application.
(System event) Data Model event: A new row of UIData component is
selected
Navigation
User defined in faces-config.xml
Implicit: tries to find page based on action + .xhtml
AJAX
Provides a built in JS resource library

JMS / JTA / JavaMail

Java API for XML Processing JAXP
Parse and transform XML
DOM and SAX (push parser) access. XSLT processing.
StAX: Pull parser
Java API for XML Web Services JAX-WS
Web Services using JAXB bindings
Support for Message Handlers
Custom serializers / deserializers
Client APIs and techniques for implementing servers
Java Architecture for XML Binding JAXB
Bind XML schema to Java
SOAP with Attachments API for Java (SAAJ)
Low level API used by JAX-WS and JAXR. Not used directly
SOAP 1.1 spec support
Java API for XML Registries
Access to registries over the web.
Support ebXML and UDDI standard
J2EE Connector Architecture JCA
Used to create resource adapters that support access EIS
JDBC / JNDI / JPA
Java Authentication and Authorization Service JAAS
Allows J2EE app to authenticate / authorize
Java version of PAM
Managed Beans
Lightweight POJOs with support for resource injection, lifecycle callbacks,
interceptors.
Generalization of the managed beans of JSF
Can be used anywhere, not just web modules
Bean Validation
Validation of JavaBeans
Define validation constraints in one place, share across layers (server, browser)
Java Authorization Contract for Containers (JACC)
Defines a contract between a Java EE app server and an authorization policy
provider.
Java Authentication Service Provider Interface for Containers (JASPIC)
SPI for authentication providers that implement message processing
authentication
Modify outgoing message to ensure they can be authenticated
Authenticates incoming messages
Containers
Interface between a component and low level functionality
Provides security, transactions, JNDI lookup services, remote connectivity to enterprise
beans.
Communication Technologies
RMI
Uses Java Remote Method Protocol (JRMP) to turn local method invocations to
remote invocations.
Java IDL

5-12-2014 14:52

Java Arch

4 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

Allows CORBA (Common Object Request Broker Architecture) calls defined in an

IDL
RMI-IIOP
RMI API over IIOP (Internet InterORB Protocol)
Layers:
Application: App code, EJBs. etc
Upper: App server / APIs
Lower: OS / Hardware

Identify non-functional and quality-of-service requirements that influence application

design, including trade-offs in performance, availability, and serviceability.
Non functional requirements: criteria that can be used to judge the operation of a system, rather than
specific behaviors. Functional requirements is detailed in the system design. Non-functional
requirements is detailed in the system architecture.
Performance, availability, disaster recovery, security

Common Architectures

Identify the appropriate strategy for deploying client applications to desktop and mobile
platforms, the principles for designing a user interface and the benefits of applying
client-tier patterns.
Two tier: Client -> Database
Three tier: Client -> App server -> Database
Multi tier architecture as usual in J2EE
Client tier - Browser or rich client
Presentation tier - servlet container
Business tier - EJBs or web services
Integration tier - communication to databases, messaging systems, ERP systems, etc.
Resource tier - databases, legacy systems, etc.
Fat Clients in a client/server architecture runs directly on a PC's operating system. It puts a lot
of functionality into the client logic, and may communicate to the server only sporadically.
Client must be installed and updated.
Thin Clients runs on a standardized framework, such as a browser or a terminal service (Citrix
or X-windows). The client code does minimal processing, and depends heavily on server
communication.
Web browser is a standard thin client platform. It is easy to develop web software.
Browsers are cheap, reliable, and are available on many operating systems. Utilizing
scripting on the browser allows some functionality to be moved onto the user's PC.
Deployment of the client is trivial. Basic authentication and secure communication is built
into all browsers.
Different browsers behave differently. Scripting may fail, may be non-standard, or may
be subverted. Validation of data can be done using JavaScript, but it should also be
repeated on the server.
Some applications don't lend themselves to stateless page-based formats. Bookmarks
and Back button can affect application flow. Some frameworks try to alleviate this (such
as Wicket or JSF)
Rich Clients deploy as web applications, but have features more in common with desktop
applications.

5-12-2014 14:52

Java Arch

5 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

More client side processing than web applications, and require less communication than
thin clients.
Uses platform that often provides richer user interfaces than available on a web page.
(Flash / Java applets / JavaFX / Silverlight / DHTML)
Rich clients deploy at startup, so updated client software is delivered automatically.
Highly portable, running on most operating systems and browsers.
Smaller footprint than fat clients, and may run on inexpensive hardware.
They don't have back-button or bookmarking vulnerabilities.
Development of rich clients is more difficult than web applications.
Require more memory and processing power than a web client.
Startup times may be substantial.
Platform plugin might not be availble / enabled / up to date.

Identify best practices for exception handling, logging, and business tier patterns.
Exception handling
Use checked exceptions for recoverable errors, else use unchecked
Avoid exceptions for normal control flow
Dont use exception codes, add more exception types
Fail fast
Let framework deal with exceptions (Make such exception to 404 code)
Avoid empty catch blocks
User standard exceptions
When rethrowing an exception, make sure to pass original exception to constructor
System exceptions:
Problems with support services.
Should throw non-checked EJBException.
Rollback transaction
Might cause container to destroy bean
Application exceptions:
Does NOT roll back transaction
Client should handle exception
Logging
Logger should be static and final to ensure that every instance of a class shares the
same logger
Best to use logging only to log the following
Method entry (optionally with parameter values)
Method exit
Root cause of exceptions
Log the custom exceptions in the catch handler
Session beans
Distributed business components
A session bean is dedicated to a single client or user.
A session bean lives only for the duration of the client's session.
A session bean does not survive container crashes.
A session bean is not a persistent object.
A session bean can time out.
A session bean can be transaction-aware.
A session bean can be used to model stateful or stateless conversations between the
client and the business tier components.
Can be used as Facade to the business tier.
Session beans: Stateless vs Stateful
Stateless if only requires one call to complete operation. Stateful if it needs multiple
calls.
Stateful session beans might be faster than stateless sessions beans that have to pull
the state from DB
HttpSession vs Stateful Session Beans

5-12-2014 14:52

Java Arch

6 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

If all clients come through the web tier, then HttpSession may be used. If web clients,
Java apps, and other EJB, then stateful session beans.
Business Delegate
Service Locator
Session Facade
Transaction attributes
Required: If the client is running within a transaction, the method executes within the
clients transaction. If not, starts a new transaction. DEFAULT
RequiresNew: If no transaction, creates new. If client is running within transaction,
suspends transaction and creates a new one.
Mandatory: If no transaction, throws Exception
NotSupported: If within transaction, suspends transaction
Supports: If within transaction, uses transaction. If not, does NOT start new one.
Never: If invoked within transaction, throws Exception

Identify design patterns that address specific challenges in the web tier, including
authentication, authorization, and scaling and clustering to meet demand.
Sun defines 8 service level concerns:
Performance is a raw measure of work done, in response time or TPS. More tiers can increase
response time, but can increase throughput
Scalability is the ability to support quality of service as system load increases. Most commonly
it is related to performance (e.g. "How does throughput change as load increases"), but it could
relate load to any of the service level measures.
Vertical scaling means adding resources such as memory, processor speed, networking
hardware, etc.
Horizontal scaling means adding parallel redundant components to a system.
Adding tiers increases the components at which horizontal and vertical scaling can
occur, so multi-tier systems scale better for performance, availability, etc.
Reliability measures integrity and consistency of the application and all its transactions. A
system that loses messages would be unreliable. If a system has a single point of failure, then the
system is only as reliable as the hardware and software at that point. A reliable system maintains
data integrity no matter what happens.
Adding tiers increases complexity, which may decrease reliability. However, multi-tier
architectures support redundant processors, which may increase reliability.
Availability: An architecture that supports redundant modules will be more reliable. Highly
available systems tend to be multi-tiered. Horizontal scaling can add redundant load-balanced
components which will increase availability.
Maintainability is the ability to correct flaws in the system without impacting other components
of the system. Architectures should be easy to understand and easy to alter safely.Breaking a
system into independent modules makes maintenance easier, so a multi-tiered architecture will be
more maintainable.
Extensibility is the ability to add functionality or modify existing functionality without impacting
existing functionality. Decomposing a system into separate tiers may make extensibility on any
layer easier.
Manageability is the ability to ensure the quality of service as it runs. Managing a system
involves monitoring activity, reconfiguring, deploying and undeploying. Separating concerns into
different tiers may make manageability of a given tier easier, or management of the whole system
more difficult.
Security involves protecting the system from being compromised. It includes concerns of
confidentiality and data integrity, but also relates to Denial of Service attacks. Security becomes
harder as an architecture becomes more complex, so adding tiers can be bad from this
perspective. Comprehensive security support from the system software and operating system can
address this. Also, extra attention should be paid to physical security if the application is split
between separate machines.
If tiers are protected behind separate firewalls, then multiple tiers may have better
security characteristics. A typical pattern is a DMZ where application servers hide behind
an additional firewall.

5-12-2014 14:52

Java Arch

7 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

Six independent variables or dimensions

Capacity The capacity dimension is the raw power in an element, perhaps CPU, fast network
connection, or large storage capacity. Capacity is increased through vertical scaling and is
sometimes referred to as height. Capacity can improve performance, availability, and scalability.
Redundancy The redundancy dimension is the multiple systems that work on the same job,
such as load balancing among several web servers. Redundancy is increased through horizontal
scaling and is also known as width. Redundancy can increase performance, reliability, availability,
extensibility, and scalability. It can decrease performance, manageability, and security.
Modularity The modularity dimension is how you divide a computational problem into separate
elements and spread those elements across multiple computer systems. Modularity indicates how
far into a system you have to go to get the data you need. Modularity can increase scalability,
extensibility, maintainability, and security. It can decrease performance, reliability, availability, and
manageability.
Tolerance The tolerance dimension is the time available to fulfill a request from a user.
Tolerance is closely bound with the overall perceived performance. Tolerance can increase
performance, scalability, reliability, and manageability.
Workload The workload dimension is the computational work being performed at a particular
point within the system. Workload is closely related to capacity in that workload consumes
available capacity, which leaves fewer resources available for other tasks. Workload can increase
performance, scalability, and availability.
Heterogeneity The heterogeneity dimension is the diversity in technologies that is used within a
system or one of its subsystems. Heterogeneity comes from the variation of technologies that are
used within a system. This might come from a gradual accumulation over time, inheritance, or
acquisition. Heterogeneity can increase performance and scalability. It can decrease performance,
scalability, availability, extensibility, manageability, and security.
Common practices to meet Service Level Requirements :
Load balancers
In network switches due to speed
In software due for better manageability and flexibility
DNS based. Easies but no session affinity
Round-robin
Response-time or first available
Least loaded
Weighted algorithm
Client DNS-based algorithm
Failover
Extra capacity in existing servers
Stand by server
Clustering
Two node clusters (symmetric and asymmetric)
Clustered pairs
Ring
N+1 (Star)
Scalable (N-to-N)
Replication
Active replication. All redundant components process all requests.
Passive replication. Only one component processes requests, and

Identify Java EE technologies, including JMS, JCA and Web Services, and design patterns
that address specific challenges in enterprise integration.
JCA: Java EE Connector Architecture
JMS: Java Messaging Services
Useful intra-company (control both the message producer and consumer)
Async intrinsically
Publish/subscribe or Point-to-point
Message delivery acknowledgments

5-12-2014 14:52

Java Arch

8 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

Message level encryption

Transactions (JTA)
Web services:
Used to interact with incompatible systems (.Net, etc)
Can maintain compatibility as long as WSDL is stable
Tech independent
Async messaging
Advantages
Loose coupling
Does not block sender
Network doesnt have to be available (messages can be queued)
Least demanding on communications mechanisms
Disadvantages
Reliability is an issues
Good for publish-subscribe
Sync messaging
Advantages
Good for transaction processing
Fail safe communication
Can cope with error situations
Disadvantages
Tight coupling between sender and receiver
Blocks sender
Network must be available
More demanding on communication mechanism
Integration technologies
Mainframe terminal -> Screen scraper
JNI => C/C++
Java IDL => CORBA
JCA => Heterogenous EIS
Async Web Services
Server side push: Client sends request to server. When done, server connects to client
to send response
Polling: Must be supported by app server and client. Method returns Future<?>.
Callback: Must be supported by app server and client. Client passes method to handle
response.
JMS Bridge: JMS over SOAP to enable interoperability between two JMS systems
JAX-WS Handlers:
Protocol handlers: can act on SOAP information
Logic handlers: protocol independent can act on message context properties and
message payload. (SOAP and XML/HTTP)
Web Service Cache: Use handlers to cache responses. Can be done on client OR server.
Web Service Broker
Layer between client and service
Monitor and potentially limit the usage of exposed services,
Coordinates interactions among one or more services, aggregates responses and may
demarcate and compensate transactions
Remote services need be refactored to support local access

Identify the challenges in integrating enterprise resources, the Java EE technologies that
address them (including JPA and JDBC), and the communication protocols that support
tier-to-tier communication (including RMI, IIOP, and CORBA).
Challenges
Limited control over participating applications
Few standards / vendor lock-in
Web services address only part of the challenge. XML is common language not common
semantics

5-12-2014 14:52

Java Arch

9 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

Integration becomes mission critical

JPA
API for high level access to relational data
ORM
A criteria query API (JPQL)
Standardized query hints
Standardized metadata for DDL generation
Mapping strategies
Single table per class hierarchy (uses @DiscriminatorColumn)
Table per concrete class (poor support for polymorphic relationships)
Joined subclass strategy
Application managed
EM / Container managed EM
Locking
Optimistic locking (uses @Version column)
OPTIMISTIC Obtain an optimistic read lock for all entities with version attributes.
OPTIMISTIC_FORCE_INCREMENT Obtain an optimistic read lock for all entities
with version attributes, and increment the version attribute value.
PESSIMISTIC_READ Immediately obtain a long-term read lock on the data to
prevent the data from being modified or deleted. Other transactions may read the
data while the lock is maintained, but may not modify or delete the data. The
persistence provider is permitted to obtain a database write lock when a read lock
was requested, but not vice versa.
PESSIMISTIC_WRITE Immediately obtain a long-term write lock on the data to
prevent the data from being read, modified, or deleted.
PESSIMISTIC_FORCE_INCREMENT Immediately obtain a long-term lock on the
data to prevent the data from being modified or deleted, and increment the version
attribute of versioned entities.
READ A synonym for OPTIMISTIC.
WRITE: A synonym for OPTIMISTIC_FORCE_INCREMENT.
NONE No additional locking will occur on the data in the database.
JDBC
Low level API to access database
JDBC to ODBC to any ODBC enabled datasource
Native and pure Java drivers
RMI
Object is passed by value (objects are easier to reconstruct)
Any object can be passed (Serializable or Remote objects)
Heterogeneous objects are NOT supported
IIOP
Abstract protocol (used by other protocols)
CORBA
Allows over the wire interoperability between different EJB implementations (also non
Java clients)
Heterogeneous objects are supported (opposite of RMI)
Widely supported standard
Uses IIOP wire protocol
Objects are not passed by value, only the argument data is passed
Server / client has to reconstruct the data
Only common data types accepted
JRMP (Java Remote Object Protocol)
Java-to-Java
Native transport for RMI (RMI-JRMP)
Alternative to RMI-IIOP
RMI-IIOP
RMI over IIOP
More overhead than RMI-JRMP
CORBA distributed computing capabilities to Java
Pass-by-reference: Pass pointer to same object in same memory space
Pass-by-value: Pass different object with same values. Copy of original object

5-12-2014 14:52

Java Arch

10 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

Integration and Messaging

Identify the APIs available for a Java EE technology-based system to communicating with
external resources, including JPA, JDBC, RMI, Web Services, JMS, and JCA. Outline the
benefits and drawbacks of each approach.
JPA
Supports java objects
Standard/portable
Easier to develop
JDBC
Does not support java objects
Non standards implementation (dialects)
Low level integration
RMI
Uses JRMP as native protocol (can be tunnelled through port 80)
IIOP is now recommended
Can be much faster than XML
Web Services
Web services via SOAP or XML-RPC support RPC integrations. Most common protocol
is HTTP or HTTPS, (other: mail, JMS, jabber, or in-memory comm)
SOAP interfaces are defined by WSDL documents. No need to share class files, as with
RMI. Good for communicating between totally different techs: Java / perl, PHP / C#, etc.
Web services are typically slower than other mechanisms, so the recommended practice
is to use coarse-grained calls.
Web services are not as object-oriented as RMI or CORBA.
No built-in support for transactions or sessions.
The JEE standard for SOAP web services is JAX-WS.
Code first or WSDL first
XML is much more verbose than binary messages
Not reliable as Messaging
JMS
Synchronous or asynchronous.
Transactional or non-transactional.
Messages may be persistent or not.
Messaging patterns are either point-to-point or publish and subscribe.
With point-to-point messaging, one or more message producers send messages to a
named Queue. Then, one or more message consumers take messages off the Queue to
process them.
In the publish and subscribe pattern, message producers send messages to a named
Topic. The queuing system then transports copies of the message to all running
subscribers. Message consumers may register themselves as having a "durable
subscription", meaning that they want the message even if they are not currently online.
The queuing system will hold a copy of the message until the durable subscriber connects.
JCA
The JCA is a standard for integrating between JEE application servers and 3rd party
applications. Most commonly, JCA is used to support Java Messaging to external message
queuing systems, so messages can flow transparently between JEE and non-java MQ
systems. JCA adapters can connect to other systems, such as SAP or CICS.
JCA adapters are packaged in RAR files. If a vendor provides a JCA adapter, then that

5-12-2014 14:52

Java Arch

11 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

adapter can be used with any JEE application server.

The adapter interfaces directly to the application server to support minimal standards for
connection management, transaction management, and security.
Applications within the application server interface with the adapter using a client API.
Typically, the API will conform to the Common Client Interface (CCI). Using the CCI is
similar to using stored procedures within JDBC.
Standard API to EIS
Allows to integrate connection pooling, transactions (local or distributed), security when
accessing these legacy resources.
Not restricted by the SecurityManager of the EJB container
Can create threads, read and write files, open sockets, etc.
Allows throttling of connections using pool sizes (just like JDBC connections).
Resources are managed by the application server
Can expose Common Client Interface (CCI) or some custom API
Connection pooling, leak detection, throttling, timeout management and configuration of
connections to legacy resources should NOT be implemented in application code.
As reusable as a JDBC driver. Forces reuse.

Describe the technologies used to integrate business components with Web Services,
including XML over HTTP, JSON, SOAP and REST.
XML over HTTP
REST style web services using JAX-WS
More general than SOAP
JSON
Human readable
Attribute value pairs
More compact
Less strict (no validation / no namespace)
More structural information ( 1 vs 1)
SOAP
Protocol specification for exchanging structured information
Travels over other protocols (mostly HTTP or SMTP)
SOAP building blocks
Envelope (identifies the XML doc as a SOAP message)
Header
Body (call and response information)
Fault (exceptions while processing the message)
Can be made faster using MTOM or FastInfoset
REST
Representational state transfer
Architectural style, not standard
GET / PUT / POST / DELETE on elements and collections
Implemented by JAX-RS

Identify and detail the technologies used to integrate business components with external
resources, including JMS and JCA.
JCA
JCA addresses the need to access the business logic of Enterprise Information Systems
(EIS) in a tightly-coupled way.
JCA provides support for resource adaptation, which maps the J2EE security,
transaction, and communication pooling to the corresponding EIS technology.
Initially, connectors were intended to access legacy transaction servers on mainframes in
a synchronous request/reply mode, and this is how the majority of connectors work today.
The standard is currently evolving toward more asynchronous and two-way connectivity.
Some user-defined variants of the connector are more sophisticated and work on a

5-12-2014 14:52

Java Arch

12 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

logical connection mode. As such, they can behave as invocation frameworks, selecting
the appropriate physical EIS target and business operations in a manner similar to web
services.
JMS
JMS is an asynchronous message-based interface. You can also use JMS to access
business logic distributed among heterogeneous systems. Having a message-based
interface enables the following functions:
Point to point and publish/subscribe mechanisms. Message-based frameworks can push
information to other applications without their requesting it explicitly. The same information
can be delivered to many subscribers in parallel.
Rhythm independence. JMS frameworks function in asynchronous mode but also offer
the capability of simulating a synchronous request/response mode. This allows source and
target systems to work simultaneously without having to wait for each other.
Guaranteed information delivery. JMS frameworks can manage the messages in
transactional mode and ensure message delivery (but without any guarantee of timeliness
of delivery).
Interoperability between heterogeneous frameworks. The source and target applications
can operate in heterogeneous environments without having to handle problems of
communication and execution related to their respective frameworks.
Making exchanges more fluid. The switch to message mode allows finer-grained
information exchange.

Identify how a Service Oriented Architecture (SOA) facilitates system integration and best
practices.
Software architecture design pattern based on discrete pieces of software providing application
functionality as services to other applications
Services are unassociated and loosely coupled units of functionality
Services are described by metadata (WSDL). Metadata allows systems to configure dynamically
by discovery of defined services.
Allows users to form ad hoc applications build from existing software services
Principles:
Standardized service contract: Services adhere to a communications agreement, as
defined collectively by one or more service-description documents.
Service loose coupling: Services maintain a relationship that minimizes dependencies
and only requires that they maintain an awareness of each other.
Service abstraction: Beyond descriptions in the service contract, services hide logic from
the outside world.
Service reusability: Logic is divided into services with the intention of promoting reuse.
Service autonomy: Services have control over the logic they encapsulate, from a
Design-time and a Run-time perspective.
Service statelessness: Services minimize resource consumption by deferring the
management of state information when necessary
Service discoverability: Services are supplemented with communicative meta data by
which they can be effectively discovered and interpreted.
Service composability: Services are effective composition participants, regardless of the
size and complexity of the composition.
Service granularity: A design consideration to provide optimal scope and right granular
level of the business functionality in a service operation.
Service normalization: Services are decomposed and/or consolidated to a level of
normal form to minimize redundancy. In some cases, services are denormalized for
specific purposes, such as performance optimization, access, and aggregation.[12]
Service optimization: All else equal, high-quality services are generally preferable to
low-quality ones.
Service relevance: Functionality is presented at a granularity recognized by the user as a
meaningful service.
Service encapsulation: Many services are consolidated for use under the SOA. Often

5-12-2014 14:52

Java Arch

13 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

such services were not planned to be under SOA.

Service location transparency: This refers to the ability of a service consumer to invoke a
service regardless of its actual location in the network. This also recognizes the
discoverability property (one of the core principle of SOA) and the right of a consumer to
access the service. Often, the idea of service virtualization also relates to location
transparency. This is where the consumer simply calls a logical service while a suitable
SOA-enabling runtime infrastructure component, commonly a service bus, maps this
logical service call to a physical service.
Idempotent: Ability to redo an operation if you are not sure whether it was completed
Service contracts should include QoS and SLA attributes
Service contracts can have Pre (constraints) and Post (benefits) conditions.

Service Architecture
Physical design: databases, software components, legacy systems, identity stores, XML
schemas, service agents, etc. Changes in elements would affect the capabilities of the
service
Service contracts are independent from the implementation
Service Composition Architecture
Services can address new features by being recomposed
Internal composing details are not important for the service contract
Service Inventory Architecture
The service inventory architecture accounts for the processing requirements of all
services, to identify bottlenecks
Allows service candidates to be redesigned as needed before implementation
Service oriented enterprise architecture
Umbrella term for service, composition, inventory architectures. Plus any enterprise wide
resources accessed by the services (databases, ERP, EIS)
In a SOA world services are expected to be:
Async
Has metadata / discoverable
Autonomous
Independent
Technology agnostic
Not able to participate in distributed transactions
In a fire-and-forget service, error handling is the duty of the consumer, not the produce
Coarser methods are better than fine grained methods for remote interfaces
Loose coupling

Business Tier Technologies

Identify the correct EJB technology to apply for a given scenario, including entity classes,
session beans, message-driven beans, timers, interceptors, and POJOs.
When to use EJB
Application needs to be scalable
Need for transactions
Variety of clients
Remote vs Local
(L) Tightly coupled beans, that will call each other a lot
(R) If accessed by application clients
(R) If components are distributed in architecture

5-12-2014 14:52

Java Arch

14 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

(L) Performance: Low latency

(R) Performance: Be able to scale
Beans are designed to be accessed as remote objects, but also support local interfaces for
optimal performance.
Beans are always guaranteed to be thread-safe. Beans are pooled, and never have more than
one client at a time.
Stateful session beans
Maintains a conversational state as a "session". State is retained for the duration of the
client-bean session.
Allows Extended Mode use of the EntityManager. Manager is closed after the SFSB is
closed
Stateless session beans
Stateless beans do not maintain any conversational state from previous invocations.
Beans are pooled to maintain thread-safety, but stateless beans provide better
performance and scalability than stateful beans. Stateless beans may have instance
variables, whose value will be retrained for use on subsequent calls, but the clients cannot
rely on these variables for "session" type processing.
Message driven beans
Supports asynchronous processing of JMS messages. Message driven beans are
similar to stateless session beans, in that they never assume a conversational state.
Entity beans. Beans that are persisted to a database. Deprecated.
Interceptor
Related but distinct classes that are invoked when a method is invoked in an EJB
Same lifecycle as EJB @PostConstruct, @PreDestroy, @PrePassivate, and
@PostActivate
Annotations or XML deployment descriptors
Validate parameters / Verify performance / DI extension / Exception mapping
Timer service
Can call stateless session beans, singleton or MDB NOT Stateful beans
Timers are scheduled with the TimerService object which can be injected or retrieved
from the EJBContext
Can be programmatic or automatic (methods annotated with @Schedule)
Timers are persistent by default
In EJB 3 all beans are POJOs.
In EJB 3 deployment can be done in XML or annotations.
JPA uses entity classes. ORM model

Identify benefits and drawbacks of different persistence technologies such as BMP, CMP,
and JPA, including ease of development, performance, scalability, extensibility, and
security.
Bean Managed Persistence
BMP offers a tactical approach
The developer takes care of handling persistence
BMP uses hard coded queries so we can optimize our queries
Container Managed Persistence
CMP is more strategic
Vendor takes care of everything by using O-R or OODB mappings using metadata.
A developer cannot optimize performance as the vendor takes care of it
Mapping defined using XML or XDoclet
We should start developing CMP beans, unless we require some kind of special bean, like multitables, that cannot be completely realized with a single bean. Then when we realize that we need
something more or that we prefer handling the persistence (performance issue are the most
common reason), we can change the bean from a CMP to a BMP.
JPA: Java persistence architecture
Use CMP if not too many relationships between DB tables

5-12-2014 14:52

Java Arch

15 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

Use BMP is database portability is important

Performance is critical / Complex data types

Identify the benefits and drawbacks of implementing Web Services in the EJB component
container.
JAX-WS (JEE5 + )
POJO can be turned into a web service using annotations.
No need to define SEI (Service Endpoint Interface, extending jaxa.rmi.Remote)
Stateless session beans can be deployed as web services with annotations.
SOAP services are cross platform (PHP, .NET)
Used when need for advanced QoS scenarios.
When need to use WS-* set of protocols (security, reliability)
Message oriented and RPC
Dynamic service requires NO WSDL or XML
Support async and sync communication
Dynamic or static invocation
Implements WS-I Basic Profile for interoperability
JAX-RS
REST web services
Uses annotations to map POJOs as a webresource
Easier for clients to consume

Select the appropriate use of JPA and JPQL in a given scenario.

Use DAO for legacy read-only data

Web Tier Technologies

Identify the benefits and drawbacks of using URL rewriting and cookies to manage HTTP
session state.
Cookies
Cookie support is inconsistent
Some users have them disabled
Some firewalls filter them
Some browsers dont support them
Only small data can be stored (4k max for compatibility)
Stored in the filesystem
URL rewriting
Makes pages longer since all links must be rewritten
Works almost everywhere (regardless of browser or settings)
Both are vulnerable to unauthorized access.
Not much data should be stored in cookies. At the most: Session id / user login / site preference

Identify appropriate uses for JSP and Servlet technology, and JavaServer Faces in a given
Java EE application.

5-12-2014 14:52

Java Arch

16 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

JSF
Provides a GUI component model
Event driven model, similar to GUI widgets
Better matches MVC design pattern
A backing bean coupled to each page.
Each property is bound to either a component instance or its value
Methods that perform functions on the component (validation / event handler /
processing)
Properties can be primitive of object for which converter exists
Configured in faces-config.xml
Configured with annotations:
@ManagedBean (class) Designate a class as being a managed backing bean:
Scopes: @RequestScoped @SessionScoped @ApplicationScoped @ViewScoped
@CustomScoped @NoneScoped
@ManagedProperty (field) Configure a class variable to be managed, including
names, values and scope.
JSF life cycle When processing an HTTP request, JSF goes through these steps:
Restore view
Apply request values
Process validations
Update model values
Invoke application
Render response

Identify the benefits of using an EJB container with a web container instead of a web
container alone.
In web centric apps, the web tier is responsible for most of the applications functionality.
In EJB centric design the EJB encapsulate the core application logic.
EJB is more work (easier in EJB 3 than in EJB2)
EJBs provide thread safety, as well as container managed transactions, security, and scalability.
EJBs are a better tool for large, complex, and distributed applications.
EJBs provide better support for fat clients, since workstation clients may communicate directly to
the EJBs.

Identify the differences between client pull and server push architectures.
HTTP Pull
Client checks server for latest data at regular intervals
HTTP Streaming (Page streaming)
Streaming data in response to long-lived HTTP transaction.
HTTP Streaming (Service streaming)
Uses XMLHttpRequest object
Background connection is kept open
COMET / Reverse AJAX / Bayeux
Server sends data to client on event. Even if connection is closed
Uses the persistent connection feature in HTTP/1.1. Unless specified otherwise, the TCP
connection between the server and the browser is kept alive, until an explicit close
connection message is sent by one of the parties, or a timeout/network error occurs.
Long Polling (Async Polling)
Mix of pure server push and client pull.
After a subscription to a channel, the connection between the client and server is kept
open for a defined period of time (45 seconds default)
If event occurs, data is sent. Client must reconnect
If event does NOT occur, timeout occurs. Client must reconnect
Topic based

5-12-2014 14:52

Java Arch

17 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

Identify the benefits and drawbacks of using a browser to access asynchronous, lightweight
processes on the server.
Advantages
Easier to get HTTP through a firewall (compared to something like IIOP)
Less need to understand the domain
Easier to implement
No need to update client.
Browsers are ubiquitous
Browsers are familiar environments
Disadvantages
Doesnt support arbitrary data formats (mostly HTTP)
Harder to maintain conversational state (sessions)
Less rich interface than traditional GUI
Cant normally work disconnected (offline)
Harder to validate (would need more connections or to download validation code)
Uses more bandwidth than a Java client
More elaborate security required compared to apps in same security domain as server
Could have higher latency / bandwidth
Differences in JS support
Need to duplicate validation logic (client & server)
Cant connect directly to EJB, only to web tier

Design Patterns

Demonstrate knowledge of Java EE design patterns including: Service Starter, Singleton,

Bean Locator, Resource Binder, Dependency Injection, Payload Extractor, Context Holder,
and Thread Tracker.
Service Starter
Initialize an EJB upon server start (e.g. to load a cache).
Uses @Startup.
Calls methods marked with @PostConstructs
Order can be declared using @DependsOn
Used to be faked using a Servlet with load-on-startup=1.
Singleton
Default uses @Lock(LockType.WRITE),can only be accessed by a single thread.
Use LockType.READ for concurrent access.
Default uses concurrency management by container. Can be disabled using
ConcurrencyManagementType.Bean.
As gatekeeper (sequential access to legacy resource) or caching singleton.
Singleton is per node, not per cluster (vendor extensions might provide this)
As other EJB, can be shutdown using @PreDestroy
Natural bottleneck
Object referenced by the singleton wont be garbage collected
Bean Locator
Utility class to encapsulates JNDI if DI not available (e.g. Stateful EJB cant be injected
into a servlet).
Responsible for the JNDI global name constructor
Used in exceptional cases
No performance impact if lookups are eager
Resource Binder

5-12-2014 14:52

Java Arch

18 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

Put a custom resource into JNDI using a @Singleton with @Startup and the JNDI API
(Context.(re)bind()).
Other beans can import newly bound resources. Order can be achieved using
@DependsOn.
Cleanup can happen on @PreDestroy
Can use the Re-Injector pattern to allow injecting this resource using @Inject.
Payload Extractor
Factor out the (reusable) type checking and error handling for a MDB message into a
reusable interceptor.
Poisoned messages (for example wrong type) moved by the interceptor to a "dead letter
queue" via a stateless EJB using the JMS API (a DeadLetterHandler bean). This happens
in new transaction (REQUIRES_NEW) to ensure message is sent regardless of message
processing outcome.
Context Holder
To pass some context data yet not to add it as a param to each method on the call tree
(S.Facade > Service > DAO, indirectly PDO)
TransactionSynchronizationRegistry (TSR)
Use the standard @Resource TransactionSynchronizationRegistryworks as a
map. DI makes the object easily accessible
Provided by JavaEE 5 / 6 spec
Dependent on existence of transactions
ThreadLocal
May be problematic if a S.Facade invokes a Service and each is from a distinct
thread pool = diff. thread.
Interceptor
The actual context set perhaps by an interceptor.
Interceptors have access to context data via the InvocationContext
Limited to EJBs
Context data can be made accessible using the Re-Injector pattern
Thread Tracker
Name a thread after the bean and business method its currently executing for easier
monitoring/troubleshooting (instead of e.g. http-0.0.0.0-8180-1?)
Works via an interceptor
Much slower than a direct call
Violates the spec, so should only be used for debugging.
Dependency Injection (CDI):
Ability to integrate with EL
Decoration of objects
Events / Observer pattern /
Interceptors
Stereotypes (default set of annotations)
Dependency Injection Extender
Integrate another DI frameworks managed beans into an EJB via a custom Interceptor,
which will invoke the DI framework to inject its beans into the EJB upon each call (e.g. via
Guices Injector.injectMember(invocationCtx.getTarget());)
The interceptor must ensure proper beans lifecycle w.r.t. its scope (request x session x
)
Strategies:
Stateful Session Bean Injector can use per-instance injectors and cache the
injected components for the EJBs lifetime
Stateless Session Bean Injector either all the members must be injected before
each call or its necessary to use smart proxies able to react e.g. to transactions for
non-idempotent components
Transactional Integration the injected components already participate in a
transaction started in the session bean
Retired patterns
Service Locator: Replaced by DI
Composite Entity: Replaced by JPA
Transfer Object Assembler: Replaced by functionality in JPAs EntityManager

5-12-2014 14:52

Java Arch

19 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

Business Delegate: Most exceptions no longer checked, DI makes plumbing

unnecessary.
Domain Store: Replaced by functionality in JPAs EntityManager
Value List Handler: JPA entities can be detached. Sometimes used as strategy inside
Paginator
Session Facade: Replaced by boundaries using EntitityManager.
Transfer Object: JPA entities are detachable
Data Access Object: Replaced by EntityManager
Service Activator: Replaced by @Asynchronous
Business Object: JPA entities are business objects
Web Service Broker: EJBs can be exposed using annotations
Core J2EE patterns
(P) Intercepting Filter
Centralizes pre-processing and post-processing of requests and responses
(P) Context Object
Encapsulates the specifics of protocol implementations to be shared
Decouples applications from protocols and system interfaces
(P) Front Controller
Determines processing based on the request
Centralizes logic (applies security, delegates, chooses view)
Separates concerns
(P) View Helper
Separates logic from the view
Helps encapsulate view processing logic
(P) Composite View
Eliminates duplication of common headers, footers, etc
Views can change based on authorization
(P) Dispatcher View
Handles the request and generates a response while managing limited business
processing
Used when views are static and limited business processing.
(P) Service to Worker
Performs business logic before control is passed to the view
Used to centralize business logic for requests

Identify a design pattern, using a description of its features, from the following: Facade,
Strategy, Observer, Composite, and Abstract Factory.
Abstract Factory (C): Way to encapsulate a group of individual factories that have a common
theme without specifying their concrete classes.
Facade (S): A facade is an object that provides a simplified interface to a larger body of code,
such as a class library.
Composite (S): Composes zero-or-more similar objects so that they can be manipulated as one
object.
Strategy (B): Enables an algorithm's behavior to be selected at runtime.
Observer (B): Observers are notified of any state changes in any subject that the observer has
registered to.

Select an appropriate pattern for a given application challenge from the following: Facade,
Strategy, Observer, Composite, and Abstract Factory.
Abstract Factory
When the client does not know (nor care) about the concrete object it gets.
Separates the details of implementation from its general usage.
Point of creation for family of objects
Use when:
System should be independent of how its products are created
System should be configured with one of multiple families of objects (AWT

5-12-2014 14:52

Java Arch

20 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

classes in Windows / Mac)

Families of objects must be used together
java.awt.Toolkit, DAO, and Transfer Object Assembler
Facade
You want to provide a simple interface to a complex subsystem. Subsystems often get
more complex as they evolve. A Facade can provide a simple default view of the
subsystem that is good enough for most clients. Clients needing more customizability will
look beyond the Facade.
There are many dependencies between clients and the implementation classes of an
abstraction. Introduce a Facade to decouple the subsystem from clients and other
subsystems, thereby promoting subsystem independence and portability.
You want to layer your subsystems. Use a Facade to define an entry point to each
subsystem level. If subsystems are dependent, then you can simplify the dependencies
between them by making them communicate with each other solely through their Facades.
Composite
You want to represent part-whole hierarchies of objects, in a tree structure
You want clients to be able to ignore the difference between compositions of objects and
individual objects. Clients will treat all objects in the composite structure (or compositions)
uniformly.
Strategy
Many related classes differ only in their behavior. Strategies provide a way to configure a
class with one of many behaviors.
You need different variants of an algorithm. For example, you might define algorithms
reflecting different space/time trade-offs.
An algorithm uses data that clients shouldn't know about. Use the Strategy pattern to
avoid exposing complex, algorithm-specific data structures.
A class defines many behaviors, and these appear as multiple conditional statements in
its operations. Instead of many conditionals, move related conditional branches into their
own Strategy class.
Observer
When an abstraction has two aspects, one dependent on the other. Encapsulating these
aspects in separate objects lets you vary and reuse them independently.
When a change to one object requires changing others, and you don't know how many
objects need to be changed.
When an object should be able to notify other objects without making assumptions about
who these objects are. Loosely coupled.
JMS Publish / Subscribe model and java.lang.Observable java.lang.Observer
Other GOF Patterns
(C) Virtual Factory Method or Constructor: defins a point of creation for an object type in which
there is no knowledge of the concrete type to use.
jaxax.ejb.EJBHome, jaxax.ejb.EJBLocalHome, jaxax.jms.QueueConnectionFactory,
jaxax.jms.TopicConnectionFactory, java.text.Collator, java.net.ContentHandlerFactory,
javax.naming.spi.InicialContextFactory, javax.net. Socket, java.sql.DriverManager.
(C) Prototype: creating objects that need to be instantiated based on copying using another
object such referred to as "prototype". All objects are created to exist containing values
java.lang.Object
(C) Singleton - objects that need to be instantiated only once throughout the lifecycle
java.lang.Runtime
(C) Builder: Point of creating a complex object (compound) separated from its representation so
that this point of construction can be parameterized to construct different variations of the same
object.
(S) Adapter or Wrapper: convert the interface of one class to another required interface, defining
an intermediate point of connection with the objective of promoting communication between two
incompatible interfaces.
JCA, java.awt.event.ComponentAdapter
(S) Bridge or Handle / Body: Separates the abstraction of an action of its different
implementations, so that both can be flexibly interchangeable. A change of the implementation
should not affect clients
(S) Wrapper or Decorator - its intention is to define an alternative means of adding the heritage

5-12-2014 14:52

Java Arch

21 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

responsibilities to an object in a flexible and dynamic run-time.

javax.ejb.EJBObject, java.io.BufferedReader and java.awt. *
(S) Flyweight - its intention is to define an efficient point of sharing that supports a large number
of manipulations of fine-grained reusable objects.
java.lang.String Pooling and Resources (EBJ Stateless).
(S) Proxy or Surrogate: Defines an object substitute for the real object. The replacement can
transparently mediate the interactions for the real object
Used javax.ejb.EJBObject RMI stub (Proxy)
Behaviour
(B) Chain of respansability: Decouples the sender of the request from the processor. Allows
multiple receivers to handle the request transparently. List can be created dynamically
Used by Servlet / JSP Request Dispatcher
(B) Command or Action or Transaction: Command that may be encapsulated as a uniform
object, allowing flexibility in commands and actions sent. Allows implementation of undo, logging,
transactions.
JEE MessageDrivenBean invoke business logic based on content of messages. Servlet /
JSP are invoked based on type of HTTP request (put, get, post, etc.)
(B) Interpreter: Define objects that can represent and interpret a given a particular grammar
(B) Iterator: Way that the aggregated objects within an object can be accessed by other objects
sequentially without exposing the internals
java.util.Iterator, java.util.Enumeration.
(B) Mediator: Object used to encapsulate the relationship between two other objects, causing
the particular relationship of these two target objects can be implemented indirectly, flexible and
interchangeable
(B) Memento: Capture and store the state of an object so that this object can be restored to its
original state before.
Entity Beans using Bean-Managed Persistence (BMP)
(B) State: Enables an object to change its behavior when its internal state changes
(B) Template Method: Methods that allows subclasses to override parts of the methods without
rewriting. Provides a skeleton
(B) Visitor: Way to represent an operation to be performed on the elements of an object
structure

Identify the use of the law of leaky abstractions or a specific anti-pattern in a given
scenario.
Leaky abstraction:
An implemented abstraction where details and limitations of the implementation leak
through.
Law of Leaky Abstractions:"All non-trivial abstractions, to some degree, are leaky."
Strange results not observed during the original test, but under heavy load
Golden Hammer
Assuming that a favorite solution is universally applicable
Hot potato
A MDB raises an exception, and doesnt acknowledge the message
The server sends the message again, MDB throws exception, etc.
Other Anti patterns
Too many web page items
Excessive layering
Incomplete process transition
Not enough education / over analysis
Magic Servlet
No separation of business logic / view / controller
Monolithic JSPs
Compound JSPs
Coarse or Fine Commands
Command granularity should be based on the model, not the view
Fat Commands

5-12-2014 14:52

Java Arch

22 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

Commands should be thin wrappers around model objects

Cacheless Cow
Not caching dynamic content when possible
Synchronized Read/Write Bottleneck
Caused by Read / Write locks
Can be fixed by doing Copy-on-Write
Lapsed Listeners
Listeners not unregistering
Leak Collections
Long lived collections can keep reference to large code blocks
Connections Thrashing
Creating too many connection from scratch (no pool)
Split Cleaners
Resource allocation and clean up in different places
Hardwired Connections
Not using flexible and stable interfaces for integration communication
XML Misuse
Using XML for large scale searches or summarization
Rigid XML
Round tripping
Chatty interface on a distributed boundary (remote EJB)
Round Bean in a Square Hole
Use of incorrect bean types
Everything is an EJB

Security

Identify elements of the security model in the Java SE environment for remote clients,
including Web Start, applets and the role of the SecurityManager class.
Sandbox
Applets
By default cant open other programs / loading libs / native calls / network call / file
systems
Trusted if signed / installed in localhost
JDK Security Manager controls access to System Resources (based on policy file/key store)
Based on policy
Bytecode analyzer: Checks for code signatures and language access restrictions
(private / public / protected )
Protection Domains
Application domains
System domains (access to network / filesystem )
Permissions determine if JVM is granted access to resource (file / socket / AWT / All)
Policy
Access control mechanism
External config (text file, etc.)
Web Service Security
Authentication and Authorization: Using credentials
Message-level data integrity: Using XML signatures
Message-level and transport confidentiality: Using encryption

5-12-2014 14:52

Java Arch

23 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

Select appropriate locations to implement Java EE security technologies or features in a

UML component and deployment diagram.
Component diagrams may have security ports on the component.
Deployment diagram may have firewalls, DMZ which are security components.

Classify security threats to an enterprise application select measures an architect can

propose to mitigate them.
Input Validation Failures: Server side validation
Output Sanitation: Generated outpu must be verified. Unknown values must be eliminated
(comments and ids)
Buffer Overflow: Fix input validation/ output sanitation / data injection.
Data Injection Flaw: Ensure input is validated
Cross-Site Scripting (XSS): Verify input / output (Specially user HTML code). Escaping of data
strings.
Improper Error Handling: Dont display internal error messages
Insecure Data Transit / Storage: Encrypt data
Weak Session Ids: Encrypt session Ids
Weak Security tokens: Protect passwords / Multifactor authentication
Weak Password Exploits / Password cracking: Strong password policy / Multifactor
authentication. Account lockout.
Weak Crypt: 128bits +
Session Theft / Session hijacking / Replay attack: Invalidate session after logout / SSL for
secure communication
Insecure Config: Misconfigured SSL certs / Default passwords / Misconfigured webserver &
plugins
Broken Authentication: Verify authentication data / force reauthentication
Broken Access Control: Ensure ACL are accurate. Run pen testing on apps
Policy Failures: Verification at design and policy management.
Audit and Logging Failures: Log files must be secured and monitored
DoS & DDoS: Router filtering / Redundant resources / Host name verification. Patterns such as
Secure Pipe / Intercepting Web Agent / Intercepting Validator
Man in the middle MITM: SSL/TLS or IPSec. Secure Pipe
Phishing: Monitor unusual user activity. Education of the users
Multiple Sign-On Issues: Single Sign On.
Security model must take into account:
Underlying system infrastructure (hardware, including the networking layer and
components)
User authentication
User authorization
Auditing
Data encryption
System hardening against specific common attacks

Identify techniques associated with declarative and programmatic security, including the
use of annotations, deployment descriptors, and JAAS technology.
Declarative
Defined in deployment descriptors / annotations
EJB JAR: META-INF/ejb-jar.xml
WAR: META-INF/web.xml
Java JAR: META-INF/application-client.xml
Programmatic
EJBContext.getCallerPrincipal
HttpServletRequest.getUserPrincipal
EJBContext.isCallerInRole

5-12-2014 14:52

Java Arch

24 van 24

https://docs.google.com/document/d/19wRpcFyLH309H_W1jFxTN-...

HttpServletRequest.isUserInRole
JAAS Authentication
Configured using JAAS config file (my-jaas.conf)
One or more LoginModule (per application)
Required: Must succeed
Requisite: Must succeed. Processing stops if failed
Sufficient: Is success, returns
Optional: Authentication continues regardless pass/fail
JAAS Authorization
The app associates Subject with the Principal based on the users access control
context.

Identify the security technologies that apply to an applications code, messaging and
transport layers
Application code
Provided by component container
Not transferable to other environments
Appliable across multiple transports
Advantages
Security suited to the needs of the application
Fine grained, application specific
Disadvantages
Data is close to or contained within the point of vulnerability
The application is dependent on security attributes that are not transferable
between application types.
Support for multiple protocols makes this type of security vulnerable.
Messaging
Security information embedded in the SOAP message
Signature / Encryption (end to end security)
Can be applied to different parts of message (envelope, attachments, etc)
Transport Layer
Secure transport using TLS/SSL HTTPS
Authenticate client and server using PKI / certs
Simple well understood technology
Encrypts everything (body / attachments) .. All or nothing
Tightly coupled with transport
Point to point encryption / not end to end

Gepubliceerd door Google Drive Misbruik rapporteren Automatisch elke 5 minuten

bijgewerkt

5-12-2014 14:52