实例教程.pdf

BPELBPEL 实例教程实例教程了解如何创建一个将一系列虚拟的、与旅行相关的 web 服务结合起来的示例业务流程，然后将其部署到 Oracle BPEL Process Manager 运行时环境。本文相关下载示例代码 Oracle BPEL Process Manager 和 Designer面向 Web 服务的业务流程执行语言(BPEL 或 BPEL4WS)是一种使用 Web 服务定义和执行业务流程的语言。BPEL 使您可以通过组合、编排和协调 Web 服务自上而下地实现面向服务的体系结构(SOA)。BPEL 提供了一种相对简单易懂的方法，可将多个Web 服务组合到一个新的复合服务(称作业务流程)中。本文将介绍如何创建一个将一系列虚拟的、与旅行相关的 web 服务结合起来的示例业务流程，然后将其部署到 Oracle BPEL Process Manager 运行时环境。BPEL 背景知识首先，介绍一些背景知识。BPEL 基于 XML 和 Web 服务构建；它使用一种基于 Web的语言，该语言支持 web 服务技术系列，包括 SOAP、WSDL、UDDI、Web 服务可靠性消息、Web 服务寻址、Web 服务协调以及 Web 服务事务。BPEL 代表了两种早期工作流语言-Web 服务流语言(WSFL)和 XLANG 的交汇。WSFL 由IBM 基于有向图概念设计。XLANG 是一种由 Microsoft 设计的块结构化语言。BPEL组合了这两种方法，并提供了丰富的词汇来描述业务流程。BPEL 的第一个版本诞生于 2002 年 8 月。此后，随着许多主要供应商(包括 Oracle)的纷纷加入了，催生了多项修改和改进，并于 2003 年 3 月推出了 1.1 版。2003 年4 月，BPEL 提交结构化信息标准促进组织(OASIS)以实现标准化，并组建了 Web 服务业务流程执行语言技术委员会(WSBPEL TC)。该努力使 BPEL 在业界获得更广范围的认可。在企业内部，BPEL 用于标准化企业应用程序集成以及将此集成扩展到先前孤立的系统。在企业之间，BPEL 使与业务合作伙伴的集成变得更容易、更高效。BPEL 激发企业进一步定义它们的业务流程，从而导致业务流程的优化、重新设计以及选择最合适的流程，进而实现了组织的进一步优化。BPEL 中描述的业务流程定义并不影响现有系统，因此对升级产生了促进作用。在已经或将要通过 Web 服务公开功能的环境中，BPEL 是一项重要的技术。随着 Web 服务的不断普及，BPEL 的重要性也随之提高。编制与编排Web 服务通常公开某些应用程序或信息系统的操作。因此，组合多个 Web 服务实际上涉及基础应用程序及其功能的集成。可以用两种方式组合 Web 服务：编制编排在编制(通常用于专用业务流程)中，一个中央流程(可以是另一个 Web 服务)控制相关的 Web 服务并协调对操作所涉及 Web 服务的不同操作的执行。相关的Web 服务并不知道(也无需知道)它们参与了组合流程并在参与更高级别的业务流程。只有编制的中央协调员知道此目标，因此编制主要集中于操作的显式定义以及Web 服务的调用顺序。(见图 1。)图 1：通过编制组合 Web 服务而编排并不依赖某个中央协调员。相反，编排所涉及的每个 Web 服务完全知道执行其操作的时间以及交互对象。编排是一种强调在公共业务流程中交换消息的协作方式。编排的所有参与者都需要知道业务流程、要执行的操作、要交换的消息以及消息交换的时间。(见图 2。)图 2：通过编排组合 Web 服务从组合 Web 服务以执行业务流程的角度而言，编制是一个更灵活的范例，它相对于编排而言具有以下优点：元件流程的协调由某个已知的协调员集中管理可以组合 Web 服务而不必使它们知道它们正在参与更大的业务流程可以准备其他方案以防发生故障。BPEL 支持两种不同的业务流程描述方法(支持编制和编排)：可执行流程允许指定业务流程的准确细节。它们遵循编制范例，并可由编制引擎执行。抽象业务协议允许只指定双方之间的公共消息交换。它们不包含流程的内部细节并且无法执行。它们遵循编排范例。现在，我们来逐步演示如何创建可执行的BPEL 业务流程；可以下载它的代码并将其部署到 Oracle BPEL Process Manager。我们将假设已经按照安装指导成功安装了 Oracle BPEL Process Manager，并假设它使用缺省端口 9700。如果在安装过程中选择了其他端口，则必须相应地修改示例。构建业务流程BPEL 流程指定参与的 Web 服务的确切调用顺序-顺序地或并行地。使用 BPEL，您可以表述条件行为。例如，某个 Web 服务的调用可以取决于上次调用的值。还可以构造循环、声明变量、复制和赋予值、定义故障处理程序等。通过组合所有这些构造，您可以以算法的形式定义复杂业务流程。实际上，由于业务流程本质上属于活动图，因此使用统一建模语言(UML)活动图表示它们可能很有用。通常情况下，BPEL 业务流程接收请求。为了满足请求，该流程调用相关的 Web 服务，然后响应原始调用方。由于 BPEL 流程与其他 Web 服务通信，因此它在很大程度上依赖于复合型 Web 服务调用的 Web 服务的 WSDL 描述。我们来看一个示例。一个 BPEL 流程由多个步骤组成，每个步骤称作活动。BPEL支持基元活动和结构活动。基元活动表示基本构造，用于如下所示的常见任务：使用 invoke 调用其他 Web 服务使用 receive(接收请求)等待客户端通过发送消息调用业务流程使用 reply 生成同步操作的响应使用 assign 操作数据变量使用throw 指示故障和异常使用 wait 等待一段时间使用 terminate 终止整个流程。然后，我们可以组合这些基元活动以及其他基元活动，以定义准确指定业务流程步骤的复杂算法。为组合基元活动，BPEL 支持几个结构活动。其中最重要的是：顺序(sequence)，它允许定义一组将按顺序调用的活动。流(flow)，用于定义一组将并行调用的活动 Case-switch 构造(switch)，用于实现分支 While(while)，用于定义循环使用 pick 能够选择多个替换路径之一。每个 BPEL 业务还将使用partnerLink 定义合作伙伴链接，使用 variable 声明变量。为了理解 BPEL 是如何描述业务流程的，我们将定义雇员出差安排的简化业务流程：客户端调用此业务流程，指定雇员姓名、目的地、出发日期以及返回日期。此BPEL 业务流程首先检查雇员出差状态。我们将假设存在一个可用于进行此类检查的 Web 服务。然后，此 BPEL 流程将检查以下两家航空公司的机票价格：美国航空公司和达美航空公司。我们将再次假设这两家航空公司均提供了可用于进行此类检查的 Web 服务。最后，此 BPEL 流程将选择较低的价格并将出差计划返回给客户端。然后，我们将构建一个异步 BPEL 流程。我们将假设用于检查雇员出差状态的 Web服务是同步的。由于可以立即获取此数据并将其返回给调用方，因此这是一个合理的方法。为了获取机票价格，我们使用异步调用。由于确认飞机航班时刻表可能需要稍长的时间，因此这也是一个合理的方法。为简化示例，我们假设以上两家航空公司均提供了 Web 服务，且这两个 Web 服务完全相同(即提供相同的端口类型和操作)。在实际情形下，您通常无法选择 Web 服务，而是必须使用您的合作伙伴提供的服务。如果您有幸能够同时设计 Web 服务和 BPEL 流程，则应考虑用哪个接口更好。通常，您将对持续时间较长的操作使用异步服务，而对在相对较短的时间内返回结果的操作使用同步服务。如果使用异步 Web 服务，则 BPEL 流程通常也是异步的。当您用 BPEL 定义业务流程时，您实际上定义了一个由现有服务组成的新 Web 服务。该新 BPEL 复合 Web 服务的接口使用一组端口类型来提供类似任何其他 Web 服务的操作。要调用用 BPEL 描述的业务流程，则必须调用生成的复合 Web 服务。图3 是我们流程的示意图。图 3：出差安排示例 BPEL 流程在开发此示例 BPEL 流程的过程中，您将经历下列步骤：熟悉相关的 Web 服务为此 BPEL 流程定义 WSDL 定义合作伙伴链接类型开发此 BPEL流程：定义合作伙伴链接声明变量编写流程逻辑定义。第 1 步：列出相关 Web 服务的清单在您开始编写 BPEL 流程定义之前，必须先熟悉从业务流程中调用的 Web 服务。这些服务称作合作伙伴 Web 服务。本示例使用雇员出差状态 Web 服务以及美国航空公司和达美航空公司 Web 服务(这两个 Web 服务具有相同的 WSDL 描述)。(同样，本示例中使用的 Web 服务是虚构的。)雇员出差状态 Web 服务雇员出差状态 Web 服务提供 EmployeeTravelStatusPT 端口类型，通过它可以使用 EmployeeTravelStatus 操作检查雇员出差状态。此操作将返回雇员可以使用的乘机标准(可能为经济舱、商务舱或头等舱)。(见图 4。)图 4：雇员出差状态 Web 服务航空公司 Web 服务航空公司 Web 服务是异步的；因此它指定了两个端口类型：第一个端口类型 FlightAvailabilityPT 用于使用 FlightAvailability 操作检查航班可用性。为返回结果，该 Web 服务指定了第二个端口类型 FlightCallbackPT。此端口类型指定 FlightTicketCallback 操作。尽管航空公司 Web 服务定义了两个端口类型，但它只实现FlightAvailabilityPT。FlightCallbackPT 则由作为 Web 服务客户端的 BPEL 流程实现。图 5 是此 Web 服务体系结构的示意图：图 5：航空公司 Web 服务第 2 步：为 BPEL 流程定义 WSDL接下来，我们必须将此业务出差 BPEL 公开为 Web 服务。因此，第二步是为它定义WSDL。此流程将必须从它的客户端接收消息并返回结果。它必须公开TravelApprovalPT 端口类型，后者将指定一个输入消息。它还必须声明ClientCallbackPT 端口类型(用于使用回调将结果异步返回给客户端)。图 6 说明了此流程。图 6：此 BPEL 流程的 WSDL第 3 步：定义合作伙伴链接类型第三步是定义合作伙伴链接类型。合作伙伴链接类型表示 BPEL 流程与相关方(包括BPEL 流程调用的 Web 服务以及调用 BPEL 流程的客户端)之间的交互。本示例包含三个不同的合作伙伴：客户端、雇员出差状态服务和航空公司服务。理想情况下，每个 Web 服务都应在 WSDL 中定义相应的合作伙伴链接类型。(实际情形可能不是这样的。)然后，我们可以使用 WSDL 包装合作伙伴 Web 服务(导入 Web 服务的 WSDL 并定义合作伙伴链接类型)。或者，我们可以在 BPEL 流程的 WSDL 中定义所有合作伙伴链接。但由于此方法违反了封装原则，因此不建议使用。对于本示例，我们定义了三个合作伙伴链接类型(每个类型位于 Web 服务的相应WSDL 中)：travelLT：用于描述此 BPEL 流程客户端与此 BPEL 流程本身之间的交互。此交互是异步交互。此合作伙伴链接类型在此 BPEL 流程的 WSDL 中定义。employeeLT：用于描述此 BPEL 流程与雇员出差状态 Web 服务之间的交互。此交互是同步交互。此合作伙伴链接类型在雇员 Web 服务的 WSDL 中定义。flightLT：描述此 BPEL 流程与航空公司 Web 服务之间的交互。此交互是异步交互，且航空公司 Web 服务对此 BPEL流程调用一个回调。此合作伙伴链接类型在航空公司 Web 服务的 WSDL 中定义。每个合作伙伴链接可以拥有一个或两个角色，我们必须为每个角色指定它使用的portType。对于同步操作，由于操作只是单向调用，因此每个合作伙伴链接类型仅有一个角色。例如，此 BPEL 流程对雇员出差状态 Web 服务调用EmployeeTravelStatus 操作。由于它是同步操作，因此此 BPEL 流程等待完成并仅在完成操作后取得响应。对于异步回调操作，我们必须指定两个角色。第一个角色描述客户端操作调用。第二个角色描述回调操作调用。在本示例中，BPEL 流程与航空公司 Web 服务之间存在一个异步关系。正如我们已经指出的，我们需要三个合作伙伴链接类型：两个链接类型指定两个角色(因为它们是异步的)，一个链接类型指定一个角色(因为它是同步的)。合作伙伴链接类型在特殊命名空间的 WSDL 定义。首先，我们在客户端使用的 BPEL流程 WSDL 中定义 travelLT 链接类型以调用此 BPEL 流程。所需的第一个角色是出差服务(即，我们的 BPEL 流程)的角色。客户端使用 TravelApprovalPT 端口类型与此 BPEL 服务通信。第二个角色 travelServiceCustomer 描述了此 BPEL 流程将在ClientCallbackPT 端口类型中对其执行回调的客户端的特征：plnk：partnerLinkType name=travelLTplnk：rolename=travelServiceplnk：portType name=tns：TravelApprovalPT/plnk：role plnk：role name=travelServiceCustomerplnk：portType name=tns：ClientCallbackPT/plnk：role/plnk：partnerLinkType 第二个链接类型是employeeLT。它用于描述此 BPEL 流程与雇员出差状态 Web 服务之间的通信，并在此雇员 Web 服务的 WSDL 中定义。此交互是同步交互，因此我们需要一个名为employeeTravelStatusService 的角色。此 BPEL 流程使用雇员 Web 服务上的EmployeeTravelStatusPT：plnk：partnerLinkType name=employeeLTplnk：rolename=employeeTravelStatusServiceplnk：portType name=tns：EmployeeTravelStatusPT/plnk：role/plnk：partnerLinkType 最后一个合作伙伴链接类型 flightLT 用于描述此 BPEL 流程与航空公司 Web 服务之间的通信。此通信是异步通信。此 BPEL 流程对航空公司 Web 服务调用一个异步操作。此 Web 服务在完成请求后对此 BPEL 流程调用一个回调。因此，我们需要两个角色。第一个角色描述航空公司 Web 服务对于此 BPEL 流程服务的角色，即航空公司服务(airlineService)。此 BPEL 流程使用 FlightAvailabilityPT 端口类型进行异步调用。第二个角色描述了此 BPEL 流程对于航空公司 Web 服务的角色。对于航空公司Web 服务而言，此 BPEL 流程是一个航空公司客户，因此角色名称为airlineCustomer。航空公司 Web 服务使用 FlightCallbackPT 端口类型进行回调。此合作伙伴链接类型在航空公司 Web 服务的 WSDL 中定义：plnk：partnerLinkType name=flightLTplnk：rolename=airlineServiceplnk：portType name=tns：FlightAvailabilityPT/plnk：role plnk：rolename=airlineCustomerplnk：portType name=tns：FlightCallbackPT/plnk：role/plnk：partnerLinkType 了解合作伙伴链接类型对于开发 BPEL 流程规范至关重要。有时，它可以帮助生成所有交互的图表。定义合作伙伴链接类型后，我们已经完成了准备阶段，并准备开始编写业务流程定义。第 4 步：创建业务流程现在，您就可以开始编写 BPEL 流程了。通常，BPEL 流程等待客户端传入的消息，以启动业务流程的执行。在本示例中，客户端通过发送输入消息 TravelRequest 启动此 BPEL 流程。然后，此 BPEL 流程通过发送 EmployeeTravelStatusRequest 消息调用雇员出差状态 Web 服务。由于此调用是同步调用，因此它等待EmployeeTravelStatusResponse 消息。然后，此 BPEL 流程通过向上述两家航空公司 Web 服务发送 FlightTicketRequest 消息对它们进行并发异步调用。每个航空公司 Web 服务通过发送 TravelReponse 消息进行回调。然后，此 BPEL 流程选择较合适的航空公司并使用 TravelResponse 消息对客户端进行回调。我们首先编写一个空的 BPEL 流程提纲，它展示了每个 BPEL 流程定义文档的基本结构：process name=BusinessTravelProcess.partnerLinks！-The declaration ofpartner links-/partnerLinks variables！-The declaration of variables-/variables sequence！-The definition of the BPEL business process mainbody-/sequence/process 我们首先添加所需的命名空间。此处，我们必须定义目标命名空间以及用于访问雇员和航空公司 WSDL 以及此 BPEL 流程 WSDL 的命名空间。我们还必须为所有 BPEL 活动标记声明命名空间(此处采用缺省命名空间，以便不必限定每个 BPEL 标记名)。BPEL 活动命名空间必须为：process name=BusinessTravelProcesstargetNamespace=xmlns=xmlns：trv=xmlns：emp=xmlns：aln=.合作伙伴链接接下来，我们必须定义合作伙伴链接，它们定义与此 BPEL 流程交互的不同方。每个合作伙伴链接都与描述其特性的特定 partnerLinkType 相关。每个合作伙伴链接还最多指定两个属性：myRole：表明业务流程本身的角色。partnerRole：表明合作伙伴的角色。合作伙伴链接仅可以指定一个角色，通常同步请求/响应操作也仅能指定一个角色。对于异步操作，它指定两个角色。在本示例中，我们定义四个角色。第一个合作伙伴链接称作客户端，由 travelLT 合作伙伴链接类型描述其特性。此客户端调用该业务流程。我们需要指定 myRole 属性以描述此 BPEL 流程(travelService)的角色。我们必须指定第二个角色：partnerRole。此处，该角色为travelServiceCustomer，它描述 BPEL 流程客户端的特性。第二个合作伙伴链接称作 employeeTravelStatus，由 employeeLT 合作伙伴链接类型描述其特性。它是 BPEL 流程与 Web 服务之间的一个同步请求/响应关系；我们再次仅指定一个角色。此时，该角色为 partnerRole，这是因为我们描述了 Web 服务(它是此 BPEL 流程的合作伙伴)的角色：最后两个合作伙伴链接对应于航空公司 Web 服务。由于它们使用同一类型的 Web 服务，因此我们基于一个合作伙伴链接类型 flightLT 指定两个合作伙伴链接。此处，由于我们使用异步回调通信，因此需要两个角色。此 BPEL 流程(myRole)对于航空公司 Web 服务的角色为 airlineCustomer，而航空公司(partnerRole)的角色为 airlineService：partnerLinks partnerLink name=clientpartnerLinkType=trv：travelLTmyRole=travelServicepartnerRole=travelServiceCustomer/partnerLink name=employeeTravelStatuspartnerLinkType=emp：employeeLTpartnerRole=employeeTravelStatusService/partnerLinkname=AmericanAirlinespartnerLinkType=aln：flightLTmyRole=airlineCustomerpartnerRole=airlineService/partnerLink name=DeltaAirlinespartnerLinkType=aln：flightLTmyRole=airlineCustomerpartnerRole=airlineService/partnerLinks 变量 BPEL 流程中的变量用于存储消息以及对这些消息进行重新格式化和转换。您通常需要为发送到合作伙伴以及从合作伙伴收到的每个消息定义一个变量。就我们的流程而言，我们需要七个变量。我们将它们命名为 TravelRequest、EmployeeTravelStatusRequest、EmployeeTravelStatusResponse、FlightDetails、FlightResponseAA、FlightResponseDA 和 TravelResponse。我们必须为每个变量指定类型。可以使用 WSDL 消息类型、XML 模式简单类型或 XML模式元素。在我们的示例中，我们对所有变量使用 WSDL 消息类型：variables！-input for this process-variablename=TravelRequestmessageType=trv：TravelRequestMessage/！-inputfor the Employee Travel Status web service-variablename=EmployeeTravelStatusRequestmessageType=emp：EmployeeTravelStatusRequestMessage/！-output from the Employee TravelStatus web service-variablename=EmployeeTravelStatusResponsemessageType=emp：EmployeeTravelStatusResponseMessage/！-input for American and Deltaweb services-variable name=FlightDetailsmessageType=aln：FlightTicketRequestMessage/！-output from American Airlines-variablename=FlightResponseAAmessageType=aln：TravelResponseMessage/！-output from Delta Airlines-variablename=FlightResponseDAmessageType=aln：TravelResponseMessage/！-output from BPEL process-variablename=TravelResponsemessageType=aln：TravelResponseMessage/variablesBPEL 流程主体流程主体指定调用合作伙伴 Web 服务的顺序。它通常以 sequence(用于定义多个将按顺序执行的操作)开始。在顺序中，我们首先指定启动业务流程的输入消息。我们使用 receive 构造(它等待匹配消息，在本示例中为TravelRequest 消息)实现此目的。在 receive 构造中，我们不直接指定消息。而是指定合作伙伴链接、端口类型、操作名称以及可选变量(用于保存收到的消息以用于随后的操作)。我们将消息接收与客户端合作伙伴链接在一起，并等待对端口类型TravelApprovalPT 调用 TravelApproval 操作。我们将收到的消息存储到TravelRequest 变量中：sequence！-Receive the initial request for business travel from client-receive partnerLink=clientportType=trv：TravelApprovalPToperation=TravelApprovalvariable=TravelRequestcreateInstance=yes/.receive 等待客户端调用 TravelApproval 操作，并将传入的消息以及有关业务出差的参数存储到 TravelRequest 变量中。此处，此变量名与消息名相同，但并不一定要相同。接下来，我们需要调用雇员出差状态 Web 服务。但在调用之前，我们必须为此 Web服务准备输入。查看雇员 Web 服务的 WSDL，可以看到我们必须发送由雇员部分组成的消息。我们可以通过复制客户端发送的消息的雇员部分来构造此消息。编写相应的赋值语句：.！-Prepare the input for the Employee Travel Status Web Service-assign copy from variable=TravelRequestpart=employee/tovariable=EmployeeTravelStatusRequestpart=employee/copy/assign.现在，我们就可以调用雇员出差状态 Web 服务了。为了进行同步调用，我们使用invoke 活动。我们使用 employeeTravelStatus 合作伙伴链接，并对EmployeeTravelStatusPT 端口类型调用 EmployeeTravelStatus 操作。我们已经在EmployeeTravelStatusRequest 变量中准备了输入消息。由于它是同步调用，因此该调用等待回应并将其存储在 EmployeeTravelStatusResponse 变量中：.！-Synchronously invoke the Employee Travel Status Web Service-invokepartnerLink=employeeTravelStatusportType=emp：EmployeeTravelStatusPToperation=EmployeeTravelStatusinputVariable=EmployeeTravelStatusRequestoutputVariable=EmployeeTravelStatusResponse/.下一步是调用上述两个航空公司 Web 服务。同样，我们先准备所需的输入消息(这两个 Web 服务的输入消息相同)。FlightTicketRequest 消息包含两部分：flightData：它从客户端消息(TravelRequest)中检索而得。travelClass：它从EmployeeTravelStatusResponse 变量中检索而得。因此，我们编写一个包含两个copy 元素的赋值：.！-Prepare the input for AA and DA-assign copy fromvariable=TravelRequestpart=flightData/tovariable=FlightDetailspart=flightData/copy copy fromvariable=EmployeeTravelStatusResponsepart=travelClass/tovariable=FlightDetailspart=travelClass/copy/assign.输入数据包含需要传递给航空公司 Web 服务的数据。由于格式相同，因此我们可以使用一个简单复制直接传递它。在实际情况下，通常需要执行转换。为此，可以使用具有 assign 的XPath 表达式、使用转换服务(如 XSLT 引擎)或使用由特定 BPEL 服务器提供的转换功能。现在，我们准备调用这两个航空公司 Web 服务。我们将进行并发的异步调用。为表述并发，BPEL 提供了 flow 活动。对每个 Web 服务的调用将包含两个步骤：使用 invoke 活动进行异步调用。使用 receive 活动等待回调。我们使用 sequence对这两个活动进行分组。这两个调用只在合作伙伴链接名称上存在差别。我们对一个调用使用 AmericanAirlines，对另一个调用使用 DeltaAirlines。两者均对FlightAvailabilityPT 端口类型调用 FlightAvailability 操作，发送FlightDetails 变量中的消息。使用 receive 活动接收回调。我们再次使用这两个合作伙伴链接名。receive 等待对 FlightCallbackPT 端口类型调用 FlightTicketCallback 操作。我们将结果消息分别存储到 FlightResponseAA 和 FlightResponseDA 变量中：.！-Make aconcurrent invocation to AA in DA-flow sequence！-Asyncinvoke of the AA web service and wait for the callback-invokepartnerLink=AmericanAirlinesportType=aln：FlightAvailabilityPToperation=FlightAvailabilityinputVariable=FlightDetails/receive partnerLink=AmericanAirlinesportType=aln：FlightCallbackPToperation=FlightTicketCallbackvariable=FlightResponseAA/sequence sequence！-Async invoke of the DA web service and waitfor the callback-invoke partnerLink=DeltaAirlinesportType=aln：FlightAvailabilityPToperation=FlightAvailabilityinputVariable=FlightDetails/receive partnerLink=DeltaAirlinesportType=aln：FlightCallbackPToperation=FlightTicketCallbackvariable=FlightResponseDA/sequence/flow.在该流程的这个阶段，我们收到两个机票报价。在下一步中，我们必须选择一个机票报价。为此，我们使用 switch 活动。.！-Select the best offer and construct the TravelResponse-switch casecondition=bpws：getVariableData(FlightResponseAA,confirmationData,/confirmationData/Price)=bpws：getVariableData(FlightResponseDA,confirmationData,/confirmationData/Price)！-Select American Airlines-assign copy fromvariable=FlightResponseAA/tovariable=TravelResponse/copy/assign/case otherwise！-Select DeltaAirlines-assign copy from variable=FlightResponseDA/tovariable=TravelResponse/copy/assign/otherwise/switch.在 case 元素中，我们检查美国航空公司的机票报价(FlightResponseAA)是等于还是低于达美航空公司的机票报价(FlightResponseDA)。为此，我们使用 BPEL 函数 getVariableData并指定变量名。价格位于 confirmationData 消息的内部，虽然它是唯一的消息部分，但我们仍必须指定它。我们还必须指定查询表达式以找到价格元素。此处，我们采用简单的 XPath 1.0 表达式。如果美国航空公司的机票报价低于达美航空公司的机票报价，则将FlightResponseAA 变量复制到 TravelResponse 变量(我们最终将此变量返回给客户端)。否则，我们将复制 FlightResponseDA 变量。我们已经到达此 BPEL 业务流程的最后一步-使用 invoke 活动将回调返回给客户端。对于此回调，我们使用客户端合作伙伴链接并对 ClientCallbackPT 端口类型调用 ClientCallback 操作。保存答复消息的变量为 TravelResponse：.！-Make acallback to the client-invokepartnerLink=clientportType=trv：ClientCallbackPToperation=ClientCallbackinputVariable=TravelResponse/sequence/process 后续步骤下载用于 Web 服务的业务流程执行语言一书中的示例章节。访问 Web 服务技术中心到此，我们已经完成了我们的第一个 BPEL 业务流程规范。您可以看到，BPEL 并不是很复杂，并允许相对简单和自然的业务流程规范。第 5 步：部署和测试我们部署到 Oracle BPEL Process Manager 的每个 BPEL 流程都需要一个流程描述符。BPEL 标准不包括此流程描述符，且它特定于 BPEL 服务器。部署流程描述符是流程在给定平台上的唯一实现部分，必须重写它才能在不同 BPEL 引擎上运行该流程。Oracle 流程描述符是一个 XML 文件，它指定有关 BPEL 流程的以下细节：BPEL源文件名、BPEL 流程名(ID)、所有合作伙伴链接 WSDL Web 服务的 WSDL 位置以及可选的配置属性。流程描述符的默认文件名为 bpel.xml，但我们可以使用任何其他名称：BPELSuitcase BPELProcesssrc=Travel.bpelid=TravelProcessCh4partnerLinkBindingspartnerLinkBinding name=clientpropertyname=wsdlLocationTravel.wsdl/property/partnerLinkBindingpartnerLinkBinding name=employeeTravelStatuspropertyname=wsdlLocation/property/partnerLinkBinding partnerLinkBindingname=AmericanAirlinespropertyname=wsdlLocation/property/partnerLinkBinding partnerLinkBindingname=DeltaAirlines