扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
作者:Olaf Zimmermann 来源:论坛整理 2007年12月24日
关键字:
在本页阅读全文(共5页)
除了组合 OOAD、BPM 和 EA 技术之外,还有几个重要的 SOAD 概念和方面有待充实:
服务分类和聚合
服务有不同的用法和用途;例如,软件服务可以不同于业务服务(如前面的 图 5所示)。此外,还可以将原子服务编排成级别更高、功能齐全的服务。
服务组合可以通过可执行模型(如 BPEL 建模的模型)来加以简化;这是传统的建模工具和方法不能处理的事情。
策略和方面
服务具有语法、语义和 QoS 特征,所有这些都必须进行建模;正式的接口契约必须涵盖的比 Web 服务描述语言(Web Services Description Language,WSDL)的多。因此, Web 服务策略(WS-Policy) 框架是一个重要的相关规范。
除了已经制定的良好 体系结构可跟踪性原则之外, 业务可跟踪性也是一个理想的品质:应该有可能将所有的运行时构件直接与非技术领域专家可以理解的语言联系起来。这对于直接在业务和服务层公开的抽象非常重要。Sarbanes-Oxley (SOX) 法案是需要这种业务可跟踪性的业务驱动程序的一个例子。
流程:中间相遇
在真实世界中,并没有全新的项目,必须始终考虑遗留系统( 遗留系统是现有系统的同义词)。因此,需要 中间相遇的方法,而不是单纯的自顶向下或自底向上的流程。
在设计取决于现有的 IT 环境而不是现在和将来的业务需要的情况下,自底向上的方法往往会导致不好的业务服务抽象。而自顶向下的方法可能会产生不足的非功能性需求特征,并且损害其他的体系结构品质因素(例如因域模型中缺乏标准化而导致的性能问题),另外,也会在服务和组件中产生不匹配的不良问题。
服务获取和知识代理
这是一个知识管理和生命周期问题:如何成功地准备好服务并且使其在概念化之后可以重用?
应该将重用看作是标识和定义服务最主要的推动标准之一。如果组件(或服务)不可能重用,就不无法将其作为服务进行部署。它可以连接到另一个与企业体系结构相关的服务,但是不能单独作为一个服务而存在。
然而,即使从开始就计划好了重用,还必须形式化服务获取流程。由多个使用者使用服务是明确的 SOA 设计目标。构建时服务注册中心(例如企业 UDDI 目录)可能能够解决部分问题。
示例:汽车工作订单
汽车工作订单(Automotive Work Order)描述了一家汽车维修公司管理其顾客运营的流程。我们将通过这个领域中的问题来阐述 SOAD 的观点。
工作订单代表汽车服务公司和顾客之间的约定,以进行一系列例行维修或应急维修,例如例行 50,000 英里服务,更换刹车片或轮胎,或者换油。
业务场景(如 图 7所示)如下:
图 7. 工作订单的宏流示例
如果您将此作为一个独立的应用程序从头开始创建,您就可能创建一组如 图 8所示的类。
图 8. 工作订单的类图示例
如果您将工作订单构造为一个 OO 应用程序,这些软件对象将包含所有必需的业务规则,并且理解应该遵循的业务流程。
然而,这种方法在实践方面存在着一些缺点:
许多步骤涉及与现有遗留系统和数据库(例如帐单编制、日程安排以及库存系统)的连接,它们不可能遵循 OO 范式进行设计(在这样的情况下,应用适配器或仲裁器会有所帮助)。
为了使系统尽可能地灵活,将一些规则外化是有帮助的,这样就可以在不更改代码的情况下修改流程或工作流。例如像下面这样的规则:
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者