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 wi