SCA和BPEL的关系

最新推荐文章于 2020-12-23 17:01:16 发布

雨果吧

最新推荐文章于 2020-12-23 17:01:16 发布

阅读量1.6k

点赞数

分类专栏：企业应用文章标签： processing payment documentation reference 语言 binding

企业应用专栏收录该内容

75 篇文章 3 订阅

订阅专栏

Relationship between SCA and BPEL

Added by Mike Edwards (IBM), last edited by Mike Edwards (IBM) on Mar 19, 2007

原文选自OSOA

名词对照：

Compose -------------组合（不知道有没有更合适的词）

Business Process----业务流程

Component-----------组件

Composite------------(没有翻译：)

End Point-------------(没有翻译：)

译文：SCA和BPEL的关系

SCA和BPEL –对手还是朋友？

很多时候当我们讨论基于服务的应用时，大家经常会疑惑于SCA和BPEL扮演的角色，它们是相互冲突的技术规范，还是做了相同的事情？。事实上，SCA和BPEL没有矛盾。在SOA应用解决方案里，它们是一对好朋友，各司其职又互相补充，合作愉快。

当然SCA和BPEL有共同的地方，这也是大家容易混淆它们的原因之一。首先两者都使用基于XML的语言来描述；另外它们都描述了多个服务组合成一个服务，都描述了使用WSDL port type接口的服务调用和被调用。而两者的区别在于，SCA描述的是应用服务的关系结构；BPEL则使用包含若干一定顺序关系的操作的业务流程来实现业务逻辑。

也就是说，SCA关注的是应用中存在了哪些组件，这些组件提供了什么服务，又依赖于哪些服务引用，这些组件彼此的依赖关系是什么样的，组件之间的连接如何定位end point，使用什么通信方式和协议，组件以及连接上的访问策略等等；BPEL则关注业务逻辑，如何编排这些组件提供的服务来实现一个业务流程。BPEL 流程通过 partnerLink来对外提供服务，在内部实现里调用其他服务，这需要定义服务抽象接口，配置end point和通信方式。

总之，SCA可以描述了一个业务解决方案的结构，由哪些组件构成整个系统，组件之间的关系，但是组件提供服务的调用顺序规则由业务逻辑决定。使用BPEL实现SCA组件是一个很好的结合，这样就可以既用静态组合关系的角度，有用动态调用顺序的角度来看构成整个系统的这些组件了。当然SCA不限制只用这种方式，还可以使用其他各种支持的语言实现组件，如Java , C++等。

所以，构建由服务集合而成的应用系统时，BPEL和SCA是一对很好的配合。以下的示例描述它们是如何工作的。

BPEL 和业务流程

BPEL使用XML语言描述可执行的业务流程，通过一个或者多个partnerLinks配置流程和外界关联，定义交互的接口。一类partnerLinks定义为供其他客户端调用业务流程的服务；另一类定义为流程所依赖和调用的其他服务，还有一类既是流程提供的服务又是流程需要的服务-这是双向对话模式的服务调用。

以下是一个简单的订单处理BPEL实现—很多公司都需要提供这样的服务，处理并分发客户订单。

<process name="purchaseOrderProcess"

targetNamespace="http://example.com/bpel/OrderProcessing"

xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"

xmlns:lns="http://example.com/wsdl/purchase">

Example of a WS-BPEL process for handling a purchase order.

</documentation>

<partnerLink name="orderProcessing"

partnerLinkType="lns:orderProcessingLT" myRole="orderProcessingService" />

<partnerLink name="payment" partnerLinkType="lns:paymentLT"

myRole="paymentRequester" partnerRole="paymentService" />

<partnerLink name="warehouse" partnerLinkType="lns:warehouseLT"

myRole="warehouseRequester" partnerRole="warehouseService" />

<partnerLink name="eventLog" partnerLinkType="lns:eventLogLT"

partnerRole="eventLogService" />

</partnerLinks>

</variables>

<receive partnerLink="orderProcessing" portType="lns:orderProcessingPT"

operation="placeOrder" variable=" PO " createInstance="yes">

<documentation>Receive Purchase Order</documentation>

</receive>

<flow>

A flow to handle order processing including accounts, shipping

</documentation>

<links>

</links>

<copy>

<from>$PO.customerInfo</from>

<to>$shippingRequest.customerInfo</to>

</copy>

</assign>

<invoke partnerLink="warehouse" portType="lns:warehousePT"

operation="checkInventory"

inputVariable=" PO " outputVariable="availability">

<documentation>Check inventory</documentation>

</sources>

</invoke>

</sequence>

<invoke partnerLink="payment" portType="lns:paymentPT"

operation="orderPayment" inputVariable=" PO ">

<documentation>Complete payment</documentation>

</targets>

</invoke>

<invoke partnerLink="warehouse" portType="lns:warehousePT"

operation="shipOrder"

inputVariable=" PO " outputVariable="shippingInfo">

<documentation>Dispatch Order</documentation>

</invoke>

<receive partnerLink="payment" portType="lns:paymentCallbackPT"

operation="sendInvoice" variable="Invoice" />

</sequence>

</flow>

<reply partnerLink="orderProcessing" portType="lns:orderProcessingPT"

operation="placeOrder" variable="Invoice">

<documentation>Invoice Processing</documentation>

</reply>

</sequence>

</process>

开始是流程的partnerLinks定义了本流程提供给客户端调用的接口。还有若干变量定义，使用<sequence…/>定义的一组方法，在本例中orderProcessing partnerLink对应的方法是placeOrder 。不同的partnerLinks关联不同的方法调用和调用返回应答。最后定义了流程返回给客户的应答消息，在这里是订单的发票或者是发货单。

受篇幅所限没有详细列出parnterLinkType定义，相关的WSDL文件和一些其他BEPL元素。

以上的BPEL程序里也没描述每个服务的位置和调用方式，这些信息由BPEL之外的语言来描述，SCA登场。

SCA和应用系统的服务结构

SCA是一个有效的描述由服务集合构成的应用系统结构的手段。看以下示例图：

Figure1: Example Order Processing composite application

在这个例子中，给客户提供了订单处理服务，一般会使用基于SOAP的Web Service来作为服务接口的技术实现方式。服务会包含诸如创建订单，检查有效性，获取订单状态信息等方法。

Order Processing 服务由Order Processing组件来实现，同时Order Processing组件也会调用其他的几个组件提供的服务，如EventLog 组件， AccountsComposite 和WarehouseComposite。EventLog组件由Java程序实现， AccountsComposite 和WarehouseComposite是包含其他组件的Composite，提供服务接口供Order Processing组件调用。

Order Processing组件不需要知道AccountsComposite 和WarehouseComposite的内部实现，实现由这些Composite的开发人员负责。

可以看出，SCA表示了组件是如何构成整个应用系统的，组件之间的调用关系。除此之外，SCA还可以表示组件连接的关联信息，例如如果AccountsComposite是一个使用EJB技术的J2EE应用实现，那么PaymentService就使用EJB binding；Order Processing组件可以使用JMS binding来连接WarehouseComposite。同时SCA还可以定义这些连接上的访问安全策略。例如帐目信息可能很敏感，所以要求PaymentService方法操作的数据都要加密；另外这些方法也可能需要认证以确保只有受信的客户才能调用。此外WarehouseService的一些方法，如给客户派发订单需要保证事务可靠性，以确保这些订单发并且只发一次。

SCA没有描述的是Order Processing组件调用它所依赖的服务的顺序规则。先检查客户帐目状态，检查订单上货物的库存状态，计算订单货物总价，再要求客户支付，给客户发货—所有这些操作都是创建订单方法需要的，调用这些操作的顺序规则由Order Processing组件的程序代码来实现。

在应用系统中一起使用SCA和BPEL

SCA表示了构成应用系统的服务集合的结构， BPEL流程定义了这些独立操作的执行顺序流。毫无疑问，SCA和BPEL能够相互补充构建业务解决方案。

BPEL可以实现SCA中的Composite或者Component。一个Composite可以包含多个Component。

在Composite内部，BPEL用来实现各个Component之间交互的逻辑如上面例子所示。当然BPEL并不是唯一的选择，还可以使用其他语言来实现，如BPMN,JAVA语言等。对于Component，BPEL可以实现其内部的逻辑。同样可以使用JAVA或者C++语言来实现内部逻辑。

BPEL作为Component实现的一种方式与SCA配合使用，在SCA里使用implementation.bpel语法关键字来表示。

回到上面定义的Order Processing服务，使用BPEL实现Order Processing组件就是一个很好的方式。Order Processing组件调用其他组件的一些方法完成其功能逻辑。BPEL正适合做这项工作。其间SCA描述了这些组件间的调用关系，为BPEL流程的partnerLinks提供了服务endpoint和通信协议的配置。