重新部署了流程后，再次执行该流程时可在 ESB 控制台看到其实例。

　　考虑到性能和将 ESB 添加到图中的影响，需要注意的是 BPEL 和 ESB 以原生或内存方式通信(如果可能)。只有在分发后，它们才通过 HTTP 使用 SOAP 进行调用。此外，组件间的内存中优化可以针对 SOA 实现无缝的可跟踪方法。

　　第 2 步：在 ESB 系统内重用规范的模型和转换以实现“区别对待”

　　通过应用该模式，BPEL 流程可以保持一致性，专注于业务问题，而不是协议转换，并完全基于规范的模型进行工作。

　　第二步的目标是在 BPEL 流程中重用转换文件以及规范的客户模型，向外部服务使用方公开客户请求的规范表示。

　　重用 BPEL 流程的两个以上文件所需执行的第一个步骤就是引用这些文件。在示例中，第一个文件名为 CustomerUpdateProcess.xsd，其中包含了简介部分所述的客户模型。

　　第二个转换文件名为 Transformation_Cannonical2Protocol.xsl，可将规范的表示转换为原有表示。

　　执行完这些操作后，就可使用这两个文件了。在 ESB 系统图中，创建一个新的路由服务 (UpdateCustomerCanonical)，并添加一个名为“execute”的新异步操作。该新操作将从 CustomerUpdateProcess.xsd 模式中提取参数 CustomerUpdateProcessProcessRequest 元素。

　　接下来，通过创建新的路由规则将该路由服务连接到数据库服务 (UpdateCustomerService)，如以上屏幕截图的底部所示。

　　因为路由服务的输入与数据库服务的参数不同，所以这时要重用转换 (Transformation_Cannonical2Protocol.xsl)。

　　Oracle JDeveloper 中的 ESB 系统最终将如下图所示，其中包含两个路由服务：一个是规范服务 (UpdateCustomerCanonical)，另一个是具有原有格式及其公开操作(合并/写入)的服务 (PlainExposed)。

　　在企业服务总线内重新注册该系统后，就可向 BPEL 流程添加逻辑来调用该系统了。

　　在 BPEL 流程内，创建一个新 partnerlink，它指向路由服务 UpdateCustomerCanonical 的抽象定义 (WSDL)。而具体的绑定定义则再次添加为 wsdlRuntimeLocation 标志。因此，剩下的就是简单的分配了，如下图所示。

　　assign 规则 (Assign_ToInput) 将流程的输入变量挨个映射到 CanCustomerServiceESB 的输入变量。

　　一旦重新部署并执行了 BPEL 流程，就可在 ESB 控制台中看到该实例，如以下屏幕截图所示。

　　请看 BPEL 控制台，即便更改了 partnerlink，整个系统的可跟踪特性仍得到了改善，只需单击操作，用户就可跟踪实例从 BPEL 到 ESB，反之亦然。

　　结论

　　采用 BPEL 流程之前，该流程需要了解原有数据库服务及其格式，还有之间的转换，现在，原有服务对于流程完全透明。无需牺牲流程自身的编排就可对其进行替换。

　　应用这些模式和最佳实践的好处有哪些?业务编排完全基于规范的模型业务，而非由协议驱动。ESB 的引入提高了可靠性;利用其精确的错误诊断功能，您可以实时对故障做出反应、随时更改路由以及重试失败的调用。