使用Weblogic Integration的应用程序架构

　　我的答案是，根据具体条件，在每个层上定义多个项目。对于Workshop项目，以下方法可帮助您做出决策：

　　Bottom-up（自底向上）

　　这是一种由来自后端系统的启动窗体(starting form)组成的方法。对于每个后端，都应该定义一个或多个Workshop项目。随后（第3部分：对性能调优和部署的影响），我们将介绍定义多个项目的优点。这些项目根据需要可以是“控件”项目或“流程”项目。如果后端将使用一个Weblogic Integration事件生成器调用您的应用程序，您可能就要考虑为该后端定义一个流程项目。您可能还希望在该层定义应用XQuery转换的流程。一个好的实践是，不要在连通性层的Workshop项目中使用有状态的流程。

　　 然后向上在编排层添加流程以编排不同的后端。.

　　Top-down（自顶向下）

　　企业所需的启动窗体定义了用于表示企业和标准的XML模型的流程，该模型随后可被用于编排层。您可能希望以UML为起点，将域模型实体转换为XML“类型”，将实体组合转换为XML元素（文档）。在该层定义将被用作流程的参数的文档时要特别小心。

　　 将流程拆分为主流程中的子流程来表示业务，只有节点具有业务涵义。所有的细节都应该被抽取到子流程，如果可以的话，应该使用无状态的子流程。如果可以的话，惟一的有状态流程应该是最顶级的流程。从一开始就要考虑对有状态流程进行版本控制。

　　 从业务分析的角度将相关的流程聚合到不同的Workshop项目中。以每个项目容纳一个技术可重用方面的方式将所有技术可重用的流程放入特定的Workshop项目中。

　　 然后向下在连通性层添加控件或流程项目，以提供从标准模型到相关的后端模型的转换。

　　Meet-in-the-middle（在中间会合）

　　这是两种方法的结合。这种方法很难应用，因为它要取决于您对相关系统的了解。这种了解不只是业务方面的，还包括技术方面的。我认为最好是有一个或一组可以将应用的业务方面和技术方面结合起来的架构师。您可能希望专注于该应用程序中的一个选定的部分，覆盖一个重要的用例，并在开发过程中定义第一次迭代。

　　我们来考虑一个典型的例子：

两个后端系统，一个用于CRM，一个用于记帐

两组处理业务逻辑的可重用流程

一组表示业务流程或其一部分的长期活动的流程

一组处理错误的流程，这组流程是我们要处理的技术方面之一

　　如第一部分中所说，我们将使用由一个部署单元组成的单个Workshop应用程序作为起点，并记得随后可从不同的应用程序重用对后端系统的访问。如果在所有的应用程序内部都公开标准的XML模型，那么就很容易在不同的应用程序中重用对后端系统的访问。在流程之间传递的参数应该从设计角度和技术角度认真考虑，后者将在本系列的第3部分中进行讨论。

　　取决于后端系统的版本，对后端系统的访问可以有不同的生命周期，并且可以在开发过程的后期单独进行维护和部署。此后应用程序的这些部分可以在不同的Workshop应用程序中重新组织并公开为服务。如果这些服务由流程组成，那么可以通过web-services控件或流程控件/服务-调度程序控件对其进行访问。对这些服务的访问应该根据重用需求和重用来源进行考虑。在部署在同一个Weblogic域上的应用程序之间，如果考虑性能因素，那么就可能使用流程控件而不是服务调度程序控件。我们将在本系列第3部分中介绍性能问题。

　　现在我们回到定义应用程序的项目上。我们将从后端系统开始，考虑为第一个后端定义两个Workshop项目：

　　[MyApplication][CRMServices]Processes和

　　[MyApplication][CRMServices]Controls

　　，并为第二个后端定义一个项目：

　　[MyApplication][BillingServices]Controls

　　注意：

包含在方括号“[]”中的名称是变量。

对项目以及包含一组项目的Workshop应用程序的命名应该认真考虑。所有项目名称都应该以应用程序名称([MyApplication])为前缀。在本系列的第3部分我们还将讲到这一方面。

在定义项目时，我们假设CRM后端需要调用我们的应用程序。这通常是通过Weblogic Integration事件生成器实现的。这种情况下就必须有一个流程项目。可能还需要应用XQuery转换，以便将编排层中所使用的标准XML模型转换为后端XML格式，或将后端XML模型转换为标准模型。在这种情况下，可能需要一个流程项目，考虑只在流程项目中使用数据转换控制(dtf)。

Weblogic Integration事件生成器需要使用一个消息调度程序渠道来发送从后端接收到的消息。

对不同后端的访问是在不同的Workshop项目中完成的。这是有意为之的，在第3部分中我们将看到，这将对性能调优造成直接的影响。我们不希望来自后端的事件引发线程饥饿或可能的死锁。

　　在编排层，我们可以考虑定义4个项目：

　　[MyApplication][MyModule1]Processes

　　[MyApplication][MyModule2]Processes

　　[MyApplication][MyModule3]Processes

　　[MyApplication]ErrorManagerProcesses

　　在表示层，我们可以考虑定义两个web应用程序。其中一个用于与应用程序相关的管理性任务。

　　[MyApplication][MyModule1]Web

　　[MyApplication][MyModule2]Web

　　除了这些项目外，我们还可以定义一个用于可重用控制的项目和一个用于java类的项目：

　　[MyApplication][MyCommonModule]Controls

　　[MyApplication][MyCommonModule]Java

　　下图描述了所有这些：

　　最佳实践是在开始开发之前，画一张应用程序及其不同模块或Workshop项目的图。这项任务应该由软件架构师来完成并维护，需要考虑与开发、重用和性能调优相关的组织需求。

　　图中所使用的图形表示法：

　　注意：如图中所示，我们可以在流程项目中定义控件和定制控件。如果这些控件只由一个应用程序的一个项目使用，那么这是很实用的。只有用于同一个应用程序或不同应用程序的不同Workshop项目的公共控件需要在“控件”项目中定义。例如，流程控件可能被用于从同一个Weblogic域中包含该流程的项目/应用程序之外的另一个项目或应用程序调用流程。因此这些控件应该放入一个控件项目，以便可以在不同的Workshop项目中重用。如果需要在不同的Workshop应用程序中使用这些控件，可以考虑将其放入一个公共目录中，并通过引用或作为库将控件项目导入到不同的应用程序，控件项目将在应用程序的APP-INF/lib目录下生成一个jar文件。