企业级应用系统体系架构面向服务分析与设计

《企业级应用系统体系架构面向服务分析与设计》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

企业级应用系统体系架构（九）面向服务分析与设计ChenHaopengFriday,July02,20211 面向服务架构带来的影响系统分析与设计服务识别与服务流程编排为主要工作2 面向服务架构带来的影响系统开发与部署服务的发现与组合成为了系统开发的主要工作3 业务建模业务建模的目的通过业务建模抽取、整理和挖掘企业的无形资产通过业务建模标准化和规范化业务流程和业务规则通过业务建模保障企业管理信息系统的顺利实施4 业务建模业务建模的方法ARIS、BPEL、BPMN……5 模型驱动的架构设计模型驱动的架构(Model-drivenarchitecture,MDA)是对象管理组织OMG在2001年发布的软件设计方法，面向服务的分析与设计通常会采用MDA。在MDA中，软件设计分成三个阶段：计算无关的模型CIM：包含系统业务需求，但是不包含任何有关系统实现的细节平台无关的模型PIM：包含由识别出的服务构成的完整的业务流程，但是不包含使用何种技术来开发这些服务的细节平台相关的模型PSM：将平台无关的模型与具体的服务实现平台绑定，构成对系统的平台相关的视图6 服务组织方式在进行面向服务的分析与设计时，需要考虑如何将Web服务组织到一起。Web服务的组织方式通常有两种：编制（orchestration）和编排（choreography）7 服务组织方式编制是指在流程中有一个作为流程中心的Web服务，它负责控制流程中其他参与交互的Web服务，协调Web服务间的消息传递。除流程中心Web服务之外的其他参与交互的Web服务通常是不关心其他的Web服务的存在，也不需要知道自己被谁调用或正在参与一个什么样的具体业务流程。因此，Web服务能够在不了解彼此影响的情况下被添加到流程中或从流程中被移除。只有中心Web服务了解这个具体的业务过程的逻辑。因此编制模式是中央集权型的，这个中心Web服务了解编制的总体目标、涉及的操作以及操作的调用顺序。8 服务组织方式编排是指参与业务过程的Web服务之间是协作关系，并没有像编制中位于中心的Web服务这样的协调者。因此，为了实现一个业务流程，每一个参与其中的Web服务都需要明确地知道自己应该在什么情况下与哪些其他的Web服务进行交互。通过比较可以知道编制是以Web服务的视角来组织业务流程编排则是以宏观的角度来观察多个Web服务间的交互协作，可以更好的模拟现实中的公共流程。两者的关键区别是：编排是一种对等模型，业务流程中会有很多协作方，这些协作方互相对等，没有隶属层次关系；而编制是一种集控式的请求者/提供者模型，它定义了集控中心，由其决定在流程中应该使用哪些服务，以及应该如何使用这些服务，但是没有定义多个参与方之间应该如何进行协作。9 业务服务到软件服务的映射从系统分析员构建的业务服务到系统架构师设计的软件服务之间的映射是构建平台相关的模型PSM的重要步骤，通常可以采用的方法主要有自顶向下和自底向上两种方式。自顶向下方式就是“分而治之、逐步求精”，即在事先充分了解系统需求的情况下，从系统架构开始分析设计，不断递归地将其分块细化到一个个小的模块，然后实现这些小模块的功能。自底向上方式则相反，是先对一个个功能模块进行设计分析并实现，然后再考虑如何将这些模块组合以实现整体系统的需求，是从细节入手的设计方式。10 业务服务到软件服务的映射自顶向下的分析与设计过程是由业务需求驱动的其优点是由于是由需求驱动的，因此业务流程中的业务服务和软件之间的交互是完全匹配的；缺点是可能对现有软件服务的利用率不高，因为识别出来的业务服务有可能与现有软件服务之间不能完全匹配，导致可能会彻底放弃现有软件服务自底向上的分析与设计要解决的问题就是如何使得现有的服务可以被业务流程所引用其优点是通过不断地将业务服务与已有的软件服务进行匹配，使得对已有软件服务能够进行最大限度的复用；缺点是以现有服务驱动进行匹配，因此可能会发现很多业务服务无法找到合适的现有服务进行匹配，导致需要新开发的服务数量变多通过综合运用两种模式，可以实现业务服务到软件服务的映射，完成平台无关的模型向平台相关的模型的演化。11 服务粒度的确定在进行服务识别和划分时，服务的粒度是一个十分重要的问题。服务粒度太细会使得服务流程过于复杂，而且服务流程执行的效率也会降低很多；服务流程太粗会使得服务流程难以改动，从而使得随需应变无法实现。从随需应变出发，需要我们能够预判业务流程在将来有可能出现的变化，然后根据这种预判来设计服务的粒度具体来说，我们要求对业务流程中的各个环节进行抽象表示，然后根据考虑在流程上那些部分是随着业务的发展有可能产生变化的，然后将这些有可能产生变化的地方识别成细粒度的服务来表示。12 服务粒度的确定当识别出来的服务粒度过细时，可以考虑使用服务外观模式将服务数量降低到合理的范围内。13 服务的实现在实现各个服务时，首先需要考虑的是使用何种技术框架虽然目前服务都是以Web服务的方式实现的，但是Web服务本身也分为传统的基于SOAP的实现方式和基于REST的实现方式在基于SOAP的Web服务中，服务的调用者和服务的消费者之间传递的是SOAP消息在基于REST的web服务中，服务器端完全是无状态的，客户端的状态就是由服务器端推送过去的数据，这些数据的语义就形成了表述这两种web服务的实现方式都可以选择但是由于基于REST的服务实现方式可以使服务器变成无状态的，这也就意味着服务器端不需要花费很大的代价为每个客户端维护其唯一的状态，这对于潜在客户端数量巨大的web服务来说特别合适。因此，基于REST的服务会成为我们优先考虑的选择，而WSDL2.0增加对REST的web服务的支持也说明了这种发展趋势。14 Web2.0客户端Web2.0技术选型时需要考虑很多因素，其中最主要的因素有：浏览器兼容性：由于浏览器之间存在差异，因此，并非所有的浏览器对相同的脚本具有相同的解释效果，要考虑所采用的web2.0技术对浏览器的兼容性。安全性：在客户端浏览器中执行的脚本和程序会产生潜在的对安全性的威胁，因此，要考虑不同的web2.0技术的安全架构对系统安全性的影响。执行开销：不同的web2.0技术开发的脚本和程序对于执行时所需的开销是不同的，它们对内存和CPU的占用存在较大的差异，因此执行开销是必须考虑的因素。除上述最主要的因素外，还包含其他因素，例如可扩展性、性能、可靠性等。无论采用哪种web2.0技术，最根本的动力在于将部分计算任务推至客户端执行，在利用客户端资源的同时，降低服务器端的压力，使服务器端成为无状态的。这一点和我们尽量将服务实现成为无状态的是一致的。15 服务的调试与测试在测试和调试过程中，应该分成两个层次来进行：测试服务流程和测试单个的服务。在测试服务流程时，关心的是整个流程的正确性，而不是单个服务的正确性。在执行这个层次的测试时，服务的具体实现可能还无法获得，此时可以运用ServiceStub和Plugin模式即针对服务流程中的服务生成ServiceStub，即一种返回指定值的服务实现，它并不是服务的最终实现，而仅仅用以支撑对服务流程的测试。同时，在调用服务时，通过读取plugin的配置文件来指定调用服务的哪个具体实现。在测试单个服务时，我们已经可以确保服务流程的正确性了，因此只需要关注具体的服务实现。首先，我们需要对服务的构件进行测试，确保服务的业务逻辑实现是正确的。其次，要使用与服务实现语言无关的方式来测试，确保服务能够被异构的服务调用者调用。16 EndTobecontinued17