解读SOA架构及SOA发展现状.doc

解读SOA架构及SOA发展现状 学号：1110379174 姓名：李敏相信今天已经没有人对SOA的概念感到陌生，或者说没有听到过这个名字。但，你眼中的SOA是什么？造成这种理解上的差异，原因有两点。其一，给SOA下定义的组织机构太多，没有统一的标准。若干标准化组织、大厂商等都给出了自己对SOA的理解，但这些理解并不统一。其二，人们对SOA的理解曾一度被解决方案厂商所误导。或者由于短视，或者迫于抢占市场的压力，SOA解决方案供应商们关心的是打着SOA的旗号卖产品。但凡能沾点边儿的，都贴上了SOA的标签。SOA是什么？SOA有什么特点和实施原则？与其他的技术有什么区别与联系？Web服务和SOA又是什么关系？SOA的出现对于信息化产业有什么影响？本文将就上面提到的这些问题，尝试根据自己的理解给出SOA的解读并介绍SOA在当今中国的发展现状。 SOA定义面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。从其名字上看，它有两个核心：一是服务，二是架构。它以服务为核心。传统的整合架构都是以应用为核心，而SOA里谈的一切都是从服务展开的。它不是某种特定技术，而是一种架构风格、架构思想或一组指导架构设计原则。在特定风格、思想和原则的指导下设计出来的企业应用架构就是具有SOA的特性和优势的架构。 SOA特点及实施原则 SOA的实施具有几个鲜明的基本特征。实施SOA的关键目标是实现企业IT资产的最大化重用。要实现这一目标，就要在实施SOA的过程中牢记以下特征： *可从企业外部访问 *随时可用 *粗粒度的服务接口分级 *松散耦合 *可重用的服务 *服务接口设计管理 *标准化的服务接口 *支持各种消息模式 *精确定义的服务契约 SOA服务具有平台独立的自我描述XML文档。Web服务描述语言（WSDL， Web ervices Description Language）是用于描述服务的标准语言。 SOA 服务用消息进行通信，该消息通常使用XML Schema来定义（也叫做XSD， XML Schema Definition）。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。 在一个企业内部，SOA服务通过一个扮演目录列表（directory listing）角色的登记处（Registry）来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。统一描述，定义和集成（UDDI， Universal Description， Definition， and Integration）是服务登记的标准。 每项SOA服务都有一个与之相关的服务品质（QoS， quality of service）。QoS的一些关键元素有安全需求（例如认证和授权），可靠通信（译注：可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。），以及谁能调用服务的策略。众所周知，业务是不断发展、变化的，业务创新越来越成为企业核心竞争力的一部分。传统IT支撑业务发展的方式是为新业务构建新的业务系统，设计新的数据库，系统多是“竖井状”的孤岛形式，系统间连接常见的是点对点的缺乏规划的连接方式。久而久之，这样的方式已经无法满足业务发展对IT带来的要求，IT成为企业的严重短板。SOA出现的主要目的就是彻底改变这种局面，使IT变得灵活，与业务对齐，不再成为企业的后腿。甚至能够促进业务的发展，并创造新的业务价值。为什么SOA能够实现IT和业务对齐呢？这得归功于SOA架构中的若干实施原则。*应用功能的服务化：将应用程序打散成服务是SOA实施的关键之一。一方面，遗留系统的功能和数据不能丢弃，只有重用才能利用其价值。另一方面，将应用作为整体，是从技术和实施上都非常难于复用的。所以，SOA的实施原则要求将应用中的功能模块抽象成开放、标准、粒度适中的服务，进而促进现有功能重用、避免重复投资、加速新业务开发的速度。*架构的松耦合原则：SOA的另一重要原则是松耦合，松耦合不仅表现在服务本身，还表现在架构层面。服务的松耦合表现在服务的描述与其底层实现技术是分离的。换言之，一个服务，其底层实现可能是Java，也可能是.NET;架构的松耦合表现在服务消费者与服务提供者的分离，在服务消费者及提供者之间置入仲裁(Mediation)模块。这样，服务提供者对服务的修改对服务消费者产生的影响可降至最低。*面向服务的整合：面向服务的整合是SOA的核心之一，主要由企业服务总线(ESB)提供这一部分的能力。服务消费者之间既有面向服务的调用，也有面向消息的处理。企业服务总线提供的协议转换、数据格式转化、多种消息处理机制、审计、日志等功能能够最大限度地提高SOA架构的灵活性和扩展性。*服务的组合及编排：服务梳理出来之后，基于服务的组合和编排就成为可能。服务的组合和编排能够最大限度地重用现有功能，支持业务的创新。偏重于技术层面的服务/消息组合可由ESB提供，而偏业务层面的服务组合和编排可通过BPM组件实现。当然，SOA实施原则还有许多，如服务治理、安全访问、信息服务、门户服务的实施原则，Web服务和SOA在理解SOA和Web服务的关系上，经常发生混淆。Web 服务并不是实现SOA的惟一方式，但是SOA的火爆在很大程度上归功于WebService标准的成熟和应用的普及为广泛的实现SOA架构提供了基础。根据2003年4月的Gartner报道，Yefim V. Natis就这个问题是这样解释的：“Web服务是技术规范，而SOA是设计原则。特别是Web服务中的WSDL，是一个SOA配套的接口定义标准：这是Web服务和SOA的根本联系。”从本质上来说，SOA是一种架构模式，而Web服务是利用一组标准实现的服务。Web服务是实现SOA的方式之一。用Web服务来实现SOA的好处是你可以实现一个中立平台，来获得服务，而且随着越来越多的软件商支持越来越多的Web服务规范，你会取得更好的通用性。 SOA架构给信息化带来的新变革SOA的出现给传统的信息化产业带来新的概念，不再是各自独立的架构形式，能够轻松的互相联系组合共享信息。 可复用以往的信息化软件。基于SOA的协同软件提供了应用集成功能，能够将ERP、CRM、HR等异构系统的数据集成。 松散耦合方式，只要充分了解业务的进程，就可以不用编写一行代码，通过流程图实现一套我们自己的信息系统。就像已经给你准备好了砖瓦和水泥，只需要想好盖什么样的房子就可以轻松的盖起。加快开发速度，并且减少了开发和维护的费用。软件将所有的管理提炼成表单和流程，以记录管理的内容，指定过程的流转方向。 更简便的信息和数据集成。信息集成功能可以将散落在广域网和局域网上的文档、目录、网页轻松集成，加强了信息的协同相关性。同时，复杂、成本高昂的数据集成，也变成了可以简单且低成本实现的参数设定。创建了完全集成的信息化应用新领域。 在具体的功能实现上，SOA协同软件所实现的功能包括了知识管理、流程管理、人事管理、客户管理、项目管理、应用集成等，从部门角度看涉及了行政、后勤、营销、物流、生产等。从应用思想上看，SOA协同软件中的信息管理功能，全面兼顾了贯穿整个企业组织的信息化软硬件投入。尽管各种IT技术可以用于不同的用途，但是信息管理并没有任意地将信息分为结构化或者非结构化的部分，因此ERP等结构化管理系统并不是信息化建设的全部;同时，信息管理也没有将信息化解决方案划分为部门的视图，因此仅仅以部分为界限去构建软件应用功能的思想未必是不可撼动的。基于SOA的协同软件与 ERP、CRM等传统应用软件相比，关键的不同在于它可以在合适的时间、合适的地点并且有正当理由而需要它提供服务的任何用户提供服务。SOA在当今中国的发展现状前几年，硝烟弥漫、战火纷飞，各路厂商奋力拼杀在SOA市场上。大厂商拼的是在市场上的统治地位，小厂商若能分得一杯羹也满意了。喧嚣之后总要归于沉静。转眼间，云计算铺天盖地席卷而来，绚丽的云彩抓住了大众的眼球。SOA像是退居幕后的明星、落幕的英雄，很少再被人提起，甚至有人宣布“SOA已死”。那么，SOA真的销声匿迹了吗？中国式SOA的当前状态是怎样的呢？SOA呼声渐弱，实际上它越来越火。的确，现在大厂商们都已经不再把SOA作为市场宣传的重点了。但是，SOA却走到了应用最广泛的时期。经过几年的历练，中国的SOA不论理论、实践，还是产品都得到了长足的发展。一方面，中国培养了一大批掌握SOA精髓的系统集成商和独立软件提供商，如华为、东软、用友、金蝶、中软他们或将SOA的理念植入到其解决方案中，或将SOA理念融合进其产品之中。SOA架构师、整合架构师的队伍也不断壮大。另一方面，中国也拥有了自主研发的SOA中间件产品，如普元、炎黄盈动的流程引擎;锐易特、东方通、金蝶的ESB都是市场上的佼佼者。伴随着国人对SOA的理解越来越深入，越来越成熟和专业的SOA产品及解决方案将会随之而来。SOA已经深入人心。现在，几乎所有待建的系统和平台都要求基于SOA架构。SOA已经成为基本的架构原则，不论是系统间的整合，还是平台的建设，人们会不约而同地采用SOA原则来架构灵活、易于扩展的系统。SOA的几点不足尽管SOA已经深入人心，但并非所有的人都能将SOA原则使用得很好。若不能很好运用SOA，就无法收获相应的价值。下面给出几点常见的不足之处，我无法在这篇文章中展开讨论这些问题，但还是期待从业人员正视这些不足之处，找到正确的实施方法。*对SOA的理解参差不齐。若不能充分理解SOA，未能理解SOA的目标和架构原则，就无法正确实施SOA。在一些项目实施过程中，旧系统被直接推翻，而不是先将遗留系统服务化，然后再循序渐进式地改进。若所有旧系统全部推翻后重建，势必会耗费大量时间和人物力才能完成，不符合SOA多次少量投入的特点。此外，许多人理解的服务就是Web Service规范的服务。而事实上，SOA不限定采用何种技术，只要是开放、标准的技术即可，比如JMS、RESTful Service等。*忽略服务梳理和服务描述的重要性。我清楚地记得一个项目，用户通过这样的方式生产Web服务：将系统里的某个通用Java接口中的所有方法全部暴露出来，使用某个WSDL自动生产工具生成一个超级大的WSDL文件以及许多关联的数据描述(XSD)文件。WSDL中暴露了大量原有程序中的Java包结构和数据结构信息。这个例子是一个糟糕的实践。*哪些功能应该封装成服务、服务该如何描述，这些工作是需要规划的。我们需要根据业务、现有系统等方面，全方位(或局部)梳理业务，才能找到那些适合于暴露成服务的功能。确定好应该暴露的服务之后，进一步确定服务规约，描述其输入和输出、与其他系统的依赖关系、服务非功能性需求等。*重视工作流(Workflow)，忽视服务自动编排(Service Choreography)。我见到的大多数BPM项目都是关于工作流的，工作流是以审批为主的业务流程，在中国尤为突出。这种流程在某种程度上比此前从一个办公室走到另一办公室、然后再到下一个办公室的场景已经先进许多了。但我们知道除了工作流之外，BPM还有其他形式，比如服务自动编排，这样的场景却在很大程度上被忽视了。*服务治理未得到充分重视。服务治理或管理对于长期SOA实施的成败至关重要。随着SOA的持续发展，企业中的服务会越来越多，服务的变更、服务位置的变化和服务的版本升级相关工作越来越频繁，如何把这些变化造成的影响控制到最小？再者，当服务多了之后，如何快速便捷地找到所需的服务也是极为重要的工作。所以，服务管理和治理越发显得重要。云计算冲击下的SOA云计算是新宠，就像当年的SOA一样。当市场在大肆宣传云计算时，SOA在一旁淡然地笑了。喜欢挑起争端的人会说：“云计算来了，SOA该靠边站。”这种说法只能当作不负责任的市场噱头，不能当真。然而，二者并非同一层面的事物，不具有可比性，所以也就不存在谁替代谁的问题。相反，云计算和S