I passed the first test in the SCEA exam today. So I thought I would post some notes that I made as a last minute reminder. These are just meant as cram notes, to look at while you're waiting in the lobby or something right before the test, and are not intended as study notes.
EJB
The EJB specifies how many instances to pool at deploy time.
Valid lifecycle for Entity: Does Not Exist, Pooled, Ready
Finder methods of Entities return either Remote Reference or Enumeration
Entity Beans can NOT use BMT.
Only SFSB can implement SessionSynchronization interface.
Application Exceptions do not cause transactions to rollback.
Create method is optional in Entity home.
EJB Life Cycles:
SLSB:Does Not Exist, Ready
SFSB: Does Not Exist, Ready, Passive
Entity: Does Not Exist, Pooled, Ready
Primary Key:
Must override equals and hashcode
Can be compound or single field
Can be undefined until deployment
All fields must be public
When using CMP, a no-arg constructor is required
Bean class provides
implementations of
1) Home interface methods 2) Remote interface methods 3) EJB callbacks
EJB CONTAINER MODEL
Acts as a Decorator.
The bean pool acts as a Flyweight pattern implementation.
EJBObject and EJBHome are examples of Decorators because they provide transactions and security.
Container Adds: Life cycle mgmt, Naming, Object Distribution, Persistence, Security, Transactions, Concurrency
TRANSACTION ATTRIBUTES
Never: requires that no transaction already exists. Throws
RemoteException if one does.
Not Supported: Transaction will be
suspended if one exists.
Supports: uses the client transaction
context if it exists, or no transaction context otherwise.
Mandatory: requires an existing
transaction. Throws TransactionRequiredException if one does not exist.
Required: causes the enterprise bean to
use existing transactional context if it exists, or to create one
otherwise.
Requires New: always creates a new
transaction context before the method call, and commits or rolls back after the
method call. Any existing client transaction context will be suspended until the
method call returns.
Enterprise beans that implement interface SessionSynchronization must have either the Required, RequiresNew, or Mandatory transaction attribute. Implement SessionSynchronization in your Stateful Session Beans if you need to be aware of transactional events. For CMT ONLY. With bean-managed, you’re demarcating the transactions so you already know when these events occur.
ACID
Atomic: transaction must execute
completely or not at all.
Consistent: the database must be in a
legal state when the transaction begins and when it ends. This means that a
transaction can't break the rules, or integrity constraints, of the
database.
Isolatable: Transaction must execute
without interference from other processes or transactions.
Durable: Data must be written to the
data store before the transaction completes.
TRANSACTION ISOLATION LEVELS
Serlizable: all transactions occur in a completely isolated
fashion; i.e., as if all transactions in the system had executed serially, one
after the other. The DBMS may execute two or more transactions at the same time
only if the illusion of serial execution can be maintained. At this isolation
level, phantom reads cannot occur
Repeatable Read: All data records
retrieved by a SELECT statement cannot be changed; however, if the SELECT
statement contains any ranged where clauses, phantom reads may occur.
Read Committed: Data records retrieved
by a query are not prevented from modification by some other transaction.
Read Uncommitted: In this isolation level, dirty reads are allowed. One transaction may
see uncommitted changes made by some other transaction.
TRANSACTION TERMS
Phantom Read: occurs when, during a transaction, two
identical queries are executed, and the collection of rows returned by the
second query is different from the first.
Non-Repeatable Read: non-repeatable
reads may occur when read locks are not acquired when performing a
SELECT.
Dirty Read: A dirty read occurs when a
transaction reads modified data from a row that has been modified by another
transaction, but not yet committed.
COMMON ARCHITECTURES
Non-Functional Requirements
Performance, Scalability, Reliability, Availability, Extensibility, Maintainability, Security, Manageability
PROTOCOLS
HTTP 80
HTTPS 443
FTP 21
JRMP 1099
IIOP 535
Telnet 23
SSL Protocol runs below HTTP and above TCP/IP
DESIGN PATTERNS
Abstract Factory: Provide an interface
for creating families of related or dependent objects without specifying their implementations.
Builder: Separate the construction of a
complex object from its representation so that the same construction process can
create different representations.
Factory Method: Define an interface for
creating an object, but let subclasses decide which class to instantiate.
Prototype: Specify the kinds of objects
to create using a prototypical instance, and create new objects by copying this
prototype.
Singleton: Ensure a class has only one
instance with global access.
Adapter: Convert the interface of a
class into another interface clients expect so they can work together.
Bridge: Decouple an abstraction from its
implementation so the two can vary independently.
Composite: Compose objects into tree
structures to represent part-whole hierarchies so that clients can treat
individual objects and compositions uniformly.
Decorator: Attach additional
responsibilities to an object dynamically.
Facade: Provide a unified interface to a
set of classes in a subsystem to make it easier to use.
Flyweight: Use sharing to support large
numbers of fine-grained objects efficiently.
Chain of Responsibility: Avoid coupling
the sender of a request to its receiver by giving more than one object a chance
to handle the request.
Command: Encapsulate a request as an
object to support undo operations, queue or log requests.
Interpreter: Given a language, define
its grammar and an interpreter of sentences in that grammar.
Iterator: Access elements of an
aggregate object sequentially.
Mediator: Define an object that
encapsulates how a set of colleague objects interact so they don't have to refer
to each other explicitly.
Memento: Capture an object's internal
state without violating encapsulation so that it can be restored to this state
later.
Observer: When one object changes state,
its listeners are notified and updated automatically.
State: Allow an object to alter its
behavior when its internal state changes. The object will appear to change its
class.
Strategy: Define a family of algorithms,
encapsulate each one, and make them interchangeable.
Template Method: Define the skeleton of
an algorithm, deferring some steps to subclasses.
Visitor: Represent a new operation
without changing the classes on which it operates.
MESSAGING
Pub/Sub: Topics. Push.
P2P: Queues. Pull. (send and forget)
I18N
Items subject to I18N:
Languages for Messages
Formats of Dates, Numbers
Sort Order (Collation)
Currency symbol & position
Tax and other legal rules
Cultural Preferences
Java Supports I18N:
Properties, Resource Bundle, Locale, Unicode, java.text package, InputStreamWriter/OutputStreamReader
Collator: abstract base class for
performing locale-specific String comparisons. Subclasses implement different
comparison algorithms. RuleBasedCollator (provided with JDK) is a concrete
subclass that provides simple, data-driven, table collator.
CollationElementIterator: used as an
iterator to walk through each character of an international String.
CollationKey: represents a String to
compare when using Collator. Comparing two of these returns the relative order
of the strings they represent. Using this is faster than actual String
comparisons.
BreakIterator: contains methods for
finding boundaries of line breaks, sentences, words, and characters in text.
CharacterIterator: defines protocol for
bi-directional iteration over a set of Unicode characters. Methods return either
the index or the character value. Classes implement this interface to provide
this functionality for various sequences of characters.
StringIterator: provides this
functionality for iterating over a string.
SECURITY
A VPN is a trusted network running over a non-trusted network.
Unsigned applets run in the sandbox. Signed applets with a public key by trusted parties have full access. For example, a signed applet can connect to arbitrary hosts. If a policy file is created with grant privileges, an applet will be restricted to the grants in the file, regardless of signing.
A java.security.MessageDigest only provides proof that a piece of code has not been altered.
In SSL handshake, 1) Server is validated to client 2) client and server choose
a crypto algorithm.
After signing a JAR file, files could be added to it later without necessarily invalidating the signature.
Asymmetric cryptography means a separate key for encrypting and decrypting.
Even if applet code is signed, the browser’s policy may prevent it from certain things. The policy file will need to explicitly grant permissions for what it wants to do, ie, read local files.
FIREWALL
Packet Filter Firewall: Looks at the
information related to IP address of a packet, types of connections, etc. and
then provides filtering based on that. Uses this to decide which packets to let
through and which to deny. IP spoofing may fool it.
Application-Level Proxies: Work at the
application level to provide proxy services. Allows more specific inspection of
the packets. Can use application level knowledge to decide what to filter.
Usually requires separate proxy for each type of application you want to filter.
Stateful Packet Inspection Firewall:
Examines and remembers outgoing packets so that when incoming packets come in,
that information will be used to determine whether or not to let the incoming
packets through. For example, if any outgoing packets didn’t request an incoming
packet, it will be filtered.
Java sandbox consists of following elements:
Byte code verifier, Access controller, Security manager
Class loader (applet class loader, url class loader, rmi class loader, default internal class loader, custom built class loaders)
Security package (security provider interface, message digests, keys, certificates, digital signatures, encryption)