博主：注意：该书出版时间是2004年。仅需阅读自己关注的部分。
第一章
讨论J2EE的架构，分布式架构下是否必须使用EJB组件。大意是：J2EE是个伟大的平台和技术标准，但是官方却误导了大家。官方（当年，2002年）推荐的书籍和实践是不对的，应该是问题驱动而不是用J2EE驱动开发，致使很多人为了用J2EE而用J2EE，而不是根据项目的实际情况选择合适的技术。
首先，官方推荐的“J2EE开发模式”扭曲了我们熟悉的GoF中的设计模式。其次，J2EE的EJB组件并非是开发分布应用必需的技术，还可以使用SOAP中的WebService技术。
全都是陈年旧事儿，大致看看即可。
1. 三层结构（P27）
作者提到的三层结构与我的认识不同。
1. Enterprise Information System(EIS) Tier
有时也叫 Integration Tier
包括：DBMS，legacy mainframe applications。The EIS tier is outside the control of the J2EE server.
2. Middle Tier
This tier contains the application's business objects, and mediates access to EIS tier resources.
3. User Interface(UI) Tier
In web applications, the UI tier consists of servlets, helper classes used by servlets, and view components such as JSP pages.
可以看到，作者认为，EIS层是中间层之外的，不受J2EE控制的外部事物。而UI层则包括 JSP/Servlet，中间层包括业务逻辑和与EIS层交互必不可少的中间件。
2. Non-distributed Architectures(P28)
Web Application with Business Component Interfaces
博主：这莫非就是 service/serviceImple 两层结构的由来？
3. MVC(P37)
Model, view, and controller objects map onto J2EE components as follows:
❑ A model is a JavaBean that exposes data. A model object should not know how to retrieve
data from business objects, but instead, should expose bean properties that enable its state to
be initialized by a controller. Thus, the rendering of a view will never fail because of reasons
such as failure to retrieve data. This greatly simplifies error handling in the presentation tier (it
is also possible to use XML documents as models).
❑ A view is a component that is used to display the data in a model. A view should never
perform business logic or obtain data other than that which is made available to it in a model.
View components in J2EE systems are most often JSP pages. Each view in this architectural
pattern is analogous to one implementation of a simple contract ("display a certain set of
objects"). Thus, each view can be replaced with another view that displays the same model
differently, without altering the application's behavior.
❑ A controller is a Java class that handles incoming requests, interacts with business objects,
builds models, and forwards each request to the appropriate view. A request controller does
not implement business logic (this would impinge on the responsibilities of the middle tier).
4. 可移植性(P39)
接口级别（设计级别）的可移植，源代码级别的可移植。作者认可接口级别的可移植，源代码级别的移植代价很高。
We must distinguish between implementation portability ("this code runs without
change on any application server") and design portability ("this application will work
correctly and efficiently on any application server, if a small number of clearly
identified interfaces are re-implemented"). Total implementation portability can be
achieved in J2EE, but may not be a realistic or even a very worthwhile outcome.
Design portability is achievable, and delivers most of the business value of portability.
Even when portability is not a business requirement, design portability should flow
from good OO design practice
第二章
可直接略过，信息有些过时。主要讲选择J2EE中间件，组建团队，选择开发工具，识别和防范风险。
第三章
测试J2EE应用。
5. 常见测试
很贴心的把常见的测试种类都解释了一遍。
Definitions
o Unit tests
Unit tests test a single unit of functionality. In Java, this is often a single class. Unit tests are the
finest level of granularity in testing, and should test that each method in a class satisfies its
documented contract.
o Test coverage
This refers to the proportion of application code that is tested (usually, by unit tests). For example,
we might aim to check that every line of code is executed by at least one test, or that every logical
branch in the code is tested.
o Black-box testing
This considers only the public interfaces of classes under test. It is not based on knowledge of
implementation details.
o White-box testing
Testing that is aware of the internals of classes under test. In a Java context, white-box testing
considers private and protected data and methods. It doesn't merely test whether the class does
what is required of it; it also tests how it does it. I don't advocate white-box testing (more of this
later). White-box testing is sometimes called "glass-box testing".
o Regression tests
These establish that, following changes or additions, code still does what it did before. Given
adequate coverage, unit tests can serve as regression tests.
o Boundary-value tests
These test unusual or extreme situations that code under test should be able to handle (for example,
unexpected null arguments to a method).
o Acceptance tests (sometimes called Functional tests)
These are tests from a customer's viewpoint. An acceptance test is concerned with how the
application meets business requirements. While unit tests test how each part of an application does
its job, acceptance tests ignore the implementation details and test the ultimate functionality,
using concepts that make sense to a user (or customer, in XP terminology).
o Load tests
These test an application's behavior as load increases (for example, to simulate a greater
population of users). The aim of load testing is to prove that the application can cope with the load
it is expected to encounter in production and to establish the maximum load it can support. Load
tests will often be run over long periods of time, to test stability. Load testing may uncover
concurrency issues. Throughput targets are an important part of an application's non-functional
requirements and should be defined as part of business requirements.o Stress tests
These go beyond load testing to increase load on the application beyond the projected limits. The aim
is not to simulate expected load, but to cause the application to fail or exhibit unacceptable response
times, thus demonstrating its weak links from the point of view of throughput and stability. This can
suggest improvements in design or code and establish whether overloading the application can lead to
erroneous behavior such as loss of data or crashing.
都是常见的名词，注意最后2个测试：负载测试和压力测试的区别。
转下一篇博客。
来源：CSDN
作者：huanqing2010
链接：https://blog.csdn.net/qilei2010/article/details/104794969