面向服务架构( 三 )


面向服务架构

文章插图
面向服务的体系结构中的角色2、服务提供者:服务提供者是一个可通过网路定址的实体 , 它接受和执行来自请求者的请求 。它将自己的服务和接口契约发布到服务注册中心 , 以便服务请求者可以发现和访问该服务 。图2面向服务的体系结构中的角色3、服务注册中心:服务注册中心是服务发现的支持者 。它包含一个可用服务的存储库 , 并允许感兴趣的服务请求者查找服务提供者接口 。面向服务的体系结构中的每个实体都扮演着服务提供者、请求者和注册中心这三种角色中的某一种(或多种) 。面向服务的体系结构中的操作包括:发布:为了使服务可访问.需要发布服务描述以使服务请求者可以发现和调用它 。查询:服务请求者定位服务.方法是查询服务注册中心来找到满足其标準的服务 。绑定和调用:在检索完服务描述之后 , 服务请求者继续根据服务描述中的信息来调用服务 。面向服务的体系结构中的构件包括:(1)服务:可以通过已发布接口使用服务 , 并且允许服务使用者调用服务 。(2)服务描述:服务描述指定服务使用者与服务提供者互动的方式 。它指定来自服务的请求和回响的格式 。服务描述可以指定一组前提条件、后置条件和/或服务质量(Q0S)级别 。利用价值对 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特性6.1概述SOA服务具有平台独立的自我描述XML(标準通用标记语言的子集)文档 。Web服务描述语言(WSDL , WebServicesDescriptionLanguage)是用于描述服务的标準语言 。SOA服务用讯息进行通信 , 该讯息通常使用XMLSchema来定义(也叫做XSD , XMLSchemaDefinition) 。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中 。服务间的通讯也可以看作企业内部处理的关键商业文档 。在一个企业内部 , SOA服务通过一个扮演目录列表(directorylisting)角色的登记处(Registry)来进行维护 。应用程式在登记处(Registry)寻找并调用某项服务 。统一描述 , 定义和集成(UDDI , UniversalDescription , Definition , andIntegration)是服务登记的标準 。每项SOA服务都有一个与之相关的服务品质(QoS , qualityofservice) 。QoS的一些关键元素有安全需求(例如认证和授权) , 可靠通信(译注:可靠讯息是指 , 确保讯息“仅且仅仅”传送一次 , 从而过滤重複信息 。) , 以及谁能调用服务的策略 。为什幺选择SOA?不同种类的作业系统 , 套用软体 , 系统软体和套用基础结构(applicationinfrastructure)相互交织 , 这便是IT企业的现状 。一些现存的应用程式被用来处理当前的业务流程(businessprocesses) , 因此从头建立一个新的基础环境是不可能的 。企业应该能对业务的变化做出快速的反应 , 利用对现有的应用程式和套用基础结构(applicationinfrastructure)的投资来解决新的业务需求 , 为客户 , 商业伙伴以及供应商提供新的互动渠道 , 并呈现一个可以支持有机业务(organicbusiness)的构架 。SOA凭藉其松耦合的特性 , 使得企业可以按照模组化的方式来添加新服务或更新现有服务 , 以解决新的业务需要 , 提供选择从而可以通过不同的渠道提供服务 , 并可以把企业现有的或已有的套用作为服务 , 从而保护了现有的IT基础建设投资 。如图1的例子所示 , 一个使用SOA的企业 , 可以使用一组现有的套用来创建一个供应链複合套用(supplychaincompositeapplication) , 这些现有的套用通过标準接口来提供功能 。6.2服务架构为了实现SOA , 企业需要一个服务架构 , 服务消费者(serviceconsumer)可以通过传送讯息来调用服务 。这些讯息由一个服务汇流排(servicebus)转换后传送给适当的服务实现 。这种服务架构可以提供一个业务规则引擎(businessrulesengine) , 该引擎容许业务规则被合併在一个服务里或多个服务里 。这种架构也提供了一个服务管理基础(servicemanagementinfrastructure) , 用来管理服务 , 类似审核 , 列表(billing) , 日誌等功能 。此外 , 该架构给企业提供了灵活的业务流程 , 更好地处理控制请求(regulatoryrequirement) , 例如SarbanesOxley(SOX) , 并且可以在不影响其他服务的情况下更改某项服务 。6.3SOA基础结构要运行 , 管理SOA应用程式 , 企业需要SOA基础 , 这是SOA平台的一个部分 。SOA基础必须支持所有的相关标準 , 和需要的运行时容器 。图3所示的是一个典型的SOA基础结构 。SOAP , WSDL , UDDIWSDL , UDDI和SOAP是SOA基础的基础部件 。WSDL用来描述服务;UDDI用来注册和查找服务;而SOAP , 作为传输层 , 用来在消费者和服务提供者之间传送讯息 。SOAP是Web服务的默认机制 , 其他的技术为可以服务实现其他类型的绑定 。一个消费者可以在UDDI注册表(registry)查找服务 , 取得服务的WSDL描述 , 然后通过SOAP来调用服务 。WS-IBasicProfileWS-IBasicProfile , 由Web服务互用性组织(WebServicesInteroperabilityOrganization)提供 , 是SOA服务测试与互用性所需要的核心构件 。服务提供者可以使用BasicProfile测试程式来测试服务在不同平台和技术上的互用性 。J2EE和.Net儘管J2EE和.NET平台是开发SOA应用程式常用的平台 , 但SOA不仅限于此 。像J2EE这类平台 , 不仅为开发者自然而然地参与到SOA中来提供了一个平台 , 还通过他们内在的特性 , 将可扩展性 , 可靠性 , 可用性以及性能引入了SOA世界 。新的规範 , 例如JAXB(JavaAPIforXMLBinding) , 用于将XML文档定位到Java类;JAXR(JavaAPIforXMLRegistry)用来规範对UDDI注册表(registry)的操作;XML-RPC(JavaAPIforXML-basedRemoteProcedureCall)在J2EE1.4中用来调用远程服务 , 这使得开发和部署可移植于标準J2EE容器的Web服务变得容易 , 与此同时 , 实现了跨平台(如.NET)的服务互用 。6.4服务品质在企业中 , 关键任务系统(mission-criticalsystem , 译注:关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的 , 那幺该系统就是该企业的关键任务系统 。比如 , 电话系统对于一个电话促销企业来说就是关键任务系统 , 而文字处理系统就不那幺关键了 。)用来解决高级需求 , 例如安全性 , 可靠性 , 事物 。当一个企业开始採用服务架构作为工具来进行开发和部署套用的时候 , 基本的Web服务规範 , 像WSDL , SOAP , 以及UDDI就不能满足这些高级需求 。正如前面所提到的 , 这些需求也称作服务品质(QoS , qualityofservices) 。与QoS相关的众多规範已经由一些标準化组织(standardsbodies)提出 , 像W3C(WorldWideWebConsortium)和OASIS(theOrganizationfortheAdvancementofStructuredInformationStandards) 。下面的部分将会讨论一些QoS服务和相关标準 。安全Web服务安全规範用来保证讯息的安全性 。该规範主要包括认证交换 , 讯息完整性和讯息保密 。该规範吸引人的地方在于它藉助现有的安全标準 , 例如 , SAML(asSecurityAssertionMarkupLanguage)来实现web服务讯息的安全 。OASIS正致力于Web服务安全规範的制定 。可靠在典型的SOA环境中 , 服务消费者和服务提供者之间会有几种不同的文档在进行交换 。具有诸如“仅且仅仅传送一次”(once-and-only-oncedelivery) , “最多传送一次”(at-most-oncedelivery) , “重複讯息过滤”(duplicatemessageelimination) , “保证讯息传送”(guaranteedmessagedelivery)等特性讯息的传送和确认 , 在关键任务系统(mission-criticalsystems)中变得十分重要 。WS-Reliability和WS-ReliableMessaging是两个用来解决此类问题的标準 。这些标準现在都由OASIS负责 。策略服务提供者有时候会要求服务消费者与某种策略通信 。比如 , 服务提供商可能会要求消费者提供Kerberos安全标示 , 才能取得某项服务 。这些要求被定义为策略断言(policyassertions) 。一项策略可能会包含多个断言 。WS-Policy用来标準化服务消费者和服务提供者之间的策略通信 。控制当企业着手于服务架构时 , 服务可以用来整合数据仓库(silosofdata) , 应用程式 , 以及组件 。整合套用意味着例如异步通信 , 并行处理 , 数据转换 , 以及校正等进程请求必须被标準化 。在SOA中 , 进程是使用一组离散的服务创建的 。BPEL4WS或者WSBPEL(WebServiceBusinessProcessExecutionLanguage)是用来控制这些服务的语言 。WSBPEL目前也由OASIS负责 。管理随着企业服务的增长 , 所使用的服务和业务进程的数量也随之增加 , 一个用来让系统管理员管理所有运行在多相环境下的服务的管理系统就显得尤为重要 。WSDM(WebServicesforDistributedManagement)规定了任何根据WSDM实现的服务都可以由一个WSDM适应(WSDM-compliant)的管理方案来管理 。其它的qos特性 , 比如合作方之间的沟通和通讯 , 多个服务之间的事务处理 , 都在WS-Coordination和WS-Transaction标準中描述 , 这些都是OASIS的工作 。6.5SOA不是Web服务在理解SOA和Web服务的关係上 , 经常发生混淆 。根据2003年4月的Gartner报导 , YefimV.Natis就这个问题是这样解释的:“Web服务是技术规範 , 而SOA是设计原则 。特别是Web服务中的WSDL , 是一个SOA配套的接口定义标準:这是Web服务和SOA的根本联繫 。”从本质上来说 , SOA是一种架构模式 , 而Web服务是利用一组标準实现的服务 。Web服务是实现SOA的方式之一 。用Web服务来实现SOA的好处是你可以实现一个中立平台 , 来获得服务 , 而且随着越来越多的软体商支持越来越多的Web服务规範 , 你会取得更好的通用性 。6.6SOA的优势SOA的概念并非什幺新东西 , SOA不同于现有的分散式技术之处在于大多数软体商接受它并有可以实现SOA的平台或应用程式 。SOA伴随着无处不在的标準 , 为企业的现有资产或投资带来了更好的重用性 。SOA能够在最新的和现有的套用之上创建套用;SOA能够使客户或服务消费者免予服务实现的改变所带来的影响;SOA能够升级单个服务或服务消费者而无需重写整个套用 , 也无需保留已经不再适用于新需求的现有系统 。总而言之 , SOA以藉助现有的套用来组合产生新服务的敏捷方式 , 提供给企业更好的灵活性来构建应用程式和业务流程 。