关于SOA架构设计的案例分析下

SOA,即Service Oriented Architecture。面向服务的体系结构( Service-Oriented Architecture , SOA )是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

SOA是一种IT体系结构风格,是包含运行环境、编程模型、系统构造方法和环境架构风格和相关方法论等在内的一整套新的发布式软件系统构造方法和环境,涵盖服务的整个生命周期:建模—开发—整合—部署—运行—管理。

SOA支持将业务转换为一组相互链接的服务或可重复业务任务,可以对这些服务进行重新组合,以完成特定的业务任务,从而让您的业务快速适应不断变化的客观条件和需求。

服务是SOA的核心:

业务被划分为粗粒度的业务服务和业务流程;

业务服务相对独立、自包含、可重用,由一个或者多个分布的系统所实现,而业务流程由服务组装而来;

一个“服务”定义了一个与业务功能或业务数据相关的接口,以及约束这个接口的契约,如服务质量要求、业务规格、安全性要求、法律法规的遵循、关键业绩指标等。

由于SOA是 通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用 的架构模型,并采用标准的服务接口,这使得他具有一下优点:

(1)编码灵活性

可基于模块化的低层服务、采用不同组合方式创建高层服务,从而实现重用,这些都体现了编码的灵活性。此外,由于服务使用者不直接访问服务提供者,这种服务实现方式本身也可以灵活使用。

(2)明确开发人员角色

可以根据不同人员熟悉的业务环境,有针对性的部署业务流程和划分工作任务,以便更好的分配人力、物力等资源。

(3)支持多种客户类型

借助精确定义的服务接口和对XML、Web服务标准的支持,可以支持多种客户类型,包括PDA、手机等新型访问渠道。

(4)更易维护 、更高的可用性

由于 服务提供者和服务使用者的松散耦合关系 、 开放标准 接口 的采用 ,使其具有很好的维护性和可用性。

(5)更好的伸缩性

依靠服务设计、开发和部署所采用的架构模型实现伸缩性。服务提供者可以彼此独立调整,以满足服务需求。

SOA技术Web Service基本协议:UDDI、WSDL、SOAP。

简单来说,XML是最低级的通用语言。它是一种可扩展标记语言,不同的平台和语言都能够理解它。很对web服务标准中都使用了XML。标记的内容都将由定义语法的模式进行验证或解析。

Web服务是能够进行重用的功能构建块。必须由提供者系统使用标准协议和语义对其进行发布、查找和调用。这是使用具有不同语法和相关结构的xml进行的。

Web服务描述语言(WSDL)是一个XML实例文档,符合用于服务请求方和提供者之间的通信的w3c标准XML语法。它描述web服务如何工作。正是由于WSDL文件,Web服务才被称为“自描述”,因为可以从WDSL文件生成SOAP消息。很多工具都可以从WSDL文件创建客户机代码。

WSDL文件包含以下元素:

(1)  type:使用某种语法的数据类型定义

(2)  Message:要传递的数据

(3)  Part:消息参数

(4)  Operation:服务支持的操作的抽象描述

(5)  Port Type/Interface:一个或多个端点支持的操作的抽象集。

(6)  Building:特定端口类型的具体协议和数据格式规范

(7)  Port/Endpoint:绑定和网络地址的结合。

(8)  Service:相关端点的结合,包括其关联的接口、操作、消息等。

UDDI定义如何查找web,UDDI并不像WSDL和SOAP一样深入人心,因为很多时候,使用者知道web服务的位置。

UDDL列表保存在UDDL注册中心。每个列表可以包含以下内容:

(1)白页:地址、联系人和已知标志符

(2)黄页:基于标准分类法的行业类别

(3)绿页:有关业务公开的服务的技术信息

SOAP是用于在网络上交换基于XML的消息的协议。

SOAP消息包含以下元素:

(1)  Envelope:必需的元素,用于将文档标志为SOAP消息

(2)  Header:包含应用程序特定的信息

(3)  Body:必需的元素,定义调用和响应信息

(4)  Fault:包含有关出现的错误的信息

SOA架构特性:

(1)  敏捷性:服务的独立性,使得每个服务可以被单独地开发、测试和集成

(2)  重用性:不同模块和系统中的重复部分,可独立出一个个服务。

(3)  低耦合性:技术和位置的透明性,使得服务的请求者和提供者之间高度耦合

SOA的基本原则:

(1)  无状态:以避免服务请求者依赖于服务提供者的状态

(2)  单一实例:避免功能冗余

(3)  明确定义的接口:接口稳定,明确;数据隐藏。

(4)  自包含和模块化:业务稳定、重复出现的活动和组件,独立运行部署、版本控制、自我管理和恢复

(5)  粗粒度:服务数量不应该太大,依靠小徐交互而不是远程过程调用,通常消息量比较大,但是服务之间的交互频率较低

(6)  服务之间的松耦合性:服务使用者看到的是服务的接口,其位置、实现技术、当前状态等对使用者是不可见的,服务私有数据对服务使用者是不可见的

(7)  重用能力:服务应该是可以重用的

(8)  互操作性、兼容和策略声明。

对SOA的需要来源于需要使业务IT系统变得更加灵活,以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现, IT  系统既可以利用现有系统的功能,又可以准备在以后做一些改变来满足它们之间交互的需要。

下面举一个具体的例子。一个服装零售组织拥有  500  家国际连锁店,它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色,甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容,那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用  WSDL  接口在操作方面的灵活性,每个公司都可以将它们的现有系统保持现状,而仅仅匹配  WSDL  接口并制订新的服务级协定,这样就不必完全重构它们的软件系统了。这是业务的水平改变,也就是说,它们改变的是合作伙伴,而所有的业务操作基本上都保持不变。这里,业务接口可以作少许改变,而内部操作却不需要改变,之所以这样做,仅仅是为了能够与外部合作伙伴一起工作。

  另一种形式是内部改变,在这种改变中,零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店,这可以看作是采用店中店( store-in-store )的业务模型。这里,虽然公司的大多数业务操作都保持不变,但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修,但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下, SOA  模型保持原封不动,而内部实现却发生了变化。虽然可以将新的方面添加到  SOA  模型中来加入新的出租安排的职责,但是正常的零售管理系统继续如往常一样。

  为了延续内部改变的观念, IT  经理可能会发现,软件的新配置还可以以另外的一种方式加以使用,比如出租粘贴海报的地方以供广告之用。这里,新的业务提议是通过在新的设计中重用灵活的  SOA  模型得出的。这是来自  SOA  模型的新成果,并且还是一个新的机会,而这样的新机会在以前可能是不会有的。

  垂直改变也是可能的,在这种改变中,零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话,就会带来  SOA  模型结构的显著改变,与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下, SOA  模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题,这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式,而不是在许多现有的软件平台上常常看到的其他方式。

  正如您可以看到的,在这里,改变和  SOA  系统适应改变的能力是最重要的部分。对于开发人员来说,这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生,这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是,架构师的作用就是引起对  SOA  模型大的改变。这种分工,就是让开发人员集中精力于创建作为服务定义的功能单元,而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起,它已经有十多年的历史了,通常用统一建模语言( Universal Modeling Language , UML ),并且描述成模型驱动的体系结构( Model-Driven Architecture , MDA )。

  对于面向同步和异步应用的,基于请求 / 响应模式的分布式计算来说, SOA 是一场革命。一个应用程序的业务逻辑( business logic )或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如,服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用,而无须理解服务的底层实现。举例来说,一个服务可以用。 NET 或 J2EE 来实现,而使用该服务的应用程序可以在不同的平台之上,使用的语言也可以不同。

软件产品设计成SOA架构及目的或者现实的意义是:保全或保护企业原来遗留下来的软件系统(数据),实现软件数据的无缝接轨,避免企业原有投资打水漂、数据需重复录入。由此,可以缩短软件产品的实施推广期。可以在实施推广期间,快速调整以最大程度的满足客户的需求。在客户应用业务发生改变,必须进行新的投入、改造时,产品可以进行新的快速扩展或直接第三方设备(软、硬件)兼容。从而避免产品本身的僵化,成为使用者的遗留系统。

猜你喜欢

转载自www.cnblogs.com/lijing925/p/10964397.html
今日推荐