我们将以前面提到的文档中心服务为例来说明识别合适的组件的过程。为讨论方便起见,我们现在来列出文档中心服务的需求。文档中心将采用一个数据库来作为持久存储,对客户端授权,在内存中缓存文档。
组件的实践性定义
|
当我们谈论组件时,您考虑问题的角度应该是:我的服务需要操作哪些设施?Avalon相信将系统投影(cast)的概念。系统的开发者会面对一个组件的职责列表,组件则被称为它的角色(role)。
什么是角色?
|
角色的概念来自剧院。一部戏剧、音乐剧或电影片都会有一定数量的角色,由演员来扮演。尽管演员似乎从不短缺,角色的数量却是有限的。演出的脚本 定义了角色的功能或行为。如同剧院里发生的一样,脚本决定了您如何与组件交互。考虑系统中的不同角色,您会将组件的投影为角色,并与之对话。
一个角色是一类组件的契约。例如,我们的文档中心服务需要操作数据库。Avalon Excalibur定义了一个组件,符合"Data Source"脚色的需要。在Excalibur中有两个不同的组件,都能满足该角色的需要。 具体使用哪一个取决于服务所处的环境,但是它们都满足相同的契约。大量基于Avalon的系统对每个角色将只用到一个活动的组件。脚本就是工作接口:其它组件与之交互的接口。
在确定组件的接口时,必须有确定的契约并牢记在心。契约规定了组件的使用者必须提供什么,以及组件生产出什么。有时在契约中必须包括使用语义。一个例子是临时存储组件和持久存储组件之间的区别。当接口和协议定义好之后,您就可以致力于实现。
|
|
怎样算是一个好的候选组件?
|
在我们的文档中心服务中,我们已识别了四个可能的组件:DataSourceComponent (来自Excalibur)、 Cache、Repository、Guardian。您应该寻求那些很可能有多种实现的角色,与这些实现的交互可以无缝地进行。
通个这个例子,您会发现一些情况下您需要使用可替换的设施。大多数情况下,您只会用到该设施的一种实现,但您需要能独立地升级它而不影响到系统的其它部分。其它情况下,您需要根据环境的不同使用不同的实现。例如,Excaliber定义的"Data Source"通常会自己处理所有的JDBC连接池,但有时你可能希望利用Java 2 Enterprise Edition(J2EE)中提供的设施。Excalibur解决这个问题的办法是,一个"Data Source"组件直接管理JDBC连接和池,另一个组件使用Java's Naming and Directory Interface (JNDI) 来得到特定的连接。
|
怎样不算是一个好的组件?
|
习惯于使用JavaBeans的人喜欢把所有的东西都实现为一个JavaBean。这意味着从数据模型到事务处理的一切东西。如果您用这种方式来处理组件,您可能会得到一个过于复杂的系统。把组件视为一个服务或设施的模型,而不是数据的模型。您可以有从其它资源拉数据的组件,但数据还是应该保持为数据。在Avalon Excalibur中这种哲学的一个例子是连接(Connection)不是一个组件。
另一个例子是我们前面提到的Guardian组件。可能存在的争议是,Guardian所包含的逻辑与文档中心服务太相关,不能做为一个组件用在完全不同的服务中。尽管管理复杂性有多种方式,也有多种方式让它变得灵活,但有时为它付出额外的工作并不值得。在这种情况下,您必仔细权衡您的决定。如果一个潜在组件的逻辑将被一致地应用,那么将它作为一个组件可能是有意义的。在一个系统中可以有一个组件的多个实例,它们可以在运行时进行选择。如果潜在组件的逻辑只是根据另外一个组件来确定的,也许可以把这些逻辑放到另外的那个组件中去。通过Guardian组件和Repository组件的例子,我们可以辩称Guardian太专注于Repository,不是作为一个组件来实现的。
|
分解文档中心服务
|
我们将列出将要实现的组件,以及它们的角色、根本原因和来源(如果组件已经存在的话)。
DocumentRepository
|
DocumentRepository是整个服务的父组件。在Avalon中,服务实现为Block,Block是一个特定类型的组件。Block必须有一个工作接口,扩展了Service marker接口。Block接口也扩展了Avalon的Component接口。请注意,Block和Service是包含在Avalon Phoenix中的接口。最后,Service从技术上说仍是一种特定类型的Component。
DocumentRepository是我们从持久存储中取得Document对象的方法。它与服务中的其它组件交互,以提供安全性、功能性和速度。这个特定的DocumentRepository会与数据库连接,在内部使用数据库的逻辑来建造Document对象。
|
DataSourceComponent
|
DataSourceComponent由Avalon Excalibur提供。它是我们获得有效的JDBC连接对象的方式。
|
Cache
|
Cache是一个短期内存中的存储设施。DocumentRepository将用它来保存Document对象,并通过一个散列算法来引用。为了提高Cache组件的可重用性,存储的对象必须实现一个Cacheable接口。
|
Guardian
|
Guardian组件的作用是基于参与者管理许可。Guardian将从数据库中装入许可规则集。Guardian将使用标准Java安全模型,以保证对特定Document的访问。
|
|
小结
|
到目前为止,您应该对怎样才算是一个好组件有一些认识了。例子描述了在文档中心服务中的所有组件,简要介绍了它们将完成的工作。快速浏览这个列表,它体现了将设施实现为组件而不是数据的方法。到目前为止,你应该能够确定您的服务需要操作什么组件。
我们将描述Avalon的契约和接口,为我们实际编写组件打下基础。
Avalon Framework是整个Avalon项目的中心部分。如果您理解了框架所定义的契约和结构,您就能理解任何利用该框架的代码。请记住我们已讨论过的原理和模式。在本部分中,我们将详细解释角色的概念在实践中是怎样起作用的,组件的生命周期以及接口是如何工作的。
定义组件的角色
|
在Avalon中,所有的组件都扮演一个角色。原因是您通过角色来获取您的组件。在这个舞台上,我们唯一要考虑的是角色的签名。回顾一下第二部分,我们把组件定义为"一个工作接口和该工作接口的实现的组合"。工作接口就是角色。
创建角色的接口
|
下面您将看到一个接口的例子,以及一些最佳的实践和原因。
package org.apache.bizserver.docs;
public interface DocumentRepository extends Component
{
String ROLE = DocumentRepository.class.getName();
Document getDocument(Principal requestor, int refId);
}
|
最佳实践
|
-
包含一个名为"ROLE"的字符串,这是角色的正式名字。该名字与该工作接口的完全限定名称是一样的。这在今后我们需要得到一个组件的实例时会有帮助。
-
如果有可能,请扩展组件接口。这会使您在发布组件时变得更容易。如果您不负责控制该工作接口,那么这点对你无用。问题也不会太大,因为您在发布时总可以将其强制转换为Component 的实例。
-
做一件事并把它做好。组件的接口应该尽可能地简单。如果您的工作接口扩展了其它一些接口,就会把组件的契约给搞得难以理解。一个老的美国首字母缩写对这一点表述得很好:Keep It Simple, Stupid (KISS)。比自己更聪明(犯傻)并不难,我自己就干过几次。
-
只确定您需要的方法。客户程序应该不知道任何实现细节,太多的可替换方法只会带来不必要的复杂性。换言之,选择一种方式并坚持不变。
-
别让您的角色接口扩展任何生命周期或生存方式的接口。如果实现任何一个这样的类或接口,您就是在试图实现规范。这不是一个好模式,只会在将来带来调试和实现问题。
|
选择角色名称
|
在Avalon中,每个角色都有一个名称。它是您取得系统中其它组件引用的方式。Avalon开发团队已经概括了一些对角色命名的习惯方式。
命名习惯方式
|
-
工作接口的完整限定名通常就是角色名。例外情况列在本通用规则的下面。在这个例子里,我们理论上的组件名称应该是"org.apache.bizserver.docs.DocumentRepository"。这就是应该包含在您的接口的"ROLE"属性里的名字。
-
如果我们通过一个组件选择器得到了该组件的引用,我们通常使用从第一条规则推导出的角色名称,在末尾加上单词"Selector"。这条命名规则的结果将是"org.apache.bizserver.docs.DocumentRepositorySelector"。您可以通过DocumentRepository.ROLE + "Selector" 来得到这个名称。
-
如果我们有多个组件实现相同的工作接口,但用于不同目的,我们将分离角色。一个角色是组件在一个系统中的目的。每个角色名都将以最初的角色名开头,但表示角色目的的名字会以/${purpose} 的形式附在后面。例如,对DocumentRePository我们可以有如下的目的: PurchaseOrder(购买订单)和Bill(账单)。这两个角色可被分别表述为DocumentRepository.ROLE + "/PurchaseOrder" 和DocuementRepository.ROLE + "/Bill" 。
|
|
|
|
Framework接口概述
|
整个Avalon Framework可以被分成七个主要类别(根据API): Activity, Component, Configuration, Context, Logger, Parameters, Thread, and Miscellany。每一类(Miscellany除外)表示了一个考虑方向(concern area)。一个组件通常实现几个接口来标明它所关心的考虑方向。这使组件的容器能以一致的方式来管理每个组件。
Avalon接口的生命周期
|
当一个框架实现了多个接口以分开考虑组件的各个方面时,存在搞不清方法调用次序的潜在可能性。Avalon Framework意识到了这一点,因此我们开发了事件生命周期次序的协定。如果您的组件不实现相关的接口,就简单跳到下一个要处理的事件。因为存在一个正确的创建和准备组件的方法,您可以在接收到事件时设置好组件。
组件的生命周期被分成三个阶段:初始化阶段、活动服务阶段和销毁阶段。因为这些阶段是依次发生的,我们将依次讨论这些事件。另个,因为Java语言的原因,Construction和Finalization的行为是隐含进行的,所以跳过不谈。我们将列出方法名和所需的接口。在每个阶段中,会有一些由方法名标识的步骤。如果组件扩展了括号中指定的接口,这些步骤会依次执行。
初始化阶段
|
以下的步骤依次发生,在组件生存期中只发生一次。
-
enableLogging() [LogEnabled ]
-
contextualize() [Contextualizable ]
-
compose() [Composable ]
-
configure() [Configurable ] orparameterize() [Parameterizable ]
-
initialize() [Initializable ]
-
start() [Startable ]
|
活动服务阶段
|
以下的步骤依次发生,但在组件的生存期中可能发生多次。请注意,如果您选择不实现Suspendable接口,那么您的组件有责任在执行任何re开头的步骤时保证正确的功能。
-
suspend() [Suspendable ]
-
recontextualize() [Recontextualizable ]
-
recompose() [Recomposable ]
-
reconfigure() [Reconfigurable ]
-
resume() [Suspendable ]
|
销毁阶段
|
以下的步骤依次发生,在组件生存期中只发生一次。
-
stop() [Startable ]
-
dispose() [Disposable ]
|
|
Avalon Framework契约
|
在本部分中,我们将按字母次序介绍所有内容,除了最重要的部分:Component,我们把它放在最前面。
当我使用"容器"或"容纳"来描述组件时,我是有特殊含义的。我是指那些已经由父组件实例化并控制的子组件。我不是指通过ComponentManager或ComponentSelector得到的组件。更进一步,容器组件所接收到的一些Avalon步骤执行命令必须传播到它的所有子组件,只要这些子组件实现了相应的接口。特定的接口是指Initializable、Startable、Suspendable和Disposable。 这样安排契约的原因是这些接口有特别的执行约定。
Component
|
这是Avalon Framework的核心。这个考虑方向所定义的接口会抛出ComponentException异常。
Component
|
每个Avalon组件必须 实现Component接口。Component Manager和Component Selector只处理Component。这个接口没有定义方法。它只是作为一个标记性接口。
任何组件必须使用不带参数的缺省构造方法。所有配置都是通过Configurable 或Parameterizable 接口来完成的。
|
Composable
|
一个用到其它组件的组件需要实现这个接口。这个接口只有一个方法compose() ,该方法带唯一一个ComponentManager 类型的参数。
围绕该接口的契约是:在组件的生存期中,compose() 被调用一次且仅被调用一次。
这个接口与其它任何定义了方法的接口一样,都使用的是反向控制模式。它由组件的容器调用,只有该组件需要的那些组件会出现在ComponentManager 中。
|
Recomposable
|
在少数的情况下,组件会需要一个新的ComponentManager 和新的组件-角色映射关系。在这些情况下,需要实现recomposable接口。它的方法也与Composable的方法名称不一样,是recompose() 。
围绕该接口的契约是:recompose() 方法可以被调用任意多次,但不能在组件完全初始化好之前调用。当该方法被调用时,组件必须以一种安全和一致的方式更新它自己。通常这意味着组件进行的所有操作必需在更新之间停下来,在更新之后再继续。
|
|
Activity
|
这组接口与组件生命周期的契约相关。如果在这组接口调用过程中出现了错误,您可以抛出一个通用的Exception。
Disposable
|
如果一个组件需要以一种结构化的方式知道自己不在需要了,它可以使用Disposable 接口。一旦一个组件被释放掉,它就不能再用了。实际上,它就等待着被垃圾收集。该接口只有一个方法dispose() ,该方法没有参数。
围绕该接口的契约是:dispose() 方法被调用一次,也是组件生存期中调用的最后一个方法。同时也表明该组件将不再使用,必须释放该组件所占用的资源。
|
Initializable
|
任何组件如果需要创建其它组件,或需要执行初始化操作从其它的初始化步骤中获取信息,就要用到Initializable 接口。该接口只有一个initialize() 方法,该方法没有参数。
围绕该接口的契约是:initialize() 方法被调用一次,它是初始化过程中最后被调用的方法。同时也表明,该组件已处于活动状态,可以被系统中其它组件使用。
|
Startable
|
任何组件如果在其生存期中持续运行,就要用到Startable 接口。该接口定义了两个方法:start() 和stop() 。这两个方法都没有参数。
围绕该接口的契约是:start() 方法在组件完全初始化之后被调用一次。stop() 方法在组件被销毁之前被调用一次。它们都不会被调用两次。start() 总在stop() 之前被调用。对该接口的实现要求安全地执行start() 和stop() 方法 (不像Thread.stop() 方法) 并且不会导致系统不稳定。
|
Suspendable
|
任何组件如果在其生命期中允许自己被挂起,就要用到Suspendable 接口。虽然它通常总是和Startable 接口在一起使用,但这不是必需的。该接口有两个方法:suspend() 和resume() 。这两个方法都没有参数。
围绕该接口的契约是:suspend() and resume() 可以被调用任意多次,但在组件初始化并启动之前,或在组件停止并销毁之后不能调用。 对已挂起的组件调用suspend() 方法,或对已在运行的组件调用resume() 将没有任何效果。
|
|
Configuration
|
这一组接口描述了配置方面的考虑。如果发生任何问题,例如没有所需的Configuration 元素,那么可以抛出ConfigurationException 异常。
Configurable
|
那些需要根据配置确定其行为的组件必须实现这个接口以得到Configuration 对象的实例。该接口有一个configure() 方法,只有一个Configuration 类型的参数。
围绕该接口的契约是:configure() 方法在组件的生存期中被调用一次。传入的Configuration 对象一定不能为null。
|
Configuration
|
Configuration 对象是一由配置元素组成的树,配置元素拥有一些属性。在某种程度上,您可以将配置对象看作一个大大简化的DOM。Configuration类的方法太多,不便在本文中介绍,请看JavaDoc文档。您可以从Configuration 对象中取得String , int , long , float , or boolean 类型的值,如果配置没有将提供缺省值。对属性也是一样的。您也可以取得子Configuration 对象。
契约规定,具有值的Configuration 对象不应有任何子对象,对子对象也是这样的。
你会注意到你无法得到父Configuration 对象。设计就是这样做的。为了减少配置系统的复杂性,大多数情况下容器会将子配置对象传给子组件。子组件不应该有权访问父配置的值。这种方式可能带来一些不便,但是Avalon团队在需要做折衷的情况下总是选择把安全性放在第一。
|
Reconfigurable
|
实现该接口的组件行为与Recomposable 组件非常相似。它只有一个reconfigure() 方法。这样的设计决策是为了降低Re开头的那些接口的学习难度。Reconfigurable 对Configurable 来说就象Recomposable 对Composable 一样。
|
|
Context
|
Avalon中Context 的概念起源于需要一种机制来实现从容器向组件传递简单对象。确切的协议和名字绑定有意没有定义,以便给开者提供最大的灵活性。围绕Context 对象的使用的契约由您在您的系统中定义,尽管机制是一样的。
Context
|
Context 接口只定义了一个get() 方法。它有一个Object 类型的参数,返回以参数对象为键值的一个对象。Context 对象由容器组装,然后传递给子组件,子组件对Context 只有读权限。
除了Context 对子组件总是只读的之外,没有别的契约。如果您扩展了Avalon的Context ,请注意遵守该契约。它是反向控制模式的一部分,也是安全性设计的一部分。另外,在Contex中传一个引用 给容器的做法也是不好的,原因和Context应该是只读的相同。
|
Contextualizable
|
希望接收来自于容器的Context 对象的组件应该实现该接口。它有一个名为contextualize() 的方法,参数是容器组装的Context 对象。
围绕这个接口的契约是:contextualize() 在组件的生存期中被调用一次,在LogEnabled 之后,但在其它初始化方法之前。
|
Recontextualizable
|
实现该接口的组件行为与Recomposable 组件非常相似。它只有一个名为recontextualize() 的方法。这样的设计决策是为了降低Re开头的接口的学习难度。Recontextualizable 对Contextualizable 就如同Recomposable 对Composable 。
|
Resolvable
|
Resolvable接口用于标识一些对象,这些对象在某些特定上下文中需要分离(need to be resolved)。一个例子是:某对象被多个Context 对象共享,并根据特定的Context 改变其自身的行为。在对象被返回之前Context 会调用 resolve() 方法。
|
|
Logger
|
每个系统都需要具备对事件记录日志的能力。Avalon内部使用了它的LogKit项目。尽管LogKit有一些方法可以静态地访问一个Logger实例,但Framework希望使用反向控制模式。
LogEnabled
|
每个需要Logger实例的组件都要实现该接口。该接口有一个名为enableLogging() 的方法,将Avalon Framework的Logger 实例传递给组件。
围绕该接口的契约是:在组件的生存期中只调用一次,在任何其它初始化步骤之前。
|
Logger
|
Logger 接口用于对不同的日志库进行抽象。它提供一个唯一的客户端API。Avalon Framework提供了三个实现该接口的封装类:针对LogKit的LogKitLogger 、针对Log4J的Log4jLogger 、和针对JDK1.4日志机制的Jdk14Logger 。
|
|
Parameters
|
Avalon认识到Configuration对象层次结构在许多场合下太重量级了。因此,我们提出了一个Parameters 对象来提供Configuration 对象的替代,使用名称-值对的方法。
Parameterizable
|
任何希望用Parameters 来取代Configuration 对象的组件将实现该接口。Parameterizable 只有一个名为parameterize() 的方法,with the parameter being the Parameters object.
围绕该接口的契约是:它在组件的生存期中被调用一次。该接口与Configurable 接口不兼容。
|
Parameters
|
Parameters 对象提供了一种通过一个String 类型的名字取得值的机制。如果值不存在,有方便的方法允许你使用缺省值,也可以得到Configurable 接口中任何相同格式的值。
尽管Parameters 对象与java.util.Property 对象之间存在相似性,但它们还是存在重要的语义差别。首先,Parameters 是只读的。 其次,Parameters 总是很容易从Configuration 对象中导出。最后,Parameters 对象是从XML 片断中导出的,看上去是这样的:
<parameter name="param-name" value="param-value"/>
|
|
|
Thread
|
线程标记器(marker)用于根据组件的使用发出容器的基本语义信息信号。它们考虑到线程安全,对组件的实现提供标记。最佳实践是把这些接口的实现推迟到最终实现该组件的类。这样做避免了一些复杂情况,有时某个组件被标记为ThreadSafe ,但从它派生出来的组件实现去不是线程安全的。这个包中定义的接口组成了我们称之为LifeStyle系列接口的一部分。 另一个LifeStyle接口是Excalibur包的一部分(所以它是这个核心接口集的扩展),Poolable 定义在Excalibur的池实现中。
SingleThreaded
|
围绕SingleThreaded 组件的契约是实现该接口的组件不允许被多个线程同时访问。每个线程需要有该组件的自己的实例。另一种做法是使用一个组件池,而不是每次请求该组件时都创建一个新的实例。为了使用池,您需要实现Avalon Excalibur的Poolable 接口,而不是这个接口。
|
ThreadSafe
|
围绕ThreadSafe 组件的契约是:不管有多少线程同时访问该组件,它们的接口和实现都能够正常工作。尽管这是一个有弹性的设计目标,但有时候由您所使用的技术,它就是不能实现。实现了这个接口的组件通常在系统中只有一个实例,其它的组件将使用该实例。
|
|
其它
|
在Avalon Framework的根包(root package)中的这些类和接口包括了Exception层次和一些通用工具类。但是有一个类值得一提。
Version
|
JavaTM 版本技术是在jar包中的manifest文件中有一项指定。问题是,当jar被解包后您就失去了版本信息,并且版本信息放在易于修改的文本文件中。当您把这些问题与一个较陡的学习曲线放在一起考虑时,检查组件和接口的版本就比较困难。
Avalon开发小组设计了Version对象,让您可以容易地检查版本和比较版本。您可以在您的组件中实现Version 对象,测试合适的组件或最低版本号也会更容易。
|
|
|
我们将向你展示怎样使用Avalon Framework和Avalon Excalibur来实现您的服务应用程序。我们将向您展示Avalon有多么易于使用。
在您完成分析以后,您需要创建组成您的系统的组件与服务。如果Avalon只是描述了一些您可以使用的编程习惯,那么它的用处就不大。但即使是这样,运用这些编程习惯和模式也会对理解整个系统有所帮助。Avalon Excalibur提供了一些有用的组件和工具,您可以在您自己的系统中使用它们,这可以让您的日子过得更轻松些。作为我们的演示,我们把定义一个组件从一个repository中取出一个文档实现的全过程走一遍。如果您还记得我们关于理论上的业务服务器的讨论,我们曾确定将这个组件作为一个服务。在实际情况中,一个组件就是一个服务的情况是很多的。
实现该组件
|
这里,我们定义如何实现我们的组件。我们会把实现前面提到的DocumentRepository组件的过程整个走一遍。我们需要弄清楚的第一件事就是我们的组件所关注的领域。然后我们需要弄清楚怎样创建和管理我们的组件。
选择关注的领域
|
我们在前面已经为DocumentRepository组件定义了角色和接口,我们已准备好来创建实现。因为DocumentRepository的接口只定义了一个方法,我们有机会创建一个线程安全的组件。这是最受欢迎的一类组件,因为它允许只消耗最少的资源。为了让我们的实现是线程安全的,我们确实需要仔细考虑如何实现该组件。既然我们所有的文档都存放在数据库中,而且我们希望使用一个外部的Guardian 组件,我们将需要访问其它组件。作为一个负责任的开发者,我们希望对有助于调试组件的信息记录日志,追踪内部发生了什么。Avalon框架的优美之处在于,您只需实现您需要的接口,可以忽略不需要的那些。这就是Separation of Concerns带来的好处。当您发现需要考虑一个新的方面时,您只需实现相关的接口就为组件加入了新的功能。 对于使用您的组件的部分来说,不需要作任何改动。
既然线程安全是一个设计目标,我们就已经知道了需要实现ThreadSafe接口。DocumentRepository接口只有一个方法,所以对于该组件的工作界面的使用是满足该需求的。而且我们知道,Component在完全初始化之前是不会被使用的,在它被销毁之后也不会被使用。
为了完成设计,我们需要实现一些隐含的接口。我们希望解决方案足够安全,让我们可能显式地得知组件是否已经完全初始化。为了达到这个目标,我们将实现Initializable和Disposable接口。由于关于环境方面的信息可能发生改变,或者可能需要能定制,我们需要让DocumentRepository实现Configurable接口,Avalon提供的取得所需组件的实例的方法是利用一个ComponentManager。我们需要实现Composable 接口来从ComponentManager取得组件实例。
因为DocumentRepository访问数据库中的文档,我们需要做一个决定。我们是要利用Avalon Excalibur DataSourceComponent呢,还是希望自己实现数据库连接管理的代码。在本文中,我们将利用DataSourceComponent。
此时,我们的类骨架看起来是这样的:
public class DatabaseDocumentRepository
extends AbstractLogEnabled
implements DocumentRepository , Configurable, Composable, Initializable,
Disposable, Component, ThreadSafe
{
private boolean initialized = false;
private boolean disposed = false;
private ComponentManager manager = null;
private String dbResource = null;
/**
* Constructor. All Components need a public no argument constructor
* to be a legal Component.
*/
public DatabaseDocumentRepository() {}
/**
* Configuration. Notice that I check to see if the Component has
* already been configured? This is done to enforce the policy of
* only calling Configure once.
*/
public final void configure(Configuration conf)
throws ConfigurationException
{
if (initialized || disposed)
{
throw new IllegalStateException ("Illegal call");
}
if (null == this.dbResource)
{
this.dbResource = conf.getChild("dbpool").getValue();
getLogger().debug("Using database pool: " + this.dbResource);
// Notice the getLogger()? This is from AbstractLogEnabled
// which I extend for just about all my components.
}
}
/**
* Composition. Notice that I check to see if the Component has
* already been initialized or disposed? This is done to enforce
* the policy of proper lifecycle management.
*/
public final void compose(ComponentManager cmanager)
throws ComponentException
{
if (initialized || disposed)
{
throw new IllegalStateException ("Illegal call");
}
if (null == this.manager)
{
this.manager = cmanager;
}
}
public final void initialize()
throws Exception
{
if (null == this.manager)
{
throw new IllegalStateException("Not Composed");
}
if (null == this.dbResource)
{
throw new IllegalStateException("Not Configured");
}
if (disposed)
{
throw new IllegalStateException("Already disposed");
}
this.initialized = true;
}
public final void dispose()
{
this.disposed = true;
this.manager = null;
this.dbResource = null;
}
public final Document getDocument(Principal requestor, int refId)
{
if (!initialized || disposed)
{
throw new IllegalStateException("Illegal call");
}
// TODO: FILL IN LOGIC
}
}
|
您在以上代码中可以发现一些结构模式。当您在设计时考虑到安全性时,您应该在组件中显式地强制实现每个契约。安全强度总是取决于最弱的那一环。只有当您肯定一个组件已经完全初始化以后才能使用它,在它被销毁后,就再也不要用它了。我在这里放上这些逻辑是因为您在编写自己的类时也会采用相同的方式。
|
组件实例化和管理组件
|
为了让您能理解容器/组件的关系是如何工作的,我们将先讨论管理组件的手工方式。接下来我们将讨论Avalon's Excalibur组件体系结构是如何为您隐藏复杂性的。您仍会发现有些时候宁愿自己管理组件。但在大多数时候,Excalibur的强大能力和灵活性就能满足您的需要。
The Manual Method
|
所有Avalon的组件都是在某处创建的。创建该组件的代码就是该组件的容器。容器负责管理组件从构造到析构的生命周期。容器可以有一个静态的"main"方法,让它能从命令行调用,或者它也可以是另一个容器。在您设计容器时,请记得反向控制的模式。信息和方法调用将只从容器流向组件。
颠覆控制(Subversion of Control)
|
颠覆控制是反向控制的反模式。当您把容器的引用传递给组件时,就实现了颠覆控制。当您让一个组件管理它自己的生命周期时,也属于这种情况。以这种方式操作的代码应该被视为是有缺陷的。当您将容器/组件关系混在一起时,它们的交互将使系统难于调试,并难以审计安全性。
|
为了管理子组件,您需要在它们整个生命同期都保存对它们的引用。在容器和其它组件可以使用该子组件之前,它必须完成初始化。对我们的DocumentRepository来说,代码看起来可能象下面的样子:
class ContainerComponent implements Component, Initializable, Disposable
{
DocumentRepository docs = new DatabaseDocumentRepository();
GuardianComponent guard = new DocumentGuardianComponent();
DefaultComponentManager manager = new DefaultComponentManager();
public void initialize()
throws Exception
{
Logger docLogger = new LogKitLogger( Hierarchy.defaultHierarchy()
.getLoggerFor( "document" ) );
this.docs.enableLogging( docLogger.childLogger( "repository" ) );
this.guard.enableLogging( docLogger.childLogger( "security" ) );
DefaultConfiguration pool = new DefaultConfiguration("dbpool");
pool.setValue("main-pool");
DefaultConfiguration conf = new DefaultConfiguration("");
conf.addChild(pool);
this.manager.addComponent( DocumentRepository.ROLE, this.docs );
this.manager.addComponent( GuardianComponent.ROLE, this.guard );
this.docs.compose( this.manager );
this.guard.compose( this.manager );
this.docs.configure(conf);
this.guard.initialize();
this.docs.initialize();
}
public void dispose()
{
this.docs.dispose();
this.guard.dispose();
}
}
|
为了简洁,我把显式地检查从以上代码中移去了。您可以看到手工地创建和管理组件是很细节化的工作。如果您忘记做了组件生命周期中的某一步,您就会发现bug。这也需要对您正在实例化的组件有一些深入的了解。另一种做法是给上面的ContainerComponent 增加一些方法,来动态地处理组件的初始化。
|
Automated Autonomy
|
开发者的本性是懒惰的,所以他们会花时间写一个特别的ComponentManager 作为系统中所有组件的容器。通过这种方式,他们就不必深入地了解系统中所有组件的接口。这可能是个令人沮丧的任务。Avalon的开发者已经创建了这样一个怪兽。Avalon Excalibur的组件体系结构中包括了一个ComponentManager,通过XML的配置文件来控制。
当您把管理组件的责任交给Excalibur的ComponentManager时,存在一个折衷。您放弃了对CompomentManager中包含哪些组件的精细控制。但是,如果您的系统相当大,您会发现手工控制是一项令人沮丧的工作。在这种情况下,出于对系统稳定性的考虑,最好由一个地方集中式地管理系统中所有的组件。
既然可以与Excalibur的组件体系结构有不同中层次的集成程度,我们将从最低层次开始。Excalibur有一组ComponentHandler对象,它们作为每类组件独立的容器。它们管理您的组件的整个生命周期。让我们引入生存方式(lifestyle)接口的概念。一个生存方式接口描述了系统是怎样对待一个组件的。既然组件的生存方式对系统运行会产生影响,我们就需要讨论当前的一些生存方式所暗含的意义:
-
org.apache.avalon.framework.thread.SingleThreaded
-
org.apache.avalon.framework.thread.Threadsafe
-
org.apache.avalon.excalibur.pool.Poolable
ComponentHandler接口处理起来是很简单的。你通过Java类、Configuration对象、ComponentManager对象、Context对象和RoleManager对象来初始化构造方法。 如果您知道您的组件将不需要上述的某一项,您可以在它的位置上传一个null。 在这之后,当您需要对该组件的引用时,您就调用"get"方法。当您用完之后,您调用"put"方法将组件归还给ComponentHandler。 以下的代码便于我们理解这一点。
class ContainerComponent implements Component, Initializable, Disposable
{
ComponentHandler docs = null;
ComponentHandler guard = null;
DefaultComponentManager manager = new DefaultComponentManager();
public void initialize()
throws Exception
{
DefaultConfiguration pool = new DefaultConfiguration("dbpool");
pool.setValue("main-pool");
DefaultConfiguration conf = new DefaultConfiguration("");
conf.addChild(pool);
this.docs.configure(conf);
this.docs = ComponentHandler.getComponentHandler(
DatabaseDocumentRepository.class,
conf, this.manager, null, null);
this.guard = ComponentHandler.getComponentHandler(
DocumentGuardianComponent.class,
null, this.manager, null, null);
Logger docLogger = new LogKitLogger( Hierarchy.defaultHierarchy()
.getLoggerFor( "document" ) );
this.docs.enableLogging( docLogger.childLogger( "repository" ) );
this.guard.enableLogging( docLogger.childLogger( "security" ) );
this.manager.addComponent(DocumentRepository.ROLE, this.docs);
this.manager.addComponent(GuardianComponent.ROLE, this.guard);
this.guard.initialize();
this.docs.initialize();
}
public void dispose()
{
this.docs.dispose();
this.guard.dispose();
}
}
|
这里,我们只少写了几行代码。我们还是手工地创建了Configuration对象,还是设置了Logger,还是不得不对ComponentHandler对象进行初始化和销毁。 这里我们所做的只是防止受到接口变化的影响。您会发现用这种方式对代码有好处。Excalibur所做的更进了一步。大多数复杂的系统都有一些配置文件。它们允许管理员调整关键的配置信息。 Excalibur可以用以下的格式读取配置文件,并从中创建系统的组件。
<my-system>
<component
role="org.apache.avalon.excalibur.datasource.DataSourceComponentSelector"
class="org.apache.avalon.excalibur.component.ExcaliburComponentSelector">
<component-instance name="documents"
class="org.apache.avalon.excalibur.datasource.JdbcDataSource">
<pool-controller min="5" max="10"/>
<auto-commit>false</auto-commit>
<driver>org.gjt.mm.mysql.Driver</driver>
<dburl>jdbc:mysql:localhost/mydb</dburl>
<user>test</user>
<password>test</password>
</component-instance>
<component-instance name="security"
class="org.apache.avalon.excalibur.datasource.JdbcDataSource">
<pool-controller min="5" max="10"/>
<auto-commit>false</auto-commit>
<driver>org.gjt.mm.mysql.Driver</driver>
<dburl>jdbc:mysql:localhost/myotherdb</dburl>
<user>test</user>
<password>test</password>
</component-instance>
</component>
<component
role="org.apache.bizserver.docs.DocumentRepository"
class="org.apache.bizserver.docs.DatabaseDocumentRepository">
<dbpool>documents</dbpool>
</component>
<component
role="org.apache.bizserver.docs.GuardianComponent"
class="org.apache.bizserver.docs.DocumentGuardianComponent">
<dbpool>security</dbpool>
<policy file="/home/system/document.policy"/>
</component>
</my-system>
|
根元素可以由您任意指定。 您会注意到我们已经定义了一些组件。 我们有了熟悉的DocumentRepository类和GuardianComponent类,以及一些Excalibur DataSourceComponent类。 而且,现在我们对Guardian组件有了一些特定的配置信息。 为了把这些系统读入您的系统,Avalon框架为您提供了一些方便:
DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder();
Configuration systemConf = builder.buildFromFile("/path/to/file.xconf");
|
这确实对我们前面手工构建配置元素的代码起到了简化作用,而且它限制了我们在编程时需要明确了解的信息。 让我们再看一眼Container类,看看是否真的省了一些事。记住我们指定了5个组件( ComponentSelector算作是一个组件), 以及每个组件的配置信息。
class ContainerComponent implements Component, Initializable, Disposable {
ExcaliburComponentManager manager = new ExcaliburComponentManager();
public void initialize()
throws Exception
{
DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder();
Configuration sysConfig = builder.buildFromFile("./conf/system.xconf");
this.manager.setLogger( Hierarchy.getDefaultHierarchy()
.getLoggerFor("document") );
this.manager.contextualize( new DefaultContext() );
this.manager.configure( sysConfig );
this.manager.initialize();
}
public void dispose()
{
this.manager.dispose();
}
}
|
难道不令人惊奇?我们对数量超过两倍的组件进行了初始化,而代码量减少了一倍多(6行代码,而不是13行)。 这个配置文件有一个缺点,看起来有点疯狂,但它将需要写的代码数量降到了最低。
在ExcaliburComponentManager的背后发生了很多的活动。 对配置文件中的每个"component"元素,Excalibur为每个类的条目(entry)创建了一个ComponentHandler,并建立起与角色(role)的对应关系。 "component"元素和它的所有子元素是对组件的配置。当组件是一个ExcaliburComponentSelector时, Excalibur会读入每个"component-instance"元素并执行和前面同类型的操作,这次是与hint entry建立对应关系。
让配置文件好看一些
|
我们可以使用别名来改变配置文件的外观。Excalibur使用一个RoleManager为配置系统提供别名。RoleManager可以是您专门创建的一个类,也可以使用DefaultRoleManager并传入一个Configuration对象。 如果我使用DefaultRoleManager,我将把角色配置文件和系统的其它部分藏在jar文件中。这是因为角色配置文件将只由开发者改动。 下面是RoleManager接口:
interface RoleManager
{
String getRoleForName( String shorthandName );
String getDefaultClassNameForRole( String role );
String getDefaultClassNameForHint( String hint, String shorthand );
}
|
让我们来看一下Excalibur是如何使用我们的框架中的RoleManager的。首先,Excalibur循环读入根元素的所有子元素。 这包括了所有的"component"元素,但这次Excalibur并不识别元素的名称,它询问RoleManager 对这个组件我们将使用什么角色。如果RoleManager返回null, 那么该元素和它所有的子元素都被忽略。接下来, Excalibur 从角色名称中导出类名。最后的方法是动态地将类名与ComponentSelector的子类型对应起来。
Excalibur提供了一个RoleManager的缺省实现,它使用一个XML配置文件。标记相当简单,它把所有您不希望管理员看到的附加信息都隐藏起来的。
<role-list>
<role
name="org.apache.avalon.excalibur.datasource.DataSourceComponentSelector"
shorthand="datasources"
default-class="org.apache.avalon.excalibur.component.ExcaliburComponentSelector">
<hint shorthand="jdbc"
class="org.apache.avalon.excalibur.datasource.JdbcDataSourceComponent"/>
<hint shorthand="j2ee"
class="org.apache.avalon.excalibur.datasource.J2eeDataSourceComponent"/>
</role>
<role
name="org.apache.bizserver.docs.DocumentRepository"
shorthand="repository"
default-class="org.apache.bizserver.docs.DatabaseDocumentRepository"/>
<role
name="org.apache.bizserver.docs.GuardianComponent"
shorthand="guardian"
default-class="org.apache.bizserver.docs.DocumentGuardianComponent"/>
</role-list>
|
为了使用RoleManager,您需要改变容器类中的"初始化"方法。您将使用配置构造器(configuration builder)通过这个文件来构造一个Configuration树。 请记住,如果您打算使用一个RoleManager,您必须在调用"configure"方法之前调用"setRoleManager"方法。 为了展示您如何从类装入器中取得这个XML文件,我将在下面展示该技巧:
DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder();
Configuration sysConfig = builder.buildFromFile("./conf/system.xconf");
Configuration roleConfig = builder.build(
this.getClass().getClassLoader()
.getResourceAsStream("/org/apache/bizserver/docs/document.roles"));
DefaultRoleManager roles = new DefaultRoleManager();
roles.enableLogging(Hierarchy.getDefaultHierarchy().getLoggerFor("document.roles"));
roles.configure(roleConfig);
this.manager.setLogger( Hierarchy.getDefaultHierarchy()
.getLoggerFor("document") );
this.manager.contextualize( new DefaultContext() );
this.manager.setRoleManager( roles );
this.manager.configure( sysConfig );
this.manager.initialize();
|
既然我们增加了6行代码,就要看一下它带来了什么好处。 我们最终的配置文件可以这样写:
<my-system>
<datasources>
<jdbc name="documents">
<pool-controller min="5" max="10"/>
<auto-commit>false</auto-commit>
<driver>org.gjt.mm.mysql.Driver</driver>
<dburl>jdbc:mysql:localhost/mydb</dburl>
<user>test</user>
<password>test</password>
</jdbc>
<jdbc name="security">
<pool-controller min="5" max="10"/>
<auto-commit>false</auto-commit>
<driver>org.gjt.mm.mysql.Driver</driver>
<dburl>jdbc:mysql:localhost/myotherdb</dburl>
<user>test</user>
<password>test</password>
</jdbc>
</datasources>
<repository>
<dbpool>documents</dbpool>
</repository>
<guardian>
<dbpool>security</dbpool>
<policy file="/home/system/document.policy"/>
</guardian>
</my-system>
|
正如您所看到的那样,与前面的文件相比,这个文件的可读性要强很多。 现在我们可以为系统增加任意数目的组件,而不需要写更多的代码来支持它们。
|
|
|
|
使用该组件
|
现在我们已经创建了我们的组件,我们将使用它们。不管组件是如何被初始化和管理的,您访问组件的方法都是一样的。 您必须实现Composable接口,这样才能从ComponentManager得到一个引用。 ComponentManager保存着所有您需要的组件的引用。为了讨论方便起见,我们将假定我们得到的ComponentManager 是按照前一节的最终的配置文件来配置的。 这就是说我们有一个Repository, 一个Guardian, 和两个DataSources。
使用组件管理基础结构的原则
|
组件管理基础结构要求您释放您得到引用的组件。这个限制的原因是为了能正确地管理组件资源。ComponentManager的设计考虑到您对特定的角色有不同类型的组件。 ComponentSelector的另一个独特的方面是它也被设计为一个组件。这使我们可以从一个ComponentManager取得一个ComponentSelector。
有两种合法的方式来处理对外部组件的引用。您可以在初始化过程中得到引用,在销毁时释放它们。 您也可以把处理组件的代码放在try/catch/finally语句块中。两种方法各有优缺点。
Initialization and Disposal Approach
|
class MyClass implements Component, Composable, Disposable
{
ComponentManager manager;
Guardian myGuard;
/**
* Obtain a reference to a guard and keep the reference to
* the ComponentManager.
*/
public void compose(ComponentManager manager)
throws ComponentException
{
if (this.manager == null)
{
this.manager = manager;
myGuard = (Guardian) this.manager.lookup(Guardian.ROLE);
}
}
/**
* This is the method that uses the Guardian.
*/
public void myMethod()
throws SecurityException
{
this.myGuard.checkPermission(new BasicPermission("test"));
}
/**
* Get rid of our references
*/
public void dispose()
{
this.manager.release(this.myGuard);
this.myGuard = null;
this.manager = null;
}
}
|
从示例代码中您可以看到,照这样做很容易。当该对象第一次接收到ComponentManager时,它取得了一个Guardian组件的引用。 如果您可以保证Guardian组件是线程安全的(实现了ThreadSafe接口),那么就只需要做这些事。 不幸的是,从长远来看,您不能保证这一点。为了能正确地管理资源,在用完组件之后,我们必须释放对组件的引用。 这就是为什么我们保持一个对ComponentManager的引用的原因。
这种方式的主要不利之处在于处理组件池中的组件时。对组件的引用维系着该组件的生命。 如果该对象的生存期很短,这可能不是个问题;但是如果该对象是一个由Excalibur组件管理体系结构所管理的组件,只要有对它的引用,它的生存期就会继续。这意味着我们实际上把组件池变成了一个组件工厂。
这种方式的主要好处是,得到和释放组件的代码很清楚。 您不必去理解异常处理的代码。
另一个细微差别是,您把Guardian的存在与初始化这个对象的能力捆绑在了一起。 一旦在一个对象的初始化阶段抛出一个异常, 你就只好认为该对象不是一个有效的对象。有时您希望当要求的组件不存在时就让程序失败掉,那么这就不是问题。 在设计组件时,您确实需要注意到这一层隐含的意思。
|
Exception Handling Approach
|
class MyClass implements Composable, Disposable
{
ComponentManager manager;
/**
* Obtain a reference to a guard and keep the reference to
* the ComponentManager.
*/
public void compose(ComponentManager manager)
throws ComponentException
{
if (this.manager == null)
{
this.manager = manager;
}
}
/**
* This is the method that gets the Guardian.
*/
public void myMethod()
throws SecurityException
{
Guardian myGuard = null;
try
{
myGuard = (Guardian) this.manager.lookup(Guardian.ROLE);
this.criticalSection(myGuard);
}
catch (ComponentException ce)
{
throw new SecurityException(ce.getMessage());
}
catch (SecurityException se)
{
throw se;
}
finally
{
if (myGuard != null)
{
this.manager.release(myGuard);
}
}
}
/**
* Perform critical part of code.
*/
public void criticalSection(Guardian myGuard)
throws SecurityException
{
myGuard.checkPermission(new BasicPermission("test"));
}
}
|
如您所见,这段代码有些复杂。为了能理解它,您需要理解异常处理。 这可能不是问题,因为绝大多数Java开发者都知道如何处理异常。 用这种方式,您不需要太担心组件的生存方式问题, 因为一旦我们不需要它时,就释放了它。
这种方式的主要不利之处是增加了异常处理代码,因为较为复杂。 为了能将复杂度降到最低,让代码更易于维护,我们把工作代码提取出来,放在另一个方法中。 请记住在try语句块中,我们想得到多少组件的引用,就可以得到多少。
这种方式的主要好处是您可以更有效率地管理组件引用。 同样,如果您使用的是ThreadSafe组件,就没有实质差别,但如果您使用的是组件池里的组件时,就有差别了。 在每次您使用一个组件,取得一个新的引用时,有一点轻微的开销,但是被迫创建一个新的组件实例的可能性大大降低。
像初始化和销毁的方式一样,您也必须了解一个微妙的差别。 如果管理器找不到组件,异常处理的方式不会让程序在初始化时失败掉。 如前所述,这并不是完全没好处的。 很多时候,您希望某个组件存在,但是如果期望的组件不存在,程序也不需要失败掉。
|
|
从ComponentSelector取得一个组件
|
对于大多数操作,您只需要使用ComponentManager。 既然我们决定我们需要DataSourceComponent的多个实例, 我们就需要知道如何得到我们想要的那个实例。 ComponentSelector比ComponentManagers要稍复杂一些, 因为处理时有暗示要取得想要的引用。 一个组件属于一个特定的角色,这我们已经说得很清楚了。 但是,有时候我们需要从一个角色的多个组件中选择一个。 ComponentSelector使用一个任意的对象来作为暗示。 大多数时候,这个对象是一个String,尽管您可能会希望使用一个Locale对象来取得一个正确国际化的组件。
在我们已建立起来的系统中, 我们选择使用字符串来选择DataSourceComponent的正确实例。 我们甚至给了自己一个Configuration元素,来指明为了得到正确的组件,需要的字符串是什么。 这是一个好的实践,可以照着做,因为它使系统管理更容易。 比起要系统管理员记住这些神奇的配置值来,这便他们更容易看到对其它组件的引用。
从概念上来看,从ComponentSelector取得一个组件与从ComponentManager取得组件并无差别。 你只多了一个步骤。 请记住ComponentSelector也是一个组件。 当您查找ComponentSelect的角色时,ComponentManager 将准备好ComponentSelector组件并返回给您。 然后您需要通过它来选择组件。 为了说明这一点,我将扩展前面讨论的异常处理方式的代码。
public void myMethod()
throws Exception
{
ComponentSelector dbSelector = null;
DataSourceComponent datasource = null;
try
{
dbSelector = (ComponentSelector)
this.manager.lookup(DataSourceComponent.ROLE + "Selector");
datasource = (DataSourceComponent)
dbSelector.select(this.useDb);
this.process(datasource.getConnection());
}
catch (Exception e)
{
throw e;
}
finally
{
if (datasource != null)
{
dbSelector.release(datasource);
}
if (dbSelector != null)
{
this.manager.release(dbSelector);
}
}
}
|
您可以看到,我们通过使用指定组件的角色得到了ComponentSelector的引用。 我们遵守了前面提到的角色命名规范,在角色名的后名加上"Selector"作为后缀。 您可以使用一个静态的接口来处理系统小所有的角色名,以减少代码中字符串连接的次数。这样做也是完全可以接受的。
接下来,我们得从ComponentSelector到了DataSource组件的引用。 我们的示例代码假定我们已经从Configuration对象取得了所需的信息并把它放在一个名为"useDb"的类变量中。
|
|
Excalibur的工具类
|
最后这一节是向您介绍Apache Avalon Excalibur带的几类组件和工具类。 这些工具类是健壮的, 完全可以在实际生产系统中使用。 我们有一个非正式的分级式项目称为"Scratchpad",在这个项目中,我们解决潜在新工具类的实现细节问题。 Scratchpad中的工具类的品质各有不同,它们的使用方式也不能保证不变,尽管您可能觉得用起来不错。
命令行接口(Command Line Interface,CLI)
|
CLI工具类在一些项目中使用,包括Avalon Phoenix和Apache Cocoon,用于处理命令行参数。它提供了打印帮助信息的机制,并能够以短名字或长名字的方式来处理参数选项。
|
集合工具类
|
集合工具类对JavaTM Collections API进行了一些增强。 这些增强包括在两个list中找出交叉处的功能和一个PriorityQueue ,它是对Stack 的增强,允许对象的优先级改变简单的先进后出的Stack 实现。
|
组件管理
|
我们已经在前面讨论了这方面的用法。这是Excalibur中最复杂的怪兽,但是它在很少的几个类中提供了很多的功能。在简单的SingleThreaded 或ThreadSafe 两种管理类型之外,还有一种Poolable 类型。如果一个组件实现了Excalibur的Poolable 接口,而不是SingleThreaded 接口, 那么它将维护一个组件池并重用实例。大多数情况下这工作得很好。 在少数组件不能重用的情况下,就使用SingleThreaded 接口。
|
LogKit管理
|
Avalon开发团队意识到许多人需要一种简单的机制来创建复杂的日志目标层次结构。 出于RoleManager 类似的想法,团队开发了LogKitManager ,可以被前面提到的Excalibur Component Management系统使用。基于"logger"属性,它将为不同的组件给出相应的 Logger 对象。
|
线程工具类
|
concurrent包提供了一些辅助多线程编程的类:Lock (mutex的实现), DjikstraSemaphore , ConditionalEvent , 和 ThreadBarrier .
|
Datasources
|
这是根据javax.sql.DataSource 类设计的,但是作了简化。 DataSourceComponent 有两个实现:一个显式地使用JDBC连接池,另一个使用J2EE 应用服务器的javax.sql.DataSource 类。
|
输入/输出 (IO) 工具类
|
IO工具类提供了一些FileFilter类以及File 和IO相关的工具类。
|
池实现
|
Pool实现在各种情况下都能使用的池。其中有一个实现非常快, 但只能在一个线程中使用,用来实现FlyWeight模式是不错的。还有一个DefaultPool ,它不管理池中对象的数目。SoftResourceManagingPool 在对象被归还时判断是否超过一个阈值,如果超过,就让对象“退役”。最后,HardResourceManagingPool 在您达到对象的最大数目时会抛出一个异常。后面的三个池都是ThreadSafe 的。
|
Property工具类
|
Property工具类与Context对象一起使用。它们使您可以扩展Resolvable对象中的"variables"。它是这样工作的:"${resource}" 将去寻找一个名为"resource" 的Context的值,并用这个值来代替这个符号。
|
|
Avalon经受了时间的考验,可以供您使用。本部分提供的证据可以帮助说服您自己和其它人,使用一个成熟的框架比自己创建一个要好。
您可能已经被说服了,但需要一些帮助来说服您的同事,让他们相信Avalon是正确的选择。 也许您也需要说服您自己。 不管怎样,本章将帮助您整理思路,并提供一些有说服力的证据。 我们需要与对开放源代码模式的(Fear, Uncertainty, and Doubt ,FUD)作斗争。 关于开放源代码的有效性的证据,我推荐您阅读Eric S. Raymond对这一主题的优秀论述N400017. 不论您对他所持观点的看法如何,他写的文章汇编成的书The Cathedral and the Bazaar 将提供使人从总体上接受开放源代码的信息。
Avalon能工作
|
我们的底线是Avalon完成了它最初设计时要达到的目标。 Avalon没有引入新的概念和思想,而是使用了一些经受时间考验的概念,并将它们规范化。 影响Avalon设计的最新的概念是分离考虑(Separation of Concerns)模式,它大约是在1995提出的。即使在那时候, 分离考虑也是一种系统分析技术的规范化方法。
Avalon的用户群数以百计。 一些项目如Apache Cocoon, Apache JAMES, 和Jesktop是建立在Avalon之上的。这些项目的开发者是Avalon Framework的用户。 因为Avalon有如此众多的用户,它得到了很好的测试。
由最优秀的人设计
|
Avalon的作者认识到,我们不是服务器端计算的唯一一群专家。 我们使用了来自其它人的研究的概念和想法。 我们响应来自用户的反馈。Avalon不仅仅是由前面介绍的5个开发者设计的,他们带来的是反向控制、分离考虑和面向组件编程的思想,并设计了它。
开放源代码的优秀之处在于,得到的结果是最佳的思想和最佳的代码的融合。 Avalon经过一了些测试想法的阶段并拒绝了一些想法,因为还有更好的解决方案。 您可以利用Avalon开发小组所获得的知识,并在您自己的系统中运用。 您可以在自己的项目中使用Excalibur中预先定义好的组件,它们经过了测试,可以在重负载下运行无误。
|
兼容性的许可证
|
Apache Software License (ASL)可以兼容其它任何已知的许可证。 已知的最大例外是GNU Public License (GPL) 和Lesser GNU Public License (LGPL). 重要的是ASL对合作开发相当友好,如果您不想的话,也不会强迫您发布源代码。 Apache Software Foundation名下的德高望众的HTTP服务器用的是相同的许可证。
|
集群式的研发
|
大多数的Avalon用户以某种方式做出他们的贡献。这把开发,调试和文档的工作量分散到了一些用户身上。 这也表明Avalon的代码经过了更广泛的对等复查,这在公司开发中是不可能做到的。 而且,Avalon的用户支持Avalon。 尽管开放源代码的项目通常没有一个帮助平台或电话支持热钱,但是我们有一个邮件列表。 您的许多问题可以通过邮件列表得到很快的回答,比一些支持热线还要快。
|
简化的分析和设计
|
基于Avalon开发有助于开发者达到一种精神状态。 在这种精神状态下,开发者的工作集中在如何发现组件和服务上。 既然关于组件和服务的生存期的细节问题都已得到分析和设计,开发者只需选择他们需要的就行了。
需要重点指出的是,Avalon的开始并不是取代了传统的面向对象分析和设计,而是对它进行了增强。 您还是使用以前所用的技术,只不过现在您有了一组工具,能更快地实现您的设计。
|
|
Avalon已经就绪
|
Avalon Framework, Avalon Excalibur, 和 Avalon LogKit已经准备好让您使用了。它们已经成熟,只会变得越来越好。 尽管Avalon Phoenix和Avalon Cornerstone正在紧锣密鼓地开发,但您在它们基础上写的代码将来只需做些不重要的改动就能工作。
|
|
|
|