EJB
Component Characteristics
• An enterprise Bean typically contains
business logic that operates on the
enterprise’s data.
• An enterprise Bean’s instances are
created and managed at runtime by a
Container.
• An enterprise Bean can be customized
at deployment time by editing its
environment entries.
Components
• Various metadata, such as a transaction
and security attributes, are separate
from the enterprise Bean class. This
allows the metadata to be managed by
tools during application assembly or
deployment (or both).
• Client access is mediated by the
Container in which the enterprise Bean
is deployed.
Components
• An enterprise Bean can be included in an assembled
application without requiring source code changes or
recompilation of the enterprise Bean.
• A client view of an enterprise Bean is defined by the
Bean Provider. The client view can be manually
defined by the Bean developer, or generated
automatically by application development tools. The
client view is unaffected by the container and server
in which the Bean is deployed. This ensures that both
the Beans and their clients can be deployed in
multiple execution environments without changes or
recompilation.
EJB use
• Tier 1: Client
• Tier 2: EJB server
– EJB container (provides transaction
management, security, remote connectivity,
concurrency, life cycle management)
• Enterprise beans
• Tier 3: Databases, legacy code
Session beans
• Model business processes such as checking,
canceling, shipping orders.
• Run by code on a remote client: locates
bean through JNDI (Java Naming and
Directory Interface)
• EJB container creates copy of session bean
on client
Session Beans
• Four pieces of code you need to write
–
–
–
–
remote interface: methods client can use
home interface: used to create remote copy
session bean: does most of the work
client code that calls the bean
Remote Interface
public interface Hello
extends EJBObject {
String sayHello()
throws RemoteException;
Client will call only one method
Follow RMI rules: must throw
RemoteException, return types primitive or
...
Home Interface
public interface HelloHome
extends EJBHome {
Hello create(String str)
throws RemoteException, …;
}
Session Bean Implementation
public class HelloEJB
implements SessionBean {
String str;
public ejbCreate(String
str) {this.str = str; }
public String sayHello()
throws RemoteException
{return str;}…}
Session bean
• Also: ejbRemove(), ejbActivate(),
ejbPassivate()
• ejbCreate corresponds to create method in
home interface
Client: main method
Context ic = new
InitialContext();
Object obj =
ic.lookup(“helloapp/Hello”);
HelloHome hhome = (HelloHome)
PortableRemoteObject.narrow
(obj, HelloHome.class);
Client: main method
Hello hobj =
hhome.create(“Hello World”);
String hstr = hobj.sayHello();
System.out.println(hstr);
Entity Beans
• Persistent: can be container managed
• using deployment descriptor
• container also provides transaction
management
– Remote interface
– Home interface
– Entity bean class
Example
• Tier 1: WebBrowser: Applet
• Tier 2:
– WebServer: Servlet
– EJB Server
• EJB Container
– Product Entity Bean
– Order Entity Bean
– Customer Entity Bean
• Tier 3: Data Base Server
Entity Bean Class
•
•
•
•
•
•
business methods
create methods
remove methods
finder methods
load and store methods
activation, passivation methods
EJB
• Session beans
– represents a client in the server. Client calls
methods (e.g., enterOrder). Is transient:
terminates when client terminates.
• Entity beans
– represents a business object (persistent).
– Persistence can be beans or container managed
Enterprise Java Beans (EJB) and
Aspectual components
• EJB: a hot Java component technology from
SUN/IBM
• Aspectual components: a conceptual tool
for the design of enterprise Java beans (and
other components)
Enterprise JavaBeans (EJB)
• Addresses aspectual decomposition.
• An enterprise Bean provider usually does
not program transactions, concurrency,
security, distribution and other services into
the enterprise Beans.
• An enterprise Bean provider relies on an
EJB container provider for these services.
EJB
• Beans
• Containers: to manage and adapt the beans.
Intercept messages sent to beans and can
execute additional code. Similar to
reimplementation of expected interface in
aspectual component.
Aspectual components for EJB
design/implementation
• Use ACs to model transactions,
concurrency, security, distribution and other
system level issues. Translate ACs to
deployment descriptors (manually, or by
tool).
• Use ACs to model beans in reusable form.
Generate (manually or by tool) Java classes
from ACs and connectors.
Example: Use AC for EJB
persistence
As an example we consider how persistence is
handled by EJB containers. The deployment
descriptor of a bean contains an instance variable
ContainerManagedFields defining the instance
variables that need to be read or written. This will
be used to generate the database access code
automatically and protects the bean from database
specific code.
Aspectual component:
Persistence
component Persistence { PerMem p;
participant Source {
expect Target[] targets;
expect void writeOp();}
// for all targets:writeOp
participant Target
expect void writeOp();
replace void writeOp() {
// write to persistent memory p
expected();}}
Deployment
connector PersistenceConn1 {
ClassGraph g = ; // from Company to *
Company is Persistence.Source;
Nodes(g) is Persistence.Target;
with {writeOp = write*};
// must be the same writeOp for both
// Source and Target
}
Generate deployment descriptor
• Connector contains information about
ContainerManagedFields
• Connector localizes information; it is not
spread through several classes
Discussion of session bean and
entity bean distinction
• interesting modeling is done in session
beans; initially only session beans
• entity beans: dumb objects?
Enterprise beans components are intended to be
relatively coarse-grained business objects (e.g.
purchase order, employee record). Fine-grained
objects (e.g. line item on a purchase order,
employee’s address) should not be modeled as
enterprise bean components.
Ejb and aop
• deployment descriptors :=: APPC
• session beans :=: “session” APPC
– session beans are extensions of clients
• entity beans :=: “base” participants
– key participants
• regular classes :=: define through APPC
Terminology
• Building block = BB
• Participants (classes at basic level) = BB of
type 1
• APPC = BB of type 2 = consisting of set of
generic BB of type 1.
• Connectors = map generic BB
AOP
• components = building blocks type 1
• whatever does not fit into one building
block of type 1 is expressed as one building
block type 2 that consists of a set of generic
building blocks of type 1.
• generic building blocks of a building block
of type 2 are mapped to building blocks of
type 1.
Generic BB
• A building block with holes
AOP
• Properties of mapping
– one generic building block is mapped to one or
more building blocks
– building blocks may have parts. One part of
generic building block is mapped to one or
more parts of corresponding generic building
block.
Exceptions in EJB
• An application exception is an exception
defined in the throws clause of a
method of the enterprise Bean’s home
and remote interface, other than the
java.rmi.RemoteException.
• An enterprise bean business method
may encounter various system
exceptions or errors that prevent the
method from successful completion.
Examples
• Application exception: account has
insufficient balance
• System exception: failure to obtain a
database connection, JNDI exceptions,
unexpected RemoteException from
invocation of other enterprise beans,
unexpected RuntimeException, JVM
errors, etc.
Use of application level
exceptions
• Application exceptions are intended to
be handled by the client, and not by the
system administrator. They should be
used only for reporting business logic
exceptions, not for reporting system
level problems.
Application exception
• Because an application exception does
not automatically result in marking the
transaction for rollback, the Bean
Provider must do one of the following to
ensure data integrity before throwing an
application exception from an enterprise
bean instance:
– no loss of data integrity
– mark for rollback before throwing
application exception, prevents commit
System exception guidelines
• If the bean method encounters a
RuntimeException or error, it should
simply propagate the error from the
bean method to the Container (i.e. the
bean method does not have to catchthe
exception).
• Any other unexpected error conditions
should be reported using the
javax.ejb.EJBException.
What the container does
• catches a non-application exception,
• logs it (which can result in alerting the
System Administrator), and
• throws the java.rmi.RemoteException (or
subclass thereof) to the client.
What container does
• The Bean Provider can rely on the
Container to perform to following tasks
when catching a non-application
exception:
– The transaction in which the bean method
participated will be rolled back.
– No other method will be invoked on an
instance that threw a non-application
exception.
What container does
• This means that the Bean Provider does
not have to perform any cleanup actions
before throwing a non-application
exception. It is the Container that is
responsible for the cleanup.
AOP and Law of Demeter ?
• Only talk to friends