Expert one-on-one J2EE Development Without EJB 阅读笔记（一）

从今天开始要阅读这本书了。要做详细的笔记。还是决定自己边翻译边学习吧。希望能够坚持下来。


Chapter 1 Why “J2EE without EJB”?

The traditional approach to J2EE architecture has often produced disappointing results: applications 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实践以及更新的技术，比如控制反转(Inversion of Control)，面向方面的编程（AOP）。告别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刚一出现，我被它的承诺所鼓动。我相信这是企业级中间件的一条坦途。但是，时至今日，我已修正了我的想法，根据就是我和我的同事们的经历。

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规范中容器代码生成和多个源文件需要实现每个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.
因为Web Service的出现，以及鉴于EJB有时只需要local interfaces 这种认识，EJB与RMI之间的传统联系看起来过时了。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只是基础典型应用围绕分布式业务对象这种现象的一个特例，所以架构上选择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的使用显示了它的长处和短处。大多数开发者和架构师已经把他们对于EJB的使用限定于无状态会话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已经出道五年了，并且得到了大规模的应用，但是，它的复杂性意味着很显然很多开发者并不了解它。例如，很多我面试的程序员不能正确的描述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.
严格的单元测试和测试驱动开发越来越受欢迎，这无可厚非。倚仗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的试图解决的问题。

❑ 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.
相对于自EJB1.1以来，繁琐的基于XML的部署描述，代码级的元数据属性，就像在.NET中使用的那样，意味着在多数情况下，是一个更优的选择。EJB3.0看起来也是要走这条路，但是任重而道远。

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出现之初，开发者就已经遇到了难以解决的问题，只不过那时还不是那么明显。经验表明EJB不足之处如下：

❑ It doesn’t necessarily reduce complexity. It introduces a lot of complexity.
它没有降低复杂度。它引入了很多复杂度。

❑ The entity bean experiment for persistence has largely failed.
实体bean作为存储的实践，很大程度上失败了。

❑ Applications using EJB tend to be less portable between application servers than applications using other J2EE technologies, such as servlets.
使用EJB的应用比使用其他J2EE技术(例如servlets)，在不同应用服务器间的可移植性更差。

❑ 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，而导致不得不重构，或者完全失败。
❑ EJB can make simple things hard. For example, the Singleton design pattern (or alternatives) is hard to implement in EJB.
EJB把简单的问题复杂化。例如，单例设计模式很难用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. 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.
所有这一切告诉我们，在采用EJB之前，准确的分析价值定位是很聪明的做法。我希望用工具约束你有效地，冷静的去做。在第五章，我们将探讨EJB及它带来的问题。同时，让我们看看J2EE该何去何从，这本书将帮助你如何在符合预算的情况下，按时交付产品。