Web服务的控制流与数据流需求解析
1. 控制流需求
1.1 基本概念
在控制流需求中,我们需要对组件服务的终止条件进行表达。具体而言,当所有服务都可用且最终用户接受时,所有服务都应处于“成功”状态,即与虚拟旅游机构(VTA)达成预订或销售的最终协议。反之,每个服务要么保持闲置,要么处于“失败”状态,此时服务意识到无法达成预订或销售协议,并撤回任何购买或销售承诺。这意味着全局终止要求必须考虑到每个组件服务在整体组合中的事务性。
1.2 状态标记
在每个服务的抽象WS - BPEL协议规范中,我们需要将某些状态标记为成功(符号✓),将其他状态标记为失败(符号×)。例如,对于航班服务,当它收到确认报价接受的确认消息时,意味着预订已确定,协议成功终止;而当航班不可用或航班报价被拒绝时,服务则以失败告终。
1.3 VTA场景示例
以VTA场景为例,控制流需求规范如下表所示:
| 服务 | 主要要求 | 次要要求 |
| ---- | ---- | ---- |
| 航班 | ✓ | × |
| 酒店 | ✓ | × |
| VTA | ✓ | × |
主要要求是所有服务都处于成功状态,这对应“销售度假套餐”的条件;次要要求是所有服务都处于失败状态,对应“无单一承诺”的条件。需要注意的是,AllMaps服务不需要这种语义注释,因为其协议不存在失败的可能性。
1.4 控制流需求的形式化表达
控制流需求可以通过多种方式进行形式化表达。一种常见的方法是将控制流需求表示为最终执行配置的条件。例如,示例8中的控制流需
超级会员免费看
订阅专栏 解锁全文

被折叠的 条评论
为什么被折叠?



