Why “J2EE Without EJB”?
that are more complex than their business requirements warrant, show disappointing performance,
are hard to test, and cost too much to develop and maintain.
传统的J2EE构架经常给我们带来失望的结果:应用过于复杂，甚至超过了业务需求本身，性能问题，难于测试，开发和维护成本高。
It doesn’t need to be so hard. There is a better way for most applications. In this book, we’ll
describe a simpler, yet powerful architectural approach, building on experience with J2EE and
newer technologies such as Inversion of Control and AOP. Replacing EJB with lighter-weight,
more flexible, infrastructure typically produces significant benefits. We and many others have
used this approach in many production applications, with better results than are usually produced
from traditional architectures.
其实，要解决这些问题并不是非常的困难，主要是找到一种较好的方法。这本书，我们将展示一种较为简单而且健壮的构架模式-它利用了多年来在J2EE方面的教训和一些新兴的技术，如:IOC(Inversion of Control)和AOP(Aspect O) . 以及利用轻型、灵活，特有的构架模式来代替EJB带来的好处。我们已经将这种方法应用在多个产品应用中，并获得了比传统构架模式更好的效果。
Let’s begin with a quick tour of the topics we’ll examine in more detail in later chapters.
现在，就让我们来开始我们的真实体验吧
EJB Under the Spotlight
聚光灯下的EJB
Like most of my colleagues, I was excited by the promise of EJB when it first appeared. I believed
it was the way forward for enterprise middleware. However, I’ve since revised my opinions, in the
light of my experiences and those of many colleagues.
像我的同事们一样，在EJB刚出现的时候，EJB的宣传让我兴奋不已。我相信这将是企业级中间件的光明大道。可是，在不久实践中我和我的同事们改变了我们的观点。
Much has changed since the EJB specification was conceived:
自从EJB规范构建以来，很多东西已经改变了:
- Parts of the specification’s design now seem dated. For example, dynamic proxies, introduced
in J2SE 1.3, call into question the container code generation envisaged in the EJB
specification and the multiple source files needed to implement every EJB.
部分规范设计已经过时.比如说，在J2SE1.3 里面的动态代理，在EJB规范里面被叫做xxxx,并且很多程序文件需要实现每个EJB. - The traditional link between EJB and RMI remoting is looking dated, because of the emergence
of web services and the recognition that EJBs sometimes need only local interfaces.
EJB is a heavyweight model for objects that don’t need to offer remote access.
在EJB和RMI的章节中远程连接已经过期，因为随着web service 的快速发展,以及EJB有时只需要本地接口的调用。而EJB则是一个在不需要远程调用的一个重量级对象模型。 - This is a special case of the fact that basing typical applications around distributed business
objects—the architectural choice EJB implements best—has proved problematic.
只有基于分布式业务对象的典型实际用例中，EJB无非是最好的选择，这已经被无数用例所验证。 - Usage of EJB indicates its strengths and weaknesses. Most developers and architects have
restricted their use of EJB to stateless session beans and (if asynchronous calls are needed)
message-driven beans. The relative simplicity of the services provided by the EJB container to
support SLSBs means that the overhead of an EJB container is hard to justify in such applications.
EJB的使用让它的优势和弱点表露无疑.大多数的开发者和构架师只局限于使用无状态的session bean和消息驱动bean.对于EJB容器给我们提供支持SLSBs来说 ，EJB容器在这些应用上无非是空中楼阁而已。 - Although EJB has been around for five years, and its use is a given in many J2EE projects, it has
become apparent that its complexity means that many developers still don’t understand it. For
example, many developer candidates I interview can’t correctly describe how EJB containers
handle exceptions and how this relates to transaction management.
虽然EJB已经有了5年的发展，并且它应用于许多特殊的企业应用环境，但是，显而易见，他的复杂性意味着许多开发者到现在还不能真正理解。例如,我面试的众多开发者不能正确的描述EJB容器如何操作异常，如何处理事务。 - The EJB specification is becoming more and more complex in an attempt to address problems
with EJB. It’s now so long and complex that few developers or architects will have time to
read and understand it. With specifications, as with applications, the need for continual
workarounds and constantly growing complexity suggests fundamental problems.
现在的EJB规范越来越复杂的通过EJB来解决问题.这样的只有少数的开发者和构架师愿意花费时间来读它和理解它。对于规范，和应用一样，这需要不断的改善和对传统问题给出相应的解决方法. - The complexity of EJB means that productivity in EJB applications is relatively poor. A number
of tools try to address this, from “Enterprise” IDEs to XDoclet and other code generation tools,
but the complexity still lurks under the surface and imposes ongoing costs.
复杂的EJB意味着在EJB项目里的生产力的降低。一些工具试图解决这个问题，从企业的集成开发环境(IDE)到XDoclet和一些代码生成工具，但是，这只是将复杂性掩盖在了表层之下，存在着巨大的风险. - Rigorous unit testing and test driven development have become increasingly, and deservedly,
popular. It’s become clear that applications making heavy use of EJB are hard to test.
Developing EJB applications test first requires a lot of fancy footwork; essentially, minimization
of the dependence of application code on the EJB container.
严格的单元测试和测试驱动开发日益盛行，xxxx,直到流行。EJB项目难于测试这一点也越来越明显。开发EJB应用测试程序，首先要做大量的准备工作，但实际上，我们的应用代码需要将对EJB容器的依赖性降到最小，这已经违背了我们的初衷. - The emergence of Aspect Oriented Programming (AOP) points the way to more powerful—yet
potentially simpler—approaches to the middleware problems addressed by EJB. AOP can be
viewed in part as a more general application of the central EJB concepts, although of course it’s
much more than a potential replacement to EJB.
面向方面编程(AOP)的观点的提出指出了一条明确的道路 ，简单的解决了EJB在中间层上的问题。AOP部分解决了控制EJB组件的观察组件状态的通常的一些问题 ，尽管AOP还不能完全替代EJB. - Source level metadata attributes, as used in .NET, suggest a superior alternative in many cases
to the verbose XML-based deployment descriptors used since EJB 1.1. EJB 3.0 looks like it’s
heading down that road as well, but it’s a way off and will carry a lot of baggage.
Experience has also shown EJB to incur greater cost and deliver fewer benefits than were initially predicted.
Developers have encountered intractable problems that weren’t apparent when EJB first
appeared. Experience has shown that EJB fails to deliver in several areas:
经验告诉我们EJB带来巨大的成本和比想象中更少的优势。开发者遇到了许多比刚开发EJB时难于处理的问题，主要表现在以下几个方面：
- It doesn’t necessarily reduce complexity. It introduces a lot of complexity.
没有必要的简化复杂性.而且还更加的复杂。 - The entity bean experiment for persistence has largely failed.
Entity bean在持久层的实验性很大程度上是失败的。 - Applications using EJB tend to be less portable between application servers than applications
using other J2EE technologies, such as servlets.
EJB应用在应用服务器和应用其他的J2EE应用技术(servlet)之间趋于复杂 - Despite the promises that EJB would prove the key to scalability, EJB systems often perform
poorly and don’t necessarily scale up well. Although statistics are hard to come by, anecdotal
evidence suggests that the overhead of excessive use of EJB necessitates re-architecture or
causes outright failure in a significant number of projects.
~虽然EJB许诺提供了必要的测量性，但是系统的性能一直是个问题，而且，还很严重。虽然难于分析为何，众多建议EJB需要重新构架或者宣布彻底失败。 - EJB can make simple things hard. For example, the Singleton design pattern (or alternatives) is
hard to implement in EJB.
EJB 让一些简单的事情变得复杂.例如，Singleton模式很难应用于EJB.
All of these issues suggest that it’s wise to analyze exactly what the value proposition is before using
EJB. I hope to equip you with the tools to do this effectively and dispassionately.
这些问题是在使用EJB之前通过严密的分析而提出来，希望你可以利用一些工具冷静有效的使用EJB.
In Chapter 5, we’ll talk more about EJB and its problems. In the meantime, let’s look at where J2EE is
today, where I feel it’s going, and how this book will help you deliver real solutions on time and budget.
在第5章，我们将描述更多关于EJB和有关问题. 现在，让我们看一下今天的J2EE,J2EE的发展以及如何这本书帮助你获得更有效的解决方案。
What’s Left of J2EE?
You may be wondering, “What’s left of J2EE without EJB?”
你可能感到奇怪,什么是 “What’s left of J2EE without EJB?”
The answer is: a great deal. J2EE is much more than EJB. Many J2EE developers believe otherwise, and
will tell you so when they see this book on your desk, but a dispassionate analysis of what EJB does, and
what J2EE does overall, shows that EJB is only a part of a much bigger and more important picture.
答案就是:a great deal. J2EE要比EJB更加广泛。许多J2EE开发者甚至不相信这点，还会告诉你他们已经看过这本书，但是对EJB可以做什么做个分析，就知道EJB是不万能的,只是J2EE应用中一个部分，比较重要而以。
J2EE is essentially about standardizing a range of enterprise services, such as naming and directory services
(JNDI), transaction management offering a standard API potentially spanning disparate transactional
resources (JTS and JTA), connection to legacy systems (JCA), resource pooling, and thread
management. The true power of J2EE lies in these services, and this standardization has done great
service to the industry.
J2EE本质是一个企业级服务的范围标准，例如，JNDI,(JTA/JTS),JCA,resource pooling和线程管理.J2EE的强处在于这些服务，以及让这些标准构建的服务应用于工业。
EJB, on the other hand, is merely one way of leveraging those valuable services, through a particular
component model.
EJB在众多方法中仅仅是一种具有价值的杠杆，一种特殊的组件模型而已.
We can still access JNDI, JTA, JCA, resource pooling, and other core J2EE services without using EJB. We
can do this by writing code that uses them directly (not as hair-raising as it may seem) or—better—using
proven libraries and frameworks that abstract their use without imposing the complexity of EJB.
Only a few EJB container services are unique to EJB, and there are good alternatives to those. For example:
我们可以在不用EJB的情况下访问JNDI,JTA,JCA,resource pooling以及众多的J2EE核心服务.我们可以直接编码来使用他们，或者利用一些工具和框架而绕开EJB的复杂。只有少量的EJB容器服务s是EJB特有的,同样也有好的变通方法，如：
- Entity beans are the only dedicated data access components in J2EE. However, they’re also the
most questionable part of J2EE, and there are much better non-J2EE alternatives, such as
Hibernate and JDO. In some applications, JDBC is a better option.
在J2EE里，实体bean只侧重于数据存储,这也是J2EE质疑的部分，有很多不用J2EE解决的方法，例如：hibernate和JDO.在一些应用里面，JDBC是最好的选择. - Container Managed Transactions (CMT): EJBs are the only part of J2EE to enjoy declarative
transaction management. This is a valuable service, but as we’ll see in Chapters 8 and 9 we can
also achieve declarative transaction management using AOP. CMT is a relatively thin layer over
the underlying J2EE JTA service. It would be hard (and foolhardy to attempt) to replace an
application server’s global transaction management, but it’s not so hard to access it to develop
an alternative form of CMT.
容器管理事务(CMT):在J2EE里，EJB只是事务管理解决方法的一种。当然，对于这样重要的服务，我们将在第8，9章介绍我们利用AOP解决事务管理的方法.CMT只是在J2EE的JTA服务至上一个薄薄的一层.虽然艰难的替换掉了应用服务器的全局性事务管理，但利用CMT开发事务实在是不容易. - Thread pooling for business objects: We usually don’t need this if we’re supporting only web
clients (or web services clients going through a servlet engine), because a web container provides
thread pooling and there’s no need to duplicate it in the business object tier. We do need
thread pooling to support remote clients over RMI/IIOP, one case in which EJB remains a good,
simple technology choice.
业务对象的线程池:如果我们只在做web开发时，通常不需要这项服务，应为每一个web 容器都提供了一个线程池，而且不需要复制一份到业务对象层。在RMI/IIOP上开发远程调用的时候，我们就需要线程池了，这也是EJB的为数不多的、简单的技术好处之一。 - (Related) Thread management for business objects: the ability to implement EJBs as though
they are single-threaded. In my experience this is overrated for stateless service objects (the
most useful kinds of EJB). EJB can’t eliminate all threading complexity anyway, as problems can
remain with objects used by EJB facades. There are good alternatives to EJB thread management,
discussed in Chapter 12.
业务对象的线程管理:就像单线程一样，有能力扩展EJB。以我的经验，这只是过高的估计了无状态服务对象的能力。EJB根本不能消除所有线程的复杂性， 因为被EJB使用的对象就可能出问题. 在第12章，我们讨论一种比EJB线程管理更好的方式.
Only in the area of remoting is EJB the only way to implement such functionality in standard J2EE. As
we’ll see, only in RMI/IIOP remoting is EJB clearly an outstanding remoting technology; there are better
alternatives for web services remoting..
可以看出，EJB只有在远程调用方面扩展了J2EE的功能。只有在RMI/IIOP远程方面EJB有着突出的优势，这就可以让我们在web 方面有较好的选择.
There’s a strong argument that EJB attempts to address a lot of issues it shouldn’t. Take O/R mapping.
This is a complex problem to which EJB provides a complex yet under-specified solution (entity beans)
that simply ignores some of the central problems, such as mapping objects with an inheritance hierarchy
to relational database tables. It would have been better for the designers of the EJB specification to leave
this problem to those with much more experience of the issues around object persistence.
这些讨论标志着EJB试图解决一些它不能解决的问题. 操作O/R mapping，对于这个复杂的问题，EJB也给出了一套解决方案-实体bean-只不过忽略了一些重要的问题而已.例如:在继承层面有关联数据表的映射对象。这使遵循JEB规范的设计者们把问题转加到了对象的持久层上。
Note#1:J2EE is much more than EJB. Using J2EE without EJB, we don’t have to reinvent the
wheel. We don’t need to reimplement J2EE services, just consider alternative ways of
tapping into them.
J2EE要比EJB更加来的广泛。用J2EE也不一定非要用EJB,我们没必要重新发明轮子，我们也不需要重新去实现J2EE服务，只要选择一条捷径就好了。
J2EE at a Crossroads
在十字路口的J2EE
J2EE is at a fascinating point in its evolution. In many respects it’s a great success. It has succeeded in
bringing standardization where none existed; it has introduced a welcome openness into enterprise software.
It has achieved fantastic industry and developer buy-in.
J2EE的诱惑在于它的发展潜力.在许多的方面，它已经很成功，这些成功来自于非标准化。J2EE是一个公开的企业级软件，极大的被企业和开发人员认可.
On the other hand, I feel it has come up short on a number of measures. J2EE applications are usually
too expensive to develop. J2EE application projects are at least as prone to failure as pre-J2EE projects.
(Which means that the failure rate is unacceptably high; developing software is far too hit-and-miss an
affair.) In the areas where J2EE has failed, EJB has usually played a significant part.
J2EE has significant issues with ease of development. As I’ve said, J2EE applications tend to be unnecessarily
complex. This is especially true of J2EE web applications, which, like the Sun Java Pet Store, are
often absurdly over-engineered.
另一方面,我认为不足之处在于，J2EE应用开发成本太高,这使纯J2EE项目往往以失败告终.(这里的失败，意思是方案不被采纳)。
总结J2EE失败的原因，EJB往往成为重要的因素. J2EE 现在的关键问题是让开发更容易，如我所说，减少不必要的复杂. 特别是J2EE的web 应用，就像Sun Java Pet Store 就是典型的过分设计.
J2EE is still a relatively young technology. It’s not surprising that it’s imperfect. It’s time to take stock of
where it’s worked, and where it hasn’t worked so well, so that we can eliminate the negatives and enjoy
the positives. Because J2EE contains a lot, this essentially means identifying the subset of J2EE that delivers
most value, along with some supplementary infrastructure we need to harness it most effectively.
相对而言，J2EE作为新一代开发技术，有一些不足是不足为奇的. 我们可以发扬优势，去其劣势，从而来定位J2EE的应用范围,由于J2EE饱含太多的内容，原则上要定位J2EE的核心价值，开辟一条有效的发展路程.
There is a growing movement in the J2EE community toward simpler solutions and less use of EJB. My
previous book, Expert One-on-One J2EE Design and Development (2002), was a step in the growth of that
movement, but was part of a broader trend. I believe this book represents the next step in defining and
popularizing such solutions, but it’s important to note that I’m by no means alone. Fellow pioneers
include Rickard Oberg and Jon Tirsen (of Nanning Aspects), who have helped to demonstrate the power and simplicity of AOP-based solutions. The revisions in the second edition of Core J2EE Patterns suggest
that even Sun is not immune; there is a new and welcome emphasis on use of plain Java objects.
在J2EE社区，大多数发展都向着简单迈进，也包括EJB的使用. 比起我的上一本书
Some of the problems with J2EE and EJB relate to its specification-driven origins. History shows that the
most successful standards evolve, rather than are created by a committee. The danger of a “specificationfirst”
approach is shown by the example of the OMG and CORBA. The OMG was founded to create a
distributed object standard. Over 300 vendors signed up; the result was the slow production of complex
specifications that never achieved widespread acceptance. As is often the case with committees, usability
by developers was barely a consideration; the result was a horribly complex programming model.
J2EE 和 EJB的一些问题的出现，是规范驱动所引起的.历史证明,许多成功的发展要比标准更快。 "规范先行"导致的结果显而易见,如OMG和CORBA.OMG是用于创建一个分布式对象的标准。超过300人加入制定，但是结果却给我们一个从来就没有被大众所接受的超级复杂的产品。然而 标准委员会的工作中，竟然没有考虑开发者的可用性，结果当然就只能是一个复杂的编程模型了.
J2EE is partly an evolution of existing middleware, because many of the problems it addresses were
familiar when it was conceived in the late 1990s. For example, stateless session EJBs are merely an EJB
take on a component type of proven value. Service objects with declarative transaction management
existed in Microsoft Transaction Server, for example, before the EJB 1.0 specification. It’s arguable that
where J2EE has tried to innovate, through specifications being developed before any real applications
using them, it has often failed. Stateful session beans, for example, were a new and unproven component
type introduced in EJB. Five years on, they remain largely unproven. The tricky issue of state replication
remains problematic, and most architects avoid stateful session beans if at all possible.
~J2EE也是几经存在的中间件的发展部分,因为在1990年以后，J2EE遇到了许多常见的问题.例如,无状态session EJBs只是EJB提供的一种组件类型。
未完...