"Before you walk the walk, you have to learn to talk the talk" Aspect An aspect is the cross-cutting functionality you are implementing. It is the aspect, or area, of your application you are modularizing. The most common (albeit sim- ple) example of an aspect is logging. Logging is something that is required throughout an …
一份代码的可重用性（reusability）较弱，这就表明这份代码的内聚性差，即同时揉合了服务提供者的代码和使用服务者的代码，由于服务提供者的代码没有独立成一个模块，其他的调用者只得把这些代码拷贝一份，跟调用者的代码耦合在一起，结果，代码变得重复了(Dupliacted Code)。 比如，直接在JSP里用SQL访问数据（数据的提供者）并展现数据（数据的使用者），这样的代码几乎没有任何可重用性；同时，别的JSP页面想展现类似的数据时，也只能拷一份相同的SQL再拷一份相同的JDBC语句。 较强的代码重复性，意味着较多的重复劳动；更可怕的是，当服务提供者的实现发生变更时，由于它的代码被复制了多份，结果导致每一处的拷贝都要做一下修改，非常浪费时间。而这，就叫做 可维护性 (maintainability)
1. Distrubuted objectes are said to help balance performance, but in fact they usually do not。 Besides, they often make the system harder to build or deploy 2. Remote interfaces has to be different from local ones in order to reduce calls. If you choose a middleware to make them transprent, which means you’d use …
Two issuses about concurrency that’re difficult to handle: 1. offline concurrency(transcations among several databases or serveral requests) 2. multi-thread concurrency in application server side Two basic ways of controlling concurrency 1. isolation 2. to make some data immutable Optimistic Lock： detect conflictions and then solve them。 The lock is only held …
优点和缺点是从《without EJB》第一章概括出来的，希望我没有曲解作者的意思： 优点： 1.仍是最好的的业务对象分布式架构。无状态session bean还是不错的。 2.消息Bean也不错。尤其是对金融系统来说 缺点：EJB乃至整个J2EE规范的缺点，可以用一句话来概括：花了80%的时间去处理那些20%的问题，得不偿失。典型的例子就是开发人员凭空想出一些不切实际的需求来捆住自己： 1.系统除了支持web客户端，还要支持swing 2.系统所用的数据库产品和应用服务器可能会改变 3.系统可能使用两个数据库 4.系统可能不用关系数据库作持久化，有可能用XML作数据源 我个人对Rod Johnson的以下看法持保留意见： 1.他说，在远程调用方面，web services是比EJB更好的选择。按我的经验，web services的配置复杂性非常吓人。 2.他还说，分布式对象方案 破还了OO原则，因为出于性能考虑，需要为远程方法定义比本地接口要粗糙的远程接口。这破坏了透明性。但我觉得，这种透明性本来就没要去追求。 a.进行分布式交互的两个对象，未必就应该是业务对象，完全可以是一些控制指令。这些控制信息专用于远程交互，不会和本地业务对象实现同一个接口 b.分布式对象之间交互时，本来就不会涉及多大的数据量，否则就会用文件来传递数据了 c.再考虑不使用分布式对象的机会成本。不用这种东西，就要用socket、web service或者其他中间件。后果是： I.配置文件多了 II.与配置文件的配套的设计文档、安装文档也多了 III.最头疼的是，要专门一个协议。比如定义一个报文，这个报文的这个字段代表什么，字段是什么类型，长度有多少等等。 A.这个工作量不小 B.以后如果增加了新的交互功能，要尽力保证新的报文会使所有报文集在解析时不会出现二义性（如维持上下文无关文法），比起可随意取名的、可随意重载、可随意覆盖的 对象方法 要麻烦多了
啥叫“可移植性”？可移植性就是当消费者对供应商的服务不太满意时，可以换用另一个供应商，并且不需要调整自己接受服务的方式。典型的例子有：JAVA程序 V.S 操作系统，应用程序 V.S. 数据库 观察这些例子，可以发现实现可移植性的关键是：存在着一个中间层适配器，将供应商的接口适配为消费者想要的服务。供应商变了，适配器也要换。把java程序从windows迁移到linux，就需要换用linux下的jvm；把数据库从sql server换成oracle，就需把jdbc驱动换成oracle的驱动；而对应用程序开发人员来说，常常需要考虑的是，当服务组件从EJB换成Web Services时，应用层的代码要怎么改？ 解决办法和上面一样，在一开始设计的时候就要在应用层和服务层之间设计一个适配器接口以适配服务组件的接口，当服务组件更换时，重新写一个类实现这个适配器接口就可以了，应用层代码本身不需要改动。 实现可移植性还有一个约束：消费者所需的服务必须是独立于任何供应商特性的。如果在应用层的数据库查询代码里用了“select top 10 ….from …”，那么这个系统就只能用在sql server上了
个人推荐 http://www.jdon.com 里面的文章！ 板桥里人(banq)是这个网站的掌门人，他对各种技术、模式的讲解非常易懂。
这一节介绍了三种模式：Domain Object, Transaction Script 和 Table Module。 对第一种模式还不是非常明白，以后慢慢体会
耗尽时，JDBC会报异常：Address already in use 起初我以为是因为WINDOWS XP对TCP连接数的限制，换了windows 2003，还是报这个错 后来我加上了连接池，在XP下测试，这个问题不在发生
35980.39