业务和流程驱动的SOA服务识别方法总结

发布时间:2022-02-01 00:16 阅读次数:
本文摘要:今天整理和分享下流程驱动的SOA服务识别方法,该方法在传统SOA架构计划咨询中应用比力多,对于当前的微服务架构计划咨询仍然可以参考借鉴。服务识别整体流程说明服务识别和服务需求分析的主要事情是基于SOA的需求分析方法论,以流程和业务驱动IT的指导思想,对业务系统举行业务建模,用例建模和业务实体建模,形成企业级需求和业务功效清单,作为后续服务识此外输入。对于服务需求,以流程分析为基础,通过流程的逐层剖析,细化出关键的业务运动,将流程运动识别为业务用例,并对业务用例举行建模。

宝博官网

今天整理和分享下流程驱动的SOA服务识别方法,该方法在传统SOA架构计划咨询中应用比力多,对于当前的微服务架构计划咨询仍然可以参考借鉴。服务识别整体流程说明服务识别和服务需求分析的主要事情是基于SOA的需求分析方法论,以流程和业务驱动IT的指导思想,对业务系统举行业务建模,用例建模和业务实体建模,形成企业级需求和业务功效清单,作为后续服务识此外输入。对于服务需求,以流程分析为基础,通过流程的逐层剖析,细化出关键的业务运动,将流程运动识别为业务用例,并对业务用例举行建模。

用例建模自己可以作为业务系统功效开发的需求规格说明书,同时对用例分析和功效操作的识别形成业务域-》流程剖析-》用例-》业务操作的剖析历程,用于后续服务的识别。在整个分析历程中,流程的关键运动或业务用例的操作都市涉及到业务实体工具,因此需要对业务实体工具举行单独建模,分析实体工具的关键属性和工具间关系,同时分析实体工具和业务操作间的U/C矩阵,作为后续公用服务提取的基础。服务识别开始于需求分析,终止于识别出的候选服务列表。

为了有效的实施SOA工程,应用不能伶仃于其他应用而独立开发。SOA的应用应该可以共享服务,这些服务不但单属于某个独立的应用,而且有自己的生命周期,能够被独立的治理。在SOA工程中,为了有效的治理需求,各个项目必须知道其他已经存在的项目、正在开发的项目以及未来将要开发的项目需求。

所以,与SOA服务相关的需求应该在企业级层面治理。对于服务自己可以分为业务服务,数据服务,技术服务等。从上图也可以看到通过业务流程分析和业务架构梳理来识别业务服务;通过数据架构和数据建模来分析和识别数据服务;通过技术架构分析来识别关键的技术服务能力。候选服务是被识别出用于系统重用的业务功效。

一个候选服务纷歧定一对一的对应到实际交付的服务,好比,在分析阶段,一个粗粒度的服务可能对应到需求中两个或两个以上的初始候选服务。另一方面,服务识别并不是简朴的识别出候选服务,也包罗了一系列的校验和评估。

服务识别整体方法对于服务识此外方法,在前面许多文章都已经讲到过,对于SOA实施中服务识别是相关重要的一个环节,如何基于业务驱动IT的思路,识别出真正粗粒度,高度自治,可复用的服务是后期服务治理管控能否顺利的一个关键。否则SOA建设到后期很容易就酿成一个数据集成平台,而非是服务共享平台。

要知道服务的本质还是接口和交互,因此对于服务的识别总体来说两种方法:自顶朝下:基于业务流程分析入手,分析跨系统业务流程交互,识别出集成点和接口点,再转化为服务自底朝上:基于当前遗留系统已有的系统间接口情况,分析接口对应的业务场景,再举行接口转服务可以看到岂论是哪种方法,这内里都有两个重点,其一是必须要明确的清楚每一个服务的业务寄义,对应的业务场景和业务交互点在那里?其次就是需要做接口转服务这个关键行动。1. 自顶朝下的服务识别如果各个业务系统之间没有业务和数据的交互,那么跟基础不应该存在任何的接口或服务。

而对于服务的存在原因主要还是我们的端到端业务流程往往是跨了多个业务系统的交互才气实现的,而这些跨业务系统的交互点要么举行业务规则的校验,要么举行关键业务数据和票据的通报。这些交互点和集成点都是潜在的接口服务识别点,通过这种方式识别出来的服务我们就很清楚服务对应的业务流程和场景。好比采购系统和ERP之间有一个采购订单导入的接口服务,我们就很清楚整个供应链流程中,采购订单的建立和生效是在采购系统内里,可是基于采购订单的采购吸收和入库是在ERP系统,因此需要将采购订单同步到ERP系统中。这种跨系统流程分析基本会把横向的所有关键接口全部梳理出来,可是容易遗遗漏纵向的一些基础数据共享接口,距离来说我们在拟制采购订单的时候,是需要输入和选择项目信息,选择对应的库存组织信息的。

而这些基础数据需要从项目治理系统和ERP系统中同步过来。可是在流程图中往往只会有采购订单建立节点,因此容易遗漏这些基础数据共享接口。

另有就是某一个业务功效在实现历程中,可能涉及到挪用外部的业务规则和逻辑,这种交互点也容易遗漏需要特别注意。举例来说,采购订单在建立完成的时候并提交的时候需要检查预算是否足够,而这个检查规则逻辑是预算治理系统实现的,因此在这里也存在采购系统和预算系统间的业务接口和服务。2. 自底朝上的服务识别特别遗留系统情况举行SOA架构革新和服务接入的时候,我们要意识到必须要将遗留系统间的当前已有接口全部门析和梳理清楚。因为既然当前遗留系统能够正常运作,也能完成跨系统的业务交互,那么原来的接口从面上是完全能够笼罩业务需求的,我们唯一要思量的是接口自己的界说和设计是否合理的问题。

当整理出完整的接口清单后,我们要做的就是搞清楚每一个接口对应的业务场景究竟是如何的?基于这种反向思路我们只关系和接口相关的业务交互场景,而不是关注全部业务流程。搞清楚了详细的业务场景后,接着要做的重点事情就是对接口举行评估,接口的评估主要包罗了如下内容:a) 接口当前使用频度如何?是实时还是定时同步?同步频率能否满足业务的要求?b) 接口通报的数据量如何?当前在数据通报的时候有无性能问题?c) 接口自己的实现方法是如何的?好比Dblink,存储历程,WS接口,还是直接原始的JDBC接口等。

d) 接口自己的复用度如何?相关类似的接口有哪些?相互之间有哪些差异?做了接口评估最主要的仍然是要思量如何举行接口去重和接口合并,对于接口转服务的方法,我前面有专门一篇文章再谈,在这里就不再展开。自己相互独立的两个业务系统,好比A系统和B系统,按原理两个系统应该完全独立,包罗数据库,中间件,应用部署包等。两个系统之间只能通过尺度的接口举行业务和数据的交互。

可是实际在项目实施中发现一种普遍存在的现象,即A系统将自己的数据库账户完全开放为B系统,而B系统在拿到数据库毗连串信息后,通过自己编码实现完全可以对数据库A中的数据库表举行种种任意的CRUD操作。在这种情况下可以看到,A和B两个系统之间已经完全耦合在一起,这个时候A系统要做数据库层面的迁移和数据库表结构的变换往往全部会影响到B系统。如果要把这些接口点找到,必须要把B系统中的所有代码举行遍历查找和分析,往往才气够找到详细的接口点有哪些。

这些不规范的使用方式都对后续的SOA服务革新和迁移造成相对重大的影响。业务建模业务建模包罗了业务调研,业务流程分析,全局用例建模和全局数据建模几个关键内容。其中焦点仍然是基于业务流程驱动,基于流程分析来识别关键的业务用例和业务工具。

业务调研该部门包罗业务需求调研,包罗业务流程或问题发生的配景先容,详细的业务需求收集和分类。现有的业务流程现状,业务需求所在的详细业务域,涉及到的岗位角色人员信息等。业务调研包罗了业务流程,业务数据,业务系统三个方面的内容,业务调研内容详细输出为业务调研文档。

业务调研完成后应该输出完整的业务流程调研陈诉,其中也包罗了对业务系统间交互接口的调研和现状梳理。流程分析流程分析需遵循端到端流程分析的思路,对流程举行二级,或三级剖析。流程分析前可以先举行主题域分析,绘制上下文关系图,通过上下文关系图来进一步识别关键业务流程。详细参考流程分析指导书。

通过上下文关系图对主题域举行分析后,可以获得主题域中所包罗的业务事件,而这些业务事件就是业务流程的起点。流程分析时,需要注意流程的目的性、内在性、整体性、动态性、条理性、结构性这六大特性,流程是需求分析的重要内容,流程图对于和用户确认需求以及向开发团队通报需求都是很是重要的。

可以选择使用UML规范中的运动图或商业建模尺度中所推荐的跨职能流程图对流程建模。通过流程分析可以进一步明确流程的的关键业务运动,每个业务运动的输入,输出,涉及的岗位角色,通报的业务数据等关键内容。

详细流程分析输出包罗:业务系统所涉及的端到端业务流程图业务域的业务流程剖析图针对业务流程图举行的详细业务流程运动和输入、输出形貌全局用例建模凭据业务域划分和业务流程分析,举行用例的识别,流程中清晰地表达了角色所要执行的业务运动,这正是用例的内容,用例即用户使用系统完成业务运动的场景在将业务运动及报表转换为用例后,使用UML中的用例图对用例建模,用例图不光可以表达出用户是如何使用系统的,还可以表达出用户与用户之间的关系,用例与用例之间的关系。对于流程图转换到用例的详细方法,可以参考需求分析指导书中的详细说明和转换原则。对于业务用例分析和建模基础,请参考UML相关文档。

全局数据建模本部门主要是凭据流程分析和用例建模,抽取流程和用例中的关键业务实体工具举行数据建模分析。全局数据建模只需要分析出关键的业务实体,实体形貌和实体之间的关系即可,在业务实体建模环节讲进一步对该部门内容举行细化分析。全局数据建模需要输出数据观点模型,数据实体工具清单和实体形貌信息。用例建模用例建模用例建模首先是流程建模中的关键业务运动会转化为用例,这在全局用例建模中会举行分析。

从流程图中转换用例时,先基于流程图分析流程图中的职能带区(泳道)哪一些是不直接使用系统,将其清除,将余下的职能带区(泳道)转为角色,将流程图中的业务运动及判断转换为用例,决议运动是否要转换为用例的尺度是它是否属于系统领域,而决议判断是否要转换为用例的尺度是它是否独立。用例建模需要参考用例编写尺度模板举行用例的编写,针对每一个用例需要填写的内容主要包罗如下:用例的编号,名称,级别等信息。

用例执行的上下文配景先容用例执行的前置条件,后置条件,最小保证用例执行的基本流用例执行的扩展流业务规则信息假设和约束信息其它备注或说明信息业务操作分析在用例建模的历程中,用例自己即是一个实现业务价值的交互业务运动荟萃。因此可以对用例进一步分析,识别更细粒度的业务运动和操作,这些业务运动或操作可以从基本流,扩展流和业务规则中寻找。业务操作分析要求如下:业务操作即业务运动中的业务任务,有明确的业务寄义业务操作自己是可复用的业务单元业务操作自己接纳动宾结构举行形貌 业务操作自己具有高内聚,松耦合性的自治性数据建模业务实体分析用例模型只是对用户如何使用系统的业务场景举行建模,如果要构建系统,还需要对系统的框架举行建模,即要弄清楚目的系统所要治理的“物”:业务实体,并弄清楚这些业务实体间的关系。

在对业务实体建模时,一般是使用“名词动词法”识别出业务实体,并逐步确定实体间的关联关系及其属性。对业务实体建模选择使用UML规范中的类图或实体图作为模型,类图/实体图中的一个类/实体表达一个业务实体,类/实体的属性用于对业实体的属性建模,而它们之间的关系则可以用来对业务实体间的关联关系建模。对于比力庞大的业务实体,还可以接纳UML规范中的状态图对其建模,可以表达出业务实体的状态切换与触发事件的关系。

业务实体分析中需要对识此外业务实体详细形貌业务实体的数据字典信息,包罗业务实体中各个数据项的种别,长度,完整性规则,业务用途等相关信息。实体使用U/C矩阵分析实体使用分析主要包罗业务实体跨系统使用情况分析和业务实体系统内使用情况分析两方面的内容。

跨系统使用情况分析,主要是为公共数据服务的提取做准备,在该分析矩阵中需要列出业务系统发生的关键业务实体,分析这些业务实体在MSS域相关业务系统中的CRUD情况,作为后续数据服务识此外一个输入。业务实体系统内使用分析,主要分析系统内关键业务实体和业务用例之间的对应关系,找寻系统内可复用的业务操作,为系统内服务识别做准备。服务识别数据服务识别数据服务为以实现业务系统底层数据集成为目的,以业务实体为焦点的数据工具传输为主的SOA服务。

宝博体育

数据服务没有明确的业务规则和寄义。一般服务消费方在消费数据服务后都需要将数据同步到当地数据表,再凭据业务系统自身需要对数据服务举行相关业务规则的封装和实现。01 业务实体确认在业务建模和数据建模阶段,已经对业务实体举行了分析,包罗业务实体的类型,业务实体和业务功效的U/C矩阵分析等。业务实体是识别数据服务的基础,因此需要对业务建模阶段识此外业务实体举行确认。

业务实体完全是业务视角的业务工具,而不是数据库设计中的数据库表,如采购订单业务实体可能涉多层结构和多张数据库表,可是在此处的分析只需要思量采购订单业务实体工具。02 服务重用性分析在业务建模构建的U/C矩阵的基础上,可以从两个层面分析服务的重用性。一个是跨业务系统的服务重用性,一个是在一个业务应用内部业务模块间的服务可重用性。当一个业务主数据或一个焦点业务票据需要跨多个业务系统或业务模块使用的时候,则该业务实体识别为数据服务是可重用的。

03 服务实现方法分析在服务实现的时候,一方面是思量服务的可重用性,一方面是思量业务敏捷要求。对于数据类服务一般可以实现为查询类数据服务,也可以实现为导入类数据服务。当业务数据的业务敏捷性和时效性要求高时候,优先思量实现为导入和分发类服务满足业务敏捷性的要求。04 服务大数据量传输分析对于底层数据集成类服务,可能涉及到大数据量传输,这种数据对实时性要求不高,可是任何一个批次传输可能都在10万级以上的数据量。

对于这种情况要单独举行分析,分析服务数据量,挪用频度,数据同步机制等。对于大数据量传输在识别为数据服务的时候可以思量ODI服务,JMS消息,数据分页等多种方式来实现。业务服务识别业务服务是有明确业务寄义的,含详细业务规则和逻辑的,实现一个有价值的业务运动的一系列业务操作的组合。

业务服务具有显着的高业务内聚性,粗粒度特征。01 业务组件确认业务组件是实现多个业务功效的,高内聚松耦合的业务功效模块单元。

业务组件是可以举行独立需求分析,设计,开发,测试和部署的组件治理单元。对于一个完整的业务系统或业务流程是通过业务组件的交互和协同来完成。业务组件之间的交互则通过尺度的SOA服务方式举行。

即业务组件中包罗了技术组件和服务组件,其中服务组件袒露业务服务。业务组件和服务的详细关系如下:1.对SOA服务举行分析,可以从服务中发现组件。对服务举行组合、功效及UI界面封装可以形成新的组件,所以组件可以挪用一个或多个SOA服务,成为服务的消费者;2.组件根据SOA服务识别规范,抽取服务,可以成为服务的提供者。02 业务服务识别对于业务服务识别分为两个层面的内容。

其一是为了实现跨业务组件的业务流程分析出来的业务组件之间的业务交互。其二是在用例建模阶段我们对业务操作举行了详细分析,对于这些分析整理出业务操作清单,对于业务操作清单中的可重用的业务操作识别为关键的业务服务。详细识别步骤为:1.凭据业务流程或业务用例,绘制相应的跨业务组件协作的业务交互图。

2.对所有的业务交互点识别为潜在的业务服务。3.对业务操作运动列表举行分析,将可重用的业务操作识别为潜在的业务服务。UI组件服务识别UI组件是可以完成独立的业务功效的小业务应用。

UI组件可以独立举行需求分析,设计,打包,部署和运行。UI组件是一种页面内嵌的方式在多个业务系统中运行,因此在UI组件复用的情况下,基本不需要举行底层的数据集成和同步操作,可以更好的保证数据的一致性和时效性。

对于UI组件的识别主要分为两个层面举行:从顶向下识别:对于业务系统在构建中的业务系统和系统需求举行分析,在系统需求阶段会举行详细的功效需求形貌和UI界面形貌。可以针对这些需求文档分析重复的业务功效界面,将其识别为潜在的UI组件服务。

从下向上识别:该方法是首先对业务系统中的平台化功效模块举行抽象,如事情流治理,系统治理,公共技术服务等都是可以举行平台化的组件功效模块。对于平台化的组件功效模块需要和业务系统举行界面层的交互,因此对于这些界面层交互可以由平台层提供UI组件服务内嵌到各个业务系统中使用。

技术服务识别技术服务是和业务无关的,提供某种技术能力的服务。技术服务一般包罗消息,宁静,日志,会话,规则,异常,数据库治理等多个方面的内容。对于技术服务的识别仍然是包罗了两个层面:从顶向下识别:在业务建模和业务系统需求分析历程中,需要关注业务系统非功效性需求的形貌,这些非功效需求包罗了异常,日志,宁静,性能,可靠性,高可用性,可扩展性,大数据量处置惩罚等多个方面的内容。

对于这些非功效需求如果有多个业务系统或模块提出,则可以思量抽象识别为公有的技术服务。从下向上识别:该方法是从平台层面举行思量,企业在业务系统建设历程中一般会分为产物层宁静台层,对于平台层又包罗了产物平台和技术平台。在举行平台化功效构建的历程中,平台层需要朝产物层提供能力,这些能力的提供都可以思量以技术服务的方式统一提供。

以实现产物层宁静台层的集成。流程服务识别对于流程服务的识别,仍然是以前期输出的端到端流程梳理和分析入手,以焦点业务工具通报为基础,梳理识别流程片段,将流程服务转变为子流程和服务组合。流程服务的识别需要思量服务的粒度,应以识别出来的流程片段自己也具备一定的服务价值为重要的权衡尺度。


本文关键词:业务,和,流程,宝博官网,驱动,的,SOA,服务,识别,方法

本文来源:宝博体育-www.ytpentu.com

在线客服 联系方式 二维码

电话

0726-501307546

扫一扫,关注我们