SOA 快速指南 1 2 3，第 2 部分: 服务建模 |  |
|
|
级别: 初级
金 戈, IBM软件部企业集成解决方案架构师, IBM 中国软件开发实验室 SOA设计中心
姚 辉 ( yaohui@cn.ibm.com), IBM 中国SOA 设计中心高级工程师, IBM 中国软件开发实验室 赵 勇 ( zhaoyong@cn.ibm.com), IBM 中国SOA 设计中心工程师, IBM 中国软件开发实验室 谭 佳, IBM 中国SOA 设计中心工程师, IBM 中国软件开发实验室
2006 年 12 月 26 日
以服务为中心的业务活动管理与监控是最近出现的一种热门的IT技术，它的目的在于帮助企业管理人员实时获悉企业运营状况，了解企业的战略实施进展。
《SOA 快速指南 1 2 3》系列文章是笔者近年来在 SOA 项目实施中的经验结晶。该系列文章结合一个汽车贷款流程， 介绍了在 SOA 的环境下如何基于 IBM 的现有产品构造业务活动管理解决方案，详细阐述了每个实施步骤中使用的 IBM 的方法学、技术和产品。希望通过本文的介绍，能够帮助读者理清业务流程管理所包含的基本概念，并了解构建解决方案所需要的基本步骤。
众所周知，面向对象的应用构建在类和对象之上。
随后发展起来的建模技术将相关的对象按照业务功能进行分组，就形成了组件的概念；对于跨组件的功能调用，则采用接口的形式暴露出来。
进一步的将接口的定义与接口的具体实现进行解耦，就催生了SOA。而作为业务和IT之间的契约的服务，是SOA最重要的概念。
因此面向对象、基于组件、面向服务是三个递进的抽象层次。
现在我们有OOAD（Object Oriented Analysis Design）和CBD（Component Based Development）来进行面向对象和基于组件的建模与开发。但是没有一个好的方法来进行SOA的分析、设计和开发。SOMA（Service Oriented Modeling Architecture）就是在这个背景下诞生的，其主要目的就是填补OOAD和CBD在建模领域留下的空白，为SOA实施提供一个方法学的指导。
需要特别指出的是，SOMA的出现并不是要替代OOAD或者CBD，正如CBD需要借助OOAD一样，SOMA也要借助OOAD和CBD进行实现层面的建模。
与OOAD和CBD相比较而言，SOMA贯穿整个IT建设的生命周期，在项目规划、设计、实施、运行中都起到重要的作用。本文就不展开阐述了，相关信息可见参考资料。
SOMA另外一个显著的特点就是将IT与业务对齐。在具体的实施过程中，SOMA将业务特性，如：业务目标、关键业务指标等，延伸到IT的分析和架构决策过程，从而缩小业务与IT之间的差距。具体来看，业务组件模型（或者类似业务分析方法论的结果）、端到端的业务流程以及关键业务指目标是SOMA的三项主要输入，SOA的实现则是SOA的输出，从这也可以看出SOMA的定位是在业务和IT之间。
按照实施的阶段，SOMA分为服务发现、服务规约以及服务实现三个阶段。
1）服务发现：采用自上而下、自下而上和中间对齐的方式，得到服务的候选者。
自上而下 （业务领域分解）方式从业务着手进行分析，我们将业务进行领域分解、流程分解，以及进行变化分析。
业务组件模型是业务领域分解的输入。根据业务组件模型的详细描述，我们可以将业务领域按照业务职责细分为业务范围，并直接其映射到IT范畴的子系统，实现业务与IT的无缝连接。
顶级的业务流程是流程分解的输入。将业务流程分解成子流程或者业务活动，逐级进行，直到每个业务活动都是具备业务含义的最小单元。流程分解得到的业务活动树上的每一个节点，都是服务的候选者，构成了服务候选者组合。在大部分情况下，服务候选者组合都是一个很长的列表，加上自下而上和中间对齐方式还有可能发现新的服务，因此将服务候选者按照某种方式进行分类是一件非常必要的事情。业务领域分解的结果——业务范围是一个业务概念，同时可以无缝映射到IT范畴，因此它是一个好的分类原则。根据业务范围，服务候选者组合可以被划分服务候选者目录。
变化分析的目的是将业务领域中易变的部分和稳定的部分区分开来，通过将易变的业务逻辑及相关的业务规则剥离出来，保证未来的变化不会破坏现有设计，从而提升架构应对变化的能力。变化分析可能会从对未来需求的分析中发现一些新的服务候选者，这些服务候选者需要加入到服务候选者目录中。
自下而上（已有资产分析）方式的目的是利用已有资产来实现服务，已有资产包括：已有系统、套装或定制应用、行业规范或业务模型等。
通过对已有资产的业务功能、技术平台、架构以及实现方式的分析，除了能够验证服务候选者或者发现新的服务候选者，还能够通过分析已有系统、套装或定制应用的技术局限性尽早验证服务实现决策的可行性，为服务实现决策提供重要的依据。
中间对齐（业务目标建模）方式的目的是帮助发现与业务对齐的服务，并确保关键的服务在流程分解和已有资产分析的过程中没有被遗漏。
业务目标建模将业务目标分解成子目标，然后分析哪些服务是用来实现这些子目标的。在这个过程中，为了可以度量这些服务的执行情况并进而评估业务目标，我们会发现关键业务指标、度量值和相关的业务事件。
结合这三种方式的分析，我们发现服务候选者组合，并按照业务范围划分为服务目录。同时为服务规约做好其他准备，如：通过对已有资产分析进行的技术可行性评估、通过业务目标建模发现的业务事件等等。
2）服务规约：定义实现服务的服务组件的细节，包括，数据、规则、服务、可配置概要、可能的变更，同时还会涉及到消息、事件的定义和管理。
经过服务发现的阶段，我们得到了候选服务目录，接下来就需要决定暴露哪些服务。理论上所有的服务候选者都可以暴露为服务，但是一旦暴露为服务，该服务候选者就必须满足附加的安全性、性能等方面的要求，企业还必须为服务的规划、设计、开发、维护、监管支付额外的开支，因此我们会根据一定的规则来决定将哪些服务候选者暴露为服务。
这些规则包含以下几个方面：
基于企业应用开发的经验，我们还可以有其他一些方面的考虑。
在决定暴露特定的服务候选者为服务以后，服务规约还需要定义服务的消息、非功能性需求以及服务之间的依赖关系、组合关系。
3）服务实现：
根据对业务领域的理解和现有IT系统的分析，将服务的实现分配到相应的服务组件，并决定服务的实现方式。具体的实现方式，可以由已有系统暴露相关功能为服务，或者重新开发相关功能提供服务，也可以由合作伙伴来提供服务。无论采用哪种方式，都需要对于关键点进行技术可行性的分析。
定义和建模业务流程是提升业绩的关键因素。业务流程是一种可变的交互模式，当某个组织在实现特定的业务目标时，在该组织的组件及其环境之间发生了这些交互。业务流程通常很复杂，因为在应对独特而瞬息万变的环境时，人们会不断进行大量的更改。没有正式的流程文档和流程管理系统的话，这些流程复杂性就会使组织遇到不必要的障碍和瓶颈。一个良好构建的业务流程模型可以帮助您定位和排除那些隐藏的低效、高成本以及带来延迟的业务活动。
IBM© WebSphere© Business Modeler 是一个业务过程建模工具，该工具使您能够建模、设计、分析与生成业务过程报告、集成新的和修订的工作流，以及定义您的组织、资源和业务项。
本文的主题是服务建模，因此有必要阐述流程建模与服务建模的关系。
首先，进行着两项活动的角色有明显的不同，流程建模一般由业务人员或者业务咨询专家进行，而服务建模由SOA架构师在业务专员的支持下进行。
其次，两项活动看待研究对象的角度不同。流程建模从组织结构、业务流程及相关资源的角度来看待业务，流程建模关注业务活动之间的流动；服务建模则利用服务——业务与IT的契约来分析业务，服务建模关注业务活动之间的层次化和组合关系。
除了上面两点不同以外，这两项活动还是相互依赖，迭代进行的。粗粒度的流程模型是服务建模的重要输入之一，帮助SOA架构师了解业务需求。服务建模的过程发现并规约了服务，产生的结果——服务列表以及服务的主要业务属性帮助业务人员准确的定义流程模型中的业务活动和业务项。但是服务建模中IT的成分如安全性、可靠性， 流程建模并不关注；
而流程建模中的模拟运行和优化又和服务建模没有直接的关系。
根据对当前业务流程的分析，我们可以进行业务流程建模。图2展示了目标业务流程模型。
通过对现有业务环境的分析，新的业务流程必须将信贷员从繁复的人工操作中解放出来，通过自动化的方式降低信贷员的工作强度；同时通过业务规则的约束，控制过程中的操作风险和道德风险。图3就是我们设计的目标业务环境，信贷员只是整个流程中的参与者之一，由自动化的汽车贷款审批业务流程来担当承担业务流程的枢纽。
IT环境的目的是解释应用或流程在执行的过程中会与哪些相关的业务系统交互（包括交互的方式），此外，还解释相关业务人员与流程的交互方式。通过对IT环境的分析，我们可以了解已有系统的功能和相关技术指标，为后面的服务实现和架构设计提供重要的信息。根据业务模型的转型，相应的IT环境如图4所示。汽车贷款审批业务流程能够通过计算机技术自动与相关系统互联互通，同时申请人、信贷员以及信贷经理作为人工任务的执行者参与到业务流程中。
服务建模按照服务发现、服务规约和服务实现这三个步骤进行，本文会涉及前面两个步骤。服务实现与架构设计是本系列文章的下一篇文章的主题。
自上而下方式
通过对业务流程的分解，我们可以得到服务的候选者。如图5所示，每一个业务活动的单元都是服务的候选者。
中间对齐方式
通过与业务分析人员或业务咨询顾问的协作，我们可以获取服务建模的输入——业务目标。在本示例中，业务指标为"降低成本"和"降低欺诈风险"，并且通过销售成本、自服务比例和坏账率这三个关键业务指标来度量业务目标的实施情况。部分服务候选者可以与关键业务指标联系起来，例如：评估信用等级以及审批等服务候选者可以降低坏账率。
自下而上方式
通过对现有IT环境的分析，我们可以掌握现有系统的基本信息。了解到核心系统可以提供获取存、贷款记录的功能。
根据与业务目标的联系、与现有系统功能的映射，可以验证我们自上而下分析方法的结果，或者发现自上而下分析方法的遗漏。结合业务领域的分析，我们可以得到服务候选者列表。
由于服务候选者比较多，可以采用领域分解的结果来将服务候选者进行分类。领域分解的工作通常由资深的业务专家来进行，在本示例中，基于示范的目的，我们认为目标业务流程所涉及的业务范围包括客户服务和风险控制，并将它们作为分类的依据，得到服务候选者目录。
有了服务候选者目录，最重要的步骤就是服务暴露的决策，根据业务对齐、可重用性、业务可组装性等准则，我们决定暴露以下服务：
在决定暴露的服务以后，就需要对这些服务进行消息的定义和非功能性需求，同时需要定义相关的业务事件、规则。
实际项目中，服务规约会比较复杂，既包括具体的服务的操作、输入消息、输出消息，也包括相关联的业务目标、业务规则、业务事件，此外，非功能性需求等方面也是需要在服务实现以前定义。上表仅仅列举几个方面做简单的示意。
除了对单个的服务本身进行规约，服务规约还包括服务之间关系的描述，例如服务之间的依赖关系和包含关系。
在本示例中，汽车贷款流程由其他服务组装而成，评估信用等级由查询存款记录、查询贷款记录和计算信用等级组装而成；执行审批以前，必须先完成评估信用等级，因此从业务的角度来看，审批服务依赖于评估信用等级
|
|
SOA快速指南 1 2 3，第 3 部分: 服务实现及架构设计
|
|
|
|
级别: 初级
姚 辉
(
yaohui@cn.ibm.com), IBM 中国SOA 设计中心高级工程师, IBM 中国软件开发实验室
金 戈, IBM软件部企业集成解决方案架构师, IBM 中国软件开发实验室 SOA设计中心 赵 勇 ( zhaoyong@cn.ibm.com), IBM 中国SOA 设计中心工程师, IBM 中国软件开发实验室
2007 年 1 月 31 日
以服务为中心的业务活动管理与监控是最近出现的一种热门的IT技术，它的目的在于帮助企业管理人员实时获悉企业运营状况，了解企业的战略实施进展。
《SOA 快速指南 1 2 3》系列文章是笔者近年来在 SOA 项目实施中的经验结晶。该系列文章结合一个汽车贷款流程， 介绍了在 SOA 的环境下如何基于 IBM 的现有产品构造业务活动管理解决方案，详细阐述了每个实施步骤中使用的 IBM 的方法学、技术和产品。希望通过本文的介绍，能够帮助读者理清业务流程管理所包含的基本概念，并了解构建解决方案所需要的基本步骤。
SOA参考架构是一种组织SOA的构建元素--服务的方式，IBM希望通过这种参考架构为企业架构提供一种指导和参考，使得新的需求能够更快的得到响应。参考架构如图1所示。
其中左侧的绿色部分表示建模和组装，中间的蓝色部分表示部署，右边的深蓝色部门表示管理。中枢部分是企业服务总线（Enterprise Service Bus），在服务之间提供连通性支持。
参考架构描述了企业范围内SOA方案所需要的关键能力。
工具是集成架构的基本组件，SOA参考架构则提供了开发服务和业务创新优化服务。开发服务用于实现新开发的组件以及重用基础架构的能力；业务创新优化服务用于从IT和业务两个层面来监控和管理运行情况。
企业服务总线是SOA参考架构的核心。它为整个架构范围内所有服务提供相互通讯的能力。其中传输服务、事件服务以及中介服务都是通过ESB来提供的。
交互服务将IT的功能和数据传递给最终用户，并满足用户特定的使用习惯。
流程服务提供服务控制能力，将多个服务串起来实现一个业务流程。
信息服务通过联合、复制和转换来解决基于不同实现方式的不同数据源之间的数据共享难题。
SOA解决方案中的很多服务都是有已有应用提供的，访问服务提供已有应用、打包应用程序与ESB之间的桥接能力，使得已有应用的功能以服务的形式对外暴露出来。
在业务流程需要与外部的合作伙伴、供应商交互的情况下，伙伴服务提供一组文档、协议以及伙伴管理的能力。
应用服务为新的应用组件提供运行时服务。
作为所有能力的基础，基础服务用于优化通过率、性能和可靠性。
IT服务管理服务包括对服务、应用和资源的管理和保护能力，如通过负载均衡来有效的分配系统计算资源。
SOA参考架构是一个完整的企业架构，可以覆盖整个企业范围内集成的需求。参考架构中的服务通过模块化的方式进行集成，因此SOA的实现可以从一个小的项目来启动，在新的项目实施的时候，新的功能能够轻松的加到架构中，通过渐进的方式在企业范围内扩大集成的范围。
无论怎样进行服务建模，服务最终都将由不同的服务组件来实现。因此服务实现是衔接服务建模和组件详细设计的关键步骤。正如我们在第二部分提到过，服务实现首先将服务分配到相应的服务组件，然后逐个分析服务实现方式并进行技术可行性的验证。
在服务发现的过程中，我们根据业务领域的分析结果将服务按照业务范围进行分类。在服务实现的过程中，将业务范围直接映射到服务组件，从而实现业务与IT的一致性。
服务实现的方式如图2所示。"客户服务"业务组件将实现贷款流程、查询存贷款记录、发放贷款等服务。"风险管理"业务组件将实现评估信用等级、审批、担保等服务。
在我们的示例中，对于服务实现方式的选择，可以分为以下几类：
完成了服务实现的决策，也就对系统的架构提出了明确的需求。不同方式实现的服务，需要系统架构提供不同的能力，例如流程引擎、人工服务引擎以及业务规则引擎等。参考IBM的SOA参考架构，我们设计一下系统架构，将各种不同的服务实现的元素部署到系统架构中，如图4所示。
架构关键点分析：
ESB实现机制：
选择一：WebSphere Enterprise Service Bus 优点：内置的转换、路由中介，并且可以通过客户化中介扩展；采用标准的编程模型（SCA, SDO）。
选择二：WebSphere Message Broker
优点：灵活的转换、路由能力；对负载均衡、高可用性上有很好的支持；支持基于MQ的可靠传输；支持多样化的连接方式。
结论：此场景主要是业务部门级别应用，涉及的应用大多数都采用标准化技术，如：XML、Web Service等，也没有特别的分布式应用的需求。因此采用选择一，并利用WebSphere Adapter for CICS将非标准化的CICS应用连接到WebSphere Enterprise Service Bus。在随着企业向SOA全面转型的以后，建议引入Message Broker作为企业服务总线的骨干，当前方案中的WebSphere Enterprise Bus作为一个业务部门级别的节点接入骨干，形成整个企业的服务总线。
应用服务的集成：
选择一：Web Service
优点：支持分布式调用；跨平台；支持开放性标准。
选择二：EJB
优点：支持分布式调用；支持不同的J2EE中间件平台。
结论：企业服务总线是基于J2EE的实现，采用EJB的方式暴露应用服务，具备更好的性能。因此选择方案二。即使将来希望采用Web Service方式，在WebSphere Application Server上也能够很方便的将EJB（Session Bean）暴露为Web Service。
贷款系统的集成：
选择一：通过Web Service访问贷款系统。
优点：支持开放性标准。
选择二：直接通过JDBC访问贷款系统数据库。
优点：支持分布式调用；性能较高。
结论：通过Web Service 访问贷款系统，应用层访问的方式，保证业务的完整性，隔离具体的业务实现。同时避免直接访问数据库带来的安全策略等问题。因此采用选择一。
最终，方案的架构涉及以下IBM的产品。
IBM WebSphere Process Server提供的流程引擎、人工任务引擎和业务规则引擎为流程服务、人工服务以及基于业务规则的服务提供运行环境。
IBM WebSphere Enterprise Service Bus提供的连通性能力以及转换、路由中介能力为企业服务总线提供运行环境。
IBM WebSphere Business Adapter 的连通性能力帮助我们将基于CICS的核心系统功能暴露为功能服务。
IBM WebSphere Application Server提供的J2EE容器为新开发的功能服务提供运行环境。
为了验证架构的可扩展性，可以引入一些变化的场景来分析。
保险公司的多样化支持
由于各家保险公司的IT建设水平参差不齐，因此架构需要能够支持不同形式的接入。
对于能够独立提供服务网关的保险公司，采用Web Service或者socket的方式通过ESB接入。
对于不能提供服务网关的保险公司，可以实现一个人工服务，该人工服务遵循与合作伙伴服务同样的服务规约。可以让保险公司的人员访问该人工服务，或者由银行职员通过传真、电话确认信息，然后访问人工服务。
上面这两种形式的担保服务，对于业务流程是透明的，ESB会根据用户选择的保险公司，将请求路由到保险公司的服务网关或者人工服务。在保险公司建立或者升级自己的服务网关的时候，系统只需要配置或者修改ESB就可以满足业务的需求。
评估信用等级的变化
现阶段，国内还没有统一的信用评估方案，随着相应的业务环境变化导致对信用评估带来的变化，是可以预计到的。
短期的变化可能是信用评估的规则发生变化。由于每年各地的平均收入水平变化，信用评估的规则可能相应的调整。基于业务规则实现的计算信用等级服务，可以灵活的进行规则的修改。
长期的变化可能是引入统一的信用评估平台。由国家或者第三方机构提供一个全国范围内统一的信用评估平台。只需要将现有的评估信用等级业务子流程替换为外部的统一信用评估平台提供的合作伙伴服务，通过ESB来弥合传输协议和消息格式的不同，整个业务流程依然保持不变。
通过对上述变化场景的简单分析，我们验证了架构的可扩展性。当然这种可扩展性只能是在一定的程度上满足业务的变化，也只有通过对业务变化的前瞻性分析，对系统架构进行修正，才能更好的保证架构的可扩展性。这整个过程是一个迭代进行的过程
|
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
