科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道面向服务的分析与设计原理

面向服务的分析与设计原理

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

面向服务的体系结构(SOA)和 Web 服务的基本观念是成为我们日常语言的一部分,并可看作是适于设计现代企业应用程序的体系结构形式。

作者:Olaf Zimmermann 来源:论坛整理 2007年12月24日

关键字:

  • 评论
  • 分享微博
  • 分享邮件

在本页阅读全文(共5页)

第一类 SOAD 原理

  除了组合 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 范式进行设计(在这样的情况下,应用适配器或仲裁器会有所帮助)。

  为了使系统尽可能地灵活,将一些规则外化是有帮助的,这样就可以在不更改代码的情况下修改流程或工作流。例如像下面这样的规则:

  •   标准的 24,000 英里服务包括四公升油。只是在使用四升以上的油或顾客要求优质油(如合成油)时才应该收取额外的邮费。
  •   在遗留应用程序中有一套工业标准为普通汽车维修活动进行劳务估价。除非维修人员收取的费用超过该估价的 X% 并且报告产生差别的有根据的原因,否则顾客就应该支付标准的劳务费。
  •   如果超过估价的 Y% 以上,就应该联系顾客以进行确认。
    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章