dev2dev 首页 > 资源中心 > 专家Blog > 专家Blog文章
从应用程序基础架构到企业基础架构 - 第1部分
在以前的博客“使用Weblogic Integration的应用程序基础架构”中，我们已经为使用Weblogic Integration的应用程序基础架构提供了不同的方法。
本文旨在介绍某个Workshop/Weblogic Integration应用程序的应用程序基础架构。
在这篇文章中，我们将在应用程序上进一步使用一些步骤，将它拆分为多个应用程序，然后公开使用Web Services的一些部分。每个应用程序都公开为将成为SOA构建块的Web Service。
我们将从“使用Weblogic Integration的应用程序基础架构 – 第2部分”中公开的简单用例开始，并向企业基础架构移动，这样可以提高服务水平上的重用。
让我们回到“使用Weblogic Integration的应用程序基础架构 – 第2部分”中描述的典型用例，该用例大致包含以下内容：
- 两个后端系统，一个用于CRM，另一个用于记帐
- 两组可重用的进程，用于处理业务逻辑
- 一组长时间处于活动状态的进程，用于表示业务流程
- 一组用于处理错误的进程，这个组将成为我们希望要处理的技术方面之一
我们将这些内容总结在下图中：
图1
该图表示的内容是：
在图1中，有一个包含不同项目的应用程序，不同项目之间的通信是使用进程控件或消息代理器实现的。
在添加应用程序时，例如自助服务门户和一些用于制定决策的涉及人类交互的进程，我们可能会想将前面的应用程序拆分为可重用的多个部分，并与新应用程序共享后端访问。
这将导致图2中的现象：
图2
在图2中，如果所有的应用程序都在同一Weblogic域上，则它们之间的通信可以继续使用Process Controls或Weblogic Integration Message Broker来实现。
但在企业应用程序的上下文中，目标是能够在部署于不同域之上的服务之间进行通信，最终实现在不同网络中通信，并公开为可被企业中的其他应用程序重用的服务。
Weblogic Integration Processes可作为Web Service调用，不需要其他任何开发工作。另一方面，Common Workshop控件需要一个Web Services作为facade；使用Weblogic Workshop可以很容易地生成它。
图2看起来似乎有点简单；尽管如此，在实际上下文中，不同应用程序之间的通信会变得非常复杂：
-通信是以点对点的方式进行的，所以每个应用程序的配置会非常困难并且容易出错；所有应用程序都必须知道在哪儿可以找到其他应用程序。
-控制服务版本可能会变得非常困难：所有交互都依赖于每个服务的版本，因此，如果修改某一服务的接口，则需要更改所有访问它的客户端。
- 在使用Web Service时，没有保证某个SLA的简便方法。
- 没有以某种集中的方式轻松监视服务的方法。
- 用安全策略可能变得很困难；当公开服务以便在企业内部重用它时，这是必需的。
- 其他方面。
此后，当公开服务的应用程序逐渐增多时，应用程序之间的通信会变得混乱不堪（如果它们没有联合的话）。
当今企业应用程序中达成的一个常识是使用企业服务总线联合应用程序之间的所有通信。AquaLogic Service Bus在此上下文中可用作应用程序之间的中间层，如图3所示。
图3
在我们的用例中，使用服务总线作为中间层的直接好处（只提及其中的一些）是：
- 缓和点对点通信
- 能够在Web-Service上应用版本策略
- 保证服务质量并提供对服务的监视
- 处理用来访问服务的安全策略
在客户机应用程序中使用公开服务的过程并不是那么简单。即使有一个由每个服务公开的理想XML规范模型，仍然需要进行一些转换（以便从模型中提取数据），将表示某一实体或一组实体转换为表示另一个实体或另一组实体。从后端获取数据时需要实现的典型模式被应用到某一示例：
- 从帐户表示形式中提取数据，来自一个通过访问层的记帐后端，它返回规范的帐户表示形式。
- 用来自CRM后端的数据增强它。
- 转换此数据，这样进行订单处理的应用程序可以很容易地使用这些数据。
每次需要一些数据时，都由调节层中的应用程序完成这些处理。调节层上的每个应用程序都可以有自己的要求，因为它们可能将要处理不同组的实体。所以，在将调节层从数据访问层分离出来后，可能仍然需要在调节层进行一些转换。从概念上说，可能无法在调节层中干净利落地做到这一点，这取决于转换；所以，您可能想在服务总线中实现此模式。
使用Web Service进行的应用程序通信通常以更普通的方式完成的：
- 验证来自应用程序1的数据
- 使用来自另一个应用程序的数据增强此数据
- 转换此数据
- 调用目标应用程序
这是常见的集成模式，也可以将它委托给Service Bus。此模式也称为VETO（验证、增强、转换和操作）模式。
另一方面，数据访问层应该负责向上一层提供企业规范模型，在很多种情况下，可以使用基于SDO（服务数据对象，Service Data Object）的数据服务将此自动化。
实现数据访问层需要大量自定义代码，并且需要维护此代码。在应用程序基础架构的上下文中，访问数据可以使用一些人们所熟知的模式，比如DTO（数据传输对象），以及用来将应用程序与物理数据源隔离的数据访问对象（DAO）。此概念（即关注点分离）在使用数据访问层的企业基础架构中有所变化。数据从后端到企业规范模式的转换也可以通过很多工具得到自动化和简化。
在其他方面，对于企业基础架构而言，SOA的上下文中的通用数据访问层（即Data Service）可以视为后端到规范XML的映射器；对于构建应用程序访问数据库时广泛使用的O/R（对象与关系）映射工具而言也是如此。O/R映射器是适合在应用程序基础架构上下文中使用的工具；而Data Service是适合在企业基础架构上下文中使用的方法。
将AquaLogic Data Services Platform用作自动化数据访问层可以加速并简化SOA数据访问层的构建和维护。
图4
在这里可以查看图4的放大版本。
原文出处：http://dev2dev.bea.com/blog/becharag/archive/2006/11/from_applicatio.html
作者其它文章
|
