Avalon的简要历史以及创建它所有的设计原则概述
事情是从Apache JServ项目开始的。Stefano Mazzocchi和其它协助开发Apache JServ的人员认识到项目中所用到的一些模式很通用，足以用于创建一个服务器框架。 在1999年1月27日，星期三（在JServ 1.0b发布大约一个月后），Stefano拿出一份建议书，建议启动一个名为Java Apache Server Framework的项目。它的目标是成为Apache所有Java服务器代码的基础。想法是通过提供一个框架，将跨项目的一些组件和重用代码集中在一起。
Stefano Mazzocchi，Federico Barbieri和Pierpaolo Fumagalli创建了最初的版本。在2000年末，Berin Loritsch和Peter Donald参加到项目中来。那时，Pierpaolo和Stefano已转向其它项目的开发，Java Apache Server Framework开始被称为Avalon。这五个开发者是框架目前版本所使用的设计和概念的主要负责人。当前版本与2000年6月发行的版本非常相似。实际上，主要的区别是对包重新组织，以及将项目划分为子项目。同样的设计模式和接口今天依然存在。
什么是Avalon?
Avalon 是五个子项目的父项目：Framework、Excalibur、LogKit、Phoenix、和Cornerstone。当听到Avalon时，大多数人会联想到Framework，但Avalon不止包括Framework。Avalon开始作为Java Apache Server Framework时就包含框架、工具、组件和一个服务器核心的实现，这些都在一个项目中。因为Avalon的不同部分具有不同的成熟程度，发布周期也不同，我们决定将Avalon划分为前面提到的小项目。这样做也便于新开发者理解和学习Avalon的不同部分——这在以前几乎无法办到。 Framework
Avalon Framework是Avalon大伞下的所有其它项目的基础。它定义了接口、契约（contracts）和Avalon的缺省实现。Framework将大部分工作置于其中，因此也是最为成熟的项目。
Excalibur
Avalon Excalibur是一组服务器端组件，您可以在自己的项目中使用它们。它包括了池（pooling）的实现、数据库连接管理和其它一些组件管理的实现。
LogKit
Avalon LogKit是一个高速日志记录工具集，Framework、Excalibur、Cornerstone和Phoenix都用到它。它的模型与JDK 1.4 Logging package采用相同的原理，但与JDK 1.2+兼容。
Phoenix
Avalon Phoenix是服务器核心，它管理服务（Service，实现为服务器端组件，称作Block）的发布和执行。
Cornerstone
Avalon Cornerstone是一组Block或服务，这些Block可以布署在Phoenix环境中。这些Block包括了socket管理和Block之间的任务调度。
Scratchpad
Scratchpad并不是一个真正的正式项目，而是那些还没准备好放入Excalibur中的组件的一个临时区域。这些组件品质差别较大，它们的API也不保证会不变，直到它们被提升到Excalibur项目为止。
本概述的重点
在这个概述中，我们把重点放在Avalon Framework上，但会介绍足够的Avalon Excalibur和Avalon LogKit的相关知识，以便让您能够起步。我们将通过一个假想的业务服务器来展示如何在实践中使用Avalon。定义一个完整全面的方法学，或介绍所有子项目的方方面面超出了本概述的范围。我们将重点放在Avalon Framework上是因为它是所有其它项目的基础。如果您能理解该框架，您就可以理解任何基于Avalon的项目。对于Avalon中常用的一些编程习惯结构（idiom），您也会逐渐熟悉。将重点放在框架上并涉及Avalon Excalibur和Avalon LogKit项目的另一个原因是它们是正式发布并被支持的。
Avalon可用在哪里?
我被问过好几次，要求阐明Avalon 适合做什么，不适合做什么。Avalon把重点放在服务器端编程和让以服务器应用为中心的项目的设计和维护变得更容易。Avalon可被描述为一个包含了实现的框架。尽管Avalon的重点是服务器端解决方案，很多人却发现对普通应用程序来说它也是有用的。Framework、Excalibur、和 LogKit中使用的概念很通用，足以在任何项目中应用。将重点更直接放在服务器上的两个项目是Cornerstone和Phoenix。 Framework
1. 一个支持性的或封闭性的结构2. 包含思想的一个基本系统或一种安排
框架这个词在应用程序中的含义很广泛。重点放在单一行业的框架被称为垂直市场框架，例如医药系统或通信系统。原因是同样的框架不能胜任其它行业。具有很好通用性，可用于多个行业的框架被称为水平市场框架。Avalon是一个水平市场框架。您可以使用Avalon的Framework构建垂直市场框架。用Avalon构建的最有说服力的垂直市场框架的例子是Apache Cocoon出版框架。Apache Cocoon第2版是使用Avalon的Framework、Excalibur和LogKit项目构建的。它利用了Framework中的接口和契约，让开发者能用更少的时间理解Cocoon是如何工作的。它也有效地利用了Excalibur提供的数据源管理和组件管理代码，这样它就不必重新发明轮子了。最后，它使用了LogKit来处理出版框架中所有的日志问题。一旦您理解了隐藏在Avalon Framework后面的原理，您就能理解基于Avalon构建的任何系统。一旦您理解了系统，您将能更快地捕获因为误用框架所引起的缺陷。不存在魔术公式
值得一提的是，任何试图使用某种工具作为成功的魔术公式的做法都是自找麻烦。Avalon也不例外。因为Avalon的Framework是为服务器端解决方案设计的，所以用它来构建图形用户界面（GUI）不是什么好主意。Java已经有了一个构建GUI的框架，称为Swing。尽管您需要考虑 Avalon是否适合您的项目，但您还是能从它的原理和设计中学到一些东西。您需要问自己的问题是："项目将用在哪里?" 如果回答是它将运行在一个服务器环境中，那么Avalon将是一个好的选择，无论您是要创建一个Java Servlet或一个特殊用途的服务器应用。如果回答是它将运行在一个客户的机器上，并且与服务器没有交互，那么可能Avalon不太适合。即使如此，组件模型也是非常灵活，有助于在大型应用程序中对复杂性进行管理。
原理和模式
Avalon整个是基于一些特定设计原理来构建的。最重要的两个模式是反向控制（Inversion of Control） 和分离考虑（Separation of Concerns）。 Component Oriented Programming、Aspect Oriented Programming和Service Oriented Programming也对Avalon产生了影响。每种程序设计原理都可以写出数卷的书，但它们都是一些设计思维习惯。反向控制
反向控制（Inversion of Control，IOC）的概念是指组件总是由外部进行管理的。这个短语是由Brian Foote在他的一篇论文中最先使用的。组件所需的一切通过Contexts、Configurations和Loggers的方式赋予组件。实际上，组件生命周期中的每个阶段都是由创建组件的代码所控制的。当您使用这种模式时，就实现了一种组件与您的系统安全交互的方法。IOC与安全性并不等价! IOC提供了一种机制，允许你实现一个可扩展的安全模型。为了让一个系统真正做到安全，每个组件都必需安全，没有组件可以修改传递给它们的对象的内容，而且所有的交互都必须使用已知的实体。安全性是一个主要问题，IOC是程序员工具库中的一种工具，用于实现安全性的目标。
分离考虑
您应该从不同的思考方向来看待您的系统，这一思想导致了分离考虑（Separation of Concerns，SOC）模式。一个例子是从同一个问题空间的不同视角来看一个web服务器。web服务器必需安全、稳定、可管理、可配置并满足HTTP规范。每种属性都是一个单独的考虑范围。这其中的某些考虑与其它考虑相关，如安全性和稳定性（如果一个服务器不稳定，它就不可能安全）。分离考虑模式又导致了Aspect Oriented Programming (AOP) 。研究者发现许多考虑不能在类或方法的粒度上进行处理。这些考虑被称为aspect。aspect的例子包括管理对象的生命周期、记日志、处理异常和清理释放资源等。由于没有一种稳定的AOP实现，Avalon开发团队选择通过提供一些小的接口，然后由组件来实现，从而实现aspect或考虑。
面向组件的编程
面向组件的编程（Component Oriented Programming ，COP）是把系统分割成一些组件或设施的一种思想。每种设施都有一个工作接口和围绕该接口的契约。这种方式允许容易地更换组件的实例，同时不影响系统其它部分的代码。面向对象编程（Object Oriented Programming ，OOP）和COP的主要区别在于集成的层次。COP系统的复杂性更容易管理，这得益于类之间更少的相互依赖。这提高了代码重用的程度。COP的主要好处之一是修改项目代码的一些部分不会破坏整个系统。另一个好处是可以有某组件的多种实现，并可以在运行时刻进行选择。
面向服务的编程
面向服务的编程（Service Oriented Programming ，SOP）的思想是把系统划分为由系统提供的一些服务。服务
1. 为其它人执行的工作或职责2. 提供修理或维护的一种设施3. 向公众提供工具的一种设施
Avalon 的 Phoenix把每一种要提供的设施看作是一项服务，由特定接口和相关契约组成。服务的实现被称为Block。一个服务器程序是由多种服务组成的，认识这一点很重要。以邮件服务器为例，它会有协议处理服务、认证和授权服务、管理服务和核心邮件处理服务等。Avalon的 Cornerstone提供了一些低层的服务，您可以在自己的系统中加以利用。提供的服务包括连接管理、socket管理、参与者/角色管理和调度等。我们在这里介绍到服务是因为它与把我们的假定系统分解为不同设施的过程有关。
分解一个系统
您是如何决定由哪些东西组成一个组件的? 关键是定义您的解决方案所需的设施，以便能有效率地进行操作。
我们将使用一个假想的业务服务器来展示如何识别和确定服务与组件。在我们定义了一些系统用到的服务之后，我们将以这些服务中的一个为例，定义该服务所需的不同组件。我的目标是传递给您一些概念，这些概念有助于您把您的系统定义成可管理的部分。
系统分析——识别组件
尽管提供一个完整全面的方法学不是本篇的范围，我还是愿意讨论几点问题。我们将从组件和服务的面向实现的定义开始，然后提供一个实践的定义。组件
一个组件是一个工作接口和该工作接口的实现的组合。使用组件提供了对象间的松耦合，允许改变实现而不影响使用它的代码。
服务
一个服务由一个或更多的组件组成，提供了一种完整的解决方案。服务的例子包括协议处理器、任务调度器、认证和授权服务等等。
尽管这些定义提供了一个起点，但它并没有提供一个完整图景。为了把一个系统（定义为一组设施，组成一个项目）分解为必要的组成部分，我建使用自顶向下的方式。采用这种方式可以在您了解到底有哪些设施之前，避免陷入到细节的泥潭中。确定您的项目范围
您的项目预期完成什么功能，一开始您总要有个大致的想法。在商业世界里，初始工作说明（initial statement of work ）就是完成这项工作的。在开放源代码的世界里，这通常是由一个想法或一个脑力激荡的过程完成的。我想不论如何强调具备一个项目的高层视图的重要性都是不过份的。很明显，一个大项目将由许多不同的服务组成，而小项目只有一两个服务。如果您开始感到有点不知所措，只需提醒自己大项目实际上是一把大伞下的许多小项目。最终，您将能理解整个系统大的图景。
工作说明：业务服务器
业务服务器（Business Server）是一个假想的项目。出于我们讨论问题的目的，它的功能是处理销售订单，自动向客户发出账单，并管理存货控制。销售订单到达时必须得到处理，通过某种类型的事务系统。在销售订单填写30天后，服务器自动向客户发出账单。库存由服务器和工厂或仓库的当前库存量同时来管理。该业务服务器将是一个分布式系统，每个服务器将通个一个消息服务来与其它服务器通信。
发现服务
我们将使用这个Business Server项目来发现服务。考虑上面的过于概括性的工作说明，我们立即可以看到项目描述中定义的一些服务。服务的清单可被分成两大类：显式的服务（可以从工作说明中直接导出的服务）和隐式的服务（根据相似的工作发现的服务，或对显示服务起支持作用的服务）。请注意，实现系统的公司不必亲自开发所有的服务 ——有一些可作为商业解决方案购买。在那些情况下，我们可能会开发一个封装层（wrapper），以便我们能够以确定的方式与商业产品实现互操作。实现系统的公司将构建大部分的服务。显式的服务
从工作说明中，我们可以快速导出一些服务。但这种初始分析并不意味我们的工作已完成，因为某些服务的定义需要其它服务的存在才能保证。事务处理服务
工作说明明确指出“销售订单到达时必须得到处理 ”。这表明我们需要有一种机制能够接受销售请求并自动地处理它们。这与web服务器工作的方式相似。它们接收到对资源的请求，进行处理并返回一个结果（如 HTML页面）。这被称作是事务处理。完整地说起来，存在不同类型的事务处理。这种一般性的事务处理服务极有可能必须分解为一些更特殊的东西，如“销售订单处理器“。具体方法取决于您的服务的通用性。在可用性和可重用性之间存在一种平衡。服务越是通用，它就越可重用。通常它也就越难于理解。
调度服务
在某些情况下，当事务完成，过了一段特定的时间之后，必须调度某个事件。而且，库存控制过程必需能周期性地开出采购订单。因为工作说明中指出“ 在销售订单填写30天后，服务器自动向客户发出账单” ，所以我们需要一个调度服务。所幸的是Avalon Cornerstone为我们提供了一个，这样我们就不必再自己写一个了。
消息服务
工作说明中指出，在我们的分布式系统中“每个服务器将通个一个消息服务来与其它服务器通信“。让我们来考虑这个问题，有时用户需要一个特定的产品或一种他们想用的方法。消息服务是利用其它公司产品的一个首选例子。极有可能，我们将采用Java Messaging Service (JMS) 来作为Messaging Service的接口。因为JMS是一个标准，它的接口不大可能短期内发生变化。从实践经验上来说，一个定义良好的面向消息的系统在可扩展性方面要强于面向对象的系统（如EJB）。可扩展性更好的一个原因是消息通常并发内存开销较小。另一个原因是它更容易把消息处理的负载分散到所有服务器上去，而不是把所有的处理集中在少量的服务器集群上（甚至是在一台服务器上）。
库存控制服务
尽管这不是一个教科书上的经典服务，但它是这个系统的一项需求。库存控制服务固定地监视工厂或仓库存货的记录，当存货开始不足时触发一些事件。
隐式的服务
运用在过去系统中获得的经验，将系统更进一步分解出其它服务，将得到没有明确指出但又是系统需要的一些服务。因为篇幅关系，我们将不做全面地分解。认证和授权服务
认证和授权服务没有在工作说明中明确地提到，但是所有的业务系统必须认真考虑安全性。这意味着系统所有的客户端都必须经过认证，用户的所有行为都必须经过授权。
工作流自动化服务
工作流自动化是企业系统中的一个热门开发领域。如果您不使用第三方的工作流管理服务器，您就需要自己写一个。通常工作流自动化所做的是使用软件系统来安排贯穿公司业务过程的任务。更多的信息请参考Workflow Management Council的网站http://www.wfmc.org/。
文档中心服务
作为一个任务的当前状态信息，"文档中心"这个词的定义很不精确。换言之，当公司接到一份购买订单时，我们的系统需要能够存储并重新调出购买订单信息。出账单和系统中其它任何过程，从库存到新的用户请求都有同样的需求。
小结
我希望Business Server项目的服务的例子可以帮助您发现更多。您会发现，当您从较高的抽象层逐渐转向较低的抽象层时，会发现需要更多类型的服务，如用于在一个打开端口上处理请求的连接服务。我们定义的某些服务将通过第三方的系统来实现，如消息服务和工作流管理服务。对这些服务来说，使用一个标准接口是最符合您的利益的，这样您可以在以后更换供应商。有些服务实际上是由多个服务组成的大服务。有些服务Avalon Excalibur或Avalon Cornerstone中已经提供了。在发现一个系统中的服务时，应该牢记的一件事是：一个服务应该是一个高层子系统。这将有助于您通过分析师团队来定义组件。因为我们已识别出了主要的服务，您可以让多个个人（或团队）并行地分解每个服务。子系统边界也定义良好，发生重叠的可能性很小。如果您决定进行并行分析，您应该回过头来识别通用的组件，以便能够尽可能地重用。
UML Diagram for the Business Server
发现组件
我们将以前面提到的文档中心服务为例来说明识别合适的组件的过程。为讨论方便起见，我们现在来列出文档中心服务的需求。文档中心将采用一个数据库来作为持久存储，对客户端授权，在内存中缓存文档。组件的实践性定义
当我们谈论组件时，您考虑问题的角度应该是：我的服务需要操作哪些设施？Avalon相信将系统投
事情是从Apache JServ项目开始的。Stefano Mazzocchi和其它协助开发Apache JServ的人员认识到项目中所用到的一些模式很通用，足以用于创建一个服务器框架。 在1999年1月27日，星期三（在JServ 1.0b发布大约一个月后），Stefano拿出一份建议书，建议启动一个名为Java Apache Server Framework的项目。它的目标是成为Apache所有Java服务器代码的基础。想法是通过提供一个框架，将跨项目的一些组件和重用代码集中在一起。
Stefano Mazzocchi，Federico Barbieri和Pierpaolo Fumagalli创建了最初的版本。在2000年末，Berin Loritsch和Peter Donald参加到项目中来。那时，Pierpaolo和Stefano已转向其它项目的开发，Java Apache Server Framework开始被称为Avalon。这五个开发者是框架目前版本所使用的设计和概念的主要负责人。当前版本与2000年6月发行的版本非常相似。实际上，主要的区别是对包重新组织，以及将项目划分为子项目。同样的设计模式和接口今天依然存在。
什么是Avalon?
Avalon 是五个子项目的父项目：Framework、Excalibur、LogKit、Phoenix、和Cornerstone。当听到Avalon时，大多数人会联想到Framework，但Avalon不止包括Framework。Avalon开始作为Java Apache Server Framework时就包含框架、工具、组件和一个服务器核心的实现，这些都在一个项目中。因为Avalon的不同部分具有不同的成熟程度，发布周期也不同，我们决定将Avalon划分为前面提到的小项目。这样做也便于新开发者理解和学习Avalon的不同部分——这在以前几乎无法办到。 Framework
Avalon Framework是Avalon大伞下的所有其它项目的基础。它定义了接口、契约（contracts）和Avalon的缺省实现。Framework将大部分工作置于其中，因此也是最为成熟的项目。
Excalibur
Avalon Excalibur是一组服务器端组件，您可以在自己的项目中使用它们。它包括了池（pooling）的实现、数据库连接管理和其它一些组件管理的实现。
LogKit
Avalon LogKit是一个高速日志记录工具集，Framework、Excalibur、Cornerstone和Phoenix都用到它。它的模型与JDK 1.4 Logging package采用相同的原理，但与JDK 1.2+兼容。
Phoenix
Avalon Phoenix是服务器核心，它管理服务（Service，实现为服务器端组件，称作Block）的发布和执行。
Cornerstone
Avalon Cornerstone是一组Block或服务，这些Block可以布署在Phoenix环境中。这些Block包括了socket管理和Block之间的任务调度。
Scratchpad
Scratchpad并不是一个真正的正式项目，而是那些还没准备好放入Excalibur中的组件的一个临时区域。这些组件品质差别较大，它们的API也不保证会不变，直到它们被提升到Excalibur项目为止。
本概述的重点
在这个概述中，我们把重点放在Avalon Framework上，但会介绍足够的Avalon Excalibur和Avalon LogKit的相关知识，以便让您能够起步。我们将通过一个假想的业务服务器来展示如何在实践中使用Avalon。定义一个完整全面的方法学，或介绍所有子项目的方方面面超出了本概述的范围。我们将重点放在Avalon Framework上是因为它是所有其它项目的基础。如果您能理解该框架，您就可以理解任何基于Avalon的项目。对于Avalon中常用的一些编程习惯结构（idiom），您也会逐渐熟悉。将重点放在框架上并涉及Avalon Excalibur和Avalon LogKit项目的另一个原因是它们是正式发布并被支持的。
Avalon可用在哪里?
我被问过好几次，要求阐明Avalon 适合做什么，不适合做什么。Avalon把重点放在服务器端编程和让以服务器应用为中心的项目的设计和维护变得更容易。Avalon可被描述为一个包含了实现的框架。尽管Avalon的重点是服务器端解决方案，很多人却发现对普通应用程序来说它也是有用的。Framework、Excalibur、和 LogKit中使用的概念很通用，足以在任何项目中应用。将重点更直接放在服务器上的两个项目是Cornerstone和Phoenix。 Framework
1. 一个支持性的或封闭性的结构2. 包含思想的一个基本系统或一种安排
框架这个词在应用程序中的含义很广泛。重点放在单一行业的框架被称为垂直市场框架，例如医药系统或通信系统。原因是同样的框架不能胜任其它行业。具有很好通用性，可用于多个行业的框架被称为水平市场框架。Avalon是一个水平市场框架。您可以使用Avalon的Framework构建垂直市场框架。用Avalon构建的最有说服力的垂直市场框架的例子是Apache Cocoon出版框架。Apache Cocoon第2版是使用Avalon的Framework、Excalibur和LogKit项目构建的。它利用了Framework中的接口和契约，让开发者能用更少的时间理解Cocoon是如何工作的。它也有效地利用了Excalibur提供的数据源管理和组件管理代码，这样它就不必重新发明轮子了。最后，它使用了LogKit来处理出版框架中所有的日志问题。一旦您理解了隐藏在Avalon Framework后面的原理，您就能理解基于Avalon构建的任何系统。一旦您理解了系统，您将能更快地捕获因为误用框架所引起的缺陷。不存在魔术公式
值得一提的是，任何试图使用某种工具作为成功的魔术公式的做法都是自找麻烦。Avalon也不例外。因为Avalon的Framework是为服务器端解决方案设计的，所以用它来构建图形用户界面（GUI）不是什么好主意。Java已经有了一个构建GUI的框架，称为Swing。尽管您需要考虑 Avalon是否适合您的项目，但您还是能从它的原理和设计中学到一些东西。您需要问自己的问题是："项目将用在哪里?" 如果回答是它将运行在一个服务器环境中，那么Avalon将是一个好的选择，无论您是要创建一个Java Servlet或一个特殊用途的服务器应用。如果回答是它将运行在一个客户的机器上，并且与服务器没有交互，那么可能Avalon不太适合。即使如此，组件模型也是非常灵活，有助于在大型应用程序中对复杂性进行管理。
原理和模式
Avalon整个是基于一些特定设计原理来构建的。最重要的两个模式是反向控制（Inversion of Control） 和分离考虑（Separation of Concerns）。 Component Oriented Programming、Aspect Oriented Programming和Service Oriented Programming也对Avalon产生了影响。每种程序设计原理都可以写出数卷的书，但它们都是一些设计思维习惯。反向控制
反向控制（Inversion of Control，IOC）的概念是指组件总是由外部进行管理的。这个短语是由Brian Foote在他的一篇论文中最先使用的。组件所需的一切通过Contexts、Configurations和Loggers的方式赋予组件。实际上，组件生命周期中的每个阶段都是由创建组件的代码所控制的。当您使用这种模式时，就实现了一种组件与您的系统安全交互的方法。IOC与安全性并不等价! IOC提供了一种机制，允许你实现一个可扩展的安全模型。为了让一个系统真正做到安全，每个组件都必需安全，没有组件可以修改传递给它们的对象的内容，而且所有的交互都必须使用已知的实体。安全性是一个主要问题，IOC是程序员工具库中的一种工具，用于实现安全性的目标。
分离考虑
您应该从不同的思考方向来看待您的系统，这一思想导致了分离考虑（Separation of Concerns，SOC）模式。一个例子是从同一个问题空间的不同视角来看一个web服务器。web服务器必需安全、稳定、可管理、可配置并满足HTTP规范。每种属性都是一个单独的考虑范围。这其中的某些考虑与其它考虑相关，如安全性和稳定性（如果一个服务器不稳定，它就不可能安全）。分离考虑模式又导致了Aspect Oriented Programming (AOP) 。研究者发现许多考虑不能在类或方法的粒度上进行处理。这些考虑被称为aspect。aspect的例子包括管理对象的生命周期、记日志、处理异常和清理释放资源等。由于没有一种稳定的AOP实现，Avalon开发团队选择通过提供一些小的接口，然后由组件来实现，从而实现aspect或考虑。
面向组件的编程
面向组件的编程（Component Oriented Programming ，COP）是把系统分割成一些组件或设施的一种思想。每种设施都有一个工作接口和围绕该接口的契约。这种方式允许容易地更换组件的实例，同时不影响系统其它部分的代码。面向对象编程（Object Oriented Programming ，OOP）和COP的主要区别在于集成的层次。COP系统的复杂性更容易管理，这得益于类之间更少的相互依赖。这提高了代码重用的程度。COP的主要好处之一是修改项目代码的一些部分不会破坏整个系统。另一个好处是可以有某组件的多种实现，并可以在运行时刻进行选择。
面向服务的编程
面向服务的编程（Service Oriented Programming ，SOP）的思想是把系统划分为由系统提供的一些服务。服务
1. 为其它人执行的工作或职责2. 提供修理或维护的一种设施3. 向公众提供工具的一种设施
Avalon 的 Phoenix把每一种要提供的设施看作是一项服务，由特定接口和相关契约组成。服务的实现被称为Block。一个服务器程序是由多种服务组成的，认识这一点很重要。以邮件服务器为例，它会有协议处理服务、认证和授权服务、管理服务和核心邮件处理服务等。Avalon的 Cornerstone提供了一些低层的服务，您可以在自己的系统中加以利用。提供的服务包括连接管理、socket管理、参与者/角色管理和调度等。我们在这里介绍到服务是因为它与把我们的假定系统分解为不同设施的过程有关。
分解一个系统
您是如何决定由哪些东西组成一个组件的? 关键是定义您的解决方案所需的设施，以便能有效率地进行操作。
我们将使用一个假想的业务服务器来展示如何识别和确定服务与组件。在我们定义了一些系统用到的服务之后，我们将以这些服务中的一个为例，定义该服务所需的不同组件。我的目标是传递给您一些概念，这些概念有助于您把您的系统定义成可管理的部分。
系统分析——识别组件
尽管提供一个完整全面的方法学不是本篇的范围，我还是愿意讨论几点问题。我们将从组件和服务的面向实现的定义开始，然后提供一个实践的定义。组件
一个组件是一个工作接口和该工作接口的实现的组合。使用组件提供了对象间的松耦合，允许改变实现而不影响使用它的代码。
服务
一个服务由一个或更多的组件组成，提供了一种完整的解决方案。服务的例子包括协议处理器、任务调度器、认证和授权服务等等。
尽管这些定义提供了一个起点，但它并没有提供一个完整图景。为了把一个系统（定义为一组设施，组成一个项目）分解为必要的组成部分，我建使用自顶向下的方式。采用这种方式可以在您了解到底有哪些设施之前，避免陷入到细节的泥潭中。确定您的项目范围
您的项目预期完成什么功能，一开始您总要有个大致的想法。在商业世界里，初始工作说明（initial statement of work ）就是完成这项工作的。在开放源代码的世界里，这通常是由一个想法或一个脑力激荡的过程完成的。我想不论如何强调具备一个项目的高层视图的重要性都是不过份的。很明显，一个大项目将由许多不同的服务组成，而小项目只有一两个服务。如果您开始感到有点不知所措，只需提醒自己大项目实际上是一把大伞下的许多小项目。最终，您将能理解整个系统大的图景。
工作说明：业务服务器
业务服务器（Business Server）是一个假想的项目。出于我们讨论问题的目的，它的功能是处理销售订单，自动向客户发出账单，并管理存货控制。销售订单到达时必须得到处理，通过某种类型的事务系统。在销售订单填写30天后，服务器自动向客户发出账单。库存由服务器和工厂或仓库的当前库存量同时来管理。该业务服务器将是一个分布式系统，每个服务器将通个一个消息服务来与其它服务器通信。
发现服务
我们将使用这个Business Server项目来发现服务。考虑上面的过于概括性的工作说明，我们立即可以看到项目描述中定义的一些服务。服务的清单可被分成两大类：显式的服务（可以从工作说明中直接导出的服务）和隐式的服务（根据相似的工作发现的服务，或对显示服务起支持作用的服务）。请注意，实现系统的公司不必亲自开发所有的服务 ——有一些可作为商业解决方案购买。在那些情况下，我们可能会开发一个封装层（wrapper），以便我们能够以确定的方式与商业产品实现互操作。实现系统的公司将构建大部分的服务。显式的服务
从工作说明中，我们可以快速导出一些服务。但这种初始分析并不意味我们的工作已完成，因为某些服务的定义需要其它服务的存在才能保证。事务处理服务
工作说明明确指出“销售订单到达时必须得到处理 ”。这表明我们需要有一种机制能够接受销售请求并自动地处理它们。这与web服务器工作的方式相似。它们接收到对资源的请求，进行处理并返回一个结果（如 HTML页面）。这被称作是事务处理。完整地说起来，存在不同类型的事务处理。这种一般性的事务处理服务极有可能必须分解为一些更特殊的东西，如“销售订单处理器“。具体方法取决于您的服务的通用性。在可用性和可重用性之间存在一种平衡。服务越是通用，它就越可重用。通常它也就越难于理解。
调度服务
在某些情况下，当事务完成，过了一段特定的时间之后，必须调度某个事件。而且，库存控制过程必需能周期性地开出采购订单。因为工作说明中指出“ 在销售订单填写30天后，服务器自动向客户发出账单” ，所以我们需要一个调度服务。所幸的是Avalon Cornerstone为我们提供了一个，这样我们就不必再自己写一个了。
消息服务
工作说明中指出，在我们的分布式系统中“每个服务器将通个一个消息服务来与其它服务器通信“。让我们来考虑这个问题，有时用户需要一个特定的产品或一种他们想用的方法。消息服务是利用其它公司产品的一个首选例子。极有可能，我们将采用Java Messaging Service (JMS) 来作为Messaging Service的接口。因为JMS是一个标准，它的接口不大可能短期内发生变化。从实践经验上来说，一个定义良好的面向消息的系统在可扩展性方面要强于面向对象的系统（如EJB）。可扩展性更好的一个原因是消息通常并发内存开销较小。另一个原因是它更容易把消息处理的负载分散到所有服务器上去，而不是把所有的处理集中在少量的服务器集群上（甚至是在一台服务器上）。
库存控制服务
尽管这不是一个教科书上的经典服务，但它是这个系统的一项需求。库存控制服务固定地监视工厂或仓库存货的记录，当存货开始不足时触发一些事件。
隐式的服务
运用在过去系统中获得的经验，将系统更进一步分解出其它服务，将得到没有明确指出但又是系统需要的一些服务。因为篇幅关系，我们将不做全面地分解。认证和授权服务
认证和授权服务没有在工作说明中明确地提到，但是所有的业务系统必须认真考虑安全性。这意味着系统所有的客户端都必须经过认证，用户的所有行为都必须经过授权。
工作流自动化服务
工作流自动化是企业系统中的一个热门开发领域。如果您不使用第三方的工作流管理服务器，您就需要自己写一个。通常工作流自动化所做的是使用软件系统来安排贯穿公司业务过程的任务。更多的信息请参考Workflow Management Council的网站http://www.wfmc.org/。
文档中心服务
作为一个任务的当前状态信息，"文档中心"这个词的定义很不精确。换言之，当公司接到一份购买订单时，我们的系统需要能够存储并重新调出购买订单信息。出账单和系统中其它任何过程，从库存到新的用户请求都有同样的需求。
小结
我希望Business Server项目的服务的例子可以帮助您发现更多。您会发现，当您从较高的抽象层逐渐转向较低的抽象层时，会发现需要更多类型的服务，如用于在一个打开端口上处理请求的连接服务。我们定义的某些服务将通过第三方的系统来实现，如消息服务和工作流管理服务。对这些服务来说，使用一个标准接口是最符合您的利益的，这样您可以在以后更换供应商。有些服务实际上是由多个服务组成的大服务。有些服务Avalon Excalibur或Avalon Cornerstone中已经提供了。在发现一个系统中的服务时，应该牢记的一件事是：一个服务应该是一个高层子系统。这将有助于您通过分析师团队来定义组件。因为我们已识别出了主要的服务，您可以让多个个人（或团队）并行地分解每个服务。子系统边界也定义良好，发生重叠的可能性很小。如果您决定进行并行分析，您应该回过头来识别通用的组件，以便能够尽可能地重用。
UML Diagram for the Business Server
发现组件
我们将以前面提到的文档中心服务为例来说明识别合适的组件的过程。为讨论方便起见，我们现在来列出文档中心服务的需求。文档中心将采用一个数据库来作为持久存储，对客户端授权，在内存中缓存文档。组件的实践性定义
当我们谈论组件时，您考虑问题的角度应该是：我的服务需要操作哪些设施？Avalon相信将系统投
最低0.47元/天 解锁文章
600
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
