a critical look at ejb

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. 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; }

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

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