to ejb or not to ejb 4

EJB folklore
Any technology that has grown as quickly as EJB has since 1997 is bound to spawn folklore. Some such myths were once true in an earlier version of the technology, many spring from unfamiliarity with EJBs, and some are promulgated by sources with hidden agendas. Below you@#ll find some example EJB folklore. Each example includes whether it@#s a myth, a half-myth, a misunderstanding, mostly true, or true:

• You don@#t need developers to understand SQL if you are using container managed entity beans. Myth: Ridiculous, of course you do. Are you telling me that a serious enterprise would put mission-critical data in a database, and then let developers with no SQL knowledge write an application to aclearcase/" target="_blank" >ccess and modify that data ... and then take it live?
  
• EJBs are portable between vendors. Half-myth: EJBs are portable if you write them to be. Session beans and BMP (bean managed persistence) entity beans usually port quite easily. In contrast, CMP (container managed persistence) entity beans need a good bit of work. Quite often, applications that rely on a clustering implementation take longer to port, as clustering is a big differentiator between vendors and is also not addressed adequately in the EJB specification. The work might not be in rewriting code, but in reconfiguring deployment descriptors and container/server configurations. In addition, administration and configuration tools and mechanisms are vendor-specific, as are things like startup and shutdown scripts and sometimes build scripts (unless the vendor uses the Ant build tool).
  
• Security is free with EJB. Misunderstanding: The EJB specification provides a fully fledged security model (that integrates with the J2EE security model). But it is just a model, you need to set up your users and roles yourself -- and potentially tie in to an existing authentication source, such as a database or LDAP server.
  
• EJB solutions are expensive. Mostly-true: The expense issue has long been a truth that should soon change to a myth. Open source and low-cost alternatives offer real competition to the entrenched market leaders. Additionally, I do not subscribe to the view that the cost of vendor licensing is usually a small fraction of a project@#s total cost. When you take into account per-CPU licensing and mandatory support contracts, the total cost of ownership is ridiculously high. Competition from within the J2EE industry and from without by Microsoft is good for pricing and feature development.
  
• CMP is faster than BMP or BMP is faster than CMP. Misunderstanding: Whether one is faster than the other depends on the quality of the vendor@#s CMP engine and also on how proprietary it is. The more proprietary an application server is, the more features it can add to its CMP engine, like batch updates, smart updates, and more.
  
• Entity beans are slow. True: Entity beans are often too slow and need to be worked around by a combination of session beans and value objects. This shortcoming is most noticeable in cases where a finder method returns thousands of rows. Invariably, you need to rework the business logic. In some cases, application servers try to be smart about loading data (lazy-loading), but such efforts often prove insufficient.
  
• Stateful session beans are bad and should be avoided. Myth: Stateful session beans scratch an itch that stateless session beans cannot: maintaining server-side state across method invocations. As such, they are a required part of the EJB model and prove valuable in certain situations. However, they should be used sparingly as server-side state always adversely affects scalability. In general, I design all session beans to be stateless by default, but if it makes sense to convert a few to become stateful to meet business requirements, then that@#s fine.

Business scenario: Ice-Cold Beer Boutique
Well, I did promise not to use the pet store or an ATM example didn@#t I?! Instead, I picked a business scenario to show how to apply the knowledge built up over the previous sections -- the Ice-Cold Beer Boutique (ICB).
Month 0: The initial business requirements
I have been commissioned to recommend a technology solution to ICB -- a budding beer entrepreneur. The initial requirements include:

• ICB plans to make its Website available to a select number of clients (less than 30) as a soft-launch. The site is a read-only catalog of premium beers available for shipment with no authentication or authorization required.
  
• We are on a very tight hardware and software budget until increased business warrants further investment. Further, the existing team is not up to speed on EJBs, but does have good Java experience.
  
• ICB plans to expand rapidly, adding read-write capabilities for authorized users, online purchasing by external clients, and plans to scale up to support 100 concurrent users in the medium term.

You will find a high-level overview of the proposed architecture and how it evolves as requirements change in Figure 2.

Figure 2. The evolution of the ICB architecture, from online catalog with no EJBs to a fully-fledged B2B architecture, using an EJB-centric model.

The correct solution
I cannot justify promoting an EJB-based solution at this stage. The business functionality requires none of the advantages EJB provides, and the load and concurrency requirements are not high enough at present to require EJB@#s scalability benefits. Further, the team lacks EJB experience, and there is no money or time for anything except basic training. However, these requirements will change if the business expands, so it would be foolish of me to build any design that mitigates against transitioning to EJBs in the future.
I recommend a JSP/servlet-centric approach for presentation and control with data access objects (DAOs) using JDBC for direct data access from the servlet layer and taglibs for direct SQL access from the JSP layer.
Month 3: The business expands
Business is good! The soft-launch was a complete success. Now ICB wants to expand. ICB wishes to take orders from 100 concurrent users, 2e hours a day, 7 days a week. Additionally, the company wants to accept online credit card reservations using a third-party provider.
The correct solution
We now have a number of compelling reasons to move to a fully fledged EJB-centric architecture. Three words to explain why:

• Scalability: In three months, the core business requirement has increased 3.3 times in the number of concurrent users. This should act as a warning flag that if the business continues to expand, increases of this size will be the norm, not the exception.
• Security: The servlet specification now provides access to a user@#s role and principal as well as authentication but does not provide per-method authorization -- the EJB specification does, and the current business scenario demands it.
• Transactions: The J2EE 1.3 specification requires that servlets and JSPs be allowed to demarcate transactions using the javax.transaction.UserTransaction interface. However, the EJB specification provides much richer transaction management semantics (see the , Chapter 17 for more details).

Month 12: ICB goes global!
In month 12, the business expands again. ICB has joined the Global Association of Beer Boutiques (GABB), and our solution must now support up to 300 concurrent users, as well as cohost and comarket WeissenBier from Germany and Abbey Beer from the Netherlands. Our new business partners use XML-RPC (XML over remote procedure call) to publish this information. They also provide access via a Java API to an Enterprise Resource Planning (ERP) system to track inventory changes and sales in realtime.
The correct solution
Now we can sit back and watch the benefits of EJB in action! A lot of work still must be done, but the core architecture to support a three-fold increase in concurrent users already exists. Because EJB servers can admit any Java code that meets the specification restrictions, not just EJBs, it also makes sense to deploy the ERP client library on to the application server and design an interface to expose the new API to existing code in a well-designed manner. Message driven beans (MDBs) and the JMS are obvious choices here. To support the increased number of concurrent users, we should employ both horizontal and vertical scaling, which will require testing to ensure the application behaves correctly in a clustered environment.
Knowledge is power
Any enterprise project can be built using EJB/J2EE. However, not all projects should be. As I began to write this article, EJB technology had just received a lot of bad press, particularly when one analyst released a research note warning against overspending on application server technology (see "").
The pro EJB group has had its day it seems, as EJB is now derided by almost everyone (too heavy, too slow, too expensive). This is short-sighted and premature: EJB technology makes complete sense for applications with high-end scalability and transaction-handling requirements. Prices are falling, JBoss (the only serious open source contender) continues to garner mind share and move into production sites, and major IT players such as HP are releasing free application servers. Microsoft is also fighting for our hearts and minds, which can only be good for the J2EE industry.
I hope that this article has laid to rest some of the folklore surrounding EJB and has shed some light on how to decide if EJB is right for you. As I@#ve mentioned before, no substitute exists for hands-on experience; a critical part of choosing any technology is using it. Reading the specification is not enough, nor is surfing message boards or email lists (although they do help a lot, especially for vendor selection!). Design, build, and evaluate a thin slice of your application to see if it warrants an EJB approach before taking the plunge. Finally, good luck!

原文转自：http://www.ltesting.net