自 Oracle 将企业服务总线 (ESB) 作为 SOA 套件的一部分发布以来，许多人都很好奇，与仅在 Oracle BPEL 流程管理器内进行完整的自包含实施相比，ESB 所具有的附加值及其使用场合。

　　它的优势之一是能够对其用户透明地虚拟化服务端点，从而提供从其自有格式到规范格式的转换以及可靠路由。

　　在该技术说明中，您将通过两个有指导的步骤了解如何通过重用现有产品采用 BPEL 流程来利用 ESB 将原有服务虚拟化，以及这样做可以获得怎样的宝贵价值。

　　设置

　　现在，开始启动流程，您将通过应用该流程了解使用 BPEL 和 ESB 的最佳实践。我们已经创建了一个使用公用模式的异步流程，它代表一个规范的客户请求，以下为部分摘录：

[…]
<element name="CustomerUpdateProcessProcessRequest">
   <complexType>
  <sequence>
  <element name="customerName" type="string"/>
  <element name="ccard" type="string"/>
  <element name="ccardNr" type="string"/>
  <element name="email" type="string"/>
  <element name="pw" type="string"/>
  </sequence>
  </complexType>
</element>
[..]

　　该规范客户请求 (CustomerUpdateProcessProcessRequest) 包含名称 (customerName)、信用卡类型 (ccard)、信用卡号 (ccardNr)，以及电子邮件地址 (email) 和口令 (pw)。

　　本说明中探讨的示例流程将更新一个原有系统(在本例中为一个数据库)，该系统最后将由不同的数据结构替代，如下所示。

<xs:complexType name="Customer">
 <xs:sequence>
  <xs:element name="custid">
   <xs:simpleType>
    <xs:restriction base="xs:string">
     <xs:maxLength value="40"/>
    </xs:restriction>
   </xs:simpleType>
  </xs:element>
  <xs:element name="fname" minOccurs="0" nillable="true">
   <xs:simpleType>
    <xs:restriction base="xs:string">
     <xs:maxLength value="40"/>
    </xs:restriction>
   </xs:simpleType>
  </xs:element>
  <xs:element name="lname" minOccurs="0" nillable="true">
   <xs:simpleType>
    <xs:restriction base="xs:string">
     <xs:maxLength value="40"/>
    </xs:restriction>
   </xs:simpleType>
  </xs:element>
  <xs:element name="creditC" minOccurs="0" nillable="true">
   <xs:simpleType>
    <xs:restriction base="xs:string">
     <xs:maxLength value="40"/>
    </xs:restriction>
   </xs:simpleType>
  </xs:element>
 </xs:sequence>
</xs:complexType>

　　该流程在出站 partnerlink (UpdateCustomerService) 和输入变量之间使用 assign 活动 (Transform_Input2ProtocolSchema) 来将规范结构转换为原有结构。

　　该转换利用 XSL(XML 样式表转换)(之后可在系统中重用)。部分代码摘录如下所示。

　　第 1 步：不修改流程源而将原有服务调用移至 ESB 中

　　现在，流程已就位，周边情况已设定，第一个目标就是虚拟化 ESB 系统后的真实服务，并使调用对该 BPEL 流程变得透明。

　　应用该模式可使流程松散，但在其基础架构服务方面仍具有可靠的耦合，且无需知晓这些服务内容。如此，更改某项服务时就不会导致整体服务崩溃或更改。

　　因为 BPEL 流程内创建的文件具有很高的可重性，所以无需更改就可用于任何一个 ESB 系统内。

　　开始之前，在创建了新的 ESB 项目后，所有与 partnerlink 有关的文件都需在 ESB 项目中可引用。在生产环境中，架构师会将其存储在一个集中的模式服务器上或信息库中，以确保这些文件只存在一个副本。为了简单起见，您可以复制他们。

　　在使用数据库适配器的情况下(本例即是如此)，要复制的文件是

　　DBAdapterOutboundHeader.wsdl(头描述)
　　UpdateCustomer.wsdl(partnerlink 的服务定义)
　　UpdateCustomer_toplink_mappings.xml(TopLink 映射)
　　UpdateCustomer_table.xsd(数据定义)

　　执行完上述操作后，这些文件就可在新创建的 ESB 系统中重用了。第一步是以 UpdateCustomer.wsdl 为基础创建一个新服务 (UpdateCustomerService)(如下所示)。

　　其结果将是流程中 partnerlink 的一个完美克隆，它公开两个操作：合并和写入。一旦所有所需文件都可使用后，ESB 就可确定该服务的类型了：

　　接下来，创建一个使用同一定义 (WSDL) 的路由服务 (Routing Service)，以向外部公开合并/写入操作。将其命名为 PlainExposed 并包含两个路由规则，以只将请求转发至由数据库适配器公开的相应操作。

　　在 ESB 系统图中应用了更改后，将如下所示。

　　创建了该系统并将其注册到企业服务总线后，BPEL 流程就可使用它了 — 目前只能在运行时使用。

　　Oracle BPEL 流程管理器在 partnerlink 级提供了一个标志来为服务定义 (WSDL) 指定运行时位置。与编译时用于类型验证的位置不同，该位置用于调用。该标志名为 wsdlRuntimeLocation，如果设置了该标志，则它必须指向具体的 WSDL(其中包含一个绑定)。在本例中，它指向了 PlainExposed 路由服务的定义，该服务可在 ESB 控制台 (ESB Console) 中找到。在运行时，通过只在运行而非加载时获取绑定 WSDL，BPEL 流程将尽可能晚地进行绑定。

　　在 BPEL 流程内，可以直观地添加该属性(双击 partnerlink 即可)，如下所示。