• 工作接口的完整限定名通常就是角色名。例外情况列在本通用规则的下面。在这个例子里，我们理论上的组件名称应该是"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"。

每个Avalon组件必须 实现Component接口。Component Manager和Component Selector只处理Component。这个接口没有定义方法。它只是作为一个标记性接口。

任何组件必须使用不带参数的缺省构造方法。所有配置都是通过Configurable或Parameterizable接口来完成的。

一个用到其它组件的组件需要实现这个接口。这个接口只有一个方法compose()，该方法带唯一一个ComponentManager 类型的参数。

围绕该接口的契约是：在组件的生存期中，compose()被调用一次且仅被调用一次。

这个接口与其它任何定义了方法的接口一样，都使用的是反向控制模式。它由组件的容器调用，只有该组件需要的那些组件会出现在ComponentManager中。

在少数的情况下，组件会需要一个新的ComponentManager和新的组件-角色映射关系。在这些情况下，需要实现recomposable接口。它的方法也与Composable的方法名称不一样，是recompose()。

围绕该接口的契约是：recompose() 方法可以被调用任意多次，但不能在组件完全初始化好之前调用。当该方法被调用时，组件必须以一种安全和一致的方式更新它自己。通常这意味着组件进行的所有操作必需在更新之间停下来，在更新之后再继续。

如果一个组件需要以一种结构化的方式知道自己不在需要了，它可以使用Disposable接口。一旦一个组件被释放掉，它就不能再用了。实际上，它就等待着被垃圾收集。该接口只有一个方法dispose()，该方法没有参数。

围绕该接口的契约是：dispose()方法被调用一次，也是组件生存期中调用的最后一个方法。同时也表明该组件将不再使用，必须释放该组件所占用的资源。

任何组件如果需要创建其它组件，或需要执行初始化操作从其它的初始化步骤中获取信息，就要用到Initializable接口。该接口只有一个initialize()方法，该方法没有参数。

围绕该接口的契约是：initialize()方法被调用一次，它是初始化过程中最后被调用的方法。同时也表明，该组件已处于活动状态，可以被系统中其它组件使用。

任何组件如果在其生存期中持续运行，就要用到Startable 接口。该接口定义了两个方法：start() 和stop()。这两个方法都没有参数。

围绕该接口的契约是：start()方法在组件完全初始化之后被调用一次。stop() 方法在组件被销毁之前被调用一次。它们都不会被调用两次。start() 总在stop()之前被调用。对该接口的实现要求安全地执行start() 和stop() 方法 (不像Thread.stop()方法) 并且不会导致系统不稳定。

任何组件如果在其生命期中允许自己被挂起，就要用到Suspendable 接口。虽然它通常总是和Startable 接口在一起使用，但这不是必需的。该接口有两个方法：suspend() 和resume()。这两个方法都没有参数。

围绕该接口的契约是：suspend() and resume() 可以被调用任意多次，但在组件初始化并启动之前，或在组件停止并销毁之后不能调用。 对已挂起的组件调用suspend() 方法，或对已在运行的组件调用resume() 将没有任何效果。

那些需要根据配置确定其行为的组件必须实现这个接口以得到Configuration 对象的实例。该接口有一个configure() 方法，只有一个Configuration 类型的参数。

围绕该接口的契约是：configure() 方法在组件的生存期中被调用一次。传入的Configuration 对象一定不能为null。

Configuration对象是一由配置元素组成的树，配置元素拥有一些属性。在某种程度上，您可以将配置对象看作一个大大简化的DOM。Configuration类的方法太多，不便在本文中介绍，请看JavaDoc文档。您可以从Configuration 对象中取得String, int, long, float, or boolean类型的值，如果配置没有将提供缺省值。对属性也是一样的。您也可以取得子Configuration 对象。

契约规定，具有值的Configuration 对象不应有任何子对象，对子对象也是这样的。

你会注意到你无法得到父Configuration 对象。设计就是这样做的。为了减少配置系统的复杂性，大多数情况下容器会将子配置对象传给子组件。子组件不应该有权访问父配置的值。这种方式可能带来一些不便，但是Avalon团队在需要做折衷的情况下总是选择把安全性放在第一。

实现该接口的组件行为与Recomposable 组件非常相似。它只有一个reconfigure()方法。这样的设计决策是为了降低Re开头的那些接口的学习难度。Reconfigurable 对Configurable 来说就象Recomposable 对Composable一样。

Context接口只定义了一个get()方法。它有一个Object 类型的参数，返回以参数对象为键值的一个对象。Context 对象由容器组装，然后传递给子组件，子组件对Context只有读权限。

除了Context 对子组件总是只读的之外，没有别的契约。如果您扩展了Avalon的Context，请注意遵守该契约。它是反向控制模式的一部分，也是安全性设计的一部分。另外，在Contex中传一个引用 给容器的做法也是不好的，原因和Context应该是只读的相同。

希望接收来自于容器的Context对象的组件应该实现该接口。它有一个名为contextualize() 的方法，参数是容器组装的Context 对象。

围绕这个接口的契约是：contextualize() 在组件的生存期中被调用一次，在LogEnabled 之后，但在其它初始化方法之前。

实现该接口的组件行为与Recomposable 组件非常相似。它只有一个名为recontextualize()的方法。这样的设计决策是为了降低Re开头的接口的学习难度。Recontextualizable 对Contextualizable 就如同Recomposable 对Composable。

Resolvable接口用于标识一些对象，这些对象在某些特定上下文中需要分离（need to be resolved）。一个例子是：某对象被多个Context 对象共享，并根据特定的Context改变其自身的行为。在对象被返回之前Context会调用 resolve() 方法。

每个需要Logger实例的组件都要实现该接口。该接口有一个名为enableLogging() 的方法，将Avalon Framework的Logger 实例传递给组件。

围绕该接口的契约是：在组件的生存期中只调用一次，在任何其它初始化步骤之前。

Logger接口用于对不同的日志库进行抽象。它提供一个唯一的客户端API。Avalon Framework提供了三个实现该接口的封装类：针对LogKit的LogKitLogger 、针对Log4J的Log4jLogger 、和针对JDK1.4日志机制的Jdk14Logger 。

任何希望用Parameters 来取代Configuration 对象的组件将实现该接口。Parameterizable 只有一个名为parameterize()的方法，with the parameter being the Parameters object.

围绕该接口的契约是：它在组件的生存期中被调用一次。该接口与Configurable接口不兼容。

Parameters对象提供了一种通过一个String 类型的名字取得值的机制。如果值不存在，有方便的方法允许你使用缺省值，也可以得到Configurable 接口中任何相同格式的值。

尽管Parameters 对象与java.util.Property 对象之间存在相似性，但它们还是存在重要的语义差别。首先，Parameters 是只读的。 其次，Parameters 总是很容易从Configuration 对象中导出。最后，Parameters 对象是从XML 片断中导出的，看上去是这样的：

<parameter name="param-name" value="param-value"/>

          

围绕SingleThreaded组件的契约是实现该接口的组件不允许被多个线程同时访问。每个线程需要有该组件的自己的实例。另一种做法是使用一个组件池，而不是每次请求该组件时都创建一个新的实例。为了使用池，您需要实现Avalon Excalibur的Poolable接口，而不是这个接口。

围绕ThreadSafe组件的契约是：不管有多少线程同时访问该组件，它们的接口和实现都能够正常工作。尽管这是一个有弹性的设计目标，但有时候由您所使用的技术，它就是不能实现。实现了这个接口的组件通常在系统中只有一个实例，其它的组件将使用该实例。

Java^TM 版本技术是在jar包中的manifest文件中有一项指定。问题是，当jar被解包后您就失去了版本信息，并且版本信息放在易于修改的文本文件中。当您把这些问题与一个较陡的学习曲线放在一起考虑时，检查组件和接口的版本就比较困难。

Avalon开发小组设计了Version对象，让您可以容易地检查版本和比较版本。您可以在您的组件中实现Version对象，测试合适的组件或最低版本号也会更容易。