1

a critical look at ejb

2

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

3

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

4

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)

5

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.

6

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

7

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)

8

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.

9

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?

10

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

11

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

12

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

13

"container-managed" really means container-managed

• 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 write-

rarely 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

14

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

deploy-test– Deployment descriptors are NOT code

15

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

16

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' // }}

Figure 1.2

17

pooling and jita

• JITA offers some benefits, but not always– Activation/passivation time is nonzero– Client call patterns are nondeterministic

18

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

19

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

20

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

21

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

22

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

23

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

24

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

25

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

26

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

27

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