a critical look at ejb
why ejb?
• Building enterprise systems is hard.
– An enterprise system must interact with a relational
– It must ensure data integrity at all times
– It must operate across the network
– It must scale up to large numbers of concurrent clients
– It must deal with those concurrent clients in a certain and
deterministic manner
– It must provide guarantees of only-authorized-actions
– It must ship sometime
ejb's intent
• EJB wants to provide basic services and environment to make
enterprise systems easier to develop.
– EJB provides a managed lifecycle environment for
– EJB provides opaque transactioning plumbing for
– EJB provides automatically-managed persistence logic
– EJB provides an enforced-authorization framework
– EJB provides all necessary support for remote operations
– EJB provides "best of breed" capabilities by providing all this
in a vendor-neutral fashion
object lifecycle management
• Amortize cost of creating objects by pooling them transparently
– Most clients don't care about object's geneaology
– Reduce object-creation complexity by offloading the act of
creation entirely
– Enhance scalability by silently using single objects to service
multiple clients (swapping client-specific state in and out as
opaque transactional plumbing
• Transactionally execute all actions to prevent inconsistency
– Despite our best programmatic efforts, sometimes things will
go wrong.
– Asking programmers to deal with all the possible right/wrong
combinations is a recipe for disaster.
– Data integrity still remains the highest priority
– Let the app server track the success or failure, and commit
or rollback as necessary.
persistence management
• Perform all state and persistence management under the control
of the application server
– Access to relational data is done through SQL
– Most Java programmers aren't great database engineers
– Therefore let the app server worry about how to obtain the
security framework
• Ensure that only authorized clients can perform sensitive actions
– Certain operations (or resources) are sensitive
– Not all users should have access to those sensitive
operations or resources
– As a result, the system needs to enforce authorization rights
– We can give the app server knowledge of what principals
have what rights
– Therefore let the app server deal with the enforcement of
authorization policy by checking roles of callers (either
declaratively or programmatically)
remoting support
• Make the server keep track of distribution and synchronization
– Since the server will be managing client-side objects
anyway, let it hand out the objects required to reach across
the wire
– If getting synchronization within a single VM is hard....
– Since the app server is already managing lifecycle
semantics, let it worry about remoting semantics (including
synchronization) as well.
ejb has the best of intentions
• The EJB Specification wants to simplify your life.
– "... make it possible to build distributed applications by
combining components developed using tools from different
– "... make it easy to write applications: Application developers
will not have to understand low-level transaction and state
management details, multi- threading, connection pooling,
and other complex low-level APIs"
– "... address the development, deployment, and runtime
aspects of an enterprise application's life cycle"
– "... define the contracts that enable tools from multiple
vendors to develop and deploy components that can
interoperate at runtime"
– "... be compatible with existing server platforms"
– Does EJB deliver?
ejb falls down in a number of important places
• EJB "hot spots"
– Complexity
– Vendor neutrality isn't all its cracked up to be
– "Container-managed" really means container-managed
– Lack of compiler assistance to enforce complexity
– Pooling and JITA
– Remoting: RMI and HTTP
– Remoting: Round trips are Evil
– Security: Lack of concrete details
• "... make it easy to write applications: ..."
– EJB 1.1 Spec == 312 printed pages (JavaSoft Press book);
EJB 2.0 Public Draft == 450+
– Writing "Hello World" requires minimum of 2 interfaces, 1
class plus a deployment descriptor
– For example, explicit restrictions on what methods may be
invoked from within other bean methods (Sections 6.6.1)
– Or the lack of guarantee about method invocation in places
(Section 6.6.3--"Missed ejbRemove() Calls")
– Developers have historically not handled complexity well
vendor portability
• Vendor portability implies "least common denominator" features
– "... using tools from different vendors"
– "... enable tools from multiple vendors to develop and deploy
components that can interoperate at runtime"
– Embracing portability means writing only Spec-compliant
– This means never taking advantage of value-added features
– How often do companies change platforms?
– How often will you be able to buy COTS components?
– Lack of Spec-mandated configuration options
"container-managed" really means containermanaged
• For Container-managed arenas, there is no developer influence
– Developers often know better than the system
– EJB will serialize all remote calls unless told otherwise
– CMP Entity beans perform poorly for read-only and writerarely data
– CMP Entity beans manage all data access: multiple network
hops and poorly- written SQL are likely
– "One size fits all" schemes almost universally worthless
loss of type-safety
• Compiler can't enforce EJB restrictions
– For example, Bean class can't implement Remote interface
– Programmatic errors can't be caught until deployment
– Stretches development cycle from compile-test to compiledeploy-test
– Deployment descriptors are NOT code
Figure 1.1
public interface TellerSession extends java.rmi.Remote
public void deposit(Money m, Account a)
throws java.rmi.RemoteException;
public void transfer(Money m, Account from, Account to)
throws java.rmi.RemoteException;
Figure 1.2
public class TellerSessionBean extends SessionBean
public void deposit(Money m, Account a)
throws java.rmi.RemoteException
// Place the Money m into the Account a
public void transfer(Account from, Account to, Money amount)
throws java.rmi.RemoteException
// Take 'amount' from 'from', deposit it to 'to'
pooling and jita
• JITA offers some benefits, but not always
– Activation/passivation time is nonzero
– Client call patterns are nondeterministic
remoting: rmi and http
• HTTP is stateless; RMI isn't
– RMI establishes a stateful link against a single server
– RMI therefore defeats load-balancing
– HTTP is a stateless protocol, as are Servlets/JSP
remoting: round trips are evil
• Traveling across the wire is not free
– Distributed object protocols (RMI, CORBA, DCOM) want to
hide the network
– But making a remote call is many orders of magnitude more
expensive than making a local call
– But EJB explicitly considers every call a remote call
– EJB offers no ability to "hint" to the server about locality
security: lack of specifics
• EJB's Security sections are deliberately vague
– EJB wants to let security be a vendor value-add
– Specifies how to declare security attributes....
– ... but offers nothing on how security roles are discovered
– Offers no "standard" way to configure security
alternatives outside ejb
• First solution: run away (in some form)
– Abandon Java entirely for C++ or .NET
– Work with a meta-object system: AspectJ, HyperJ,
OpenJava, ....
– Abandon EJB entirely: roll your own approach
– Mimic EJB's goals: roll your own layers
– Embrace-and-extend: write your own EJB server
abandon java
• Move to a language/platform that doesn't have these flaws
– This implies either adopting COM/DCOM (old technology) or
.NET (beta1 technology)
– Problem: You're abandoning Java!
– Probably unnecessary
• Recognize the complexity for what it is
– Metaobject languages provide a new approach
– AspectJ: www.aspectj.org: "Cross-cutting" classes
– HyperJ: www.alphaworks.ibm.com: "Hyperspaces"
– Dynamic Proxies (JDK 1.3)
– Problem: Expertise and Paradigm-Shift
define your own approach
• Embrace your own ideals for doing enterprise systems
– EJB wants you to build systems in a particular way
– If that way doesn't fit your needs, create your own path
– Examine object-relational mapping patterns and papers
– Work directly with other transactioning APIs (CORBA OTS)
– Problem: Expertise and Time
define your own layers
• Embrace EJB, but not the Spec
– You like the approach, but not the implementation
– Therefore, use the Zen that EJB teaches, but build your own
– Avoid EJB but embrace the "other" specs (JTA, RMI, and so
– SessionBeans over RMI == Servlets over HTTP (SOAP?)
– Problem: Expertise and Time
alternatives within ejb
• Work within the EJB framework and system
– Avoid container-managed persistence entity beans
– Abandon vendor-neutrality and use vendor features wisely
– Abandon the notion of distributed transactions
– Embrace the fact that EJB doesn't cover everything
– Understand the flaws presented in this presentation, and
avoid the traps
EJB leverages the managed-execution environment concept
EJB wants you to "Don't worry, be happy"
You can't, though, if you want reliable, robust apps
EJB isn't The Silver Bullet, but can be useful

Logon Sessions and Tokens