Docstoc

Sun Certified Enterprise Architect Quick Reference

Document Sample
Sun Certified Enterprise Architect Quick Reference Powered By Docstoc
					Sun Certified Enterprise Architect - Quick Reference
Date:       May 2001
Author:     Chris Broecker



1 Introduction
This memo contains quick reference information that I found useful in preparing for the “Sun Certified
Enterprise Architect for the J2EE platform (SCEA)” exam offered by Sun Microsystems, Inc.
Feel free to send any feedback to chris_broecker@yahoo.co.uk.


2 Object-orientation concepts
Encapsulation: Hiding the specifics of how data are represented and operations are implemented
behind a public interface that is as simple as possible.
Inheritance: A more specific class inherits interface and/or implementation from a more general base
class. The specific class “is a” base class, e.g. a Circle is a Shape.
Use of interfaces: Instead of referring to classes directly, operations are often described more flexibly
in terms of interfaces. The interface defines a contract of features that a class has to supply. The
specific instance used at runtime can be any object that implements the interface and does not have a
specific base class.
Encapsulation and use of interfaces are very good tools for reducing complexity and coupling,
improving the maintainability of any system. Inheritance has to be used with some care, but can also
be used effectively to avoid duplication and create flexible systems.


2.1       UML
The Unified Modelling Language (UML) is a graphical language that unifies the industry’s best
engineering practises for modelling systems. It consists of
          UML Semantics (formal specification)
          UML Notation Guide (visual guide used by practitioners)
          UML Extensions (objectory process for software engineering, business modelling)
          Object Constraint Language (OCL): for expressing constraints and conditions
UML 0.9 has been defined in June 1996 by the Three Amigos (Booch, Rumbaugh, Jacobson). Further
refined in UML 1.0 (Jan 1997) and UML 1.1 (Nov 1997).


2.2       Diagram types

                                           Use Case diagrams
Structure                    Behaviour                Implementation             Environment
Class diagrams               Sequence diagrams        Component diagrams         Deployment diagrams
Object diagrams              Collaboration diagrams
                             Activity diagrams
                             Statechart diagrams
Refer to Fowler for details. Note that implementing an interface is called ‘Realisation’ in UML.




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                       Page 1 of 22
3 Common architectures
Software architecture is the study of large software systems, from the perspective of their structure.
The study of software architecture concerns itself with achieving non-functional qualities (see below) in
large systems.


3.1    Non-functional qualities

Scalability - the ability to support the required quality of service as the load increases
Maintainability - the ability to correct flaws in the existing functionality without impacting other
components/systems
Reliability - the assurance of the integrity and consistency of the application and all of its transactions.
Reliability spans from the OS to the Application to the service provided.
Availability - the assurance that a service/resource is always accessible
Extensibility - the ability to add/modify additional fuctionality without impacting existing functionality
Manageability - the ability to manage the system in order to ensure the continued health of a system
with respect to scalability, reliability, availability, performance, and security.


3.2    Effects
The following table outlines some inherent properties of common architectures.
                   Single tier                     Two-tier                          Three- or Multi-tier
Scalability        Very limited                    Still limited, DB connections     Good. Resource pooling
                                                                                     possible, hardware can be
                                                                                     added if and when need
                                                                                     arises.
Maintainability    Poor, tight coupling            Difficult, data access and        Good, layers can be changed
                                                   business logic are mixed          independently.
Reliability        OK, Data consistency is
                   simple because one storage
Availability       Poor, single point of failure   Poor, DB server is still single   Excellent with appropriate
                                                   point of failure                  redundancy architecture.
Extensibility      Poor, tight coupling            Difficult, data access and        Good, layers can be changed
                                                   business logic are mixed.         independently.
                                                   Code is dependent on DB
                                                   schema.
Performance        OK                              Poor, DB Server can               Good. Because the system is
                                                   become bottleneck. Each           scalable, performance can be
                                                   client requires a connection,     influenced by choosing the
                                                   no pooling. High network          right system components.
                                                   bandwidth required, because
                                                   all data has to travel to         Bottlenecks can be removed
                                                   client.                           at the relevant layer.

Manageability      Relatively easy                 Poor, complex client              OK
                                                   installation and
                                                   maintenance
Security           OK                              Problematic, because client       Good. Only certain services
                                                   has too much control.             can be accessed, no direct
                                                                                     database access.
                                                                                     Firewalls and authentication
                                                                                     and authorization systems




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                                Page 2 of 22
                   Single tier                   Two-tier                        Three- or Multi-tier
                                                                                 help to further control access.
Notes              No distribution               Two options: Combine            More difficult to program
                                                 Presentation with Business      because distribution,
                   Green screen, dumb            layer (Thick client), or some   concurrency, transactions,
                   terminals                     Business with DB layer (Thin    security, resource
                                                 client, use Stored Procs)       management have to be
                                                                                 understood and taken care of.
                                                 Improved, graphical user
                                                 interface                       The EJB architecture helps to
                                                                                 reduce this overhead.
                                                 Re-use difficult




3.3     Fault tolerance
A failure is a discrepancy between the desired or specified and the actual behaviour of a system.
Failures are external symptoms of faults (defects).
Fault tolerance is the ability to prevent failures even when some of the system components have faults.
The key to achieving fault tolerance is redundancy. Redundancy requires replication:
Hot backup: Extra, live copies (replicas) of an object are serving client requests and synchronise
continuously with the primary object. If the primary object fails, one of the copies takes over.
Warm backup: Backup copies of an object run, but don’t serve clients. Synchronisation happens at
certain, regular intervals. In case of a failure, a copy takes over from the last synchronisation point.
Cold backup: The primary object synchronises with stable storage in certain intervals. In the case of a
failure, a new object is instantiated and reads the storage for set-up.
Fault handling includes service replication, fault detection, fault recovery, and fault notification.
Fault detection is often done by using heartbeats (server sends periodical signal to monitor) or polling
(monitor checks server once in a while).
Fault handling in CORBA involves Replica Managers and Replica Service Agents.
Active Replication: Every replica handles requests and replies. Interceptor has to block extra calls to
third objects and extra responses (same as hot backup).
Passive Replication: One primary replica handles requests and synchronises state with secondary
replicas. Requests are also logged. For fail-over, a secondary replica becomes primary and processes
all requests after the last synchronisation point (same as warm backup).


3.4     Miscellaneous concepts

DNS Round Robin: Spreading incoming IP packets among a number of DNS addresses equally. That
means that each subsequent packet is sent to the next address in a list, until the end of the list is
reached and the next packet is sent to the first address again. This is a simple load-balancing strategy.
It does not take into account the actual load on the machines.
Data Access Objects: Encapsulate the data access logic for a session bean or other component in a
separate class. If you provide a common interface, multiple data access implementations can be
provided, e.g. for different database systems. They simplify maintenance of code, make the path to
CMP easier, and can be automatically generated by sophisticated tools. DAO’s are a bit like EJB’s, but
don’t offer distributed access and transaction control. If these features are not needed, they are easier
to use. There is a standard proposal for DAO’s called JDO (Java Data Objects).




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                            Page 3 of 22
4 Legacy connectivity
Options for integrating legacy systems include CORBA, RMI-IIOP, JNI, and Messaging.


4.1    CORBA
CORBA is a unifying standard for distributed object systems. CORBA is managed by OMG, and can be
used with many platforms and languages. Disadvantages: Complex standard, slow-moving.
In a CORBA architecture, objects communicate through ORBs, using IIOP as the protocol.
Object Adaptor: Maps object references to implementations, activates object if necessary. Portable
Object Adaptor (POA) now widely used.
Repositories: Interface and implementation repositories are used by ORBs.
IDL: Interfaces are defined in the OMG IDL and can be compiled to a concrete language interface, e.g.
Java, C, C++,COBOL, Ada, Smalltalk. IDL-to-Java Mapping defines details for Java.
Invocation: Static invocation uses pre-compiled stubs and skeletons for a specific language and
object. Dynamic invocation does not use stubs and skeletons, but discovers object and methods
dynamically using the Dynamic invocation interface (DII) at the client and dynamic skeleton interface
(DSI) at the server. There are similarities between DII and using COM’s IDispatch interface.
Corba Object Services (COS): Naming, Event (asynchronous messages), Object Transaction Service
(OTS), Concurrency control, Security


4.2    RMI-IIOP
Goal: Marry RMI and CORBA. Connect RMI clients to CORBA servers and vice versa.
Benefits: Greater re-usability, legacy integration, robust firewall navigation. In the future support for
transaction and security contexts can be added (new EJB/IIOP standard).

Specification
RMI-IIOP works with CORBA 2.3 ORBs. Required specs: Objects-by-value (IIOP does not traditionally
support pass-by-value) and Java-to-IDL.
Java-to-IDL mapping defines how RMI and IIOP work together and the necessary RMI restrictions that
are known as RMI/IDL. The mapping enables Java-to-IDL compilers to be written that take a Java
remote interface and produce a corresponding CORBA interface specification in IDL.
Connectivity                RMI Server                  RMI-IIOP Server             CORBA Server
RMI Client                  OK                          OK                          Not possible
RMI-IIOP Client             OK                          OK                          Restrictions apply
CORBA Client                Not possible                OK                          OK


EJB 1.1 mandates RMI-IIOP API to be present. However, there may still be two kinds of EJB servers:
CORBA based and proprietary. The latter do not use CORBA, but implement communication
differently (not using IIOP).

Development changes
Narrowing: Direct cast does not work on IIOP, PortableRemoteObject.narrow has to be used. In RMI
direct cast works because Stub class can be loaded dynamically over the net.
Two new packages for RMI-IIOP: javax.rmi (PortableRemoteObject) and javax.rmi.CORBA (internal)
(Normal RMI package is java.rmi).



e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                           Page 4 of 22
No distributed garbage collection: Manually unregistering is necessary via unexportObject method.
RMI-IIOP clients must use JNDI. RMI registries and COS Naming can be plugged into JNDI.
Tools: Generation of RMI-IIOP stubs and skeletons: “rmic - iiop". IDL-to-Java compiler: “idlj”. Java-to-
IDL-compiler: “rmi -idl”.
Note: Making object public through both JRMP and IIOP at the same time is possible.


4.3    Java IDL
Java IDL embeds Java into the CORBA world. It includes a new Java IDL API (org.omg.CORBA,
org.omg.CosNaming) and tools including an IDL-to-Java compiler (idltojava) and an ORB.
The ORB includes the Java-to-IDL and Objects-by-Value specs (both mandated by CORBA 2.3 and
necessary for RMI-IIOP connectivity). It does not define an interface repository, however, so no
dynamic lookup of parameters is possible.
Sun recommendation: Java IDL should be used when accessing existing CORBA servers is the main
purpose, whereas RMI-IIOP should be used when serving requests from CORBA clients is the main
purpose.

Development
Process: Write interface in IDL, compile to Java (results in interface and several classes). Use
interface in client programming. Descend server from generated ImplBase class (aka ‘implementation
skeleton’).
IDL-to-Java also generates ‘Stub’ class (client proxy), ‘Holder’ class (for out or inout parameters) and
‘Helper’ class (for narrowing and reading/writing).
ORB interface (org.omg.CORBA.ORB) and implementations (e.g. com.sun.CORBA.iiop.ORB). Getting
an ORB: static ORB.init.
NamingContext in package org.omb.CosNaming.
Object references: Temporary references (through proxy) and long-lived ‘stringified’ interoperable
object references (IOR).


4.4    JNI
Java Native Interface (JNI) is a standard for linking Java to native programs written in other languages
like C and C++.
A good way to integrate a legacy application that is not written in Java into a distributed system is to
wrap the application using JNI and make it accessible through RMI.




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                         Page 5 of 22
5 EJB components and containers
Enterprise Java Beans: A standard server-side component model for component transaction monitors.
1996 Microsoft introduced MTS, one of the first CTM. Middleware solutions suffered from vendor-
specific APIs. In 1997, EJB was created, refined 1999 in version 1.1.


5.1    EJB component structure

Remote interface
interface Thing extends javax.ejb.EJBObject (extends java.rmi.Remote)
Declares business methods. Every method must throw RemoteException (see RMI)

Home interface
interface ThingHome extends javax.ejb.EJBHome (extends java.rmi.Remote)
Create methods: One or more create methods with arbitrary signatures. Return remote interface.
Throw CreateException, RemoteException, plus custom exceptions.
Find methods [Entity beans only]: At least findByPrimaryKey(PkClass), possibly others. Starting with
‘findBy’. Return single bean remote interface or Enumeration/Collection of remote interfaces. Throw
FinderException, RemoteException, plus custom exceptions.
Remove: remove() is automatically inherited.

Bean class
class ThingBean implements javax.ejb.EntityBean/SessionBean (extend javax.ejb.EnterpriseBean,
which extends java.io.Serializable)
1. Fields: Transient, persistent (CMP/BMP) according to bean type, see below
2. Business methods:
Must have methods matching signatures of remote interface. However, RemoteException does not
have to be declared as thrown. Class should not implement the remote or home interface.
3. EJB methods:
ejbCreate: One version matching each create method in home interface. Return PkClass for entity
beans and void for session beans.
ejbPostCreate [Entity beans only]: One version matching each create method in home interface.
Return void. When this is called, the EJBObject exists in the EntityContext and the object is stored in
the persistence store.
ejbActivate/ejbPassivate: Acquire/release resources like database connections, sockets.
ejbLoad/ejbStore [Entity beans only]: Used for BMP, also for dealing with CMP and calculated fields.
ejbFind [Entity beans with BMP only]: One version for each signature in home interface, return primary
key class or Enumeration/Collection of primary keys.
ejbRemove: May remove aggregated beans, often empty.

Primary key class [Entity beans only]
class ThingPK implements java.io.Serializable
Fields must be public. Must define no-argument constructor. Must redefine equals and hashCode.
For CMP, fields must be a subset of the container managed fields and have same names and types.




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                       Page 6 of 22
Custom key classes as described above are called compound keys. Single-field keys can also be used
by defining a single (Wrapper class or String) field and referencing it in the <primkey-field> tag.
In EJB 1.1, definition of the primary key for an entity can be deferred until deployment.


5.2       Session Beans
Stateless: Bean is attached to client only during method execution, no memory.
Stateful: Bean handles specific client, state can be passivated. All fields not marked as transient have
to be serializable or primitive types.
For stateful session beans, the following references are guaranteed to be maintained by the container:
          Home/remote references of other beans
          JNDI contexts and SessionContext
          UserTransaction
EJB methods: setSessionContext: Called after ejbCreate, SessionContext is passed and can be
stored. Can also be used to set up JNDI contexts. Usually empty for stateless beans.

Lifecycle stateless
Two states: Not Existent, Ready
Constructor, setSessionContext, ejbCreate move from Not Existent to Ready. Business methods stay
in Ready.

Lifecycle stateful
Three states: Not Existent, Ready, Passivated.
Constructor, setSessionContext, ejbCreate move from Not Existent to Ready. Business methods stay
in Ready. ejbPassivate moves from Ready to Passivated.
Additional state for transactions: Ready in Transaction.
Business method with transaction moves from Ready to Ready in Transaction. Methods commit and
beforeCompletion, afterCompletion(true) move from Ready in Transaction to Ready. Same holds true
for rollback and afterCompletion(false).


5.3       Entity Beans
Are optional in EJB 1.0, mandatory in EJB 1.1.
Container Managed Persistence (CMP): Container persists object state at chosen points in time.
ejbLoad and ejbStore are still called, but can be empty. Fields to persist must be public and listed in
deployment descriptor. Finder methods are not implemented, but are defined by container tools. In EJB
1.1, CMP fields can include remote references to other beans.
Bean Managed Persistence (BMP): Bean is responsible for persisting state in ejbCreate, ejbLoad,
ejbStore, and ejbRemove methods. Synchronisation points with persistence store are still chosen by
the container. Finder methods must be implemented. An EJBException (RuntimeException!) should be
thrown when SQL or other system errors occur during persistence handling.
EJB methods: setEntityContext/unsetEntityContext:

Lifecycle
Three states: Not Existent, Pooled, Ready.
Constructor and setEntityContext move from Not Existent to Pooled. Finding stays in Pooled.
ejbCreate and ejbPostCreate move from Pooled to Ready. ejbStore and business methods stay in
Ready. ejbPassivation moves from Ready to Pooled.



e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                       Page 7 of 22
5.4       EJB restrictions
In EJB components and code called by them, the following restrictions apply to enable the EJB
container to handle scalability, load balancing, and other middleware services.
          No use of static fields or methods. Singleton pattern can still be implemented using JNDI
          No thread control
          No direct I/O access
          No use of customised socket factories


5.5       EJB API
Package javax.ejb
EJBHome: getEJBMetaData(), getHomeHandle() [EJB 1.1], remove(Handle), remove(Object primKey)
EJBObject: getEJBHome(), getHandle(), getPrimaryKey() [Entity], isIdentical(EJBObject), remove()
EJBContext: getEJBHome(), getCallerPrincipal(), isCallerInRole(String), getEnvironment()
[deprecated], getUserTransaction(), getRollbackOnly(), setRollbackOnly()
EntityContext: getEJBObject(), getPrimaryKey()
SessionContext: getEJBObject()
Exceptions: CreateException (extended by DuplicateKeyException), FinderException (extended by
ObjectNotFoundException), RemoveException, EJBException (RuntimeException, extended by
NoSuchEntityException)
In other packages: java.lang.IllegalStateException
Note that primary keys do not include the home interface whereas the handle does, so an EJB object is
identified by its home interface plus primary key or the handle, which provides a getEJBObject()
method for easy access.


5.6       Transactions
Transactions implement the ACID properties: They are atomic, consistent, isolated and durable.
Transactions can be managed by the bean (Session Beans only) or by the container.
Bean managed transactions make use of the Java Transaction API (JTA) to begin transactions and
perform commit or rollback (using the javax.transaction.UserTransaction class).
Container managed transactions allow the assignment of transaction types to specific methods:
NotSupported: The method is always executed outside the current transaction.
Supports: The transaction state is left as is
Required: When not in a transaction, a new one is started.
RequiresNew: A new transaction is always started.
Mandatory: Not being in a transaction results in an exception.
Never: Being in a transaction results in an exception.
Container managed transactions can be influenced through EJBContext.setRollbackOnly.
Transactions are automatically rolled back with system exceptions, but not with application exceptions.




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                        Page 8 of 22
5.7       Deployment descriptors
One or more Enterprise Java Beans are deployed in .jar files. These contain the necessary Java class
files, possible other files and a deployment descriptor called ‘META-INF/ejb-jar.xml’. The deployment
descriptor is in XML format since EJB 1.1.
Root tag: <ejb-jar>, main sub-tags: <enterprise-beans> and <assembly-descriptor>
Optional sub-tags: <description>, <display-name>, <small-icon>, <large-icon> (same for beans)

<enterprise-beans>
<entity> or <session> wrapping each bean definition, containing:
          <ejb-name>: Unique identifier, also default for JNDI lookup
          <home>, <remote>, <ejb-class>: Fully qualified class names
          <env-entry><env-entry-name></…><env-entry-type></…><env-entry-value></…></…
          <ejb-ref><ejb-ref-name>Other</…><ejb-ref-type>Entity/Session</…>
           <home>OtherHome</…><remote>Other</…></…>
          <resource-ref><res-ref-name>subdir/Sample</…><res- type>Class</…>
           <res-auth>Container/Application</…></…>, <description> possible
          <security-role-ref><role-name>(Matching isCallerInRole call></…>
           <role-link>(Matching assembly descriptor role, optional)</…></…>, <description> possible
<session only>
          <transaction-type>Bean/Container</…>
          <session-type>Stateful/Stateless</…>
<entity> only:
          <reentrant>: Sould always be false
          <persistence-type> (Bean/Container), <prim-key-class>, <primkey-field>
          For CMP: <cmp-field><field-name>Name</…></… >
Note that Entity Beans transactions are always container-managed.

<assembly-descriptor>
<security-role>: <description>, <role-name>
<method-permission>: <role-name>, <method>*
<container-transaction>: <method>*, <trans-attribute> (NotSupported, Supports, Required,
RequiresNew, Mandatory, Never)
*<method><ejb-name>Name</…><method-name>Name or * </…></…>, optionally also
<method-param> to distinguish signatures and <method-intf> to distinguish Home/Remote.


5.8       JNDI
Java Directory and Naming Interface (JNDI) is a standard interface to naming and directory services
such as LDAP, X.500, COS Naming.
Package javax.naming.
Usage: Obtaining an InitialContext, passing properties if required, calling lookup with path or name.

Narrowing
For RMI-IIOP and thus EJB 1.1, narrowing is required:



e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                      Page 9 of 22
ThingHome thingHome = (ThingHome) PortableRemoteObject.narrow(remoteRef, ThingHome.class);

Enterprise Naming Context (ENC)
The JNDI context java:comp/env is used as the standard initial context for bean home and remote
references. For access from inside other EJB’s, the subcontext ejb should be used and appropriate
references be defined in the deployment descriptor.


5.9    Design strategies
Bulk accessors for entity bean properties to reduce network round-trips.
Dependent objects should be immutable, e.g. Address object passed back from Customer bean. Also
called value objects.
Only fine-grained objects should be dependent value objects, other objects with more state and
behaviour should be beans on their own.
Session beans as façade for entity beans to reduce network round-trips.
Avoid chaining stateful session beans because of timeout problems.
Data Access Objects can hide complexities of DB access and make schema or DB changes easier.




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                  Page 10 of 22
6 Protocols
The Transport control protocol and Internet protocol (TCP/IP) form the Internet’s transmission basis.
IP: Lower level, packet-based, connectionless, no guaranteed delivery.
TCP: Higher level, connection-oriented, error-correction.
Other application-level protocols are based on TCP/IP, e.g. FTP, HTTP.


6.1    SSL
SSL runs above TCP/IP and below application-level protocols. It supports client and server
authentication, and privacy through encryption.
Handshake process: Authenticate server to client, select cipher supported by both client and server,
optionally authenticate client to server, use public-key encryption to exchange keys, establish
encrypted SSL session.


6.2    Port overview

Standard port           Protocol/Service     Comment
21                      FTP                  File transfer protocol
23                      telnet               Remote login
25                      SMTP                 Simple mail transfer protocol
80                      HTTP                 WWW transmission protocol
110                     POP3                 Post office protocol
161                     SNMP                 Simple network management protocol
443                     SSL                  Secure sockets layer
389                     LDAP                 Lightweight directory access protocol
636                     LDAPS                LDAP over SSL
-                       IIOP                 Internet Inter-Orb Protocol
1099                    JRMP                 Java remote method protocol




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                     Page 11 of 22
7 Design Patterns
Design patterns formalise solutions to particular problems that are often faced in OO design.
Patterns are described by:
          The problem they solve
          A diagram and description of the proposed solution
          A discussion of benefits and possible issues with the application of the pattern


7.1       Creational patterns

Factory Method
Create objects not directly, but using a method of some base class. Hides information about what
particular object is constructed and how. Subclasses of the base class can instantiate the correct
class. Defers instantiation to subclasses.
Example: Abstract Application object provides createDocument method, so that MyApplication can use
its own MyDocument class.

Abstract Factory
Group together a number of factory methods. Provide an interface for the generation of a whole group
of related objects, so that different factories can create objects for different frameworks or platforms.
Example: Abstract GraphicsFactory, concrete OpenGLFactory and Direct3Dfactory classes

Singleton
Ensure there is exactly one instance of a class and provide convenient access to it.

Builder
A class dedicated to creating some object type. Hides specifics of the object creation. Can offer
mutiple methods to create objects step-by-step.
Particularly useful if a number of otherwise different classes have similar construction patterns.
Builders can be used to build Composites.
Example: Building objects from file representations in certain formats

Prototype
Provides a clone method on objects, so that new, similar objects can be cloned instead of newly
created. Thus, a pool of ready-made objects could be used without knowing about their details.
Useful if creation is costly and objects that are needed differ only slightly.


7.2       Structural patterns

Adapter
Wrapper around other class that adjusts interface to suit needs. Contains other object and delegates
requests to it.

Proxy
Controls access to a class, hides location and persistence. Can defer instantiation.
Example: RMI Stub



e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                       Page 12 of 22
Façade
Provides a simplified interface to a complex set of inter-related classes. Reduces coupling.
Example: Session bean provides access to several entity beans.

Bridge
Separates abstract and concrete inheritance trees.
Fairly large-scale pattern; if it is used, then often in conjunction with Abstract Factory.
Example: Java AWT peer classes

Flyweight
Share objects with a lot of intrinsic (immutable) data. Pass all extrinsic data needed to methods.
Example: Character class in text processing

Composite
Derive a group class that composes base class instances from the bass class itself. Complete object
hierarchies can then be built.
Example: AWT Components

Decorator
Derive from base class and contain instance of base class. Can add new functionality to any class
instance derived from base.
Same class diagram as Proxy
Example: Java IO, BufferedReader


7.3     Behavioural patterns

Memento
Provide an interface to externalize an object’s state so that it can be re-set to that state later.
Example: Usage in undo operation

Visitor
Provide a hook in a base class that accepts an abstract operation to be performed on an element.
Particularly useful for Composite hierarchies or other structures which should be flexibly usable.
Example: Perform printing, type checking, and metrics gathering on Abstract Syntax Tree

Iterator
Accesses a container while hiding the specific container used.
Example: C++ Standard Template Library (STL), java.util.Enumeration

State
Define a separate class to represent an object’s state. Useful if actions are very state-dependent and
the number of states is likely to change. State-dependent methods are delegated to the State class.
Example: TCP Connection class with states ‘closed’, ‘established’, and ‘listen’

Command
Separates an action (or request) from its invocation (or trigger).




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                          Page 13 of 22
Example: Menu systems

Chain of Responsibility
Method for event handling in hierarchical systems. Events get passed on from most specifically
affected class to container classes and eventually the root default handler.
Example: Displaying GUI help

Mediator
Controls communication between systems of classes. Avoids complex coupling across systems.
Example: Systems management mediator controlling several processes

Observer
Defines a standard interface for notification of object changes, decoupling the observable from the
observers. One-to-many relationship from observable to observers.
Example: Multiple views on one set of data

Strategy
Encapsulates an algorithm used to perform a task, enabling dynamically switching the algorithm.
Example: Pluggable caching strategy

Interpreter
Define a language and a corresponding grammar to define instances of a domain. An abstract
expression class can be derived from the grammar. Parsers create syntax trees for processing.
Example: Regular expressions for searching

Template Method
Parameterises certain aspects of a class, making it easy to create new classes with certain properties.
Defining parameters or behaviour is done by sub-classing and overriding methods.
Methods can be abstract hooks that have to be defined in sub-classes or template methods that use
the hooks to define some common behaviour. Concrete, independent operations are also possible.
Example: InputStream defines read(buf) and read(buf,off, len) in terms of the template method read().




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                    Page 14 of 22
8 Messaging
Message-Oriented-Middleware (MOM) provides a common reliable way for programs to create, send,
receive and read messages in any distributed Enterprise System.
MOM ensures fast, reliable asynchronous electronic communication, guaranteed message delivery,
receipt notification and transaction control.
The Java Message Service (JMS) provides a standard Java-based interface to MOM.


8.1       Models

Point-To-Point Messaging: Multiple senders, single receiver
Publish-Subscribe Messaging: Multiple senders, multiple receivers
Request-Reply Messaging: This is the normal synchronous model and can be implemented by using
two related asynchronous messages.


8.2       JMS API
The JMS API defines separate interfaces for point-to-point (Queue) and publish-subscribe (Topic), so
that service providers can choose to support just one model.
Supports distributed transactions.
Package: javax.jms

Class overview
Base class:       Destination    Connection    Connection     Session        Message        Message
                                 Factory                                     Producer       Consumer
Point-to-point:   Queue          Queue         Queue          Queue          Queue          Queue
                                 Connection    Connection     Session        Sender         Receiver
                                 Factory                                                    / -Browser
Publish-          Topic          Topic         Topic          Topic          Topic          Topic
subscribe:                       Connection    Connection     Session        Publisher      Subscriber
                                 Factory


MessageListener interface for MessageConsumer: void onMessage(Message msg).
There are also various message classes depending on content type, e.g. TextMessage,
BytesMessage, MapMessage.
QueueBrowser can be used to look at a queue without consuming any messages.
The call createSubscriber creates a subscriber that only sees messages while connected, whereas
with createDurableSubscriber messages are queued for the subscriber.

Development
Lookup concrete ConnectionFactory through JNDI. Lookup topic/queue trough JNDI. Get connection
from factory. Call start on connection. Create session from connection (passing flags for
acknowledgement, transaction mode).
          Sender: Create sender from session (passing queue). Create message from session. Send
           message using sender instance, passing delivery mode and message instance.
          Receiver: Create receiver from session (passing queue). In endless loop: Call receive on
           Receiver, returning message, handle message.



e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                     Page 15 of 22
       Publisher: Create publisher from session (passing topic). Create message from session.
        Publish message using publisher instance.
       Subscriber: Create subscriber from session (passing topic). Call setMessageListener on
        subscriber.
At the end: Close session. Close connection.




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                 Page 16 of 22
9 Internationalisation
To be usable across national and regional boundaries, applications have to adapt to local customs.
Cultural-dependent aspects of an application that need to be adapted include:
          Data Input
          Data Storage
          Data Formatting
          Localizing content
These aspects affect the following objects:
          Text: Messages, Labels, Errors, other content
          Numbers: Plain numbers, currency values, percentage values
          Dates and Time
          Images, Sounds and other data
Internationalisation is sometimes abbreviated as I18N because there are 18 chars between I and N.


9.1       Locale class (java.util)
Locale class captures properties of a local environment: language and region.
          Language is specified by ISO 639 two-letter code in lowercase, e.g. fr, en
          Region is specified by ISO 3166 two-letter code in uppercase, e.g. CA, US
Getting locales: 1. Locale.getDefault() 2. new Locale(lang, region) 3. Locale.UK (this is a constant).
Each JVM has a default locale which can be changed by specifying the system properties
‘user.language’ and ‘user.region’.
Check available locales: Locale.getAvailableLocales() or DateFormat.getAvailableLocales()


9.2       ResourceBundle class (java.util)
A ResourceBundle is a container for key-value pairs that are locale-dependent.
Can be specified in a .properties file or in a class (best derived from ListResourceBundle).
Retrieval: ResourceBundle.getBundle(name[, locale]). Looks for most specific first, then drops region,
language, tries default locale instead of desired, then overall default. Prefers classes over .properties.
Access: getString(name), getStringArray(name), getObject(name)


9.3       Formatters (java.text)
Base class Format, Usage: ‘format(something)’ for output and ‘parse(String)’ for input

NumberFormat
Creation: getNumberInstance, getPercentageInstance, getCurrencyInstance (pass Locale optionally)

DateFormat
Creation: getDateInstance, getTimeInstance(), getDateTimeInstance (pass Locale optionally)
SHORT, MEDIUM, LONG, FULL formats




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                       Page 17 of 22
Composition: Uses a NumberFormat for time formatting.
Subclass: SimpleDateFormat allows specifying date/time formats in details using pattern strings.

MessageFormat
Creation: new MessageFormat(pattern), also static usage via format(pattern, arguments)
Replaces parameters in message strings, e.g. “{0} not found at {1, time}” becomes “SomeFile.java not
found at 11:30 PM”, but with a different pattern becomes “11 Oct 99, 11:30:00: SomeFile.java missing”


9.4    Additional notes
Properties are just an extension of Hashtable for representing key-value pairs; they don’t support
internationalisation explicitly.

Unicode
The primitive Java character type and the Java String class are based on Unicode. Unicode is a two-
byte character set that includes all relevant symbols of languages currently in use throughout the world.
Unicode comes with a variety of encodings
To actually display certain characters, relevant fonts have to be installed.
The Collator class (java.text) should be used for sorting international strings.

Java IO
Input and output streams operate on bytes, whereas readers and writers operate on characters.
Characters are based on Unicode and support internationalisation.
Where byte and character streams meet, a character encoding is needed. The classes
OutputStreamWriter and InputStreamReader use encodings to read and write characters to and from
byte streams. JVM’s may differ in what encodings are supported.
There is always a default encoding for any JVM. Examples of encodings are UTF-8 and ISO-LATIN-1,
as defined by the IANA Charset Registry.




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                     Page 18 of 22
10 Security
Cryptography, Digital signatures and Certificates can be used to increase the security of a system.
Java offers a number of interfaces for related services. Firewalls are also important for protecting the
gateway between trusted and untrusted networks.


10.1 Cryptography

Communication security threats
Eavesdropping: Information is kept intact, but privacy is compromised.
Tampering: Information in transit is changed or replaced and then sent on.
Impersonation: Information passes to the wrong person, who poses as the intended recipient. Persons
or systems can pretend to be somebody else (Spoofing) or something else (Misrepresentation).

Goals of cryptography
Privacy: Communication between two parties is unintelligible to an intruder.
Tamper detection: Verify that information has not been changed in transit.
Authentication: Confirm that the sender of the information is who he claims to be.
Non-repudiation: Prevents senders from claiming at a later date the information was never sent.

Symmetric Key Cryptography
One key is used for encryption and decryption.
Problem is key exchange between remote parties. Advantage is efficient implementation.

Public-Key Cryptography
Also called “ asymmetric cryptography”. Pair of two associated keys: The private key is kept secret; the
public key is published openly.
Encryption with public key ensures privacy.


10.2 Digital signatures

Message digest or one-way hash function: Number of fixed bit length that changes with every subtle
change in the message and cannot be reversed.
Digital signature: Encryption of the message digest with the public key.
Method: Send digital signature along with message. Receiver calculates message digest of the
received message and compares with the decrypted message digest.


10.3 Certificates
Problem: Verify validity of a person’s public key.
Certificate: Electronic document that identifies an individual, a server, a company, or some other entity
and associates the entity with a public key.
Certification authority (CA): Validates identity and issues certificates.
Certificates contain identity name, expiration date, CA name and digital signature, and other
information like a serial number.




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                        Page 19 of 22
Authentication: Process of confirming an identity. In general, can be based on assets (ID cards,
private key file), knowledge (ID and password), or individual properties (biometrics).
Network authentication can be password-based or certificate-based. Advantage of certificates:
Password does not need to be sent across the network. Single-sign on is easier.
X.509 v3: ITU Standard for certificate content. X.509 v3 binds a distinguished name (DN) to a public
key. DN is a series of name-value pairs, e.g. uid=doe,e=doe@abc.com,cn=John Doe,o=ABC,c=US,
like in LDAP.
X.509 Data Section: 1) Version no of X.509 standard 2) Serial number (unique to CA) 3) Information 4)
Public Key Info: Algorithm and Data 5) Validity Period 6) Subject’s DN 7) Optional extensions
X.509 Signature Section: 1) Algorithm or cipher used by the CA 2) Digital signature of certificate by CA
Certificate chains: Hierarchy of CA’s, parents certifying children. Allows verifying certificates by just
having the trusted public key of the root CA.
Public Key Infrastructure (PKI): Set of standards and services that facilitate the use of public-key
cryptography and X.509 v3 certificates.
Key recovery or key escrow: Ability to retrieve backups of private keys under certain, carefully defined
conditions. Example is the m-of-n principle, m of n trusted individuals have to agree.
Public Key Cryptography Standards (PKCS): Set of standards driven by RSA Labs with broad
industry support. Includes RSA public-key and Diffie-Hellman algorithms.


10.4 Java Security Model
Security architecture has changed from JDK 1.1 to 1.2. In JDK 1.1, the ‘sandbox model’ distinguished
between remote code (applets) that was run with security restrictions in the sandbox, whereas local
code was totally trusted. With Java 2, all application code is subject to security control.
The Java language supports writing safe code: Strong type checking, automatic memory management,
range checking, JRE bytecode verifier.
The Java 2 platform explicitly supports access control to various important resources like files and
sockets through permissions and the SecurityManager.
Protection domain: Conceptual set of resources that are currently available to a principal.
Permissions are resolved by checking the protection domain assigned to a class.
Two main protection domains: Application and system.

Classes
Permission: Abstract base class for all permissions, e.g. java.io.FilePermission.
PermissionCollection: List of permissions of same type. Permissions: List of PCs.
Types of permissions: (Basic), File, Socket, Property, Property, Runtime, AWT, Net, Security, All
Defining new permissions: Descend from Permission, implement implies method.
CodeSource: Defines URL of a remote codebase along with associated certificates.
Policy: The current security policy. Policy.getPolicy(), getPermissions(CodeSource)
ProtectionDomain: Uniquely identified by a CodeSource. A class belongs to exactly one PD.
AccessController: Has checkPermission method (also called by SecurityManager)
AccessControlContext: Defines state of access control, used to pass access info between threads.
Principal: Interface for entities like persons, companies, used in X.509 certificates




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                         Page 20 of 22
10.4.1 Tools

keytool
Create public/private key pairs, issue cert requests (for sending to CA), manage key store.

jarsigner
Signing and verifying JAR files. “jarsigner [options] jar-file alias”

policytool


10.4.2 Files
Can be found in {JDK Home}/lib/security
Java.security – Security Properties File
Java.policy – System Policy File
Cacerts – Certificates Keystore File


10.5 Java Cryptography Architecture (JCA)
Package java.security.
Engine classes: MessageDigest, Signature, KeyPairGenerator, KeyStore, SecureRandom etc.
Interface are implemented by providers.
Default provider SUN is shipped with Sun’s JDK 1.2, includes DSA, MD5, SHA-1, X.509 certs, JKS.


10.6 Additional Java Security Services

Java Authentication and Authorization Service (JAAS) 1.0
Supports access control based on who runs the code. J2SE only supports access control based on
where code is coming from and who signed it.
Implements Pluggable Authentication Module (PAM).
Principal: Named entity or account. (Roles and Groups are Principals as well.)
Subject: Person or Service using a system. Represented by a set of Principals.
Credential: Additional security info about a subject, e.g. certificate, password. Public/Private
Two-phase login like two-phase commit.
Authorisation: Policy files like Java 2 policies, with new principal key word.

Java Cryptography Extension (JCE) 1.2.1
Extensions to the Java Cryptography Architecture (JCA), that is part of J2SE.

Java Secure Sockets Extension (JSSE) 1.0.2
Provides SSL (Secure Sockets Layer) 3.0 and TLS (Transport Layer Security) 1.0.
SSLSocket and SSLServerSocket classes
HTTPS support
Package javax.net.ssl




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                           Page 21 of 22
10.7 Firewalls
A firewall is a system that enforces an access control policy between two networks.
Purpose of firewalls: Control incoming and outgoing travel, address translation, monitoring.
Screening types: Check whether data have been requested, check sender, check content.
Network Address Translation (NAT): Make it seem like all outgoing traffic originates from the firewall.
Attack types: Information theft, Information sabotage, Denial of service.
Firewalls are certified by the ICSA (International Computer Security Agency).

ICSA firewall categories
Packet filter firewalls: Based on information in single IP packets; port, source/dest IP address
Application-level proxy servers: Inspection of data for specific services, e.g. HTTP, FTP, SMTP
Stateful packet inspection firewalls: Stores requests and checks incoming data against them.

Additional support might be provided for:
De-militarised zones (DMZ): Zone for protected, controlled public access, separate from intranet.
Virtual Private Networks (VPN). VPN’s are more cost-effective than leased lines or dial-in.
Virus detection
Load Balancing

Firewall implementation types
Router/Firmware-based firewalls: Built into router. Usually limited capabilities available.
Software-based firewalls: Sophisticated applications on a workstation. Difficult to maintain.
Dedicated firewall appliances: Best solution. High throughput, less maintenance, more security.




e5995cb0-bf77-45b1-b67b-03fce678df5a.doc                                                        Page 22 of 22

				
DOCUMENT INFO
Categories:
Tags:
Stats:
views:5
posted:5/27/2012
language:
pages:22