自 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> |
该转换利用 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 即可)，如下所示。
重新部署了流程后，再次执行该流程时可在 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 的引入提高了可靠性;利用其精确的错误诊断功能，您可以实时对故障做出反应、随时更改路由以及重试失败的调用。
(责任编辑：铭铭 mingming_ky#126.com TEL：（010）－68476636)