chap4-2-数据服务与SOA基本概念

数据集成与数据服务第4章SOA与数据服务基本概念2023/2/5本章目录4.1SOA参考架构4.2SOA原理与基本体系架构4.3SOA关键技术4.4SOA与大数据服务4.1SOA与数据服务基本概念SOA，ServiceOrientedArchitecture面向服务的体系架构面向服务的架构以服务为中心的体系结构回顾：SOA起因：处理可伸缩性和分布的老办法不管用了!不再能一致化系统，或维持对系统的控制。一致化和控制的前提是集中，集中则无法扩展，当前已经将集中发挥到极致。需要新的方法——一个接受异质、带来分散的方法。SOA作用于：在大型分布式系统中，保持灵活性的唯一办法就是支持异质、分散和容错。SOA四大主要元素SOA：是一种帮助系统在增长的同时保持可扩展性和灵活性的方法，也有助于填平“业务/IT”鸿沟。4大主要元素：1）服务：一个服务是一项自足的、能作为一个或多个流程一部分的业务功能。服务能由任何技术、在任何平台上实现。2）企业服务总线（ESB）：是一个基础设施，支持服务在异质系统间进行调用，使分布式系统和服务间的高互操作性成为可能。其职责包括：数据转化、（智能）路由、处理安全和可靠性、服务管理、检测、日志。SOA四大主要元素4大主要元素：3）松耦合：减少系统依赖的概念。业务流程分布在多个后端系统上，最小化修改和故障的影响至关重要。目标：灵活性、可伸缩性、容错。代价：复杂化。4）政策和过程：维护异质系统。什么是服务？服务特征：1）本质上，服务就是业务功能的IT体现。SOA的目标就是基于对业务规则和功能的抽象来构筑大型分布式系统。2）服务的自描述性（支持动态发现与延迟绑定）服务具有可发布、可发现、机器可处理的接口契约接口定义良好：包括：完整的服务行为和语义。服务契约：服务质量（QoS）及服务等级协议（SLA）。什么是服务？3）服务自治：独立、自主、自给自足。4）抽象性：服务是种抽象，向使用者隐藏服务实现细节；有助于分离服务供应者的内部数据结构和外部接口。实现平台透明性。5）粗粒度：支持基于业务逻辑的积木式装配。6）连接与交互方式——松耦合式绑定，基于标准化消息进行通信。服务可具有可复用、可组合、位置透明以及可互操作等特点。BeforeSOA–AfterSOAsource:IBMSOA适用范围1.分布式系统OASISSOA参考模型对SOA的定义指出：SOA是“组织和利用分布式能力”的范式。SOA使得需要一定分布式能力的实体能定位、使用这些能力。即：SOA方便了服务供应者和服务消费者之间的交互，使业务功能的实现成为可能。SOA适用范围2.所有者各异OASISSOA参考模型对SOA的定义指出：这些分布式能力“可能出于不同所有权范围控制之下”。SOA包括的某些实践和流程基于事实：分布式系统的网络不被某个唯一的所有者掌控。不同的组、不同部门、甚至不同公司都可能管理不同系统。则，不同平台、进度、优先级、预算等都必须被考虑进来。SOA适用范围2.所有者各异无论是处于一个所有者各异的环境中，还是处于一个你能控制一切的环境中，处理问题、做出调整的方式会根据需要而相应变化。（必须向他人妥协，必须接受不同的优先级，不同解决方案的存在。不能控制所有东西。）SOA适用范围3异质（Heterogeneity）大系统缺乏一致性。用不同的平台、不同的编程语言（及编程范式）、不同的中间件。它们是异质的。老的解决集成分布式系统的方法：试图消除异质性。已不可行。SOA则依靠对异质性的承认和支持来处理大系统。SOA的目标仅仅是：在异质化存在的地方，用一种合适的方式处理异质化。SOA构建IT系统的特点-以业务为中心以相对于面向对象、面向构件技术，SOA更多从用户业务出发让业务人员参与SOA系统的规划、设计和管理。在深刻理解业务的基础上构建IT系统，实现IT系统与用户业务的密切结合实施中把完成实际业务流程的一项任务封装为服务基于业务选择合适的技术，避免技术制约业务SOA构建IT系统的特点-灵活适应变化用户业务实现为一系列松散耦合的服务服务可以根据用户业务变化和发展进行按需调整、重构和重新组合提高IT系统对于业务灵活变化的适应能力SOA构建IT系统的特点-重用IT资源，提高开发效率

重用服务带来对原有IT资源的重用度提升

大量高重用的服务资源为快速构建新的业务功能和业务系统奠定了基础提高IT系统的开发效率，节约成本

保护用户前期的信息化投资和IT资产积累

实现用户信息化可持续发展服务架构的分层灵活重组

高重用性底层标准化上层定制化关注点分离不同策略ExampleLayersPresentation

&workflowComposedServicesBasicServicesUnderlying

APIaccordingto:TietoEnatorAB,KurtsBilder主要服务类型基本服务以数据和逻辑为中心的

封装数据操作和数据模型，保证数据一致性是无状态的(stateless)，具有高度的可重用性一般是基于遗留IT系统的API，是SOA成熟度模型中的最基本地级别服务可以被重复调用，且无需维护上下文状态，例如天气预报，没有作业或者会话的概念，返回服务调用结果之后，处理就完成了，后续调用与前面的没有任何关系。主要服务类型组合服务利用网关，适配器等技术将不一致的基础服务组合为提供一致访问的服务封装了业务工作流程服务类型SOA的多层参考架构(IBM)Layer1:遗留系统客户已经开发使用的信息系统.CRMERP应用旧的面向对象应用

商业智能应用使用面向服务的集成技术对其进行集成TheSOALayersLayer2:服务构件层-企业构件负责实现服务功能和保证服务质量-对企业级或者部门级资产进行管理和控制的集合-典型的，采用基于容器的技术（如应用服务器）来实现组件，负载管理和负载均衡，高可用性Layer3:服务层-商业业务选择支持和公开的服务-可以通过服务发现，进行静态绑定和调用，或者编排-为组合服务-将企业范围、业务单元、特定项目级的特定功能，以服务描述的形式具体化了他们的接口子集-在运行时提供服务实现接口所提供的功能-这一层的接口公开为一个服务描述，服务可以独立存在或者编排为组合服务。Component构件SOA体系架构下的应用软件标准构造单元用以构造能为高级和更组粒度的应用软件模块

(Services,References,Properties)用以封装更为低层和更细粒度的逻辑实现

(Implementation)Services:服务是被使用的功能References:实现时所要依赖于其他构件的服务Properties:实现时影响构件动作的可设置数值Implementation:支持各种实现技术（Java,C++,PHP,JavaScript,EPEL,SQL,XQuery,Composite…）相同点：Service和component，都是基于可重用的思想组件从服务提供者地角度，侧重于IT实现，通过接口与实现分离，将功能分解为独立的构造单元，可以单独开发，打包和部署，依赖于特定的技术规范，如J2EE，.Net，Python等，与具体应用有着相同的生命周期服务则代表更高层次的抽象和演进，从服务使用者的角度，侧重描述到底能提供什么，而不是如何提供，只要提供了业务所需的行为和质量，具体是不是组件实现的无关紧要，它独立于应用的部署，可以根据业务需要，独立重构和演进，使得大规模的重用变得更容易。服务在业务和IT技术之间提供了一个中间层，TheSOALayersLevel4:业务过程层(服务组合与协同层)-通过编制（Orchestration）或编排（Choreography）合成组合服务-用以支持业务处理和业务流程Layer5:访问层(表现层)-将用户接口从组件中分离出来-提供访问服务或组合服务的方式TheSOALayersLevel6:集成(ESB)

-这一层使服务可以集成-通过一些可靠性和性能保证技术，比如智能路由，协议中介和其他转化机制-经常被描述为ESB。Level7:服务质量(QoS)-这一层提供了监视，管理和维持诸如安全，性能和可用性等QoS的能力。-监测SOA应用程序健康的机制和工具服务质量 QoS指的是服务的一种能力，它能相应预期的请求，并能以一定的质量完成相关的任务，符合服务提供者和客户的预期可用性：服务正常运转的时间，修复时间（TTR）可访问性：大量客户同时使用服务的成功率标准性性能：吞吐量和等待时间服务质量 QoS指的是服务的一种能力，它能相应预期的请求，并能以一定的质量完成相关的任务，符合服务提供者和客户的预期可靠性：与网络等故障无关，能始终如一的正确运行可伸缩性：服务能力随需求量而变化安全性：认证、授权、消息完整性、机密性本章目录3.1SOA与数据服务基本概念3.2SOA原理与基本体系架构3.3SOA关键技术3.4SOA与大数据服务SOA推广应用的挑战以服务为导向

重用性职责分担标准化SOA三步骤

第一个步骤是找到服务。对于一个企业（服务对象）来讲有那么多种业务，怎么确定SOA架构里需要哪些服务，以及有哪些服务是需要抽象出来的？SOA三步骤

第二个步骤就是服务的描述。这些服务之间的相互关系是怎样的，这些服务分别由哪些服务组件实现。SOA三步骤

第三个步骤就要考虑这些服务采用什么样的技术实现，可能是租用别人提供的服务，也可以重用以前有的服务，也可以重新开发一套服务，或者我利用我们的已有系统，把已有系统的功能进行封装成一个服务等，已达到服务实现的目的。SOA原则理念标准化服务契约StandardizedServiceContracts松散耦合LooseCoupling抽象化Abstraction可重用性Reusability自治性Autonomy无状态Statelessness可发现性Discoverability可组合性Composability管治GovernanceSOAPrinciples-StandardizedServiceContracts“同一服务目录下的服务按照同样的契约设计标准设计契约服务契约表达服务的目的表达服务的能力使用正式的，标准化的服务契约Focusontheareasof功能表达数据表示策略经过服务发现阶段，服务目录基本形成，但是对于每个服务本身的属性信息依然零散。服务规约阶段的主要任务是规范性地描述服务各个方面的属性，其中既包括输入/输出消息等功能性属性，服务安全约束和响应时间等服务质量约束，以及服务在业务层面的诸多属性，如涉及的业务规则、业务事件、时间/人员消耗等。与此同时，规范描述服务相关方面的关系也很重要，如服务间依赖关系，服务和业务组件间关系，服务和IT组件间关系和服务消息间关系等。SOAPrinciples-StandardizedServiceContracts经过服务规约阶段，作为业务和IT互动的服务契约已经形成。但是服务契约和IT的现状还是有很大差距的为了将服务契约落在实地，服务实现阶段通过差距分析，并结合传统方法学完成每个服务实现决策。这其中包括的内容甚多，其主要包括现有系统分析，确定服务分配，服务实现决策，服务基础设施设计等方面内容。SOAPrinciples-LooseCoupling“服务对使用者来说只需低的耦合需求，并且自身也同周围环境解耦"SOA松耦合SOA松耦合SOA松耦合SOA松耦合SOA松耦合SOA松耦合SOAPrinciples-Abstraction“服务契约仅包含最基本的信息，并且关于服务的信息限于服务契约中所发布的避免增加不必要的服务信息，元数据.尽可能的隐藏服务的底层细节.保持松散耦合关系对于服务组合的设计很重要SOAPrinciples-Reusability逻辑是高度通用的契约是通用和可扩展的可以并发访问SOAPrinciples-Autonomy独立与外部环境和影响的执行逻辑增加可靠性行为可预测性SOAPrinciples-Statelessness只有必要时才维护状态信息根据每次请求消息获得服务所需的全部信息，或者根据消息从资源信息库中获得完成服务的所需全部信息增加可靠性和可伸缩性有状态的资源：一个状态数据集，表示为XML文档具有标识和生命周期多个服务都能够操纵它WS-RF资源框架SOAPrinciples-Discoverability服务具有用于注册的元数据，以便被发现和使用服务契约元数据存储在服务注册库中SOAPrinciples-Composability服务可以有效组合解决更为复杂的问题无论各个成分自身有多复杂

，都可以有效进行组合有利于可重用性灵活的服务契约，以便不同种类的数据交换SOAPrinciples-ApplyingSOA-Governance针对服务所制定的管控策略和机制，涵盖服务的整个生存周期。计划——确定治理的重点。定义——定义治理模型启用——实现治理模型度量——改进治理模型当服务越来越多时，服务URL配置管理变得非常困难，硬件负载均衡器的单点压力也越来越大。当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。

接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？

SOAPrinciples-ApplyingSOA-Governance规模继续扩大，应用之间不再是扁平的对应关系，开始分层，比如核心数据层，业务集成层等，就算没有出现循环依赖，也不允许从低层向高层依赖，以免后续被逼循环依赖。

服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？

慢慢一些敏感数据也都服务化了，安全问题开始变得重要，谁能调该服务？如何授权？

SOAPrinciples-ApplyingSOA-Governance就算是不敏感的服务，也不是能任意调用，比如某服务突然多了一个消费者，这个消费者的请求量直接把服务给拖跨了，其它消费者跟着一起故障。

虽然有SLA约定，如果不能控制，就只是君子协定，如何确保服务质量？

SOAPrinciples-ApplyingSOA-Governance

服务上线后，需要验证服务是否可用。

服务接口设计的经验一直在慢慢的积累过程中，很多接口并不能一促而蹴，在修改的过程中，如何保证兼容性，怎么判断是否兼容？另外，更深层次的，业务行为兼容吗？

SOAPrinciples-ApplyingSOA-Governance随着服务的不停升级，总有些意想不到的事发生，比如cache写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？谁能调该服务？如何授权？

SOAPrinciples-ApplyingSOA-Governance当已有很多小服务，可能就需要组合多个小服务的大服务，为此，不得不增加一个中间层，暴露一个新服务，里面分别调其它小服务，这样的新服务业务逻辑少，却带来很多开发工作量。

并不是所有服务的访问量都大，很多的服务都只有一丁点访问量，却需要部署两台提供服务的机器，进行HA互备，如何减少浪费的机器。SOAPrinciples-ApplyingSOA-Governance策略法律、规章制度、最佳实践SOAPrinciples-ApplyingSOA-Governance服务定义（服务的范围、接口和边界）服务部署生命周期（各个生命周期阶段）服务版本治理（包括兼容性）服务迁移（启用和退役）服务注册中心（依赖关系）SOAPrinciples-ApplyingSOA-Governance已计划。已标识了新服务并正在设计中，不过尚未实现或正在实现中。测试。实现后，必须对服务进行测试（稍后将对测试进行更详细的说明）。有些测试可能需要在生产环境中执行，此环境会将服务作为活动服务处理。活动。这是服务可供使用的阶段，我们通常所谈说的服务实际是处于此阶段的服务。这是一个服务，处于可用状态，在实际运行并且确实可完成相应的工作，而且尚未退役。已弃用。此阶段描述仍然处于活动状态但不会再存在很长时间的服务。这将警告使用者停止使用此服务。已退役。这是服务的最后一个阶段，表示一个不再提供的服务。注册中心可以保存有关曾经处于活动状态但不再可用的服务的记录。服务消息模型（规范数据模型）服务监视（进行问题确定）服务所有权（企业组织）服务测试（重复测试）服务安全（包括可接受的保护范围）SOAPrinciples-ApplyingSOA-GovernanceApplyingSOA–

GovernanceSOA的基本体系结构样式SOA体系结构解决什么？仅仅有松散耦合的服务还不够，服务本身不解决接口间调用关系的拓扑问题P2P，HUB的混乱和瓶颈问题仍然存在64SOA的体系结构模式应用SOA来构造业务系统，既可以通过简单的WebService调用，也可以通过复杂的企业服务总线(ESB)将异构系统集成为业务过程。按照SOA应用场景的复杂度，将其体系结构模式分为10种65SOA的体系结构模式按照SOA应用场景的复杂度，将其体系结构模式分为10种：硬连线(Hard-wired)点对点的服务发布与调用(P2P)服务适配器(Serviceadaptor)服务代理(Serviceproxy)远程服务策略(Remoteservicestrategy)单点访问(Singlepointofaccess)虚拟服务提供者(Virtualprovider)服务集成器(Serviceintegrator)企业服务总线(Enterpriseservicebus)集成化的服务生态系统(Integratedserviceecosystem)SOA基本体系结构样式之一：发布-访问发布(Publish)：为了使服务可访问，需要发布服务描述以使服务使用者可以发现它。发现(Find)：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。调用(invoke)：在检索到服务描述之后，服务使用者继续根据服务描述中的信息来调用服务。服务提供者服务注册中心服务使用者(1)发布(2)发现(3)调用一个可通过网络寻址的实体，它接受和执行来自使用者的请求一个应用程序、一个软件模块或需要一个服务的另一个服务，服务使用者根据服务契约来使用服务服务发现的支持者它包含一个可用服务的存储库，并允许感兴趣的服务使用者查找服务提供者接口WebService中该模式的实现机制WSDL：Web服务描述语言用于服务接口的描述——Whatcantheservicedo?UDDI：统一描述、发现和集成协议服务使用者通过UDDI发现相应的服务并据此将服务集成在自身的系统中——Whatkindofservicesareneeded?SOAP：简单对象访问协议用户在服务客户端与服务提供者之间传递信息，通过HTTP或JMS等各类基于文本的消息传递协议来运输WebService提供者WebService注册中心WebService客户端(1)WSDL(2)UDDI(3)SOAP68基本模式：发布-访问WSDL

WebService(J2EE,PL/SQL,

.NET,C/C++,

Legacy…)WebServiceClient(J2EE,.NET,

PL/SQL…)PointstodescriptionDescribesServiceFindsServiceInvokeswithXMLMessagesSOAPUDDI

RegistryPointstoserviceSOA基本体系结构样式之二：适配器模式企业中存在若干遗留系统(legacysystem)；这些系统采用较传统的技术开发，无法提供清晰的接口(interface)；但其他系统仍然需要访问这些遗留系统的功能；——怎么办？通过构造适配器(adaptor,wrapper)，将遗留系统中的功能进行二次包装，从而开放出接口供其他系统使用。典型技术：Java2ConnectorWebSphereBusinessIntegrationAdaptor服务适配器Wrapper包装器：在每个数据源上加一个Wrapper，负责封装数据源，将该数据源的特定数据对象逻辑的转换为一个通用的数据模型，并将对通用数据模型提出的查询转换为本地可执行的操作。绑定服务地址与遗留系统的功能之间的映射关系以上2种SOA模式的缺陷客户端为了使用服务，必须在自己的程序中写入调用服务的代码，即通过服务的URI地址来访问服务。这导致客户端与服务之间的耦合度过大，系统的灵活性受到限制。例如，客户端需要在多个候选服务之间进行灵活替换，以获得更好的QoS。——怎么办？将这种绑定关系从代码中抽取出来。SOA基本体系结构样式之三：服务代理②客户端通过“serviceregistry”来访问服务，当希望访问其他服务时，只要手工修改该registry即可——相当于一个配置文件；③客户端通过“servicebroker”来动态决定需访问那个服务；——完全动态的服务选择，很困难，需要用到服务语义的相关技术。①客户端直接绑定服务接口(WSDL/URI);以上模式存在的问题上述场景都是调用单个服务如果客户端需要同时或连续调用多个服务的功能，它必须在自己的系统中分别写出多个调用；——非常麻烦；而且，对多个服务的调用次序也是容易发生变化的，需要频繁的修改；——难以做到；以上模式存在的问题——怎么办？降低耦合度将servicebroker的思想进一步发挥，客户端不去逐一调用服务，而是首先将这些被调用的服务按逻辑关系集成起来，形成一个集成的、大粒度的服务；客户端只需调用这一个服务即可；当该服务执行时，集成器(integrator)依靠配置信息来分别调用一个个小粒度的服务；对这些配置信息进行修改，即可方便的做到变更。SOA的基本体系结构样式之四：服务集成器服务集成器OperationalSystemsService-OrientedBusinessProcessComponent-basedPresentationQoS,Security,Management&Monitoring(InfrastructureService)IntegrationArchitecture(EnterpriseServiceBus)Object-orientedCICS/COBOLCRM,ERPBusinessIntelligenceProcessChoreographyCompositeServicesPortlets5432167EnterpriseComponentsSOA中的Orchestration：服务编制Orchestration：指业务流程，以一种说明性的方式（而非编程方式）定义编制的服务的执行顺序（如并行，逻辑条件分支等），最终合称为组合服务。通常包括分支控制点、并行处理、人工相应步骤和许多预定义步骤(转换、适配器、电子邮件、报警等)。SOA中的Choreography：服务编排Choreography：指业务协作，将多个零散的、分别由多方提供的服务/业务流程按照彼此之间的协同关系组织起来，支持多方的交互行为。侧重于不同服务之间的消息传递的次序与规则，各自描述自己如何与其他服务进行消息交换，以保证期望的协同行为。Choreography&Orchestration编制（Orchestration）——面向可执行的流程：流程编制使用一个可执行的中心流程来协同内部及外部的WebService交互。通过中心流程来控制总体的目标，涉及的操作，服务调用顺序。适用于域内小粒度服务组合；有中心控制点（流程引擎），层次调用。

编排（Choreography）——面向合作：更多的强调协同工作和业务合作能力，通过消息的交互序列来控制各个部分资源的交互。参与交互的资源都是对等的，没有集中的控制。适用于域间大粒度服务协作

Orchestration的特性在于：请求者-提供者模型，通过一个中心的控制来协同流程中的各种活动（用什么服务，什么时候用，怎么用）Choreography是对等模型，高度依赖2件事情：各参与方地位平等协同工作；详细定义的通用规则以保证协同不会导致混乱.SOA中的“集成”：服务编制(ServiceOrchestration)服务编制(ServiceOrchestration)：将多个小粒度的Web服务按照特定的业务逻辑规则构造为一个可执行的业务过程，同时又可以看作是一个大粒度的复合Web服务。侧重点：如何使用已有的服务来构造新的服务。BPEL面向Web服务的过程建模语言；由IBM、Microsoft和BEA共同提出；实现基于WSDL的WebServices之间的流程编排；BPEL的一个例子Determineif

CanFulfill10:00amHandleNegativeCreditExceptionDiscountServicestartendBPELFlow?CreditServiceInventory

ServiceGetDiscountSendCreditApplicationReceiveCreditResult03:00pmSendInventoryRequestReceiveInventoryResult<process></process><switch><variable><partnerLink><partnerLink><partnerLink><faultHandlers><receive><invoke><invoke><flow></flow>BPEL是一门用于自动化业务流程的形式规约语言。用XML文档写入BPEL中的流程能在Web服务之间以标准化的交互方式得到精心组织。这些流程能够在任何一个符合BPEL规范的平台或产品上执行。所以，通过允许顾客们在各种各样的创作工具和执行平台之间移动这些流程，BPEL使得他们保护了他们在流程自动化上的投资。示例：Oracle的BPEL执行引擎OracleBPELProcessManager可用于集成应用程序和原有系统，使用较细粒度的服务组成粗粒度的服务，构建以流程为中心的组合应用程序，完成业务流程和工作流应用程序（包括复杂的路由和调升）自动化。WS-CDLWS-ChoreographyDefinitionLanguage(WS-CDL)isalanguagefordescribinghowpeer-to-peerparticipantscollaborate.ThelanguageusesXML,andsomeaspectsareinspiredbythepi-calculus.(未获得广泛认可)DifferenciesbetweenBPELandCDLCDLprovidesadefinitionoftheinformationformatsbeingexchangedbyALLparticipants,BPELprovidestheinformationformatsexchangedbyoneparticipant.(全局/局部信息交换格式)CDLprovidestheglobalmessageexchangebetweenparticipantswithoutaspecificpointofview,BPELprovidesthemessageexchangefromthepointofviewofoneparticipant(全局/局部消息传递)CDLprovides“reactive”rulesthatareusedbyeachparticipanttocomputethestateofthechoreographyandinferwhichmessageexchangewill/canhappennext.BPELspecifies“active”rulesthatareexecutedtoinferwhattodonext,oncetheruleiscomputed,theorchestrationrun-timeexecutesthecorrespondingactivity(ies).(被动/主动活动激活)WS-CDL(WebServiceChoreographyDefinitionLanguage)：专门的Web服务编排标准，由SUN,SAP,Oracle发起，目前由W3C发布。WS-CDL是一种描述多方契约的语言，有些类似WSDL扩展；可以看作是在已经存在的webserv