Transcript why ejb?

a critical look at ejb
1
why ejb?
• Building enterprise systems is hard.
– An enterprise system must interact with a relational
database
– 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
2
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
components
– EJB provides opaque transactioning plumbing for
components
– 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
3
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
necessary)
4
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.
5
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
data
6
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)
7
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.
8
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
vendors"
– "... 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?
9
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
10
complexity
• "... 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
11
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
code
– 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
12
"container-managed" really means containermanaged
• For Container-managed arenas, there is no developer influence
possible
– 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
13
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
14
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;
}
15
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'
//
}
}
16
pooling and jita
• JITA offers some benefits, but not always
– Activation/passivation time is nonzero
– Client call patterns are nondeterministic
17
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
18
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
19
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
20
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
21
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
22
metaprogramming
• 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
23
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
24
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
server
– Avoid EJB but embrace the "other" specs (JTA, RMI, and so
on)
– SessionBeans over RMI == Servlets over HTTP (SOAP?)
– Problem: Expertise and Time
25
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
26
summary
•
•
•
•
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
27