1 / 27

a critical look at ejb

a critical look at ejb. 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

yepa
Download Presentation

a critical look at ejb

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related