SOA架构

 

SOA架构

 

下图显示了SOA参考架构，其中包括Web应用层、服务层、应用层和基础架构层。
2.3.1 Web 应用层
此层的主要要求是所有业务系统和解决方案都可从任何支持的浏览器中访问。这一层是用户界面或
者表示层，包含企业基础架构服务和应用程序等组件的业务逻辑。
2.3.1.1 打包的应用程序
通常情况下，企业会批准满足其大多数业务要求的最佳的打包应用程序，然后让IT组织和系统集成
人员对打包的应用程序进行处理以便满足其需要。此类打包的应用程序的示例包括客户关系管理、
企业资源计划或特定行业的成套应用系统。
现在大多数打包的应用程序都是基于Internet协议的，这意味着用户可以使用任何支持的浏览器访问
许多功能。有些最新应用程序可以将有限的功能组作为离散的协作服务或外部控制的业务流程公开。
利用打包的应用程序的最佳实践包括：
_ 限制自定义开发的数量，使得维护和升级简单廉价
_ 尝试获得世界级的标准实现，从而减少集成和维护成本
_ 在可能的情况下使用打包的应用程序提供的UI和业务流程
_ 利用发布的应用程序编程接口（API）而不是直接访问数据库。
下面是在SOA成熟度模型中采用打包的应用程序的规定方法：
2.3.1.1.1 开发Web 应用程序
_ 部署可由任何浏览器访问的应用程序的最新版本；最好是支持适当的门户标准（如WSRP）的
版本。
_ 公开供自定义应用程序使用的应用程序服务，最好是作为Web服务。这可能要求适配器允许访
问应用程序。应用程序的一些最近版本能够通过集成网关或Web服务直接访问应用程序服务。
_ 通过合并企业外观（模板、皮肤、骨架和CSS）以及集成企业单点登录解决方案以提供完美的
用户体验。
_ 通过集成到企业标识和存取管理程序（通常是LDAP）将身份验证具体化。
2.3.1.1.2 开发复合应用程序
_ 标识可以作为复合应用程序在企业之间共享的业务对象
_ 将事件通知（触发器）发送到复合应用程序以启动特定操作
_ 修改业务流程和用户界面以启用复合应用程序
_ 公开附加业务服务以便复合应用程序能够与打包的应用程序同步。
2.3.1.1.3 自动化业务流程
_ 了解并建模业务流程以便标识重构机会
_ 标识业务流程中可由业务流程引擎自动化的可重用部分
_ 扩展公开的服务和业务流程的数目
_ 减少和合并部署的应用程序的数目。
2.3.1.2 自定义应用程序
组织可以选择开发自定义应用程序以创建独一无二的品牌并为客户和合作伙伴提供独特的体验。这
要求为内部和外部用户提供一致的完美接口。公司通常倾向于开发自定义应用程序，而不是对打包
的应用程序进行自定义，因为：
_ 修改核心事务的用户导航和用户界面并非易事
_ 大多数主要的打包应用程序并非基于公开的或标准技术，无法对其性能进行调整以适应业务需
要
_ 专有开发模型使查找资源或快速部署新业务功能变得困难
_ 与其他技术的集成不太容易实现，导致点对点的集成或者数据质量低下。
自定义应用程序的开发具有如下三个选项：
1、在应用程序服务器上开发和部署自定义应用程序
2、利用门户开发和部署自定义应用程序
3、使用基于开放标准的工具或者专用开发工具开发强大的客户端。
对于选项1和2，IT组织的第一个步骤是确定开发自定义应用程序的方法、基础架构和工具。此外，
IT组织需要定义治理和组织模型以便开发自定义解决方案。
对于选项3，强大的客户端自定义应用程序通常是使用SWING、Visual Studio或类似工具开发的。
这些强大客户端中的大多数都需要与一些外部系统相连接，建议的方法是利用开发标准（如SOAP、
Web服务、XMPP或WebDAV），而不是直接访问外部资源。此方法使得IT组织可以方便地支持和
升级集成。
2.3.1.2.1 自定义应用程序业务需求
大多数企业都已经部署了外部站点以及多个内部站点和应用程序，以支持各个业务单位的不同需要。
第一个步骤是在企业之间标准化这些站点的外观和基础架构，使得客户、合作伙伴或员工可以比较
方便地获得他们要查找的信息。
此阶段的业务要求包括：
_ 统一外部站点上的用户体验，使得潜在用户、合作伙伴、客户和分析人员能够方便地找到他们
想要查找的信息
_ 跨所有内部和外部站点标准化外观，并标准化发布内容的过程和流程
_ 为所有员工、承包商、合作伙伴和客户创建一个my<company name>站点以便提供个性化的服
务和内容
_ 提供的所有内部和外部站点的保密信息的安全访问
_ 提供具有高可靠性、可用性和可伸缩性的环境
_ 通过公共门户帮助铭记（branding）和访问多个应用程序
_ 允许用户在登录一次后访问所有服务
_ 基于用户的角色和责任提供个性化服务
_ 通过平台或环境的标准化降低维护多个系统和应用程序的维护成本
_ 标准化外观以消除多种用户培训要求
_ 降低操作和支持成本，允许IT将稀缺的资源部署在开发新功能上。
2.3.1.2.2 自定义应用程序架构方法
由于门户提供了一组经验证的功能来支持表示层，大多数IT组织已经开始标准化门户以便开发自定
义应用程序。

这个建议的架构具有以下优点：
_ 遵循SOA原则以提高各个级别的重用性
_ 提供在数周内而不是数月内提供产品或服务的能力（当具有了稳定的框架时）
_ 将产品用在它最擅长的领域，例如，使用门户进行基于权限的演示
_ 允许业务将服务组合起来以便提供新功能
_ 在域层提取数据源和相互关系，从而将更改源系统的影响降到最小
_ 使用松耦合的表示和业务逻辑使其更可靠，更可伸缩。
拟用结构中的每一个层都扮演着特定的角色：
表示层：“门户”负责处理所有表示服务。Portlet可促进用户体验的提升，其中portlet充当应用程序
的一个视图。
业务委派层：业务委派层是负责表示层和业务层之间的通信的组件。它们可提取访问业务层时所包
含的通信细则和复杂性。此层包括一个模型视图控制器框架，可帮助用户浏览网站。
服务层：服务层包含应用程序服务器的功能。该层由公开高级业务功能性的无状态功能组成。它具
有一个会话表面，这是到业务层的入口点，可提取处理来自表示层的细粒度业务实体的详细信息。
大多数业务逻辑都可以直接在会话表面或应用程序对象的子层上实现。
域层：域层也使用核心应用程序服务器。它是定义一致业务概念的业务实体集合。由于这些组件表
示不变状态，此层中需要使用处理数据库存储的技术。Entity Bean可用于实现对象模型的一些组件。
或者，简单传统Java对象（POJO）在数据访问对象（DAO）的帮助下提供一致性。Entity Bean是
实现此层的最佳机制，但是，如果对象模型比较复杂，则需要将此技术进行组合。
2.3.1.2.3 自定义应用程序框架组件
自定义应用程序框架组件可扩展应用程序服务平台中固有的服务。框架组件包括：
数据服务：为应用程序提供的持久层。容器管理足够健壮，可以利用CMP完成大多数简单的事务，
但作为处理复杂事务的选则应该提供DAO。
记录服务：应用程序用来记录和跟踪错误和活动的服务。要记录的消息类型包括要跟踪为进行诊断
而记录的所有问题、错误或故障以及为审计跟踪和用法分析而记录的活动的调试消息。每个企业都
应该标准化应用程序使用的记录服务，最理想的是利用JDK 1.4提供的功能。如果记录服务在整个企
业都一致，则允许工作人员更有效地确定性能或事务瓶颈。记录服务应标准化机制，使其与企业内
的整个开发社区进行通信，并确保与标准的兼容。不需要为此服务开发特定代码。
异常处理：管理和传达异常的机制。它与记录服务的类似之处在于团队应该利用标准应用程序服务
器功能。团队需要确定使用哪个机制并传达给企业内的整个开发社区。无需为此服务开发特定代码，
但如果团队提供了处理异常的示例的话也会十分有用。
部署/应用程序配置：记录配置详细信息的文档。这涉及标准化在各种环境下构建和部署应用程序的
机制，包括开发、QA、UAT、阶段划分和生产。
监控：监控过程的标准化和文档记录。由于操作人员必须监控平台和应用程序并预测性地解决问题，
IT内的大多数部门都已经标识和部署了监控工具。问题在于要标准化并集成监控过程和技术，以确
保所有系统中的数据的一致性。企业可能需要购买或开发并部署附加的专业监控工具。
搜索框架：搜索数据的共享功能。大多数门户应用程序都需要以表格形式向用户显示数据。团队不
应让每个开发人员都试图解决此问题，而应开发一个可应用于全部应用程序和门户的“搜索框架”。
下图演示了一个用作搜索框架的基础架构。

搜索框架提供：
_ 基于用户输入的动态查询生成
_ 排序次序、合并，等等
_ 用于显示的全部搜索结果
_ 一致的搜索处理机制
_ 字符转义和通配符解释
_ 标记页数
_ 从应用程序提取所有数据库访问代码
_ 用作输入的标准
_ java.util.List 等标准中需要的搜索结果
_ 外部文件上的查询
_ 处理公共UI任务的实用程序
_ 标记页数
_ 标准一致性。
通知框架：到所有应用程序的单个通知客户端。它应该支持到通知引擎的同步和异步接口，还应提
供通过多个通道发送通知的能力。

到不同通道的接口应该根据业务要求进行开发。
服务代理框架：提取服务实现详细信息。团队可在本地或远程部署服务，而不一定要使用服务的实
现详细信息或位置对调用应用程序进行编程。相反，服务定位器会确定服务的位置并通过合适的方
式进行调用。这支持多种代理，例如EJB、Web服务和服务总线代理；也可根据要求开发附加代理
类型。这也可由业务委派层用于将表示层从服务层分离开来。

安全框架：提供安全功能的企业级层。由于当前企业安全解决方案无法满足他们全部的业务需要，
大多数应用程序项目团队都开发了自己的安全层。支持客户端的安全框架可减少（如果不能消除）
为每个应用程序开发自定义安全代码的需要。下面是安全框架应该提供的一些功能：
_ 单点登录（SSO）：登录一次后无需再次登录就可以在应用程序之间来回切换的功能
_ 访问控制：用于三个主要领域的一组安全功能：
_ 身份验证：确定与应用程序交互的用户的身份
_ 授权：确定用户是否允许执行特定操作
_ 审计：跟踪用户执行的操作。
此外还需要几个辅助业务，例如注册、权限授予以及权限查询。这些功能应作为可由不同的应用程
序使用和重用的一般框架提供，每个功能都具有稍有不同的需要，但其基本要求都相同，包括：
_ 身份管理：具有多个用于管理一组应用程序或服务的访问控制信息的存储区可能会导致严重的
管理问题。身份管理可通过集中访问控制管理功能以及跨企业供应用户提供帮助。
_ 整合用户配置文件：门户提供这个功能的目的是允许应用程序扩展基本配置文件。此功能从多
个数据源提取用户配置文件，例如从应用程序特定的储存库提取基本配置文件和应用程序特定
的配置文件。
_ 注册、委派管理、供应和储存库：这些都是在访问控制顶部构建的，用于满足应用程序特定的
业务需要的安全扩展功能。或者，也可能是与访问控制集成的打包的解决方案。
门户产品可提供这些非自有功能的一大部分。如果不具有自己的开发自定义应用程序的门户，IT组
织将必须开发和支持此功能。
2.3.1.3 门户服务
门户服务管理应用程序的表示层。表示层通常都是基于权限的，因此需要支持此功能。
表示：门户表示功能为每个应用程序组提供外观、模板、构架和样式表。它还包括一些示例应用程
序，来帮助开始开发和利用门户导航功能，包括用于垂直导航条和水平选项卡。
个性化：门户提供个性化服务，例如portlet布局和背景模板选择。本文将在“企业安全”的配置文
件管理部分介绍应用程序环境下的附加个性化。
身份验证：所有门户产品都提供此功能。最佳实践就是使这项服务具体化。大多数企业都在其内部
实现了全局目录服务（如LDAP）。自定义应用程序框架应提供一个身份验证界面并使服务具体化。
单点登录（SSO）： ）： 企业应该不需要多次登录就能提供完美的用户体验。此框架组件不仅要支持自
定义应用程序，还应该支持打包的应用程序和企业服务。
2.3.1.4 企业基础架构服务
这些是基于应用程序的服务，该服务可供整个外部和内部用户群使用。大多数企业服务都是基础架
构组件，用户可将其中的一些组件提供的功能作为应用程序使用。下面是企业服务的一些示例。
目录服务：这是在全企业范围内提供的标准目录服务，通常与电子邮件服务结合使用。大多数企业
都实现了元目录，以便跨企业管理身份。
个人信息管理：这是标准的电子邮件、日历和地址簿功能，其中包括从任何通道访问这些信息的功
能。
协作：这提供了白板、电话会议、即时消息传递、论坛、新闻组和工作区等功能。
企业内容管理系统：这是驱动自定义应用程序如知识管理、资产或合同管理以及协作的基础架构服
务。规定方法是利用门户或内容管理提供商提供的API。所有领先的内容管理系统都提供了开发用于
上传和编写内容的模板以及用于管理批准流程的工作流的功能。
下面是实现企业内容管理系统的最佳实践：
_ 首先定义分类信息，理想情况是创建企业级分类信息。
_ 创建单个文件基础或储存库或企业级基础。这可能不太实用，但想法很好。
_ 将所有内容发布到生产环境中的单个位置，并将所有应用程序配置为从该位置检索内容，以便
降低TCO。
_ 培训作者和内容审批人以使用该系统。
_ 通过让提供商的架构师参与每个项目 与内容管理系统提供商紧密合作，尤其是在项目的设计阶
段。
_ 利用预先构建的portlet编写、审查和管理内容。
_ 在SI或内容管理系统（CMS）提供商的专业人员的帮助下将业务流程映射到CMS工作流。
搜索服务：这就使得所有外部或内部用户都可以找到他们有权访问的信息。存在多个搜索解决方案：
1. 关键字搜索，大多数用户都习惯的标准搜索功能
2. 自然语言搜索，通常用于刚刚使用该技术，想要通过使用自己当地的语言询问问题来查找
信息的非技术用户或Internet用户
3. 联合搜索，允许搜索结构化和非结构化的数据类型。
搜索引擎的集成非常简单直观。搜索引擎按请求的顺序处理XML或HTTP请求并返回结果。
搜索引擎与内容管理系统紧密协作。下面是最大程度地利用搜索引擎的一些最佳实践。
_ 为内容管理系统创建企业级分类信息。
_ 为内容定义元标记，并将其用于门户以便根据用户权限向用户显示内容
_ 使用搜索引擎根据需要crawl和创建多个集合和子集合
_ 根据需要在不同业务单位之间进行联合搜索
_ 利用门户标记和权限保护安全内容
_ 在应用程序服务器级别存储安全内容。
对于大型站点，crawl整个内容储存库的时间很成问题。根据业务需要，公司可以通过如下方式解决
这个问题：创建多个集合并在搜索条件中包含所有集合，周期性执行部分crawl，设置多个搜索引擎，
以及利用联合搜索。这有助于与搜索解决方案提供商协作开发架构和流程。
2.3.1.5 企业（基于角色的）门户
通过实现本文档中定义的网络层组件，企业可获得下图中描述的“当前状态”。

在这种状态下，IT组织可以以客户应用程序、打包的应用程序、企业服务或这些组件的组合的形式
快速部署业务解决方案。自定义应用程序框架允许业务提供格外好的用户体验。不过，它也具有如
下缺点：
_ 重新树立品牌（re-branding）用户体验可能会要求对所有站点进行更改。
_ 用户仍然需要知道每个站点的URL。通过采用一些最佳实践可以将这个缺点的程度减轻，但无
法完全消除。
_ 此模型可能会导致每个点解决方案的硬件和软件冗余。这是因为每个业务单位都想要调度自己
的维护窗口，而实现这个目标的唯一方式就是为每个点解决方案提供专用的基础架构。
目标状态是利用联合门户的概念创建基于角色的企业级门户。此方法的优点如下所示：
_ 为所有员工、客户、合作伙伴和其他用户提供一个入口点。
_ 基于用户角色的应用程序（Portlet）访问
_ 硬件和软件基础架构的整合
_ 总是打开的功能
_ 更简单的站点重新冠名
_ 联合门户通过利用服务提供的多通道交付。
2.3.2 服务层
服务层是SOA的主要启用程序，包括本节中描述的组件。
它允许在企业之间进行集成与业务流程自动化。此层基于粗粒度、松耦合的和基于标准的服务的
SOA原则。它通过为减少的应用程序和基础架构复杂性，业务服务增加的重用性，以及服务编排能
力，来帮助IT响应不断变化的业务需要。
2.3.2.1 服务总线
服务总线是为IT灵活性和与业务需求的调整提供面向服务的基础架构的关键组件。它应该与服务注
册表和服务管理组件进行完美集成，以便加速配置和部署管理并简化企业之间共享服务的管理。
该服务总线应该能够通过任何协议接受任何同步或异步消息，并根据配置规则将其路由到目的地。
此外，它应该能够将消息转换为目标要求的格式。由于这控制消费者和生产者之间的消息流，服务
总线在管理、监控和实施服务级别方面具有独特的地位。

上图表示企业服务总线（ESB）。ESB充当动态可配置的消息和服务代理。它提供了以下功能：
_ 异构环境之间的消息代理
_ 支持异步、同步、发布和订阅消息传递
_ 支持同步和异步桥接
_ 支持多种消息格式，包括SOAP、带附件的SOAP、XML、结构化非XML数据、原始数据、
文本以及带附件的电子邮件
_ 服务端点之间的异构传输
_ 支持多种协议，例如文件、FTP、HTTP(s)、多JMS提供商、RMI、Web服务、CORBA、
DCOM以及电子邮件（POP、SMTP和IMAP）和SIP。
_ 允许消费者与生产者交谈的消息转换，但不提供完全成熟的转换引擎
_ 配置驱动的路由
_ 基于策略进行消息路由，或者调用外部服务以支持复杂路由
_ 支持点对点和一对多路由方案，允许请求-响应和发布-订阅模型
_ 监控
_ 带搜索功能的服务监控、记录和审计功能
_ 捕获消息和传输属性的关键统计数据，包括消息调用、错误、性能、容量和SLA违反情况
_ 高可用性
_ 支持集群并跨集群收集统计信息以审查违反SLA的情况
_ 简化服务供应
_ 通过配置动态部署新的服务版本
_ 在设计、阶段划分和生产之间迁移配置的服务和资源
_ 支持消息资源的多个版本，通过灵活路由进行选择性的服务访问来配置这些版本。
_ 可配置的策略驱动安全
_ 支持用于进行身份验证、加密-解密和数字签名的最新的安全标准
_ 支持用于HTTP和JMS传输的SSL
_ 支持多个身份验证模型
_ 策略驱动的SLA执行
_ 根据各种属性建立SLA，包括吞吐时间、处理容量、消息处理的成功/失败比率、错误数、
安全违反情况和模式验证问题
_ 使用灵活的机制启动自动警告或启用操作人员启动的对规则违反情况的响应，这些机制包
括电子邮件通知、触发的JMS消息、触发的带JMS消息的集成过程，带JMS消息的Web服
务调用或者管理控制台警告。
下面是服务总线的一些最佳实践：
_ 在任何时候服务数目超过50时采用服务总线。如果服务数目超过150则必须使用服务总线。
_ 从小型规模开始，例如将目标定位单个复合应用程序或为跨越多个系统的分部业务流程。
_ 考虑让多个LOB根据自己的策略管理自己的服务总线，并使用一个跨不同的业务单元共享服务
的可充当代理的企业级服务总线。
_ 确定是部署供应商提供的服务总线还是内部开发的抽象层。
2.3.2.2 服务注册表
SOA要求服务是粗粒度、松耦合的和基于标准的服务。开发和部署服务后，必须为架构师、开发人
员、操作人员和业务经理提供可用的服务目录。

上图演示了服务注册表的架构。服务生产商为服务消费者用于运行时绑定的服务注册表发布了服务。
注册表还可充当业务策略在运行时执行的记录系统。
服务注册表应该提供下面的功能：
_ 核心服务，包括复制、UDDI数据存储和安全
_ 信息服务，包括数据验证、SOA映射、高级分类以及业务数据访问服务
_ 生命周期服务，包括批准和更改管理、更改通知、业务服务发现和QoS管理
_ 配置的基于Web的业务服务控制台
_ 与领先的启用、管理和安全产品连接的独立于平台的开放架构。
服务注册表的最佳实践包括：
_ 从小规模开始并逐步增长
_ 将服务注册表的每次实现复制到企业服务注册表
_ 为架构师、开发人员和操作人员提供服务浏览功能以帮助实现重用和标识服务依赖关系
_ 维护服务合同信息以及服务定义
_ 对所有服务进行版本控制。
上图演示了服务注册表的架构。服务生产商为服务消费者用于运行时绑定的服务注册表发布了服务。
注册表还可充当业务策略在运行时执行的记录系统。
服务注册表应该提供下面的功能：
_ 核心服务，包括复制、UDDI数据存储和安全
_ 信息服务，包括数据验证、SOA映射、高级分类以及业务数据访问服务
_ 生命周期服务，包括批准和更改管理、更改通知、业务服务发现和QoS管理
_ 配置的基于Web的业务服务控制台
_ 与领先的启用、管理和安全产品连接的独立于平台的开放架构。
服务注册表的最佳实践包括：
_ 从小规模开始并逐步增长
_ 将服务注册表的每次实现复制到企业服务注册表
_ 为架构师、开发人员和操作人员提供服务浏览功能以帮助实现重用和标识服务依赖关系
_ 维护服务合同信息以及服务定义
_ 对所有服务进行版本控制。
2.3.2.3 SOA 储存库
SOA储存库是在服务生命周期（从项目初期到完成）中管理元数据的关键组件。其主要目的是存储
详细元数据以便在部署前管理和治理资产。SOA储存库存储服务定义，以便团队可以检查企业内定
义了哪些服务。SOA储存库还存储了其他类型的元数据，包括过程映射、业务规则、实体和关系、
编排、转换、参考数据模型、业务活动和事件、审计要求、角色和授权映射，以及治理规则和策略。
储存库还可通过标识和管理依赖关系以最大化重用率来帮助减少“服务sprawl”。如果储存库中包
含来自组织的所有产品的元数据，则可为架构师和IT决策人员提供有关服务、系统和数据依赖关系
的有价值的总体观点。为了帮助业务、IT和操作人员进行正确的决策，SOA储存库应该将有价值的
资产存储为标准化治理流程、供销业务和技术最佳实践以及开发方针。
SOA存储库可在设计阶段帮助治理SOA资产。他们允许在SOA生命周期的不同阶段共享元数据，并
在资产填充到储存库中时提供一个理想的位置以触发批准工作流。储存库可帮助确保在资产在其生
命周期中得到合适的批准，同时降低服务的“独立开发”并支持进行较高程度的重用。
SOA储存库还提供了一个中心位置，用于管理与运行时执行（如路由、安全和SLA）的服务关联的
策略。储存库的依赖关系跟踪和影响分析功能可帮助团队管理对策略或其他资产的更改，并预测性
地分析更改对其他资产的影响。
SOA储存库应提供如下内容：
_ 发布和发现元数据（服务、业务流程、用户交互等）的能力
_ 按类别、复合应用程序名称、服务描述、范围（如分部或部门）或者储存库内跟踪的任何其他
元数据类型进行的复杂的元数据搜索
_ 服务依赖关系映射，用于跟踪服务依赖的资产以及依赖于此服务的资产
_ 元数据更改的通知
_ 可扩展元数据分类信息，以便业务可以根据自己的要求自定义分类信息
__授权过程，用于控制哪些人可以创建和操作储存库中包含的元数据
_ 所有资产的版本信息的维护
_ 影响分析，用于在进行更改前预测性地测量更改的影响
_ 与开发环境同步的开放的可扩展界面
_ 与其他外部存储的同步，例如注册表或其他储存库
_ 基于设计时策略的元数据的设计时语义验证
_ 批准工作流，用于提升或拒绝元数据
_ 多个同步储存库的联合和分区。
根据服务及其依赖关系的数目，为三个以上的项目采用SOA的IT组织可能会需要SOA储存库，尤其
当他们具有多个分布式开发团队以及许多服务时。如果组织成熟到可以重用服务来开发复合应用程
序、流程或服务，就需要使用储存库以便管理和治理重用性。
2.3.2.4 服务管理器
企业内的SOA实现变得越成熟，对总体服务管理器的需要就越发强烈。此服务管理器的主要功能在
于管理、监控和报告整个企业内的所有服务。下面是服务管理器需要提供的一些功能：
_ 管理和维护整个企业的服务级别
_ 跨企业映射和管理服务层次结构，并为操作提供依赖关系指标
_ 检测和管理异常情况
_ 审查和监控业务事务，并提供审查动态事务的功能
_ 管理服务生命周期并在部署前进行验证
_ 跨不同的系统提供非插入式服务发现功能
_ 管理多个服务总线和服务注册基础架构并与之集成
_ 利用现有监控基础架构。
2.3.2.5 共享数据服务
共享数据服务提供了多项关键功能：
_ 电子数据互换（EDI），使用网络在不同公司之间传输数据
_ 数据操作
_ 提取、转换和加载（ETL）
_ 企业信息集成（EII）
_ 数据质量
_ 数据匹配引擎
_ 数据工作
_ 工作流。
EDI和ETL是传统的方法，对于以批量模式处理大量数据尤其有用。不过，SOA有一个要求，就是能
够将一些EDI/ETL功能作为服务调用。例如，电子基金转帐必须从事件触发的源系统填充操作数据
存储。
2.3.2.5.1 企业信息集成（EII ）
EII引用软件系统，此软件系统可从各种内部和外部源获取不同格式的数据并将其看作单个数据源。

EII应该提供以下功能：
_ 跨多个源的数据建模
_ 查询（读写）开发以便从多个数据源提取信息。
_ 支持多种数据源，例如数据库、文件、应用程序适配器、LDAP和Web服务
_ 数据转换
_ 数据验证
_ 使用RMI或Web服务将数据服务公开到客户应用程序。
_ 坚持SQL、XQuery、XML、Web服务、JDBC以及J2EE等标准。
虽然定义了服务数据对象（SDO）标准以简化和统一应用程序处理数据的方式，但业界尚未清楚地
定义EII的标准。所有供应商都具有自己扩展，来处理对于每个数据存储的数据读取、数据更新以及
数据插入操作。