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

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





Class diagrams
Object diagrams

Sequence diagrams
Collaboration diagrams
Activity diagrams
Statechart diagrams

Component diagrams

Deployment diagrams

Refer to Fowler for details. Note that implementing an interface is called ‘Realisation’ in UML.

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


Three- or Multi-tier


Very limited

Still limited, DB connections

Good. Resource pooling possible, hardware can be added if and when need arises.


Poor, tight coupling

Difficult, data access and business logic are mixed

Good, layers can be changed independently.


OK, Data consistency is simple because one storage




Poor, single point of failure

Poor, DB server is still single point of failure

Excellent with appropriate redundancy architecture.


Poor, tight coupling

Difficult, data access and business logic are mixed. Code is dependent on DB schema.

Good, layers can be changed independently.



Poor, DB Server can become bottleneck. Each client requires a connection, no pooling. High network bandwidth required, because all data has to travel to client.

Good. Because the system is scalable, performance can be influenced by choosing the right system components.

Bottlenecks can be removed at the relevant layer.


Relatively easy

Poor, complex client installation  and maintenance




Problematic, because client has too much control.

Good. Only certain services can be accessed, no direct database access.

Firewalls and authentication and authorization systems help to further control access.


No distribution

Green screen, dumb terminals

Two options: Combine Presentation with Business layer (Thick client), or some Business with DB layer (Thin client, use Stored Procs)

Improved, graphical user interface

Re-use difficult

More difficult to program because distribution, concurrency, transactions, security, resource management have to be understood and taken care of.

The EJB architecture helps to reduce this overhead.


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).

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).


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.


RMI Server


CORBA Server

RMI Client



Not possible




Restrictions apply

CORBA Client

Not possible




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).

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.


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.

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

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

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.

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:


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.

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.

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)


<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</…>

·         <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.


<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.


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

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.

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





File transfer protocol



Remote login



Simple mail transfer protocol



WWW transmission protocol



Post office protocol



Simple network management protocol



Secure sockets layer



Lightweight directory access protocol






Internet Inter-Orb Protocol



Java remote method protocol


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


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


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


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


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


Controls access to a class, hides location and persistence. Can defer instantiation.

Example: RMI Stub


Provides a simplified interface to a complex set of inter-related classes. Reduces coupling.

Example: Session bean provides access to several entity beans.


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


Share objects with a lot of intrinsic (immutable) data. Pass all extrinsic data needed to methods.

Example: Character class in text processing


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

Example: AWT Components


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


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


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


Accesses a container while hiding the specific container used.

Example: C++ Standard Template Library (STL), java.util.Enumeration


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’


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

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


Controls communication between systems of classes. Avoids complex coupling across systems.

Example: Systems management mediator controlling several processes


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


Encapsulates an algorithm used to perform a task, enabling dynamically switching the algorithm.

Example: Pluggable caching strategy


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().

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:













/ -Browser









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.


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.

·         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.



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


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


Creation: getDateInstance, getTimeInstance(), getDateTimeInstance (pass Locale optionally)


Composition: Uses a NumberFormat for time formatting.

Subclass: SimpleDateFormat allows specifying date/time formats in details using pattern strings.


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 “ not found at 11:30 PM”, but with a different pattern becomes “11 Oct 99, 11:30:00: missing”

9.4         Additional notes

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


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.

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.

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,,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.


Permission: Abstract base class for all permissions, e.g.

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

10.4.1    Tools


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


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


10.4.2    Files

Can be found in {JDK Home}/lib/security – Security Properties File

Java.policy – System Policy File

Cacerts – Certificates Keystore File

10.5    Java Cryptography Architecture (JCA)


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


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.