EJB Notes 28/03/2002
6
Miscellaneous
A transaction represents a unit-of-work (one or more tasks that must all complete) and embodies the concept of an
exchange between two parties. In EJB each task is represented as a method so the unit-of-work is represented as one or
more method calls on one or more beans.
A transactional system must enforce the ACID properties :
Property Description
Atomic All or nothing – if any task fails the transaction if rolled back; if all complete the transaction is
committed (i.e. made Durable).
Consistent The state of the system must reflect the real world. This is enforced in two parts :
1. the transactional system ensures that data is Atomic, Isolated and Durable
2. the application developer ensures the system has appropriate constraints – e.g. no primary key
violation, referential integrity, etc.
Isolated The transactional system ensures that data involved in a current transaction cannot be affected by other
transactions until the current transaction completes.
The degree of isolation is controlled by setting the “isolation level”.
Durable The transactional system must ensure that the data is persistent before the transaction can be considered
to be complete – i.e. until committed, the data is still isolated.
Additionally, the transactional system ensures that the data survives system failures through 2PC (twophase
commit) and transaction logging.
A transactional system has to be able to deal with concurrency issues :
Issue Description
Dirty read TX2 reads uncommitted changes made by another TX1; if TX1 rolls back, TX2 has dirty data.
E.g. TX1 attempts to book the last seat but fails on payment; TX2 didn’t see the seat so thinks it’s
sold out.
Nonrepeatable
read
“Lost update”
TX1 reads; TX2 reads and updates; TX1 updates and blats over TX2’s update
Phantom read TX1 gets a list of seats; TX2 adds a seat; TX1 is unaware of the update
Concurrency issues can be controlled using one of 4 transaction isolation levels :
Read Type
Isolation Level Dirty Non-Repeatable Phantom
TRANSACTION_READ_UNCOMMITTED Y Y Y
TRANSACTION_READ_COMMITTED N Y Y
TRANSACTION_REPEATABLE_READ N N Y
TRANSACTION_SERIALIZABLE N N N
These isolation levels have to be viewed from the perspective of each client :
Isolation Level Description
READ_UNCOMMITTED Reader & Writer
No locks/waiting; anything goes.
Reader picks up all column changes (synched at row level)
READ_COMMITTED Reader - only wants “real” data (i.e. that made durable). Wait until available.
Writer
Wait until others have finished reading before making changes.
If writer gets there first, readers wait until writer has finished.
REPEATABLE_READ Reader - Blocks writer until finished reading or waits until writer is finished
Writer
No updates or deletions to existing rows; insert of rows allowed. Don’t allow any
updates / deletions to stuff writer is working on – writer could overwrite updates.
SERIALIZABLE Reader - Blocks writer until finished reading or waits until writer is finished
Writer
No updates, deletions or insertions except by the writer
EJB Notes 28/03/2002
7
Given a requirements specification detailing security and flexibility needs, identify architectures that
would fulfill those requirements
Architectures.
Refer to the “Common Architecture” and “Security” documents.
In summary :
• a modular architecture is the most flexible but requires more effort to manage
• security is required at all levels and a modular architecture supports this
• Java has good security support – JVM, security APIs, etc
• typical elements that support security and flexibility are : firewalls, load balancers, clustered
application servers, etc
• EJB security is flexible – declarative so can be adjusted as required; can be mapped to environment
specifics (LDAP, mainframe, etc.)
J2EE Security.
Within an EJB component security roles are defined - a role is a logical user (e.g. admin, customer). When
the component is deployed, the role is mapped to “real” J2EE users/groups (e.g. PJC is able to assume the
admin role).
To access secure resources, the Subject (client) must be authenticated and authorized :
• Authentication.
To authenticate, the Subject must present their Credentials (e.g. username/password) to the
container.
If the authentication is successful, the Subject is associated with one or more Principal objects.
N.B. authentication is not currently part of the EJB specification – e.g. the credentials may be
passed as properties to an InitialContext, JAAS may be used, etc.
• Authorisation.
Once authenticated, the Principal(s) can be checked against the Role to decide if the client is
authorised to access the secure resource.
Role based authorisation is fully supported by J2EE – security constraints in web.xml, method level
security in EJB deployment descriptor, “runAs” in deployment descriptor.
N.B. instance based authorisation (e.g. PJC is only allowed access to PJC’s account) isn’t yet
specified
J2EE also has other built-in security features :
• web-tier authentication – via HTTP authentication, FORM/j_security_check, client certificates
• secure communications – SSL; web-tier authentication can use SSL for HTTP/FORM auth
• security packages – digests, digital signatures, ciphers, certificates, etc.
EJB security
EJB supports declarative security (programmatic security is also supported) by setting the appropriate values
in the deployment descriptor :
admin
Account
*
Not very portable at the moment – authentication and “runAs” are container specific; container to container
security propagation is undefined.
EJB Notes 28/03/2002
8
Identify costs and benefits of using an intermediate data access object between an entity bean and the
data resource
Pros.
• transparency – specifics of data access are hidden from the entity bean
• modular – the DAO could be swapped for another with little disruption to the entity bean code
• cleaner code - data access factored out so simplifies entity bean code
• reusable – DAO could be re-used in a “Fast Lane Reader”
Cons.
• only suitable for BMP
• extra code - have to write DAO class, DAO wrapper calls in entity bean, maybe some DAO factories
Miscellaneous.
General restrictions.
• threads – no synchronized modifiers or blocks; no thread management
• networking - no socket servers or multicast; can’t change socket factory
• security - no reflection; no access to ClassLoader/SecurityManager; exit JVM; native libs
• no AWT
• no read/write static fields – static final fields OK
Bean restrictions.
• bean class – class modifier must be public (abstract, final not allowed); no finalize ()
• business & callback methods
method modifier must be public (static, final not allowed); arguments must be legal RMI types
Exceptions
Application exceptions represent business logic failures so are expected to be returned to the remote client.
Some common application exceptions are provided in the javax.ejb package but can also be user-defined.
System exceptions represent system level failures and are excepted to be caught by the container.
The container handles the exception and re-packages it as RemoteException before returning it to the client.
The container will deal with all unchecked exceptions – e.g. NullPointerException
Bean methods can catch exceptions are re-throw within a method – e.g. catch JDBC error and re-throw as
EJBException.
In EJB1.0, methods could throw RemoteException to indicate a system/non-application error.
In EJB1.1, methods are now expected to throw EJBException (or another RuntimeException).
However, all of the sample code (including Petstore) still uses RemoteException.
The bean method implementations must match the interface definitions in terms of exceptions apart from :
• RemoteException - the container handles remote exception issues
• EJBException - extends RuntimeException so doesn’t have to be explicitly listed in the “throws”
clause.
Method Application Exceptions
Any Application/custom exceptions
create () CreateException, DuplicateKeyException
findXXX () FinderException, ObjectNotFoundException (single return finders only)
remove () RemoveException
business methods,
ejbLoad, ejbStore
NoSuchEntityException (object has been removed elsewhere, as of EJB1.1)
Primary Services.
There are 7 primary services provided by the container : concurrency (to maintain safe/consistent access to shared entity
bean), lifecycle management (pooling/swapping), persistence (CMP), distributed objects (EJB uses RMI-IIOP), naming
(JNDI can hookup to a number of naming services), transactions (CMT) and security (EJB builds on Java2 security to
add method level security).
6
Miscellaneous
A transaction represents a unit-of-work (one or more tasks that must all complete) and embodies the concept of an
exchange between two parties. In EJB each task is represented as a method so the unit-of-work is represented as one or
more method calls on one or more beans.
A transactional system must enforce the ACID properties :
Property Description
Atomic All or nothing – if any task fails the transaction if rolled back; if all complete the transaction is
committed (i.e. made Durable).
Consistent The state of the system must reflect the real world. This is enforced in two parts :
1. the transactional system ensures that data is Atomic, Isolated and Durable
2. the application developer ensures the system has appropriate constraints – e.g. no primary key
violation, referential integrity, etc.
Isolated The transactional system ensures that data involved in a current transaction cannot be affected by other
transactions until the current transaction completes.
The degree of isolation is controlled by setting the “isolation level”.
Durable The transactional system must ensure that the data is persistent before the transaction can be considered
to be complete – i.e. until committed, the data is still isolated.
Additionally, the transactional system ensures that the data survives system failures through 2PC (twophase
commit) and transaction logging.
A transactional system has to be able to deal with concurrency issues :
Issue Description
Dirty read TX2 reads uncommitted changes made by another TX1; if TX1 rolls back, TX2 has dirty data.
E.g. TX1 attempts to book the last seat but fails on payment; TX2 didn’t see the seat so thinks it’s
sold out.
Nonrepeatable
read
“Lost update”
TX1 reads; TX2 reads and updates; TX1 updates and blats over TX2’s update
Phantom read TX1 gets a list of seats; TX2 adds a seat; TX1 is unaware of the update
Concurrency issues can be controlled using one of 4 transaction isolation levels :
Read Type
Isolation Level Dirty Non-Repeatable Phantom
TRANSACTION_READ_UNCOMMITTED Y Y Y
TRANSACTION_READ_COMMITTED N Y Y
TRANSACTION_REPEATABLE_READ N N Y
TRANSACTION_SERIALIZABLE N N N
These isolation levels have to be viewed from the perspective of each client :
Isolation Level Description
READ_UNCOMMITTED Reader & Writer
No locks/waiting; anything goes.
Reader picks up all column changes (synched at row level)
READ_COMMITTED Reader - only wants “real” data (i.e. that made durable). Wait until available.
Writer
Wait until others have finished reading before making changes.
If writer gets there first, readers wait until writer has finished.
REPEATABLE_READ Reader - Blocks writer until finished reading or waits until writer is finished
Writer
No updates or deletions to existing rows; insert of rows allowed. Don’t allow any
updates / deletions to stuff writer is working on – writer could overwrite updates.
SERIALIZABLE Reader - Blocks writer until finished reading or waits until writer is finished
Writer
No updates, deletions or insertions except by the writer
EJB Notes 28/03/2002
7
Given a requirements specification detailing security and flexibility needs, identify architectures that
would fulfill those requirements
Architectures.
Refer to the “Common Architecture” and “Security” documents.
In summary :
• a modular architecture is the most flexible but requires more effort to manage
• security is required at all levels and a modular architecture supports this
• Java has good security support – JVM, security APIs, etc
• typical elements that support security and flexibility are : firewalls, load balancers, clustered
application servers, etc
• EJB security is flexible – declarative so can be adjusted as required; can be mapped to environment
specifics (LDAP, mainframe, etc.)
J2EE Security.
Within an EJB component security roles are defined - a role is a logical user (e.g. admin, customer). When
the component is deployed, the role is mapped to “real” J2EE users/groups (e.g. PJC is able to assume the
admin role).
To access secure resources, the Subject (client) must be authenticated and authorized :
• Authentication.
To authenticate, the Subject must present their Credentials (e.g. username/password) to the
container.
If the authentication is successful, the Subject is associated with one or more Principal objects.
N.B. authentication is not currently part of the EJB specification – e.g. the credentials may be
passed as properties to an InitialContext, JAAS may be used, etc.
• Authorisation.
Once authenticated, the Principal(s) can be checked against the Role to decide if the client is
authorised to access the secure resource.
Role based authorisation is fully supported by J2EE – security constraints in web.xml, method level
security in EJB deployment descriptor, “runAs” in deployment descriptor.
N.B. instance based authorisation (e.g. PJC is only allowed access to PJC’s account) isn’t yet
specified
J2EE also has other built-in security features :
• web-tier authentication – via HTTP authentication, FORM/j_security_check, client certificates
• secure communications – SSL; web-tier authentication can use SSL for HTTP/FORM auth
• security packages – digests, digital signatures, ciphers, certificates, etc.
EJB security
EJB supports declarative security (programmatic security is also supported) by setting the appropriate values
in the deployment descriptor :
admin
Account
*
Not very portable at the moment – authentication and “runAs” are container specific; container to container
security propagation is undefined.
EJB Notes 28/03/2002
8
Identify costs and benefits of using an intermediate data access object between an entity bean and the
data resource
Pros.
• transparency – specifics of data access are hidden from the entity bean
• modular – the DAO could be swapped for another with little disruption to the entity bean code
• cleaner code - data access factored out so simplifies entity bean code
• reusable – DAO could be re-used in a “Fast Lane Reader”
Cons.
• only suitable for BMP
• extra code - have to write DAO class, DAO wrapper calls in entity bean, maybe some DAO factories
Miscellaneous.
General restrictions.
• threads – no synchronized modifiers or blocks; no thread management
• networking - no socket servers or multicast; can’t change socket factory
• security - no reflection; no access to ClassLoader/SecurityManager; exit JVM; native libs
• no AWT
• no read/write static fields – static final fields OK
Bean restrictions.
• bean class – class modifier must be public (abstract, final not allowed); no finalize ()
• business & callback methods
method modifier must be public (static, final not allowed); arguments must be legal RMI types
Exceptions
Application exceptions represent business logic failures so are expected to be returned to the remote client.
Some common application exceptions are provided in the javax.ejb package but can also be user-defined.
System exceptions represent system level failures and are excepted to be caught by the container.
The container handles the exception and re-packages it as RemoteException before returning it to the client.
The container will deal with all unchecked exceptions – e.g. NullPointerException
Bean methods can catch exceptions are re-throw within a method – e.g. catch JDBC error and re-throw as
EJBException.
In EJB1.0, methods could throw RemoteException to indicate a system/non-application error.
In EJB1.1, methods are now expected to throw EJBException (or another RuntimeException).
However, all of the sample code (including Petstore) still uses RemoteException.
The bean method implementations must match the interface definitions in terms of exceptions apart from :
• RemoteException - the container handles remote exception issues
• EJBException - extends RuntimeException so doesn’t have to be explicitly listed in the “throws”
clause.
Method Application Exceptions
Any Application/custom exceptions
create () CreateException, DuplicateKeyException
findXXX () FinderException, ObjectNotFoundException (single return finders only)
remove () RemoveException
business methods,
ejbLoad, ejbStore
NoSuchEntityException (object has been removed elsewhere, as of EJB1.1)
Primary Services.
There are 7 primary services provided by the container : concurrency (to maintain safe/consistent access to shared entity
bean), lifecycle management (pooling/swapping), persistence (CMP), distributed objects (EJB uses RMI-IIOP), naming
(JNDI can hookup to a number of naming services), transactions (CMT) and security (EJB builds on Java2 security to
add method level security).
