?
參考 Enterprise JavaBeans 4
這篇文章 講述了何時使用EJB，何時不用EJB，以及用哪些可以替代EJB！
1 When to Use EJBs
Here's a list of situations where EJBs are strong; we haven't distinguished between
different types of EJBs.
?
Single and multisystem business transactions
The ability to maintain transactional integrity for complex business entities is one of
an EJB's key strengths. EJBs aren't alone in providing straightforward transactional
control over a single data repository. However, EJBs shine where multiple resources
(relational databases, messaging systems, etc.) are involved because they allow
transactions to spread across as many different resources as you like, so long as the
resources support distributed transactions.
?
Distributed functionality
Business services often live on a remote server. For example, a business enterprise will
have many different systems, ranging in degrees of inflexibility and entrenchment. One of
these systems may need to access another; EJBs, which are inherently distributed, are
often the simplest way to distribute remote services. EJB also allows you to provide
business services to remote clients more easily than some alternatives. Remote access
through components is easier to maintain than direct database access, because the
component code can shield the client from database schema changes.
?
Portable components (not classes)
Until recently, if you wanted to share your business services with another application
developer, you were forced to share classes or at least packages. Java did not allow for
the easy creation of enterprise components, reusable software building blocks that can be
assembled with other components to form an application. EJBs allow you to package your
business logic into a tidy, distributable unit that can be shared in a loosely coupled
fashion. The user of your component need only tweak a descriptor file for her
environment.
?
Applications relying on asynchronous messaging
EJBs (specifically MDBs) provide a strong technology for handling asynchronous
communication such as JMS-based messaging or web services.
?
Security roles
If your application's business operations can be mapped to specific business roles in
your enterprise, then EJBs may be a good choice. So much is made of the transaction
management capability of EJBs that their deployment-descriptor-based security management
features are overlooked. This capability is very powerful; if your application's users
fit into distinct roles and the rules for those roles dictate which users can write what
data, EJBs are a good choice.
2 When Not to Use EJBs
There are several situations in building a software application—even an "enterprise"
software application—in which using EJBs may actually be a barrier to meeting your
business goals. The following list represents places where you might not want to use
EJBs:
?
Read-mostly applications
If your application requires only (or even mostly) database reads (as opposed to writes),
then the added complexity and performance overhead of EJBs may be unwarranted. If your
application is only reading and presenting data, you should go with straight JDBC (see
below) or another persistence mechanism. That said, if your application's writes
(database update and inserts) require transactional support (especially if those
transactions go over multiple systems), then EJBs may be the way to go—at least for the
write portion of the application.
?
Applications requiring thread control
If your application design requires extensive use of threads, then the EJB spec actually
prevents you from using EJBs (although some EJB container vendors may provide nonportable
ways around this restriction). Container systems manage resources, transactions,
security, and other qualities of service using threads; threads you create are outside of
the container's control and can potentially cause system failures. Also, EJB containers
may distribute EJBs across multiple JVMs, preventing the synchronization of threads.
?
Performance
Because EJBs do so much more than plain Java classes, they are slower than plain Java
classes. The EJB container has to do a lot: maintain transactional integrity, manage bean
instances and the bean pools, enforce security roles, manage resources and resource
pools, coordinate distributed operations, synchronize shared services (if the vendor
offers clustering capabilities), and so on. The security and transactional management
operations can have a significant impact on the performance of method calls (on both
local and remote interfaces). If you require real-time or near-real-time performance
characteristics, EJB may not be your best choice.
3 Alternatives to EJB
There are several alternatives to EJB; some of them are growing in popularity and
maturity. EJBs still rank as the de facto standard for enterprise transactional needs,
but some of the alternatives, like JDO, are also available.
3.1 JDBC
3.2 Java Data Objects
3.3 Others
Castor JDO (http://www.exolab.org)
Hibernate (http://www.hibernate.org)
Prevayler (http://www.prevayler.org)
As you can see, there are several alternatives to EJB. If your application doesn't need
the complexity or some of the features of EJB, take a look around. Data persistence with
Java has been around for some time and there is a wide assortment of approaches.