使用面向服务体系架构建模语言(使用面向服务体系架构建模语言(SoaML)建模,第)建模,第4部分部分:服服
务组合务组合
本文的写作背景
在本文中,我们组合了以前所创建的服务参与者,在第三篇中,我们使用其他参与者的功能。这就是说,我们将会从其他的服
务的组合或者组合当中创建一个新的服务。这种服务组合的技术可以重复地使用无限次,不管您的关注点是什么,也不管抽象
的层次如何。但是,可能会有结构上的限制因素,影响到服务操作、安全和性能关注、数据交换容量、线性层次交互协议和绑
定问题的整体性,它们可能会限制什么构件提供什么服务。这个问题决定了方案的结构,并超出了本文的讨论范围。
本系列所有的文章有一个共同点,那就是我们使用已存在的 IBM® Rational® 工具来构建方案工件并将它们再一次联系起来,
这样我们就可以根据需求确认方案的可执行性,并更加有效地管理变更。另外,我们通过向 IBM Rational Software Architect
中的 UML 模型添加对象管理组面向服务架构建模语言(OMG SoaML)概述,来为服务建模扩展统一建模语言(UML)。表
1 提供了一个总结,关于我们在开发范例时使用的总体进程,以及用于构建工件的工具。
表表 1. 开发进程角色、任务与工具开发进程角色、任务与工具
角色角色 任务任务 工具工具
业务执行业务执行 交付业务目标与目的
IBM® Rational® Requirements
Composer
业务分析员业务分析员 分析业务需求
IBM® Rational® Requirements
Composer
软件结构软件结构 设计方案的结构 IBM® Rational® Software Architect
Web 服务开发员服务开发员执行方案 IBM® Rational® Application Developer
服务实现审核
让我们从评审前面文章中执行的服务参与者开始讨论。图 1 显示了 Invoicer 服务提供商。
图图 1. Invoicer 服务执行服务执行
Invoicer 服务参与者为计算购买订单的初始价值提供了结账服务,并在知道传递信息时改进所做的估价。订单的全额价值取决
于产品是在哪里生产的,以及从哪里进行传递的。初始价值计算可能用于确认消费者拥有足够的信用,或者仍然想要购买产
品。在完成订单之前最好确认这一点。