Pamela Fong, 资深软件工程师, IBM

Dave Booz, 资深技术人员, IBM

Corville Allen, 软件开发人员, IBM

Mark Welesko, 资深软件开发人员, IBM

Olga Tikhonova, 顾问软件工程师, IBM

简介： WebSphere® SCA Feature Pack 实现 OSOA SCA V1.0 规范，提供灵活且轻量级的编程模型来实现面向服务架构（SOA）服务。WebSphere Process Server 是一个行业领先的流程集成服务器，在 IT 行业被广泛应用。Process Server V7 和 SCA Feature Pack V1.0.1 的最新版本已得到增强，可以在这两种运行时环境中进行事务和安全 SOA 服务的无缝互操作。本系列文章将帮助您配置并使用 SCA 绑定、Web 服务绑定和 JMS 绑定来连接这两种类型的服务。

简介

通过 WebSphere Process Server V7.0 和 WebSphere Application Server V7.0 Feature Pack for Service Component Architecture (SCA) V1.0.1，我们可以在使用 WebSphere Integration Developer V7.0（以下简称 Integration Developer）构造的 SOA 服务与使用 SCA 的 Rational Application Developer V7.5.5 之间进行互操作。本文是一个系列文章的第一篇，通过一个包含这两种组件的示例应用程序来说明如何利用 Classic SCA 与 Open SCA 之间的互操作性。在本篇文章中，我们将介绍 Classic SCA 和 Open SCA 的历史，并阐述如何组合、部署和测试由 Classic SCA 和 Open SCA 组件组成的应用程序。在后面的文章中，我们将应用程序更改为使用 JMS 和 Web Services 绑定。本文中讲述的互操作能力也适用于 WebSphere Enterprise Service Bus (ESB) V7.0。

先决条件

本系列文章假设您熟悉 SCA 概念并且具有开发 SCA 应用程序的经验。要查看并试用示例应用程序，需要安装下列软件：

WebSphere Integration Developer V7.0
支持 SCA 的 Rational Application Developer V7.5.5

动机

虽然支持 SCA 的 IBM 产品在继续改进和增强构造及支持 SOA 服务的能力，每个产品集都提供了独特的功能，可以联合起来提供一个全面的解决方案。WebSphere 业务流程管理（BPM）平台为构建业务流程、业务规则、ESB 中介以及自定义的基于传统 Java™ 对象（POJO）的业务逻辑提供 SCA 支持。WebSphere Application Server（以下简称 Application Server）为各种基于 Java 的编程提供 SCA 支持，例如 Java POJO、JEE 和 Spring。需要 SOA 方法和异构实现技术的应用程序方案可以受益于本系列文章中提到的技术。

历史和术语

在探究示例应用程序之前，需要确立一些术语来支持本系列文章中设定的上下文。词语 “互操作”（及其派生形式）只表示交换和正确解释在两种服务之间发送的消息的能力。需要注意的是，此定义明确略去了 “可移植性”，其定义为在一个平台上开发 SCA 组件而在另一个平台上部署该组件的能力。因为 SCA 是一个组件模型，其定义包含一个编程模型，所以可能会使人认为互操作也包括可移植性，但事实并非如此。

SCA 是在 2005 年发行 WebSphere Process Server 时由 IBM 首次开发的。至此以后它被并入到 IBM BPM 产品系列中，提供健壮且可伸缩的 SOA 基础设施，该基础设施在 BPM 平台中非常重要。在本系列文章中，我们将由在 WebSphere Process Server 上运行的 BPM 平台承载的 SCA 组件称为 “Classic SCA” 组件。WebSphere Process Server V7.0 就是这样一个平台。

同时，SCA 被引入一个称为 Open SOA Collaboration (OSOA) 的开放的行业协会。该团体是由 IBM 和行业合作伙伴联合建立的，作为一个开放的论坛，SOA 技术在被引入正式的标准团体作为官方标准之前将在该论坛中得到开发和优化。IBM 将 Classic SCA 作为 SOA 组件模型的基础贡献出去。OSOA Collaboration 在 2007 年完成了它的工作并将所得到的 SCA V1.0 规范贡献给 OASIS 作为标准。今天，OASIS 几乎完成 SCA V1.1 规范系列。在本系列文章中，术语 “Open SCA” 用于指示 SCA V1.x 平台承载的组件。WebSphere Application Server V7.0 Feature Pack for Service Component Architecture (SCA) V1.0.1 是本系列文章中将使用的 Open SCA 平台。

那么 Classic SCA 和 Open SCA 之间的区别是什么？正如技术委员会工作中经常发生的那样，反映用例、优先级甚至成员组织偏好的输入概念有改动。但是，重要的 Classic SCA 概念在 Open SCA 规范中仍保持不变。提供服务（服务接口）和使用其他服务（引用）的诸如组件的概念存在于这两种组件模型中。

组件具有一个通过其属性配置的实现。组件服务和引用都具有绑定，这些绑定配置为通过标准有线传输和协议（比如 Web 服务或 JMS）来进行通信。还有一个称为 “SCA（默认）绑定” 的非标准绑定，它提供一种简单的方式来连接远程服务。所有这些概念都同时存在于 Classic SCA 和 Open SCA 中。

本系列文章中使用的示例应用程序将阐释所有这些概念。下面是仍存在的主要区别列表以及一些简要说明区别性质的注释。本文不提供全面完整的比较。表 1 中列出了您在本系列文章中将遇到的概念。

表 1. Classic SCA 和 Open SCA 概念比较

Classic SCA	Open SCA	说明
模块	贡献	模块包含可以实现业务功能的编程工件和元数据。Open SCA 拥有相似的概念，称为 “贡献”。
库	贡献	库包含将在模块之间共享的编程工件和元数据。Open SCA 允许贡献充当共享工件容器。
导出	组件服务	导出用于描述模块提供的 SOA 服务的服务接口。在 Open SCA 中，服务可以带有绑定，因此不需要导出概念。
导入	组件引用	导入用于描述 SOA 服务的使用，这不是导入模块的一部分。在 Open SCA 中，引用可以带有绑定，因此不需要导入概念。
限定符	意图	限定符表示对某些运行时功能的需求，承载环境需要提供这些功能，例如 ACID 事务。Open SCA 具有相似的功能，内嵌在称为 “意图” 的概念中。这些通常是组件中需要的某种服务品质。
模块	组合	组合包含一个或多个组件以及组件之间的连接。Classic SCA 模块提供相似的机制。重要区别是组合还可以用作组件实现。

示例概述

本系列文章中使用的示例应用程序是一个虚构的糖果店应用程序，该应用程序是从 WebSphere Application Server V7 SCA Feature Pack V1.0.1 中的糖果店示例衍生而来的。糖果店的客户访问商店 Web 站点，从显示的在线目录订购糖果。该糖果店具有一项业务政策，在线订单必须超过 10 美元。当购物者选择完糖果后，他或她将通过结算流程来购买选择的糖果。结算过程将进入一个业务流程，该流程记录采购请求、检查业务规则以便确保满足订单下限，如果满足，将对客户的信用卡收费存档。最后，该业务流程记录处理采购请求的结果，然后返回。

该功能细分如下：

Web UI 交互：最终用户 Web UI 通过三个协作 JSP 来实现，这些 JSP 显示目录和购物者的购物车中的东西、收集购物者的客户编号，并提供成功采购的确认号码。
Open SCA 服务：有三种 Open SCA 服务。第一，糖果店提供目录和购物车功能。第二，对客户的信用卡收费的信用卡服务。第三，记录采购请求和结果的记录服务。
Classic SCA 服务：这是该示例的核心。它是一个 BPEL 微流程，在购物者结算时糖果店 Open SCA 服务将调用该微流程。它使用业务规则、Open SCA 信用卡服务和 Open SCA 记录服务。

客户端

最终用户交互由 Web 浏览器驱动。图 1 中显示了图形屏幕流程。

UI 视图

主购物屏幕从图 1 的左上角开始。它包含在线糖果目录和购物者的虚拟购物车中的东西。购物者已经完成购物时，单击 Checkout 按钮将使 UI 导航到第二个屏幕，在那里将询问购物者的客户编号。输入客户编号后，购物者单击 Buy it 按钮启动采购。此交互将导致运行付款业务流程。付款完成后，将返回确认号码。

服务

糖果店服务包含在 Open SCA 商店组合中，由三个 Java 组件组成，这些组件相互作用来提供购物车、产品目录以及商店自身的主要功能。这些组件如图 2 所示。

Open SCA 商店组合视图

StoreComponent 提供了一个 Web UI 层的服务接口，使用 StoreCatalog 组件来提供在线糖果目录，并使用 StoreShoppingCart 组件来存放购物者的当前订单。StoreShoppingCart 包含引用，但是请注意它不连接到此组合中的任何服务。引用将连接到 BPEL 付款业务流程，因此这是本文的要点。

Classic SCA 付款服务包含在 Classic SCA 模块内。图 3 显示了组合图表，说明提供在线订单付款的所有组件。

Classic SCA 付款组合图表

PaymentService 导出公开了一个供 Open SCA 商店服务使用的 SOA 接口。
PaymentProcess 组件存放 BPEL 流程实现。
ChargeLimit 规则集提供业务规则，强制在线商店 10 美元的下限。
CreditCardCharge 导入表示对信用卡收费服务的依赖，该服务不是此模块的一部分。
最后，AuditLogger 导入表示对审核记录服务的依赖，该服务也不是此模块的一部分。

CreditCardCharge 和 AuditLogger 导入都连接到 Open SCA 服务，本文后面将介绍这些服务。

图 4 中显示了 BPEL 付款业务流程。

付款业务流程

根据采购金额是否满足 10 美元的下限，业务流程有两条通路。如果订单的金额太低，则向调用者返回错误。如果金额超过下限，则向客户的信用卡收费。流程的所有通路都将调用审核记录程序来记录流程的始末。

示例中的最后两个服务是简单的 Open SCA 服务，每个服务通过一个组件来实现。CreditCard 组件提供信用卡收费功能，Logger 组件跟踪采购（以及采购尝试）。每个组件都包含在其自己的 Open SCA 组合中。

SCA 绑定

Classic SCA 和 Open SCA 都可以通过 SCA 绑定将远程服务连接在一起。SCA 绑定优于行业标准绑定（比如 Web 服务或 JMS）之处在于，SCA 绑定几乎不需要任何配置。SCA 运行时平台负责动态确定如何进行或接收服务调用。图 5 中完整呈现了示例中的所有 SCA 组件。

示例中所有 SCA 组件的视图

图表中的红线表示跨不同 SCA 运行时的连接。通过修改 SCA 绑定属性可以轻松配置这些连接。如果您希望直接跳到讲述如何配置这些红线的部分，则请继续阅读将 Classic SCA 连接到 Open SCA 和将 Open SCA 连接到 Classic SCA。

SCA 绑定限制

SCA 绑定具有一些限制，当设计包含来自 Classic SCA 和 Open SCA 的组件的应用程序时，这些限制非常重要。当限制不合适时，存在解决方案来减轻每种限制的影响。这些限制是：

WebSphere 单元约束：无法配置 Classic SCA 或 Open SCA 绑定来连接位于 WebSphere 单元之外的服务。通过使用 Web 服务、JMS 等行业标准绑定可以减轻此限制的影响。
WSDL 接口：Classic SCA 和 Open SCA 绑定之间的互操作性受限于 WSDL 接口。无法使用或公开具有 Java 接口的服务来进行 Open SCA 和 Classic SCA 之间的互操作。可以使用 Java 接口实现 Open SCA 到 Open SCA 或 Classic SCA 到 Classic SCA 的连接。WSDL 接口提供更多抽象，通常更适用于集成方案。仅对 WSDL 接口支持互操作性，该接口满足下列标准：
- Web Services Description Language (WSDL) V1.1
- WS-I Basic Profile V1.1
- Simple SOAP Binding Profile V1.0 标准
- 文档文字样式
Application Server V7 SCA Feature Pack 中的 Open SCA Java 编程模型没有用于异步调用请求响应服务的 API。即，当前没有编程模型 API 来发送此类请求、继续处理以及稍后在有响应时接受响应。在 Process Server 集成方案中，这意味着 Open SCA 组件不能通过需要响应的 SCA 绑定从 Open SCA 客户端调用长时间运行的业务流程（有时称为宏流程）。如果交互是单向的，则没有问题。OASIS SCA V1.1 规范中对此不足进行了说明。在解决该不足之前，Open SCA 组件必须使用一对单向接口来与长时间运行的请求-响应操作进行通信。

付款模块（Classic SCA）

本文结尾的示例工件包括您可以导入到 Integration Developer 的项目交换文件。将 Payment.zip 和 PaymentLib.zip 文件导入 Integration Developer V7.0。这样，将创建两个项目，一个名为 “Payment”，另一个名为 “PaymentLib”。下面的步骤显示了如何为相同的互操作性方案配置 Classic SCA 导入和导出。

将 Classic SCA 连接到 Open SCA

通过 SCA 导入绑定，Classic SCA 服务可以调用任何 Open SCA 域级别服务。不需要进行任何配置来公开该服务。

在我们的示例中，Payment 服务（一个 Classic SCA 服务）需要调用 AuditLogging（一个 Open SCA 服务）和 CreditCardCharge（一个 Open SCA 服务）。要查看如何进行该连接，您将项目导入 Integration Developer 后，在组合编辑器中单击名为 CreditCardCharge 的导入来显示其配置，如图 6 所示。

图 6. Classic SCA CreditCardCharge 导入配置

请注意 Module name 字段如何包含 Open SCA 组件的名称，该组件提供目标服务。Export name 字段包含 Open SCA 组件服务的名称。

检查 AuditLogging 导入来观察相似的配置。

导出 Classic SCA 服务

对于要调用 Classic SCA 服务的 Open SCA 组件，Classic SCA 服务应该具有 SCA 导出。请注意 Payment 服务的模块名称和导出名称，稍后当从 Open 连接到 Classic 时我们将需要该信息。在此应用程序中，模块名称为 “Payment”，导出名称为 “PaymentService”。

接口

CreditCardCharge 和 AuditLogger 导入都是通过导入直接从相应 Open SCA 服务获取的 WSDL 接口而创建的。不需要任何修改。

商店组合 (Open SCA)

现在我们将查看 Rational Application Developer 中的商店组合，来查看如何对其进行配置来连接到 Classic SCA Payment 服务。

将 CandyStore.zip 和 CommonArtifacts.zip 导入安装了 SCA 支持的 Rational Application Developer V7.5.5。

如果使用 Rational Application Developer 时需要刷新程序，请参考本文末尾的附录，来了解有关如何创建 Open SCA 组合的分步指南。本部分将重点讲述与 Classic SCA 服务集成所需的特定步骤。

准备付款接口

虽然人们更愿意将 Java 接口直接从 Classic SCA 组件移植到 Open SCA 组件，如我们上面所述，但是这是不受支持的。相反，将使用 WSDL 文件（该文件必须包含服务和移植定义）来生成 Java 接口以及任何 Open SCA 组件将使用的相关类型。Rational Application Developer Open SCA 工具需要同时拥有 WSDL 绑定和 WSDL 服务的 WSDL。

Integration Developer 引入的付款接口具有 WSDL portType，但是没有 WSDL 绑定和 WSDL 服务。这种情况的一个简单解决方法是将付款 WSDL 的副本放入 Rational Application Developer SCA 项目，然后使用 Rational Application Developer WSDL 编辑器来添加 WSDL 绑定和服务。

要完成此操作：

在编辑器中打开 WSDL 文件。右键单击画布并选择 Add Binding。
右键单击新的绑定并选择 Generate Binding Content。
选择 Payment 作为 portType，然后选择协议，此时选择哪个协议都没关系。选择 Overwrite existing binding information 并单击 Finish。
如果希望更改绑定的名称，可以通过单击 Property 选项卡并输入新的名称来实现。右键单击 WSDL 编辑器画布并选择 Add Service。输入 PaymentService 作为新服务的名称并按 Enter。
右键单击新的端口并选择 Set Binding > Existing Binding。单击您刚刚创建的绑定，然后单击 OK。现在 Rational Application Developer Open SCA 工具将可以使用 Payment WSDL。图 7 显示了完成上述步骤后 WSDL 编辑器的样子。

图 7. 导入到 Rational Application Developer 的 Payment WSDL

将 Open SCA 连接到 Classic SCA

在商店组合图表中，向下到达如图 8 中所示的付款参考。
在 CandyStore 项目下，导航到 SCA Content > Composites > http://soa.sca.samples.candystore/ > Store，并使用 SCA 组合编辑器打开 Store。然后选择付款参考。这是对 Classic SCA 付款组件的引用。

图 8. Rational Application Developer 中的商店组合
通过选择 Bindings 选项卡、展开 Bindings 并单击 SCA，向下导航到 SCA 绑定信息。构造对 Classic SCA 组件的引用非常简单，因为不需要任何特殊配置。
Open SCA 通过根据 Classic 模块名称和导出名称，比如 module_name/export_name，构造的 URI 来定位来自 Classic SCA 的服务。
因为 Classic SCA 模块名称为 “Payment”，导出名称为 “PaymentService”，所以示例的目标 URI 为 “Payment/PaymentService”。该 URI 将添加到 SCA 绑定配置。在 Rational Application Developer 中底部面板的 Properties 选项卡中指定该 URI，如图 9 中所示。

图 9. Payment 服务的引用目标 URI

部署示例

随示例提供了一个脚本来将服务部署到服务器上。

运行示例

部署 Classic SCA 组件和 Open SCA 组件，并测试示例应用程序。

启动 InteropCandyStore BLA 和 Payment 企业应用程序。
使用 Web 浏览器访问位于以下 URL 的应用程序：
http://localhost:9080/CandyStoreClient.war/CandyStore.jsp

请注意需要根据您的配置更新主机名称和端口。

安全性和事务传播

虽然上面的方案中没有介绍，Open SCA 和 Classic SCA 之间的调用还可以处理安全性和事务上下文传播。当在源和目标服务中启用相应的服务品质时将自动进行此操作。不需要在绑定级别进行任何其他配置。

结束语

WebSphere Process Server V7.0 和 WebSphere Application Server V7.0 Feature Pack for Service Component Architecture (SCA) V1.0.1 允许 Classic SCA 和 Open SCA 绑定之间的互操作性，从而为构造使用 Classic SCA 和 Open SCA 应用程序组件的 SOA 服务提供支持。本系列文章的第 1 部分简要介绍了 SCA 编程模型及其标准化演化。本文还说明了如何组合、部署和测试使用 Classic SCA 和 Open SCA 组件的示例应用程序，其中这些组件通过 SCA 绑定进行交互。本系列文章的第 2 部分和第 3 部分将进一步展开该示例，说明在需要标准互操作性时，如何使用行业标准 Web 服务和 JMS 绑定轻松替换 SCA 绑定。

附录

本部分提供了有关如何为本文正文中使用的示例应用程序创建 Open SCA AuditLogging 组合和 Logger 组件的详细说明。所有这些步骤都是使用支持 SCA 的 Rational Application Developer V7.5.5 来执行的。

创建 Open SCA 组件

创建组合

第一步是使用 Rational Application Developer 创建 SCA 组合文件。单击 File > New > Other。新的窗口打开时，向下滚动到 Service Component Architecture 并展开该文件夹，如图 10 所示。
选择 Composite 并单击 Next。您将看到如图 11 所示的窗口。输入下列信息：
- Composite Kind： Conventional Composite
- Project：Log
- Composite Name： AuditLogging
- Target namespace： http://soa.sca.samples.log/
- Composite path： /Log/AuditLogging.composite
单击 Finish。
使用 SCA 组合编辑器配置完组合。双击 AuditLogging.composite 文件。您将看到一个空窗口。右键单击空面板并选择 Create component，如图 12 所示。
将出现一个如图 13 所示的新组件。双击词语 component 并输入新的组件名称 Logger。
现在，返回组合编辑器，右键单击组件并选择 Creat Service。Logger 组件中将出现一个新的服务。单击如图 14 中所列的服务图标。
在 Properties 面板中，单击 Core 选项卡并输入 Logging 作为服务名称，如图 15 所示。
接下来，单击 Interface 选项卡（位于 Core 选项卡下面），然后选择 WSDL 作为接口类型。单击 Interface 字段的 Browse 按钮。从接口的可用列表中选择 Logging，然后单击 OK。现在 Interface 选项卡如图 16 所示。保存更改。

创建组件实现

现在您可以为 Logging 组件创建 Java 实现：

在 Rational Application Developer 中，右键单击 Logger 组件并选择 Regenerate Implementation，如图 17 所示。
此时将显示一个新的向导。选择 Java 作为 Implementation Type，如图 18 所示。单击 Next。
图 19 显示了向导中的第二个面板。接受默认值并单击 Finish。Rational Application Developer 会自动将新生成的类设置为组件实现。
除了生成概要实现外，Rational Application Developer 还生成符合 JAX-WS 的 Java 接口和 JAXB 类，以便处理接口类型。如果您在此步骤中收到错误消息，则可能因为 WSDL 中存在错误。一个常见错误就是在 WSDL 定义中遗漏了 WSDL 绑定和 WSDL 服务。
注意：
- 您还可以通过命令行运行 wsimport 工具。有关详细信息，请参阅 WebSphere Feature Pack for SCA 1.0.1 信息中心。
- 使用 Dynamic SDO V2.1.1 作为数据绑定也是受支持的，但是生成的接口将需要手动进行一些更新，如 WebSphere Feature Pack for SCA 1.0.1 信息中心中所述。

要完成该实现，请向方法架构添加简单的 System.out.println() 调用。打开 Log\src\soa.sca.samples.logging 下的 LoggingImpl.java 文件。通过添加 System.out.println 调用来更新该文件，从而与下面的代码匹配：

package soa.sca.samples.log.logging;

import log.samples.sca.soa.logging.*;
import org.osoa.sca.annotations.Service;

@Service (Logging.class)
public class LoggingImpl implements Logging{
@Override
    public void logOrderStart(String customerNo, double amount) {
		
	 System.out.println("Log record:  customer:"+customerNo+"
                   Amount: "+amount);
        
    }

    @Override
    public void logOrderComplete(String customerNo, String confirmationNumber) {
        
	 System.out.println("Log record:  customer:"+customerNo+" 
                   ConfirmationNumber: "+confirmationNumber);
		
    }

    @Override
    public void logOrderError(String customerNo, String error) {

	 System.out.println("Log record:  customer:"+customerNo+"
                   Error: "+error);
		
    }
}

保存对 LoggingImpl 文件的更新。

创建 SCA 贡献

接下来，创建 sca-contribution.xml 文件，以便 Open SCA 定位您的组合文件：

在 Rational Application Developer 中，转至 File > New > Other。出现新的窗口时，向下滚动到 SCA，展开该文件夹，然后选择 SCA Contribution，如图 20 中所示，单击 Next。
在接下来的面板中，选择 Log 作为 Project，然后在 Deployable composites 下选择 Log，如图 21 中所示。单击 Finish。
新的贡献将由贡献编辑器显示在一个新的窗口中，如图 22 所示。
选择 Add for Exports。如图 23 所示，将出现一个新窗口。选择 Export，然后选择 OK。
最后，将出现另一个新窗口，如图 24 所示。输入名称空间 http://soa.sca.samples.log/Logging，然后单击 OK。保存所做的更改。

客户端

将 CandyStoreClient.zip 导入到 Rational Application Developer。

在 Web 客户端中获取 Open SCA 服务

该项目将用作一个客户端来访问和调用 SCA 组件。因为这是一个 Web 应用程序，它将不在 SCA 环境中运行，将无法通过引用注入来访问 SCA 服务。相反，可以使用 CompositeContext API 来获取 Open SCA 服务。可以通过调用静态方法 CurrentCompositeContext.getContext() 从 SCA 环境外部获取 CompositeContext。

使用指向 CompositeContext 的指针，可以调用下面的方法来获取指向服务的指针：

 B getService(Class businessInterface, String referenceName)

在新项目中，导航到 WebContent > WEB-INF，然后打开 CandyStore.jsp。

请注意，JSP 通过调用 compositeContext.getService 来获取指向 CandyStore 服务的指针，如下所示：

private static Store storeService = null;
private CompositeContext compositeContext = null;

public void jspInit() {

    if ( storeService == null) {      
        compositeContext = CurrentCompositeContext.getContext();
        storeService = (Store)compositeContext.getService(Store.class, 
        "StoreComponent");
    }
    
}

getService 参数 Store.class 是指在 CommonArtifacts 项目中定义的商店接口，StoreComponent 参数是指在 CandyStore 项目中定义的 Store.composite 中定义的组件。

包含该客户端的其他两个 JPS 使用相同的方法来获取 Open SCA 服务。

原文链接:http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1005_fong/1005_fong.html

ITPub博客

集成 WebSphere Process Server 与 SCA 功能包，第 1 部分

最新文章