使用应用程序平台跨越SOA障碍

使用应用程序平台跨越SOA障碍

作者：Andy Lin和Som Sengupta

据Gartner估计，到2008年，超过60%的企业在创建关键任务的应用程序时，将会使用面向服务的架构（SOA）作为主导原则。 如果正确实施，SOA有望提高开发速度，并缩短集成时间。本文重点讨论了SOA实施中的一些挑战，并演示了使用Application Platform实现SOA的可行性。我们用BEA WebLogic Platform 8.1来说明如何使用它处理各种SOA实施问题，包括开发和集成成本、安全、事务和服务控制与管理。我们还进一步提供了一个示例（demoApp）来说明一些架构模式，这些模式有助于正确实施SOA。

SOA及其实施挑战
SOA是一个围绕网络上能够互相通信的服务集构建架构。这些服务互相松散耦合，具有明确定义且独立于平台的接口，并且可以重用。
通过SOA与现有系统的集成变得容易，同时正确帮助公司提高适应不断变化的业务要求和市场条件的能力。更加容易的集成和更好的灵活性能带来更大的投资回报。

为了正确实施SOA，首先我们必须理解它。以下部分对SOA的技术方面进行了说明，并着重讨论了实施SOA过程中的一些挑战。

SOA的技术方面：定义
服务：执行业务过程的软件组件组。
松散耦合：一个服务中产生变化，不要求所链接的服务也进行变化。
可重用的：通过集中精力于业务过程并使用独立于平台的接口，SOA帮助掩盖了服务的技术复杂性。
QoS要求：由于服务松散耦合，并且是粗粒度的，所以在实施SOA时应当考虑QoS要求。
企业服务总线（Enterprise Service Bus）：是一种实施SOA的方法。它是一种使用标准接口和消息传送来进行应用集成的软件基础架构。
SOA和Web服务：帮助实现SOA良好实施的Web服务标准，尽管它们互不依赖。

实施SOA的挑战
本节着重讨论建立SOA中的一些挑战。以下各节为这些挑战提供了更加详细的分析，并提供了根据WebLogic Platform的使用来有效解决这些问题的策略。

q 开发和集成成本
 t 重新设计您的现有系统成本太高。
q 安全
 t 在封闭的系统中实施安全性总是比在开放的架构中容易。
q 事务
q 服务控制和管理标准
 t 围绕Web服务的标准仍正在形成之中。

应用程序平台
Gartner定义了一个集成的应用程序平台，该平台包括一个企业应用服务器、一个集成代理和门户服务器。Application Platform共享一个单一中间件基础架构、单一系统管理、单一开发工具集、单一Web服务框架和一个共享的元数据仓库。

Application Platform为以下任务提供了框架：
q利用OS管理硬件
q维护对应用的透明通信通道
q 分配和安排通信信道（缓冲池）
q提供对其他EIS系统的透明连接
q确保深度安全性
q 事务支持
q业务过程引擎
q消息代理
q数据表示层
q通用开发环境
q服务管理控制台

典型的J2EE应用程序平台由以下组件构成：
qJVM：用于代码执行的管理环境
q应用服务器：为分布计算提供基础架构支持
q集成：业务过程和消息代理
q门户：用于数据表示和用户交互的框架

BEA WebLogic Platform 8.1是一个集成式平台，它使Web应用程序、Web服务、企业级Java Bean、工作流、消息传递应用程序、企业门户、贸易合作伙伴应用程序以及更多内容的组合开发成为可能。它由以下组件组成：
qWebLogic JRockit 8.1
qWebLogic Server 8.1
qWebLogic Integration 8.1
qWebLogic Portal 8.1
qWebLogic Workshop 8.1

使用应用程序平台实现SOA的可行性
面向服务的架构确保了每个服务只有在具备以下特点后才能对其他服务可用：
q异步互动
q服务间松散耦合
q粗粒度通信

一个应用程序平台用很简单的步骤就可以集合基础架构支持来实现这一点。以下步骤能使围绕应用程序组件的SOA成为可能：
q创建一个自定义控件
q建立一个新的或重用现有的转换控件，并将其连接到自定义控件上
q用异步Web服务包装自定义控件

使用上面提到的步骤，其原理如下：
q自定义控件可理解的消息格式能够通过修改业务标准进行改变。其他连接到针对Web服务的自定义控件的组件不应该被这个变化所影响。与自定义控件相关联的转换控件用于该目的。
qWeb服务遵循一种开放的通信标准。同时，通过使用异步paradigm和自描述SOAP消息交换，自定义控件能够克服语义障碍。
q如果使用Web服务封装器来加入一项代理服务，那么自定义控件就能够将其范围扩展到完全隔离和独立的系统。

解决SOA中的开发和集成挑战
新的应用开发要求一个统一的、简化的平台来减少成本和障碍。重新设计您现有的系统架构需要一个开放和可扩展的平台，该平台还要支持通过基于标准的接口与原有投资和互补应用程序进行集成。

Gartner Consulting对BEA开展了一项研究“Application Platform Suites: An Architectural Cost Analysis”，该研究分析了在集成式和非集成式平台上实施的企业应用程序，并发现集成式平台可显著地缩短上市时间并降低IT成本，特别是它能够帮助：
q缩短上市时间22%
q在整个应用程序生命周期节省25%成本
q重用软件组件和服务

SOA中的安全挑战
在应用程序架构中实现SOA会带来以下安全挑战：
q安全策略构建和分发机制应该独立于任何特定的应用程序基础架构技术。
q 基于消息的安全上下文传播是必需的。
q安全信息交换应该在一个通用逻辑层次上，也就是说，独立于内部的安全技术。
q 在一个松散耦合的环境中，每一个服务都应该是内在安全的。旧类型的网络安全（使用防火墙）是不够的。
q基于消息内容的筛选对于基于Web服务的调用变得更加重要。

WebLogic Platform 8.1的安全支持
基于WebLogic 安全框架（Security Framework）上建立的Platform Security：
q支持消息签名
q 允许基于消息的身份声明（identity assertion）
q 减少应用程序内安全代码的开发
q适应业务安全策略中的变化，而不需要修改应用程序代码
q与现有安全产品集成
q与BEA应用安全产品套件进行互操作
q 跨不同应用程序路径的安全支持
下面的示例指出了整个基于SOA的部署中的关键安全点（见图1）：
q跨Web应用程序的单一登录
q针对每个用户的个人化视图
q与SAML身份声明程序集成
q基于消息的安全上下文传播
q 用于任何用户访问的基于角色的配置文件
q用于任何已部署应用程序的集中化和基于策略的访问控制
解决SOA中的事务挑战
一个大的业务事务应该拆成一系列运行时间短的原子事务：
q需要适当的补偿动作来回滚已完成的原子事务的作用
q 每个服务可能与涉及其他服务的长时间运行的事务关联
q 原子事务的持续时间应该足够短，并且应只涉及对该服务来说是本地的资源

WebLogic Platform 8.1的事务支持
使用WebLogic Platform 8.1：
q 一组与单个工作流或子工作流关联的自定义控件能够使用隐式地可用的事务基础架构
q 两个异步连接的工作流使用两个和工作流关联的不同的原子事务
q 它们之一发生的失败能够通过回调传播，因此能够采取适当的补偿措施
q Web服务对话帮助维护事务相关性

已经建立了一个WebLogic Integration应用程序来演示跨两个工作流实例的松散耦合事务（参见图2）。 这两个工作流通过异步Web服务进行通信。
交互步骤如下：
q Perform节点用作自定义控件wrapper，并使得原子事务能够对它们可用。
q Workflow1包括一个原子事务。在该事务中，它通过自定义控件执行业务操作，并通过一个Web服务对话启动workflow2。
q 当原子事务回滚时，异常处理器“HandleAtomicException”（与workflow1关联）被触发。
q Workflow2包含原子事务。如果失败，它将通过会话Web服务回调通知Workflow1。
q Workflow1接收到Web服务回调。Web服务基础架构的会话支持帮助在workflow1和workflow2之间创建一个事务关联。
q 如果通过Web服务回调接收到的消息指出workflow2中的原子事务失败，那么将会通过异常处理器“Undo Perform”采取一个补偿措施。
q Web服务可靠性支持被用来确保关键事务交互的可用性。

关于demoApp源代码的URL，请参阅附录。该示例在WebLogic Platform 8.1 (Service Pack 2)上的一个WebLogic Integration domain中进行了测试。

解决SOA中的服务控制和管理挑战
下面对管理和监视服务的需求进行说明，服务管理需求包括以下内容：
q 统一策略配置
q 分布式SLA执行
q QoS和可靠的消息传送
q 服务供给
q 服务路由和故障恢复

服务监视需求
BEA一直与许多第三方公司合作来支持WebLogic Platform上的服务管理和监视。例如，Blue Titan和Confluent提供的控件已经和WebLogic Platform 8.1捆绑（从Service Pack 2开始）。
Blue Titan是BEA的一个战略合作伙伴。Blue Titan和BEA提供了一个联合解决方案，为企业提供建立、部署和控制不断增加的分布式Web服务应用程序所需的所有要素。通过使用Confluent for BEA，在BEA WebLogic Workshop 8.1中开发的服务就能够在开发期间被自动监测、管理和保护，而不需要编写任何额外的代码。
Confluent for BEA
q Confluent 管理平台
 t Confluent 策略管理器
 t Confluent 监视器
 t Confluent 代理和网关
q Confluent Instrumentation Control
 t 提供细粒度的监测。在Confluent for BEA自动完成的监测之外，为开发人员提供一个仪表水平的监测
Blue Titan for BEA
q  Blue Titan Network Director
 t Blue Titan Manager：提供所有的策略创建、持久性和状态管理功能
 t Blue Titan Engine：传播策略更新和队列日志信息
 t Blue Titan Control Point：执行和实施策略

在应用程序平台上实施SOA
正确的架构模式能够帮助促进SOA在应用程序平台上的实施。在这部分中，我们提供了一些示例来说明各种平台（BEA）组件之间松散耦合的交互。
在NetUI和自定义控件之间的数据转换层带来了设计上的灵活性。任何在页面流和输入字段中的改变都能够通过数据转换来封装。数据转换和通信机制的细节以可重用的方式被封装进自定义控件中。通过容纳表示用户交互数据的经过更新的模式，不同类型的页面流能够和自定义控件相关联。
调用流程控件的Web服务能够用作输入验证、路由和内容筛选的中介。这可帮助将多个流程流（process flows）和基于NetUI的前端连接起来。业务过程实施中的变化或它们的宕机时间能够对业务过程的用户隐藏。

NetUI to Database via DB/AI Control
调用AI控件的Web服务能够被用作输入验证、路由和内容筛选的中介。这可帮助将多个后端系统与基于NetUI的前端连接起来。后端企业实施的变化或它们的宕机时间能够对那些企业系统的用户隐藏。最终，这个架构模式将后端企业提供为可重用的松散耦合服务。
使用Web服务作为中介，可以连接防火墙后的企业系统。

未来趋势
在本文中，我们介绍了一些和SOA实施相关的挑战，并详细说明了一个应用程序平台（例如WebLogic Platform 8.1）如何帮助有效地处理这些挑战。尽管围绕SOA和Web服务的标准还正在形成中，我们预计它们中的一些将会对下一代的应用程序平台有重要的影响：
q  BPEL规范正在为业务过程交互协议引入开放标准。
q  WS-Policy规范给跨企业的规则和策略管理带来了一个逻辑层次的抽象。
q  XAML正引入一个通过逻辑构造来表示用户接口要求的标准。这将帮助实现跨不同用户接口的互操作性。