Avalon phoenix文档之服务器装配者(Server Assemblers)向导

服务器装配者(Server Assemblers)向导

谁应该读本文档

服务器装配者向导是为想为装配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"?>

</myAuthorizer>

<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"?>

<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"?>

<logs>

<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>

<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"?>

</factories>

<log-target id-ref="default"/>

</category>

</categories>

<filename>${app.home}/logs/default-</filename>

<date>yyyyMMdd</date>

</rotation>

</file>

</targets>

</logs>

</environment>

注：本文的一切权力归本文作者所有。