当前位置:编程学习 > JSP >>

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

上一个:to ejb or not to ejb 3
下一个:sendRedirect vs forward

CopyRight © 2022 站长资源库 编程知识问答 zzzyk.com All Rights Reserved
部分文章来自网络,