面向服务的体系结构专题报告

面向服务架构的理解与分析廖志钢摘要面向服务的体系结构（Service-OrientedArchitecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。SOA是一种以服务为中心，松散耦合、可动态优化和重用扩展的分布式应用构造方法。经过十多年的历练与发展，已成为在开放、异构的网络环境下构造集成化分布式信息系统的潮流。SOA所带来的IT系统松耦合、互操作的特性，以及由此带来的大粒度重用、大规模集成、灵活性提升等诸多优点，为软件系统的建立、整合与运维，尤其是基于互联网的软件产业的创新与发展，带来了新的动力和机遇。关键词：SOA面向服务体系架构分析1SOA的发展历程SOA的概念最初由Gartner公司于1996提出,由于当时的技术水平和市场环境尚不具备真正实施SOA的条件,因此当时SOA并未引起人们的广泛关注。伴随着互联网的浪潮,越来越多的企业将业务转移到互联网领域,带动了电子商务的蓬勃发展。为了能够将公司的业务打包成独立的、具有很强伸缩性的基于互联网的服务,出现了Web服务的概念,这可以说是SOA的开端。新技术的兴起必然伴随着一系列技术标准和规范的诞生,SOA也是如此。短短几年之内,在厂商、研究人员和标准化组织的共同努力下,已经制定出一大批SOA标准和规范,有力地推动了SOA的发展。据统计,目前有超过56个涉及SOA的各个方面的标准机构,但他们之间工作的不协调,也给SOA的发展带来的负面影响。根据Gartner的跟踪分析，2007年SOA开始走出谷底，2008则还在复苏期缓慢地艰难爬升。整体上看，SOA仍然处于成长上升阶段，还未真正广泛普及，还未形成稳定的价值。未来几年SOA将进入到应用市场主导的理性发展阶段，人们将把更多的关注点放在SOA如何“落地”，即用户如何成功实施SOA、并创造实际价值等方面。2国内对于SOA推广应用认识现状分析尽管SOA的概念进入中国已有一段时间，但国内用户至今对SOA的认识仍不够清晰，导致SOA的市场需求并不明朗。就目前国内的现状来看，对于SOA，更多的企业仍处于观望的态度，有很多的疑虑。据调查，表示对SOA关注的企业用户为数不多，其中有15.9%的流通行业，而在制造行业仅有8.6%。国内SOA应用的这一尴尬局面，很大程度上是由于认识上的误区影响了SOA推广应用。认识的误区主要表现在三方面：首先，认为SOA是万能的，可以应用于所有的场合。其实情况并非如此。SOA并不能代替已经在公司内部存在的那些被良好集成的应用系统。通过合理的部署，SOA系统可以改善原有的IT系统，使得原有的那些应用系统更具有柔性。通常情况下，复杂的IT构架对SOA的需求更加迫切，并且SOA需要与外部复杂的IT环境交互，并快速地应对频繁发生的业务变化。其次，认为构建了SOA架构，就不再需要应用整合技术。其实，SOA并非一蹴而就。虽然SOA使系统整合更容易，但是企业仍然需要核心的整合技术，例如转换、挖掘、流程整合、适配器等等，使它们成为架构和规划中的组成部分。企业先要对需求进行一次全面的评估，不仅仅局限于IT，而是面向整个企业。实现SOA可能需要耗费几年的时间。第三，认为构建了SOA，就不需要IT人员的参与，业务人员照样可以把服务连接成新的业务流程。这种想法没有考虑服务的实现仍得有人编写实施服务的软件，系统也仍需要有经验的IT专业人员把业务工作流转换成顾及企业级性能、安全、资源使用和可靠性的具体实施方案。其实这些误区的产生是由于对SOA的理解偏差所致。对于国内的用户来讲，接受SOA难的并不是技术，而是SOA理念的灌输，以及对企业文化的重新改造。SOA与传统的应用体系结构不同，SOA更多地是针对变化而设计，基于SOA的系统能具备更大的弹性，而且能够实时地根据企业的变化，调整自己的结构，以满足企业变化的需求。3SOA的理解3.1松耦合的系统这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（Ondemand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于SOA的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然SOA是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA系统原型的一个典型例子是通用对象请求代理体系结构（CommonObjectRequestBrokerArchitecture，CORBA），它已经出现很长时间了，其定义的概念与SOA相似。然而，现在的SOA已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensibleMarkupLanguage，XML）为基础的。通过使用基于XML的语言（称为Web服务描述语言（WebServicesDefinitionLanguage，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前CORBA中的接口描述语言（InterfaceDefinitionLanguage，IDL）可比了。Web服务并不是实现SOA的惟一方式。前面刚讲的CORBA是另一种方式，这样就有了面向消息的中间件（Message-OrientedMiddleware）系统，比如IBM的MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在SOA的设计中扮演重要的角色。此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何SOA中都起着重要的作用。3.2SOA的作用我可以用面向服务的体系结构做什么？SOA的需要来源于需要使业务IT系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。下面举一个具体的例子。一个服装零售组织拥有500家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用WSDL接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配WSDL接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store）的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到SOA模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。为了延续内部改变的观念，IT经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的SOA模型得出的。这是来自SOA模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来SOA模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。正如您可以看到的，在这里，改变和SOA系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对SOA模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（UniversalModelingLanguage，UML），并且描述成模型驱动的体系结构（Model-DrivenArchitecture，MDA）。对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑（businesslogic）或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用.NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。3.3SOA特性SOA服务具有平台独立的自我描述XML文档。Web服务描述语言（WSDL，WebServicesDescriptionLanguage）是用于描述服务的标准语言。SOA服务用消息进行通信，该消息通常使用XMLSchema来定义（也叫做XSD，XMLSchemaDefinition）。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。在一个企业内部，SOA服务通过一个扮演目录列表（directorylisting）角色的登记处（Registry）来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。统一描述，定义和集成（UDDI，UniversalDescription，Definition，andIntegration）是服务登记的标准。每项SOA服务都有一个与之相关的服务品质（QoS，qualityofservice）。QoS的一些关键元素有安全需求（例如认证和授权），可靠通信，以及谁能调用服务的策略。3.4SOA构建实例分析以ERP与生产管理系统集成为例，ERP具有决策支持功能，为企业提供商业智能和决策支持，其在前端展示和个性化服务上的支持却相当薄弱，而生产管理系统作为前端用户交互的门户，在前端展示和个性化服务上提供了很好的支持，但其缺乏商业智能和决策支持的功能，综上分析，ERP与生产管理系统存在优势互补的特点。因此，很好地集成以上两个系统将大大提高企业的市场竞争力。考虑到集成应具备的灵活性、可拓展性、可重用性等特点，并结合SOA的基本原则，设计了基于SOA架构的以WEB服务实现的ERP与生产管理系统集成模型框架。图1基于SOA的ERP与电子商务系统的集成模型框架模型框架技术采用J2EE的架构和标准实现。在该框架中以XML为数据交换的格式，以SOAP标准的RPC方法来调用Webservice,WSDL描述Webservice的细节，以UDDI来发布Webservice，这是Webservice中主要用到的标准协议，只要遵循这些协议，异构的Webservice之间就可以互相访问，达到多系统的交互集成。该集成模型框架的主要模块功能描述如下：SOAP-Routing：定义了一个消息路径模型，用来处理SOAP消息的传递，同时也是整个模型框架的核心，可使SOAP消息从服务客户机到服务提供者的完整交换成为可能。通过其可选的反向路径来启用双向消息交换模式，如请求/响应模式。Web服务发布模块：作为服务提供者将现有符合WSDL的Web服务向UDDI注册中心注册并发布。UDDI注册中心：作为服务注册中心提供发布和查找服务描述的方法。UDDI数据实体提供对定义业务和服务信息的支持。WSDL中定义的服务描述信息是UDDI注册中心信息的补充。在本框架中UDDI注册中心分为公共UDDI和私有UDDI注册中心。公共UDDI注册中心可以利用现有全球UDDI注册中心功能，实现全球范围内服务的发现和访问；私有UDDI注册中心是企业内部使用的UDDI注册中心，企业内部的Web服务通过这个注册中心，对企业内部发布，供企业内部使用。Web服务应用接口：作为服务使用者发起对注册中心中服务的查询，通过传输绑定服务，并且执行服务功能。服务模块：该模块提供了监视，管理和维持诸如安全，性能和可用性等QoS的能力。原子/事物引擎模块：该模块提供了原子、业务事务能力，能够对失败，误操作等一系列情况做回滚操作。功能扩展预留模块：框架的预留模块，基于企业的发展需要，企业会提出更多的新增需求，今后可以在该模块中实现。4SOA架构给信息化带来的变革随着全球信息化的浪潮，信息化产业不断发展、延伸，已经深入了众多的企业及个人，SOA系统架构的出现，将给信息化带来一场新的革命。纵观信息化建设与应用的历程，尽管出现过XML、Unicode、UML等众多信息标准，但是许多异构系统之间的数据源仍然使用各自独立的数据格式、元数据以及元模型，这是信息产品提供商一直以来形成的习惯。各个相对独立的源数据集成一起，往往通过构建一定的数据获取与计算程序来实现，这样的做法需要花费大量工作。信息孤岛大量存在的事实，使信息化建设的ROI大大降低，ETL成为集中这些异构数据的有效工具。ETL常用于从源系统中提取数据，将数据转换为与目标系统相兼容的格式，然后将其装载到目标系统中。数据经过获取、转换、装载后，要产生应用价值，还需另外的数据展现工具予以实现，如此复杂的数据应用过程，必定产生高昂的应用成本。结构化的数据管理尚可通过以上方法，予以实现其集成应用。在非结构化的内容方面，这些具有挑战性的问题令人生畏。内容管理的应用方案基于不同的信息化应用系统，而且大部分是纵向的以组织部门为界限的。在目前的内容管理市场中，经常使用来自不同厂商的产品来提供这些解决方案。即使是同一个厂商的产品，相互之间的功能也是经常重叠，并且无法集成。随着信息化建设的深入，不同应用系统之间的功能界限已趋于模糊。同时企业资源计划系统和协同商务系统，又需要商业智能的分析展现数据提供用户操作依据。在激烈竞争且多变的市场环境下，企业的管理模式很难固化，应用传统的信息化软件，当企业要做出一些改动时需要面对巨大的挑战。微软大中华区服务部总经理辛儿伦介绍说，从上世纪60年代应用于主机的大型主机系统，到80年代应用于PC的CS架构，一直到90年度互联网的出现，系统越来越朝小型化和分布式发展。2000年WebService出现后，SOA被誉为下一代Web服务的基础框架，目前已经成为计算机信息领域的一个新的发展方向。SOA的出现给传统的信息化产业带来新的概念，不再是各自独立的架构形式，能够轻松的互相联系组合共享信息。可复用以往的信息化软件。基于SOA的协同软件提供了应用集成功能，能够将ERP、CRM、HR等异构系统的数据集成。松散耦合方式，只要充分了解业务的进程，就可以不用编写一行代码，通过流程图实现一套我们自己的信息系统。就像已经给你准备好了砖瓦和水泥，只需要想好改什么样的房子就可以轻松的盖起。加快开发速度，并且减少了开发和维护的费用。软件将所有的管理提炼成表单和流程，以记录管理的内容，指定过程的流转方向。更简便的信息和数据集成。信息集成功能可以将散落在广域网和局域网上的文档、目录、网页轻松集成，加强了信息的协同相关性。同时，复杂、成本高昂的数据集成，也变成了可以简单且低成本实现的参数设定。创建了完全集成的信息化应用新领域。在具体的功能实现上，SOA协同软件所实现的功能包括了知识管理、流程管理、人事管理、客户管理、项目管理、应用集成等，从部门角度看涉及了行政、后勤、营销、物流、生产等。从应用思想上看，SOA协同软件中的信息管理功能，全面兼顾了贯穿整个企业组织的信息化软硬件投入。尽管各种IT技术可以用于不同的用途，但是信息管理并没有任意地将信息分为结构化或者非结构化的部分，因此ERP等结构化管理系统并不是信息化建设的全部;同时，信息管理也没有将信息化解决方案划分为部门的视图，因此仅仅以部分为界限去构建软件应用功能的思想未必是不可撼动的。基于SOA的协同软件与ERP、CRM等传统应用软件相比，关键的不同在于它可以在合适的时间、合适的地点并且有正当理由而需要它提供服务的任何用户提供服务。5SOA的发展方向SOA的理念和技术经过十多年的发展，有高峰时的辉煌，也有低谷时的坚持，目前正在走向平稳发展阶段。在产品和市场方面，传统老牌供应商也占据了主要份额，国内厂商如何突围走出自己的路，也是SOA下一步发展需要关注的重点。在总体发展思路上重点把握以下3点。（1）在标准规范建设上，构造和完善SOA国际和国内直至行业标准规范的总体布局，将标准规范与技术实现、业务应用相结合，推进更多的国内和行业标准国际化，提升我国自主软件产业在国际标准阵营的主动权和话语权。（2）在技术上，重点发展和建立重业务、可选配、轻量级的SOA产品平台，推动集约化应用与管控模式下的核心技术积累，在相应的体系结构、保障和优化技术等方面形成特色核心技术。促进软件服务化转型，优化产业结构，促进国内供应商基于现有SOA平台联合协作，促进成功的SOA成果应用落地。（3）在SOA应用和市场方面，发挥国内供应商产品轻量级、可选配的技术特点，结合熟悉业务需求的特长优势，协作开展咨询和服务工作，为行业用户提供咨询和工程实施服务，在项目支持上重点突破与广泛应用相结合，选择重点领域，进行联合攻关，解决用户重大工程需求问题。6结语在理解SOA和Web服务的关系上，经常发生混淆。根据2003年4月的Gartner报道，YefimV.Natis就这个问题是这样解释的：“Web服务是技术规范，而SOA是设计原则。特别是Web服务中的WSDL，是一个SOA配套的接口定义标准：这是Web服务和SOA的根本联系。”从本质上来说，SOA是一种架构