服务器装配者(Server Assemblers)向导<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
谁应该读本文档
服务器装配者向导是为想为装配phoenix服务器应用程序的人编写的。前提假设你对phoenix框架的基本概念比较熟悉。
本章集中在装配方面，对java 编成无特殊要求。也同样假设你对服务器的基本原则，基本安全措施和性能调整比较熟悉。
本章的组织
信息以节组织的，每一节详细的阐述装配服务器应用的一个方面。
内容
1.
什么是服务器应用？
2.
如何创建一个服务器应用？
3.
Config.xml规格说明
4.
Assembly.xml规格说明
5.
Environment.xml规格说明
Avalon 文档小组编写
什么是服务器应用
介绍
在phoenix中，服务器应用是一套blocks,它一起提供一个统一的用户服务。服务器应用的例子包括邮件服务器，文件服务器,Web服务器等。服务器应用是包含一套blocks组件的高层次的组件。
除了blocks以外，服务器应用还需要一定数量的其他组件来完成。服务器应用需要配置文件定义设置（例如线程，安全，日志等）；定义那些blocks如何包裹在一起；为block实例定义配置数据。Block还需要应用程序所指定的其他资源。
Peter Donald，Berin Lortisch 编写
创建服务器应用
介绍
本文档将描述装配你第一个服务器应用的步骤。创建一个服务器应用有以下步骤：
1.
选择你想装配的blocks。
2.
编写config.xml。
3.
编写assembly.xml。
4.
编写environment.xml。
5.
将组件及其相关资源打包在一个sar文件中。
选择你想装配的blocks
作为一个装配人员，为你的应用选择一个所需的精确的block是你的责任。可以从你自己的资源中获得你所需的blocks,你也可以使用phoenix提供的核心blocks,定约他人的组件，或者在在线知识库中下载组件。
编写config.xml
Blocks的配置数据存储在config.xml文件中。想了解更多的关于config.xml的详情请参看config.xml规范。
编写assembly.xml
下一步是编写assembly.xml文件，assembly.xml文件详细指定了作为服务器应用部分的blocks实例。每一个block都有一个名字。每一个block可以有从属(dependencies)，这可以通过“provide”子元素实现。Provide元素可以映射从服务器应用命名空间到BlockInfo文件中Block角色命名空间。想了解更多的关于assembly.xml的详情请参看assembly.xml规范。
编写environment.xml
下一步是编写environment.xml文件，该文件是用于配置基于代码安全的原则、日志管理原则和线程池。想了解更多的关于environment.xml的详情请参看environment.xml规范。
创建Sar文件
Sar 文件格式是标准的分布式phoenix服务应用格式。它是拥有特定目录布局的标准jar文件,config.xml、assembly.xml和environment.xml必须存储在文件的SAR-INF/目录下,而所有的jar文件，包口所有的blocks和支持类库都必须存储在SAR-INF/lib目录下。
Peter Donald 编写
Config.xml文件规范
介绍
Config.xml文件存在的目的是为每一个需要配置数据的block提供配置数据。配置数据的格式是block规范指定的。因而，请参考block文档了解相应的细节。在assembly.xml文件中，根元素下面的每一元素拥有一个相应于block规范的名字。该元素的内容就是block的配置数据。
Config.xml例子
<?xml version="1.0"?>
<config>
<myAuthorizer>
<!-- ...configuration data here... -->
</myAuthorizer>
<myBlock>
<param1>param1-value</param1>
<an-integer>2</an-integer>
...
</myBlock>
</config>
Peter Donald 编写
Assembly.xml文件规范
装配文件
Assembly.xml定义了如何装配应用程序，它也定义了组成应用程序的blocks和如何连接blocks,太还定义了包含在应用中的应用监听者。
在早期的phoenix版本中，配置文件也可以存储在Assembly文件中。现在不同了，配置数据存储在一个单独得配置文件(config.xml)中。
Assembly.xml的根元素必须是<assembly>元素。对于每一个block和属于应用程序一部分的应用监听者根元素必须包含一个子元素。这些元素在下文描述。
<block>元素
<block>元素定义了一个block和如何为这个block提供服务。<block>元素有以下属性。
属性
描述
class
Block实现类的全当限名称(fully-qulified name),这个类必须是public,必须拥有一个无参的public 构造函数。必须有一个BlockInfo文件与此类相关。
name
Block的唯一命名。该命名用于assembly文件中其他部分查阅此block，或者在config文件中查阅该block。Block命名只能包含字母、数字、“-”和“.”。
<provide>元素
<provide>元素定了如何为一个block提供特殊服务。它连接一个block和另一个为它提供所需服务的block。在block的BlockInfo文件中对于每一dependency列表至少有一个<provide>元素。对于大批的计划的服务，对于每一个denpendency可能有多于一个的<provide>元素。<provide>元素有以下属性。
属性
描述
alias
使用服务和映射服务的关键元素。默认值是name属性的值。
name
该属性是为目标block提供服务。这必须参考同一应用中的另外一个block.
role
服务的角色（role）。这必须参考block的BlockInfo文件中denpendency列表之一。该服务名和版本由dependency指定，必须同BlockInfo文件的服务列表之一对应。
<proxy>元素
<proxy>元素控制着在向其他block提供blocks前phoenix是否将proxy对象和block打包。
属性
描述
disable
使用proxy对象失效。默认值是false.
<listener>元素
<listener>元素定义了一个服务器监听。<listener>元素有以下属性：
属性
描述
class
监听类的全当限名称(fully-qulified name)。这个类必须是public,必须提供一个public的无参的构造函数。它必须实现哦org.Avalon.phoenix.ApplicationListener接口。
name
监听者的唯一的命名。它用于指向配置文件中的监听者。命名中只能含有字母、数字、“-”和“.”。
<block-listener>元素（不提倡）
<block-listener>元素定义了block的监听者。注意这种使用block的方法是不提倡的。<block-listener>的属性和<listener>元素相同。
Assembly.xml文件例子
下面是一个assembly.xml的例子。它定义了2个blocks,分别叫做myAuthorizer和myBlock，并定义了一个监听者。myBlock使用了myAthorizer提供的Athorizer服务。
<?xml version="1.0"?>
<assembly>
<block name="myAuthorizer"
class="com.biz.cornerstone.blocks.MyAuthorizer">
</block>
<block name="myBlock"
class="com.biz.cornerstone.blocks.MyBlock">
<provide name="myAuthorizer"
role="com.biz.cornerstone.services.Authorizer"/>
</block>
<listener name="myListener"
class="com.biz.cornerstone.listeners.MyListener">
</listener>
</assembly>
Peter Donald 编写
Environment.xml文件规范
介绍
Environment.xml文件的目的是配置环境或者服务器应用设置。当前这意味着可以设置安全原则和配置日志设置。下面是一个environment.xml文件样本。早期的线程池也是在本节设置的，但这已经不提倡了。注意早期的存储在environment.xml文件中的数据是存储在Server.xml文件中的。
Environment.xml例子
<?xml version="1.0"?>
<environment>
<logs>
<category name="" target="default" priority="DEBUG" />
<category name="myAuthorizer" target="myAuthorizer-target"
priority="DEBUG" />
<log-target name="default"
location="/logs/default.log" />
<log-target name="myAuthorizer-target"
location="/logs/authorizer.log" />
</logs>
<policy>
<keystore name="foo-keystore"
location="sar:/conf/keystore"
type="JKS" />
<grant code-base="file:${app.home}${/}some-dir${/}*"
key-store="foo-keystore" >
<permission class="java.io.FilePermission"
target="${/}tmp${/}*"
action="read,write" />
</grant>
<grant signed-by="Bob"
code-base="sar:/SAR-INF/lib/*"
key-store="foo-keystore" >
<permission class="java.io.FilePermission"
target="${/}tmp${/}*"
action="read,write" />
</grant>
</policy>
</environment>
如果装配人员对标准的policy十分有经验的话，Policy片段格式就十分的明显。注意，如果给有指定policy，Server应用程序将在所有允许的权限下运行。属性评价发生在类似于标准plocy文件属性扩展下发生。有几个额外的属性可以用于估计。他们包括:App.home和App.name。
有一件特殊的事情需要提醒,用户可以使用URLs的形式。例如:“sar:/SAR-INF/lib/*”。这必须申请sar文件中jar权限。注意：这些URLs必须以“sar:/”起始，必须以“/”作为文件分割符而不必关心操作系统。
Logs片段可以同时拥有两种元素。Log-targets描绘的是日志及其种类，必须拥有一个命名为“default”的log-targets。种类是自然界的继承，又一个优先权，和一个或者多个log-targets关联。参看logging文档作进一步了解。
有另一种类型的日志配置。它更容易配置。指定日志版本属性。参看javadoc中的org.apache.Avalon.excalibur.logger做进一步了解。下面是一个配置实例：
<?xml version="1.0"?>
<environment>
<logs version="1.1">
<factories>
<factory type="file" class="org.apache.Avalon.excalibur.logger.factory.FileTargetFactory"/>
</factories>
<categories>
<category name="" log-level="INFO">
<log-target id-ref="default"/>
</category>
&nb