随着企业内部 Web 服务和 BPEL 流程的激增，服务质量成为是否采用特殊服务的决定因素。如何确保服务实现所请求的功能，而不受各种障碍(如网络故障或应用程序不可用)的影响?服务能否在不同的业务流程中使用?所有这些问题的答案将决定某个特定业务流程的可重用性。业务流程的可靠性越高，跨多个应用程序的流程的可重用性就越高。

　　在 BPEL 简明手册的本部分中，我们将介绍一个由多个应用程序组成的业务情形。该情形演示了能够提供可靠功能的 BPEL 流程的必要性，以及如何在不同的业务情形中多次使用此 BPEL 流程。然后，本文将引导您逐步构建一个通过智能重试逻辑提供此高质量服务的 BPEL 流程。此外，您还将了解如何通过出色的异常管理、基于电子邮件的通知以及错误记录来增强此流程。

　　业务情形

　　服务可重用性是任何面向服务体系结构 (SOA) 策略的基石。只有能够创建一组可重用服务，企业才能从 SOA 实施中取得真正的价值。这些服务随后将由不同的部门或应用程序在不同的业务环境中使用。除了所提供的实际业务价值以外，服务的成功情况还将推动特定服务的可重用性。服务的故障率是多少?服务能否克服网络中断?服务是否足够灵活，从而实现错误与异常恢复?服务完成请求作业的可靠程度越高，服务在不同业务环境中得到使用的可能性就越高。

　　看一看图 1 所示的情形:企业需要向不同合作伙伴提供产品的技术文档。文档的访问级别取决于合作伙伴类型以及所请求的产品文档。该信息存储在 Oracle 数据库中。随着合作伙伴加入和离开网络，需要通过多个企业应用程序中的相应审批和更新来修改提供的信息(添加/更新/删除访问权限)。

　　图 1 授权提供环境

　　在授权数据库中激活、禁止和修改授权后，必须向 Documentum 发送通知。授权更改的发送顺序必须与其创建顺序一致。必须确保消息的完整性，并且必须维护完整的审计日志并将其记录到中央应用程序数据库日志中。

　　BPEL 在编排授权激活和禁止方面起到至关重要的作用。此 BPEL 流程将与 TIBCO 消息传递总线紧密协作，以便可靠地向 Documentum 传递消息。它还将负责错误记录和通知。该流程执行任务的效率和可靠性必须足够高，以免因网络中断或 Documentum 应用程序不可用而中断。它应能够不断的尝试操作，直到完成其任务。如何开发能够进行可靠处理的类似 BPEL 流程?