服务计算概论

第一章绪论§1.面向效劳计算概述1.1效劳计算起因和概念随着经济全球化和电子商务的普及，当代企业必须要面对不断变化的市场条件、剧烈的竞争压力、新出台的法规以及新的竞争威胁，从而企业要获得竞争优势就要不断调整其业务模式和需求。因此，企业应用要能需要根据业务的需要变得更加灵活，能够对业务模式和业务需求的变化迅速做出反响，具有“随需而变”的敏捷性。这种敏捷性表达在新的业务可以通过组合现有的效劳快速构造出来，业务的调整也可以通过调整效劳之间的关系迅速改变。这种应用集成既包括企业内的各种应用系统之间的集成，也包括集团企业总部与下属企业、企业与上下游伙伴之间的业务协同。但是，构建“随需而变”的应用。面对怎么样的环境呢？随需应变的软件应用需要考虑三个因素：重用、标准化封装和松耦合组装。重用不仅可以被其它效劳或使用者调用，而且可以与其它效劳一起组合成新的效劳；标准化封装通过提供统一的描述标准，消除软件对语言、平台和厂家的依赖；松耦合组装利用松耦合的组件构造灵活可变的企业应用。但是，假设实现企业应用的快速调整和构造，传统的分布式计算技术存在两大难题：一是应用程序客户端和效劳端之间的紧密耦合问题，以微软的DCOM为例，客户端和效劳器端都要求遵循同样的API，一旦一个COM对象代码有改变，那么访问该对象的客户端代码也需要相应的更改。二是不同应用程序之间的异构问题。由于企业应用严重依赖计算环境，从而使得同一企业不同应用之间，不同企业应用之间还不能有效地相互集成。总之，传统架构存在的最大缺陷就是对变化的适应性差，难以适应企业不断变化的业务需求。构造灵活可变的企业应用系统必须通过建立松耦合的计算环境来实现。计算环境包含一组计算机、软件平台、协议和相互连通的网络。在该计算环境中，计算机之间、软件平台之间可以通过网络按照协议实现数据交换和信息处理。采用标准化的效劳描述将企业应用进行封装，通过以编程方式实现的自描述接口，提供效劳的核心功能，屏蔽了应用的实现细节，这样可以通过效劳描述访问效劳构造企业应用。形象地说就是将软件封装成类似于硬件模块带接口的构件，在接口匹配的情况下可以随时“插入”特定的软件应用完成相应的功能，使效劳之间〔企业内或跨企业〕以松散耦合的形式互联、互操作完成特定的业务需求。基于效劳概念的资源封装和抽象逐渐成为资源发布、共享和应用协同的重要技术根底。这样，剥离了客户端和效劳器端之间的语言/平台依赖，消除了不同应用之间由于采用的不同系统、不同平台和不同语言所造成的异构。在接口描述不变的情况下，效劳实现的任意变更都不会对应用产生影响。这样，一方面可以将遗留系统封装为效劳进行重用，一方面可以直接调用企业外效劳提供商提供的效劳，从而可使开发者更快速、敏捷地根据企业业务的变化，构造企业应用。面向效劳计算(SOC)是一种新的计算范式,它利用效劳为根本构建块,支持异构环境下分布式应用的快速、低本钱、便捷的组合。这种方法的根本思想是通过重用已有的网络效劳而不是重新开发来构造企业应用。重用和组装是这个方法的核心，松散耦合是这个方法的本质。重用就是使应用系统具有较强的独立性，以便其作为一个“零部件”能随时被单独使用；组装就是高效而灵活地将跨组织、跨平台的应用无缝地进行组合来构造满足企业需求的应用。松散耦合的目标是使应用系统之间的依赖到达最小，任何应用系统的更改和错误对其他的应用系统没有影响。效劳是自治的，与平台无关的计算实体。效劳是可描述，可发布、可发现的、可以动态组装成分布式的、可交互的、可扩展的系统，效劳可以包括从执行简单的请求到复杂的业务流程，该流程要求不同多种层的效劳消费者和供给商之间点对点之间的关系。部署在一个系统中的任何一段代码和任何应用组件都可以重用，并且可以转化为网络效劳。实现这一思想的关键是面向效劳架构，SOA是一种符合逻辑的设计软件系统的方式，通过已发布的或可发现的接口将效劳提供给终端用户或者分布在网络上的效劳。一个结构良好、基于标准SOA通过以效劳的形式提供独立的、可重用的应用功能和更加健壮的根底，可以赋予企业更加灵活的根底设施和处理环境。Web效劳是当今最有前途的面向效劳计算技术，Web效劳利用互联网作为传输媒介、利用开放的基于因特网的标准，如简单对象访问协议SOAP作为传输数据、Web效劳描述语言WSDL用于效劳定义、业务流程执行语言BPEL编排效劳。Web效劳解决了以往分布式计算平台的两大难题：一个是平台之间的互操作问题；另一个是客户端和效劳端之间的紧密耦合问题。它提供一个与操作系统无关、与程序设计语言无关、与机器类型无关、与运行环境无关的平台，实现网络上应用的共享。效劳技术是由作为一个整体的现代社会而形成的，特别是动态业务、医疗、教育和政府效劳等关键领域，同时也将不断推动作为一个整体的社会的形成。通过封装和重用业务的核心功能、增强灵活性、提高技术迁移的适应性、改善操作效率，应用效劳技术降低了复杂性和本钱。由于这些原因，面向效劳的范型可望得到迅速地应用，由于它解决昂贵的、难以解决的业务和技术问题，将比以往的任何应用技术更具有前途。Servicestechnologiesarebeingshapedby,andincreasinglywillhelpshape,modernsocietyasawhole,especiallyinvitalareassuchasdynamicbusiness,health,educationandgovernmentservices.Applyingservicestechnologiesleadstoreducedcomplexityandcosts,exposingandreusingcorebusinessfunctionality,increasedflexibility,resiliencetotechnologyshiftsandimprovingoperationalefficiency.Forallthesereasons,itisexpectedthattheServiceOrientedComputingparadigmwillexhibitasteeperadoptioncurve,asitsolvesexpensiveandintractablebusinessandtechnologyproblems,andwillinfiltratemoreoftheapplicationsportfolio,thanpreviousapplicationtechnologies.SOC包括效劳根本原理、效劳组合、效劳管理和监控以及面向效劳的工程。§2.效劳计算产生的背景效劳计算给软件体系架构以及软件开发方法带了革命性的变化，软件体系架构从早期集中式的整体软件体系结构逐步开展成为一种松散、灵活、易扩展的分布式软件架构模式，效劳表达了面向效劳的编程方法，这种方法改变了传统的重新开发的软件设计理念和方法，通过重用已有的网络效劳构造应用的设计思想。不难看出，效劳计算是软件体系架构和软件开发方法不断演化的产物，也是进一步提高和加快软件产业开展的必然结果。2.1软件体系架构的开展历程软件体系架构是指构成软件系统的软件元素、软件元素外部可见的属性以及这些软件元素之间的关系。为便于说明问题，首先介绍软件系统的分层逻辑结构。一般而言，构造软件时都会遇到三类问题：⑴如何将软件功能以图形或字符人机界面的形式呈现给用户；⑵如何编写实际的应用逻辑实现软件功能；⑶如果利用已有资源如数据库、文件系统等完成对资源的管理和操作。基于以上分析，软件体系架构从逻辑上可以分为三层，即表示层、应用逻辑层和资源管理层1．主机计算环境。其软件体系架构的特点是，软件的所有功能集中由主机完成，而分布的是仅仅具有输入输出功能的哑终端或多人分时使用一台计算机。其优点是其所有功能都在一致的系统环境下实现，因此可方便地对系统进行调试。其缺点是组成系统的表示层、应用逻辑层和资源管理层之间彼此紧密耦合、很难维护和扩展；各个主机之间的数据、功能很难共享和相互调用。2．客户/效劳器计算环境。通过局域网相互连接的计算设备构成客户/效劳器计算环境，这种体系架构将表示层从集中式的效劳器中剥离出来转移给客户端，客户和效劳器通过网络协议、远程调用或消息等方式来相互协作，完成计算。其主要优点是将表示层和其他两层功能别离，降低了对效劳器的性能要求，支持跨平台系统开发，还可以根据需要个性化地设计和实现表示层的样式。主要缺点是客户端和效劳器端之间紧密耦合，一般一个特定的客户端只能连接到一台效劳器，容易造成“信息孤岛”；另外维护代价高，一旦应用环境发生变化需要改变业务逻辑时，每个客户端程序都要进行更新。3．多层分布式计算环境。为了满足更高的可伸缩性需求，C/S计算环境派生出多层软件架构，在C/S架构根底上进一步将效劳器端的应用逻辑层和资源管理层别离，把应用逻辑交给单独应用效劳器处理。其中，表示层被一分为二，通用功能由标准应用软件承当、而非通用功能由特定的分布式计算平台实现，浏览器和应用效劳器上的表示层之间通过标准文档形式的标准HTML对话；应用逻辑层和资源管理层之间通过标准数据访问协议〔JDBC/ODBC〕对话。其主要优点是浏览器和应用效劳器之间、应用效劳器和资源管理器之间是松耦合关系。但是，表示层和应用逻辑层之间是紧耦合的，两者之间在技术平台上耦合紧密。当表示层想访问不同平台如J2EE和DCOM上的应用逻辑时，不得不参加额外的接口适配器代码。4、面向效劳的计算环境。也就是基于标准、开放的互联网技术，以效劳为中心的计算环境。这是一个以效劳为根本单位和抽象手段的世界。随着互联网〔Internet〕的开展，开放和标准的网络协议被普遍支持，所有底层计算平台都开始支持这些标准和协议，这导致一个计算环境内部和各个计算环境之间交互的藩篱被打破。其软件架构的特点是将应用逻辑层封装为Web效劳，这样表示层就可以通过XML/SOAP协议与其实现松耦合交互，从而解决表示层和应用逻辑层紧密耦合的问题，保证了通用性和最大的交互能力，这使得计算环境开展到一个全新的阶段—基于标准、开放的互联网技术的计算环境。在这样的计算环境中，各个局部可以采用异构的底层技术，它们使用XML来描述和表示自己的数据和功能，采用开放的网络协议〔如〕来握手，在此之上，基于Web效劳来互操作和交换数据。在这里，一个很重要的新概念是"效劳"，它是一个自包含的功能，使用者通过明确定义的接口〔契约〕来与一个效劳交互，这个接口的描述基于WSDL〔WebServiceDescriptionLanguage〕这样的开放标准。Web效劳是实现效劳的技术手段，就如同各种编程语言中的对象是实现对象的技术手段，J2EE中的EJB是实现组件的技术手段一样。2.2软件编程范型的演变过程软件系统的规模越大，复杂程度也就越高，驱动软件技术不断向前开展的核心动因之一是复杂性控制。复用是控制软件复杂度的有效机制，下面从软件复用角度阐述阐述每种编程范型的特点。编程范型经历四个阶段，即面向过程的编程、面向对象的编程、面向组件的编程以及标准化的Web效劳的编程。简言之，范型就是某一学科在一定时期内开展研究活动共有的根底和准那么。编程范型是指导和制约编程活动的范型。1.面向过程的编程。是指用程序状态和改变程序状态的语句描述计算的编程范型。面向过程的语言提供一种通过过程抽象控制复杂性的方法，从而支持更大规模软件的开发，同时过程也提供一种根本的代码复用机制。但是该范型的主要缺点是：这种复用范围是一个可执行程序内复用，静态开发期复用，如果修改了过程，意味着所有调用这个过程的系统必须重新编译、测试和发布。2.面向对象的编程。是指用封装了数据和对数据操作的对象以及对象之间的消息传递描述计算的编程范型。面向对象的认识论是将系统看成由多个对象组成，通过对象之间的通信形成了系统面向对象系统中功能。其主要特征是:(1)封装性(2)继承性,(3)多态性。复用的两种最常用技术是封装性和类继承，封装机制实现了数据抽象和信息隐蔽，通过生成实例后通过对象组合组装成系统；继承机制提供了代码的复用。但是这两种复用机制都存在缺点：继承机制导致子类和父类之间的紧耦合关系，同时对象很难共享，更谈不上分布式计算环境下复用。其根本原因在于认知体系上的不完整，对象的理解不同,难以形成统一的标准和开发标准，由此基于面向对象的构件软件应运而生。3.面向组件的编程。面向组件的编程是指以构件的创立、构件的管理以及复用已有的构件组装形成应用为根本活动的编程范型。构件是模块化、可部署、可替换的软件系统组成局部，它封装了内部的具体实现并对外提供一组接口。比方Spring框架中，就采用了面向组件的思路，将系统看作一个个的组件，通过定义组件之间的协作关系〔通过效劳〕来完成系统的构建。这样做的好处是能够隔离变化，合理的划分系统。而框架的意义就在于定义一个组织组件的方式。基于构件编程范型的特点是：基于构件范型涉及三类根本活动:构件生产、构件的管理和应用组装〔基于构件的应用开发〕。构件生产者采用领域工程方法通过对领域的分析和设计总结形成可复用的领域构件。构件管理者根据一定的分类指标和特征管理构件，以方便构件的发布和发现。构件复用者负责进行基于构件的软件开发、包括构件的查询、构件理解、构件组装以及系统演化等。分布式组件技术屏蔽了网络硬件平台的差异性和操作系统与网络协议的异构性，实现企业网络内复用，不同系统之间复用。但是，分布式组件也是严重依赖其计算环境，各种分布式组件技术在构件实现和运行支撑技术缺乏统一标准，在组件描述、发布、发现、调用、互操作协议及数据传输等方面呈现出异构性，从而导致不同技术设计和实现的构件之间无法直接组装式复用如J2EE和DCOM无法互相调用。J2EE(EJB)、CORBA和DCOM是比较典型的三种分布式组件。基于构件编程范型的优点是解决分布式网络计算环境之间的组件复用，通过远程对象代理，来实现企业网络内复用，不同系统之间复用。4.面向效劳的编程。前已经叙及，不同组件技术没有统一的标准，不同厂家之间的组件很难实现互操作，最终导致了跨企业/部门的业务集成和重组难以灵活快速的进行。为彻底解决互操作问题，通过标准化的封装技术如Web效劳,SCA/SDO等，来实现更高层次的复用和互操作。效劳是通过标准封装，效劳组件之间的组装、编排和重组来实现效劳的复用。而且这种复用，可以在不同企业之间，全球复用，到达复用的最高级别，并且是动态可配置的复用。面向效劳的编程是指以效劳的创立、效劳的管理以及复用已有的效劳组装形成应用为根本活动的编程范型。效劳是自治、开放、自描述、与实现无关的网络构件。面向效劳的编程范型采用标准化的传输协议SOAP、描述协议WSDL，使软件构件的复用扩大到整个互联网，可使不同分布式平台技术〔不同厂商〕实现的Web效劳之间可以相互调用。如J2EE所提供的Web效劳可以被.NET来调用。反过来，.NET也可以调用J2EE所提供的Web效劳。Web效劳的SOAP传输协议尽管是一种标准的传输协议，但是它毕竟还是一种特殊的传输协议，一种特定的技术。Web效劳并不支持其他的传输协议，如RMI等。所以说效劳还是和特定的SOAP技术绑定在一起的。面向效劳编程范型的根本活动和基于组件编程范型根本上是一致的，不同是编程的根本组件变成了效劳。从技术实现和运行模式角度，Web应用效劳器分为脚本模式、面向对象模式和对象模式。脚本模式应用效劳器通过脚本以超文本方式描述动态页面的内容和处理逻辑，当接受到客户请求时，应用效劳器首先搜索相应的源文件，然后在效劳器端解释该源文件中的脚本，最后将脚本解释器产生的结果汇编后返回给Web应用效劳器〔是否是客户端？〕脚本模式Web应用效劳器一般都通过扩展接口〔如CGI和ISAIP〕或效劳器端脚本语言〔如果JSP、ASP和PHP〕动态地生成响应页面，但是这种模式的应用效劳器可扩展性、高可用性差，可重用性低。此外，该种模式缺乏集成历史遗留系统以及事物处理的支持能力。面向对象模式介于脚本模式和对象模式之间，其主要特点是使用面向对象编写脚本。例如，在JSP和Servlets中使用Java语言进行编码。与纯脚本模式相比，该模式可重用性较好，但是没有相应的标准，不提供统一的接口标准，其使用范围和移植性受到了限制。对象模式应用效劳器支持分布对象模型，能将应用划分为多层，易于维护，在开发和部署过程中支持组件重用，模块化程度高，业务逻辑的变化只需修改相关组件即可。与面向对象模式相比，对象模式应用效劳器遵循相应的标准和标准，其中较突出的两大类：J2EE(Java2platformenterpriseedition)和微软的.Net。J2EE由SUN公司在3年前提出，目前至少有40多种实现J2EE标准的效劳器。J2EE为事务性Web应用的开发、部署、运行和管理提供一系列的标准和标准，主要包括JavaServlets，JSP,EJB，JTA，JTS，JMS，JAXP，JMX，RMI-IIOP，JNDI，JCA，JavaMail和JAF标准。这些J2EE标准为应用效劳器的实现提供了一个完整的底层框架和一套标准的标准，在不同的J2EE应用效劳器之上的应用操作也可以互操作，移植的风险和代价小。而微软那么在其操作系统之上附加一系列具备中间件功能的软件包来提供给用效劳器的相应功能。微软.Net构建在WindowsDNA技术〔如MicrosoftTransactionServer,COM+,MSMQ,SQLServer数据库等〕根底上，在.Net中提供了一系列企业级应用效劳，为部署、管理和建立基于XML和Web的应用构筑了.Ｎet效劳器结构，包括ApplicationCenter，BizTalkServer,ExchangeServer等，它们结合了Windows平台上的一系列开发工具和技术〔如VisualStudio,CommerceServer,ExchangeServer等〕，提供了强有力的应用效劳器解决方案。虽然目前J2EE和.Net势均力敌，但是J2EE作为一种标准，具有Net无法比较的跨平台、企业应用集成能力以及可扩展性和开放性，得到许多厂商的支持，已经逐步被广阔研发人员和企业所接受，有良好的前景，逐步成为Web应用效劳器研究和开发的一个方向。§3.企业应用集成〔喻坚、韩燕波书〕3.1企业内应用集成技术3.2企业间应用集成技术3.3面向效劳的应用集成技术§4.效劳计算学科涵盖内容2.1效劳资源层主要为数据资源和软件资源的效劳化过程提供根底标准、技术和方法支持。该层主要解决两大问题：①效劳本质的认识问题，即效劳模型包含哪些方面，应用何种语言进行效劳描述，效劳具有哪些根本特征；②效劳的实现问题，即如何开发、封装、测试、部署、运行和发布效劳等。2.2效劳会聚层效劳资源层实现了各类异质异构数据和软件资源的效劳标准化，而效劳会聚层是在效劳资源层根底上进一步实现细粒度效劳到大粒度效劳的标准化，即为不同效劳之间的协同以及由多个效劳构成的效劳流程的管理提供一系列标准、技术和方法。它涵盖了效劳集成与协作、效劳编排与效劳编舞、效劳流程管理等。2.3效劳应用层经过效劳资源层和效劳会聚层，各类异质异构数据和软件资源或资源集合被整合成不同粒度的标准化效劳，这为方便、快捷、透明地应用效劳提供了可能。效劳应用层主要为效劳在使用过程中提供根本的技术和方法支持，包括效劳调用、效劳发现、效劳匹配、效劳组合、效劳验证、效劳适配、效劳监控等技术，这些技术是当前效劳计算研究与开发中最活泼的局部。2.4效劳系统层是在效劳应用层技术根底上，为指导效劳计算环境下设计、开发、运行和管理面向效劳的软件系统而提供的一组标准、技术和方法，包含了面向效劳的体系架构、企业效劳总线以及效劳系统工程等。§5.效劳计算开展现状以及应用效劳计算是企业界和学术界共同努力的结果。企业界致力于制定效劳计算相关技术标准、开发各种支撑工具软件和系统平台；学术界致力于效劳计算学科建设、理论创新和方法研究。3.1企业界企业界是推动效劳计算产生和开展的源动力。企业界对“随需应变”的软件系统的强烈需求催生了Web效劳技术、面向效劳的体系架构等效劳计算技术体系最为重要的支撑技术。W3C致力于创立Web相关技术标准并催生Web技术开展。该组织针对效劳计算根底技术，特别是Web效劳技术成立了多个工作组，涵盖了Web效劳架构、Web效劳策略、Web效劳编舞、Web效劳语义标准等工作内容。OASIS致力于推进电子商务标准的开展、整合、推广和应用，制定了当前大局部效劳计算技术标准。它为效劳计算技术专门成立了多个技术委员会，涵盖了效劳平安、可靠、效劳质量、事务、信任以及效劳流程等方面，制定了一系列重要标准。第二章面向效劳体系架构SOA(Software-OrientedArchitecture)，即面向效劳架构。软件架构〔SoftwareArchitecture，或软件体系结构〕，描述了软件系统的蓝图，即，构成一个程序或系统的构件的结构，构件间的互连，以及管理构件的设计和演化的原那么和指导。从技术上看，SOA代表了一种开放的、可扩展的、可联邦的、可组合的设计范型，是软件构件技术在分布计算环境的自然延伸。SOA的根底设施是已有中间件平台的演化和开展，保存了传统架构的成功特征。〔主要引用面向效劳架构第三章内容〕§1.什么是SOASOA的理念最初由全球最具权威的IT研究与参谋咨询公司Gartner于1996年提出，但是由于当时的技术水平和市场环境尚不具备真正实施SOA的条件，因此SOA并未引起人们的广泛关注。进入21世纪之后，Internet风起云涌，越来越多的企业将业务转移到互联网领域，带动了电子商务的蓬勃开展。为了能够将公司业务打包成独立的、具有强大伸缩性的可跨越Internet访问的效劳，人们提出了Web效劳的概念，这是SOA实践的真正发端。到现在为止，还没有一个权威的SOA标准定义，因为从不同角度，不同厂商和学术团队会有不同的答案。争论定义本身，不是目的。●OASIS〔一个SOA标准组织〕给出的SOA定义“SOA是一个范式，用于组织和利用可能处于不同所有权范围控制下的分布式系统。”●维基百科给出的SOA定义“面向效劳的体系结构〔Service-orientedarchitecture〕是构造分布式系统的应用程序的方法。它将应用程序功能作为效劳发送给最终用户或者其他效劳。它采用开放标准、与软件资源进行交互并采用表示的标准方式。”。这些定义本身，一般人员要准确理解是非常困难的，既便是专业人士，未必能够深刻理解其内涵。如何更加形象理解SOA？怎么通俗化解析SOA的核心含义？事实上，SOA的思想我国很早就有了，印刷术的开展过程其思想就完整表达了SOA的核心含义。印刷的内容-文字，在秦始皇统一六国之前，各国的文字是不统一的，据说许多常用的文字有十几种写法和读音，阻碍了各国之间的文化交流，就象SOA之前，各种软件平台、各种开发工具和各种接口的组件之间，没有统一的标准，对软件系统之间的整合造成巨大的困难。因此，伟大的始皇帝统一了六国文字，“书同文、车同轨”就是通过标准解决“复用”和“互操作”等问题。这也为大规模的印刷和文明开展提供了一个良好的根底，这种“统一封装”的文字，对文化交流起到了一个“互操作”的标准作用。在没有印刷术之前，书籍要依赖于手工抄写，这样效率当然是非常低下，而且质量也不能获得一致性的保证，也就是书籍还无法“复用”。中国人首先创造了刻版印刷术，就是将书籍刻成一块一块的凸字版，然后就可以大规模进行印刷了，当印刷出来的书籍脱销时，下次还可以继续使用，大大提高了效率，这就是“复用”，软件通过组件的封装，也可以到达重复和在不同场合屡次使用的“复用”效果。刻版印刷术有个很大的问题就是文字之间是紧耦合的，同样一个字，在另一部书之中是不能“复用”的，必须重新雕刻，也就是说刻版印刷是没有“编排”特性的。就如软件技术中微软VB开发的Com+组件就只能在Windows环境之中使用，它不能与Java开发的EJB组件进行复用和编排，因为他们与开发环境和运行环境是紧耦合的，要在UNIX环境下使用，必须重新开发〔相当于重新“刻版”〕。活字印刷就是通过文字与版面之间的松耦合，通过“排版”来实现一部书的印刷版面的，这种松耦合就大大提高了文字的字模之间的复用和编排效率。我们标准封装的“效劳”就类似一个一个的字模，通过效劳编排〔“排版”〕来实现业务流程。统一文字和活字印刷促进了人类文明进步，而SOA促进全球IT架构和应用的革命。要准确全面理解SOA，首先必须理解SOA的核心要素：SOA的目标就是通过重用现有的软件应用、以组装的方式实现灵活可变的IT系统。因此，重用、标准化封装和松耦合可编排是SOA技术本质特征。其中，标准化的封装实现各个软件应用之间的松散耦合最为关键的因素。§2SOA实现技术的本质特征2.1.1松耦合的依赖关系过去分布式技术没能解决软件应用对语言、平台和厂商的依赖性，不同技术开发的应用之间不能交互。SOA当前主流实现技术即Web效劳解决了不同应用之间的互联互通。效劳是通过效劳描述消除了应用对语言、平台和厂商的依赖，如图2-1所示，效劳消费者完全依赖效劳描述。效劳描述是效劳消费者和效劳之间的“合同”，效劳描述包括效劳消费者为实现和效劳交互需要的所有信息，如接口定义、效劳使用策略、效劳级别约定等。效劳描述按照开放标准以文本方式声明，具有实现无关性。因此效劳描述屏蔽了效劳的实现细节，剥离了传统构件所具有的与语言、平台和厂商的相关性。效劳效劳描述效劳效劳描述效劳消费者-消除组件语言的依赖，CORBA、DCOM分别采用IDL、ODL接口描述语言描述构件。每种实现技术只能实现同类产品之间的交互，不能实现不同类产品的交互。除了消除了上述关键性的依赖因素外，SOA还借助其他策略消除了更多的依赖因素，具体包括时间、访问地址和访问协议等。-消除时间依赖对基于远程过程调用的分布式系统，客户端需要同步等待请求的返回，在SOA中，我们可以集合事情驱动的原理通过单向消息实现客户端和效劳的异步交互，从而消除时间依赖。-消除访问地址依赖SOA通过间接寻址策略消除访问地址依赖，间接寻址有两种方式：一种是将访问地址放到效劳注册中心，消费者通过查询注册中心发现访问地址实现间接寻址；另一种是通过单独的配置文件规定效劳访问地址，这样当效劳地址改变的时候，只需要改变配置文件即可。-消除访问协议的依赖，如JAVA使用RMI，CORBA使用IIOP等。效劳描述包括消息传输协议如SOAP和网络传输协议如的定义，而SOA通过标准的、支持Internet、与操作系统无关的SOAP协议实现了连接互操作。2.1.2效劳资源的间接寻址间接寻址是SOA松耦合的重要表达之一，通过间接寻址可以消除效劳的访问地址依赖。图是被广泛引用的效劳交互模型，效劳注册中心是SOA间接寻址的表达。效劳效劳注册中心效劳提供者效劳请求者发现发布交互效劳交互模型包含三类角色：效劳提供者、效劳消费者和效劳注册中心。效劳交互必须发生的三种行为：发布、发现和绑定或调用。交互作用的对象是效劳和效劳描述。效劳提供者是一个接受并执行效劳请求的通过网络可访问的实体，效劳提供者将接口约定发布到效劳注册中心，以便效劳请求者发现并访问。效劳请求者是一个应用、一个软件模块或发出效劳请求的另一个效劳。效劳请求者可以通过效劳注册中心间接获得效劳描述，或者从效劳提供者处直接获得描述，然后遵从效劳描述的接口约定实现和效劳提供者所提供效劳的交互。效劳注册中心是用于发现和定位效劳的中介，包括一组供效劳请求者查询的效劳描述。效劳注册中心的作用是剥离了效劳提供者和效劳请求者之间的直接地址依赖，使效劳的地址在发生变更的时候不会影响效劳请求者。另外，效劳注册中心可以使效劳消费者实现一种更加灵活的效劳定位：在运行的时候通过约束条件在多个效劳中选择条件最匹配的效劳。一些面向效劳的应用在构造时候仅仅想利用SOA的语言/平台无关的松散耦合特点，而不需要SOA的间接寻址能力。我们将这种体系结构称为SBA，即基于效劳的体系架构。§3SOA的作用正如前边讨论过的，企业业务正在处理两个根本问题：快速变化的能力和降低本钱的需要。为了保持竞争优势，企业必须快速适应内部因素如兼并和重组和外部因素如竞争压力和顾客需求。业务需要经济的、灵活的IT根底设施其业务需要。SOA具有如下优点，有助于组织在今天的动态业务环境下获得优势。〔1〕利用已有资源使企业通过将现有的资源封装为效劳来保护IT的投资，这样企业可以持续地利用这些资源，而无需重新开发。从而表达“构造”而不是重新开发的先进设计理念。〔2〕更容易集成和控制复杂性SOA集成的观点是效劳标准，而不是实现。提供了实现透明，当根底设施和实现发生变化的时候，可以将影响降到最低。通过为别离系统中的资源提供效劳标准，集成变得可管理。〔3〕更加敏捷、快速地适应市场变化SOA利用现有资源构造新的效劳的机制，可以灵活地反响业务需求。利用现有的资源构造效劳可以减少软件开发周期，这样可以尽快地开发出新的业务，使企业更快地适应市场变化。〔4〕降低本钱，增减重用由于核心业务效劳是松散耦合，这样可以根据业务需求更加方便地使用和组合。这意味著尽量防止资源的重复开发、最大程度地利用现有资源、从而降低开发本钱。〔5〕提前开发，以备之需业务功能可以预先开发，以备未来之需。由于业务流程是由一系列业务效劳组成的，这样可以更加容易地创立、调整和管理业务流程，可以更快地抢占市场先机。SOA提供的这种灵活和敏捷是企业生存和开展的关键。构成效劳5构成效劳5效劳1效劳4效劳3效劳2效劳1效劳4效劳3效劳2效劳层效劳层应用层应用层应用3(Legacy)应用2应用3(Legacy)应用2〔.NET〕应用1〔J2EE〕§4SOA参考模型SOA的核心主体是效劳。所谓“效劳〔Service〕”，从业务角度而言，效劳是一个可重复的经过标准封装的任务，例如:检查帐号余额;开新帐户等等…。SOA的目标是通过效劳的流程化来实现业务的灵活性，所谓流程〔Process〕是由一系列相互关联的任务所组成，实现一个具体的业务功能。一个流程可以由一系列效劳来实现。效劳就像一堆“元器件”，这些元器件通过封装形成标准效劳，他们有相同的接口和语义表达规那么。但效劳要组装成一个流程和应用，还需要有效的“管理”，包括如何注册效劳、如何发现效劳、如何包装效劳的平安性和可靠性，这些就是SOA治理。SOA治理乃是将SOA这一堆元器件，进行有效组装，形成一个“产品”的关键，否那么它永远是一堆器件，而无法形成一个有机整体。SOA治理的方法和体系，就是区别于一般组件开发的技术的重要区别和特征。一个正确的框架，是指导我们开发和实施SOA架构的根底。由IBM提案，国际开放群组(TheOpenGroup)提出了一个SOA架构的参考模型，这个架构框架目前是产业界最权威和严谨的SOA架构标准。TheOpenGroup是一个非营利标准化组织，是一个厂商中立和技术中立的机构，致力于提出各种技术框架和理论结构，致力于促进全球市场的业务效率。TheOpenGroup已有超过20年的标准制定与推广历史。在1996年，由X/Open与OpenSoftwareFoundation合并组成。TheOpenGroup最有名是作为UNIX商标的认证机构。在过去，协会最知名的是其出版的SingleUNIXSpecification，它扩充了POSIX标准而且是UNIX的官方定义，其成员包括IT用户、供给商以及政府机构。TheOpenGroup在中国的创始会员为金蝶集团，金蝶集团负责成立了中国分会。TOG在1993年提出的TheOpenGroupArchitectureFramework(TOGAF)架构框架，是一套行之有效的企业架构。历经15年9个版本开展，支持开放、标准的SOA参考架构，已被80％的福布斯(Forbes)全球排名前50的公司使用。这个SOA参考模型为：根据这个模型，完整的SOA架构由五大局部组成，分别是：根底设施效劳、企业效劳总线、关键效劳组件、开发工具、管理工具等。SOA根底实施是为整个SOA组件和框架提供一个可靠的运行环境，以及效劳组件容器，它的核心组件是应用效劳器等根底软件支撑设施，提供运行期完整、可靠的软件支撑。企业效劳总线〔ESB〕是指由中间件根底设施产品技术实现的、通过事件驱动和基于XML消息引擎，为SOA提供的软件架构的构造物。企业效劳总线ESB提供可靠消息传输、效劳接入、协议转换、数据格式转换、基于内容的路由等功能，屏蔽了效劳的物理位置，协议和数据格式。在SOA根底实现的方案上，应用的业务功能能够被发布、封装和提升〔Promote〕成为业务效劳〔BusinessService〕；业务效劳的序列可以编排成为BPM的流程，而流程也可以被发布和提升为复合效劳〔CompositedService〕，业务效劳还可以被外部的SOA系统再次编排和组合。ESB是实现SOA治理的重要支撑平台，是SOA解决方案的核心，从某种意义上说，如果没有ESB，就不能算作严格意义上的SOA。关键效劳实现，是SOA在各种业务效劳组件的分类。一般来说，一个企业级的SOA架构通常包括：交互效劳、流程效劳、信息效劳、伙伴效劳、企业应用效劳和接入效劳。这些效劳可能是一些效劳组件，也可能是企业应用系统〔如ERP〕所暴露的效劳接口等等。这些效劳都可以接入ESB，进行集中统一管理。开发工具和管理工具：提供完善的、可视化的效劳开发和流程编排工具，涵盖效劳的设计、开发、配置、部署、监控、重构等完整的SOA工程开发生命周期。按照这个模型，许多SOA解决方案是只提供局部实现。这个行业中，许多国内的企业为了搭上SOA的便车，经常以偏概全，混绕概念。应该说真正按照SOA的思想和模型来构建整个企业的IT架构的案例是非常之少的。许多国外厂商的宣传案例，根本上是停留在部署应用效劳器，开发了局部WebService组件，可以实现局部数据集成，这个层次而已，而这些WebService是部署在ESB平台之上的，就已经很不错了。实现了效劳流程重组，实现SOA治理的案例就更是很少见到了。国内有许多软件企业开发的系统，宣传是SOA架构的。根本上有几种情况，其一，有些开发组件和开发平台厂商，他们也自称中间件企业，根本上是提供一个工作流平台，许多还不支持BPEL的业务流程管理，只是传统的XPDL/WfMC工作流平台〔Workflow不同于支持效劳流程的BusinessProcess〕，最常见的案例是OA办公审批，或者效劳组件开发工具，而所谓的ESB产品大局部都是EAI的升级，可以与Webservice进行接口而已，就宣称这是ESB产品了，根本的效劳注册、效劳编排和平安管理都不具备。这些解决方案只是提供了许多WebService开发的组件，而不提供SOA治理的核心架构，相当于造了许多元器件，但还不能提供整机产品。其二，许多宣称SOA架构的应用软件，根本上可以说是“支持”SOA，而不能称为“基于SOA”架构。因为支持SOA一般是指可以将其某些功能，封装为效劳〔WebService〕，可以在SOA架构之中进行管理，这比较容易到达。而“基于SOA”是指应用系统的业务功能都是封装为效劳，通过ESB进行集中管理，业务实现是通过BPEL业务流程管理进行编排，用户交互是通过交互效劳〔如门户〕进行管理，整个解决方案可以到达标准效劳封装、效劳复用、松耦合、效劳编排与重组，并且根本符合TOG-SOA的架构模型。

按照这个标准，IT用户就可以了解到真正的SOA架构的框架模型，就可以识别是否是企业所需要的架构。讲到这里，我们已经很清楚了，对于SOA的理解，有些学者或者咨询公司强调SOA不是一种技术，也不是软件，而是一种思想，一种架构风格。我认为这也是不完全准确的，这种观点认为SOA仅仅是思想和方法，将使得SOA成为一种不可知论，飘在空中，很难落地。§5基于SOA的应用系统基于SOA的应用系统构建方法与传统软件架构方法有所不同。首先基于SOA的应用系统建模和管理的组件层次是效劳：基于效劳的应用系统的本质特征是松耦合，以根本业务功能〔效劳封装〕为系统的根本实现单元，然后通过效劳编排〔流程管理〕来“组装”业务应用系统。相对于以往的应用系统，是面向技术组件，由系统程序实现业务流程，在复用、耦合方面都存在灵活性问题。

效劳建模是第一步，也就是效劳识别和颗粒度确定。效劳识别是方法论的第一步，效劳识别的主要任务，是确定在一定范围内〔通常是企业范围，或假设干业务场景范围内〕可能成为效劳的候选者列表，并确定效劳的颗粒度，以及标识效劳的接口。效劳建模也就确定了应用系统架构的耦合程度。

效劳封装阶段的主要任务是对效劳进行标准性的描述，其中包括输入/输出消息等功能性属性，以及效劳在业务层面的诸多属性。并决定效劳以何种形式向外提供效劳。效劳可能是新开发的业务功能和业务对象的封装，也可能是遗留系统的效劳封装，将遗留系统的软件资产以效劳的形式进行封装，在新的架构上利用已有的资产。

效劳治理就是将已经封装好的效劳进行集中统一有效的管理。通过ESB根底设施，提供效劳注册、存储、平安控制和版本管理等。效劳注册阶段的主要任务是将效劳注册到效劳库。此时需要决定效劳的命名、平安、性能、时间特性。

效劳编排就是根据业务流程的需求，对效劳进行组合和组装。效劳组装是以实现业务流程为目的，通过对业务效劳的组合和组装，实现更粗粒度的业务效劳，实现最终的业务需求。

应用交付阶段主要任务是完成业务系统效劳化组装和效劳部署，实现业务按需交付。基于SOA的应用系统是SOA架构的重要组成局部，也是SOA落地的地基。〔摘自金蝶中间件总经理奉继承博士原文：://blog.vsharing/fengjicheng/A1059842.html〕第三章SOA主流实现技术〔Web效劳〕简单地说，Web

效劳是部署在Web上的软件构件。Web效劳互操作性拓展了Web的能力，使其从原来的单纯面向人类的信息和功能提供平台开展成为分布式计算平台。如图1.1所示，人通过浏览器软件与Web应用交互，此时浏览器与Web应用是通过HTML语言互相传递消息；Web

效劳提供了一种可以在Web上共享的功能，应用通过标准Web和Internet协议可以直接使用Web效劳提供的功能，此时两者之间是通过XML/SOAP语言互相对话的。其中，XML是一种与平台/编程语言无关、具有可扩展类型系统的数据表示语言，适合在各种平台/编程语言的应用之间交换信息；SOAP那么提供了一种应用之间互相传递基于XML数据的消息通信协议。2.1Web效劳的定义效劳是面向效劳架构中核心概念，不理解效劳的概念，那么无法理解面向效劳的架构。目前不同组织对效劳尚无统一的定义。Ø国际标准化组织W3C：Web效劳是一个通过URL识别的软件应用程序，其界面及绑定能用XML文档来定义、描述和发现，使用基于Internet协议上的消息传递方式与其他应用程序进行直接交互。ØMicrosoft：Web效劳是为其它应用提供数据和效劳的应用逻辑单元，应用程序通过标准的Web协议和数据格式获得Web效劳，如、XML和SOAP等，每个Web效劳的实现是完全独立的。Web效劳具有基于组件的开发和Web开发两者的优点，是Microsoft的.Net程序设计模式的核心。ØIBM认为，Web效劳是一种自包含、自解释、模块化的应用程序，能够被发布、定位、并且从Web上的任何位置进行调用。Web效劳可以执行从简单的请求到错综复杂的商业处理过程的任何功能。理论上来讲，一旦对Web效劳进行了部署，其它Web效劳应用程序就可以发现并调用已部署的效劳。Ø市场研究公司Forrester以一种更加开放的方法将Web效劳定义为人、系统和应用之间的自动连接，这种连接能够实现将业务功能元素转变为软件效劳，并且创造新的业务价值。Web效劳是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术标准，这些标准使得Web效劳能与其他兼容的组件进行互操作。ØGartner将Web效劳定义为：松散耦合的软件组件，这些组件动态地通过标准的网络技术与另一个组件进行交互。Web效劳可以从多个角度来描述〔理解〕。从技术方面讲，一个Web效劳是可以被URI识别的应用软件，其接口和绑定由XML描述和发现，并可与其他基于XML消息的应用程序交互；从功能角度讲，Web效劳是一种新型的Web应用程序，具有自包含、自描述以及模块化的特点，可以通过Web发布、查找和调用实现网络调用。从应用的层面来说，Web效劳是用于集成应用的，将原有的面向对象、面向组件的软件系统改造为基于消息面向效劳的松散耦合系统或者构建新的松散耦合系统的一种协作设施。从组成框架及实现目标的角度讲，Web效劳作为一种网络操作，能够利用标准的Web协议及接口进行应用间的交互。从网格计算(gridcomputing)的角度看，Web效劳能用于Web上的资源发现、数据管理及网格计算平台上异构系统的协同设计，提出了网格效劳的新概念。§2.2Web效劳根底标准1999年，W3C和相关的企业开始讨论设计基于XML的通信协议，2000年，W3C发布SOAP〔Simple

Object

Access

Protocol〕协议的1.1版。人们把利用SOAP协议传递XML信息的分布式应用模型称为Web

效劳。2001年，W3C发布了WSDL〔Web

Services

DescriptionLanguage〕协议的1.1版。SOAP协议和WSDL协议共同构成了Web

Service的根底如下图。随后，J2EE和.NET这两大企业级开发平台先后实现了Web

Service，并将其视为平台的一项核心功能。

〔点击查看大图〕图9-2图2.Web效劳根底协议栈Web效劳平台需要一套协议来实现分布式应用程序的创立。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web效劳平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面(interface)的平台提供了一些方法来描述界面、方法和参数〔译注：如COM和COBAR中的IDL语言〕。同样的，Web效劳平台也必须提供一种标准来描述Web效劳，让客户可以得到足够的信息来调用这个Web效劳。最后，我们还必须有一种方法来对这个Web效劳进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了到达互操作性，这种RPC协议还必须与平台和编程语言无关。下面几个小节就简要介绍了组成Webservice平台的这三个技术。传输协议传输层是用来将效劳请求从效劳请求者传输给效劳提供者，或者将效劳响应从效劳提供者传输给效劳响应者的机制。目前有多种Web效劳传输标准如、SMTP和FTP，其中最流行的是标准是。Web效劳XML和XSD可扩展的标记语言(XML)是Web效劳平台中表示数据的根本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，还是64位？这些细节对实现互操作性都是很重要的。W3C制定的XMLSchema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web效劳平台就是用XSD来作为其数据类型系统的。当采用某种语言(如C#)来构造一个Web效劳时，为了符合Web效劳标准，所使用的所有数据类型都必须被转换为XSD类型。Web效劳SOAPWeb效劳建好以后，就需要去调用它。简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web效劳。实际上，SOAP在这里有点用词不当：它意味着下面的Web效劳是以对象的方式表示的，但事实并不一定如此，Web效劳写成被一系列的C函数，并仍然使用SOAP进行调用。SOAP标准定义了SOAP消息的格式，以及怎样通过协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。如果将传输层看成是两个端点之间的通路，那么效劳通信协议那么是通路上行驶的机动车。效劳通信协议描述和定义用来提供交互的效劳之间的传输机制的技术和标准。Web效劳WSDL你会怎样向别人介绍你的Web效劳有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web效劳的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web效劳的时候，他们的工具(如VisualStudio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web效劳。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web效劳描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web效劳及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的Web效劳生成WSDL文档，又能导入WSDL文档，生成调用相应Web效劳的代码。WEB效劳的描述与参考资料Web效劳是一种新的重要的应用程序。Web效劳是一段可以用XML发现、描述和访问的代码。在这一领域有许多活动，但有三种主要的用于Web效劳的XML标准：SOAP：最初是简单对象访问协议〔SimpleObjectAccessProtocol〕，SOAP定义一个XML文档格式，该格式描述如何调用一段远程代码的方法。我的应用程序创立一个描述我希望调用的方法的XML文档，并传递给它所有必需的参数，然后应用程序通过网络将该XML文档发送给那段代码。代码接收XML文档、解释它、调用我请求的方法，然后发回一个描述结果的XML文档。SOAP标准版本1.1位于/TR/SOAP/。请访问/TR/以了解W3C中SOAP相关的所有活动。WSDL：Web效劳描述语言〔WebServicesDescriptionLanguage〕是一个描述Web效劳的XML词汇表。编写一段接收WSDL文档然后调用其以前从未用过的Web效劳的代码，这是可能的。WSDL文件中的信息定义Web效劳的名称、它的方法的名称、这些方法的参数和其它详细信息。您可以在/TR/wsdl〔结尾没有斜杠符号〕找到最新的WSDL标准。UDDI：统一描述、发现和集成〔UniversalDescription,Discovery,andIntegration〕协议向Web效劳注册中心定义SOAP接口。如果您有一段代码希望作为Web效劳部署，UDDI标准定义如何将您的效劳描述添加至注册中心。如果您在寻找一段提供某种功能的代码，UDDI标准定义如何查询注册中心以找到您想要的信息。有关UDDI的所有资料来源都可以在找到。Web效劳的优点：适应性：可以使用任何编程语言、计算平台和软件体系结构开发Web效劳。应用性：Web效劳允许作为组件开发的软件被其他软件部件或被可以被输入到Web浏览器的URI重用。互操作性：到现在为止Web效劳最大的好处是它们支持不同计算平台之间的通信。平台之间的通信不再要求它们必须具有相同的硬件和软件组件。Web效劳支持使用Java、C++、.NET、JavaScript、Perl和其他编程语言开发的多种平台之间的交互操作性。因为Web效劳建于Web标准(比方XML)之上，所以业务组件之间的通信基于行业标准而非专门的协议。为啥要创立WEB效劳1.Webservice平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Webservice，只要我们可以通过Webservice标准对这些效劳进行查询和访问2..任何运行Web浏览器的机器都在使用协议。同时，当前许多防火墙也配置为只允许连接-SOA标准体系是实现SOA应用系统所涉及的国际标准、业界主流技术标准、行业标准的有机整体，涵盖业务分析、建模、设计、开发、组装、部署、测试、管理〔治理〕等各个环节。SOA标准体系基于中国的行业应用需求及标准化现状，以现有国际标准组织〔W3C、OASIS、WS-I、OMG、IETF等〕所发布的相关技术标准为核心，从根底、架构、应用三个层次提供了支撑SOA系统实现的参考标准集，为基于SOA的测试、评估及质量保证提供依据。SOA标准体系图如下：

下面依据SOA标准体系图，介绍SOA标准体系的组成局部以及各局部之间的关系。

1、根底层：

(1)XML及相关标准

XML及其相关标准是SOA的基石。其规定了效劳之间以及效劳内部数据交换的格式和结构、保障消息数据的完整性和有效性、提供不同数据表达之间互相通信的格式，同时提供在XML文档和信息内嵌的加密数据和数字签名格式、为所有Web效劳平安技术建立的提供根底。

(2)网络传输标准

数据传输是SOA系统最根本的需求之一。SOA系统是分布式系统，需要传输大量数据，数据传输就是其生命线。网络传输标准解决了如何连接，如何验证，如何发送、接收数据以及如何报告错误等问题。

2、架构层：

(1)消息传递标准

基于SOA构建的系统，系统内部各组成局部间需要不断的相互交换消息，以到达协调完成业务任务的目标。消息传递标准提供了在分布式环境中交换信息的框架，定义了消息格式、消息交换模式，保证SOA系统能可靠、及时的传递消息。

(2)效劳描述和发现标准

对松散耦合的SOA系统来讲，效劳标准化的描述、发布和发现是至关重要的。描述和发现标准和标准定义一组效劳，用于支持Web效劳提供者、Web效劳消费者以及可以用于访问这些效劳的技术接口的描述和发现。

(3)可靠性标准

可靠性是指稳定、鲁棒等效劳质量因素，可靠消息传递允许在出现软件组件、系统或网络故障时可靠的在分布式应用程序间交付消息。可靠性是使用Web效劳的必要条件。

(4)事务性标准

SOA系统是分布式系统，在分布式计算领域，事务是构造可靠分布式应用程序的关键。Web效劳事务性标准利用传统事务机制提供的协调行为来控制应用程序的操作和输出。

(5)平安性标准

平安性是SOA系统的重要方面，是大多数用户优先考虑的问题。使用Web效劳技术构建SOA系统，需要保护Web效劳，确保只被那些准许的逻辑访问。为了保持Web效劳的开放性并支持多种类型的客户端，就必须解决Web效劳的平安性问题。Web效劳平安性标准为Web效劳框架提供平安通信的方法。

(6)互操作标准

SOA和Web效劳技术的标准众多，不同的标准可能来自不同的标准化组织，存在着不能完全互联互通的问题，如何用这些标准来开发可互操作的Web效劳，是一个亟待解决的问题。因此，SOA需要互操作标准来确保SOA系统的互操作性。

(7)表示层标准

标准Web效劳或面向数据的Web效劳包括业务逻辑，但缺少表示逻辑。相同的业务流程和业务数据在不同平台不同终端上往往要求以不同的表现形式展现给用户。表示层标准将下层的内容以多样化的形态提供给上层的终端用户。

(8)业务流程标准

构建基于SOA的系统以业务为中心，业务逻辑的实现及优化通过效劳组合、效劳编排来完成。业务效劳通常跨多个组织和机构，需要将效劳进行有效的组织才能满足业务逻辑的需求。业务流程方面的标准由此而催生。

(9)集成开发标准

SOA产品及系统的具体实现需要开发标准作为指导，包括根底效劳的实现、效劳组装的实现等。同时SOA工程往往需要整合各种已有资源，作为一项系统性的工作，集成过程需要全局的标准化的效劳组件以及协议接口作为支撑。

(10)效劳管理标准

管理效劳用于发现它们存在的问题、了解效劳的状况、性能，并对效劳进行控制和配置。用效劳构建SOA系统时，业务操作全部都是由效劳来完成，效劳管理标准提供对效劳合理有效管理的方法，满足业务操作需要。

(11)质量保证标准

效劳质量及水平是判定一个SOA系统是否成功的重要因素。SOA系统的质量重点是贯穿于效劳生命周期的质量维护，包括可用性、稳定性、可维护性等多方面因素。SOA系统需要质量保证标准来确保系统的效劳质量。

3、应用层—应用标准

SOA工程最终效劳于具体的行业或领域用户，如电子政务、电子商务、企业信息化、社区信息化等等。不同用户有各自不同的特点，SOA工程的规划及设计必须首先遵从行业标准、企业的业务战略及规那么，实施中效劳设计及实现需要相关的应用标准来指导，SOA的治理也需要和企业IT策略一致。

4、组成局部关系分析

XML及相关标准是支撑SOA技术及标准开展的重要根底，在SOA热潮之前已在传统的万维网及Web技术中得到了广泛应用。XML作为目前数据交换的唯一公共语言，是架构层所有SOA标准的根底，提供了不同平台及应用软件通过网络可进行交互的数据内容和结构描述格式。相关的XMLSchema、XSLT、XMLSignature、XMLEncryption为SOA架构层中的关键消息传递、Web效劳平安等标准提供了直接构建和引用根底。根底层中以为代表的网络传输标准，广泛应用于传统Web应用，是SOA消息传递标准的根底。架构层的SOA技术标准以WS-*核心。消息传递标准构筑在传输标准之上，它以传输标准作为载体进行工作，消息传递标准之上是效劳描述和发现相关标准，标准体系的这三个局部搭建起了SOA的根本框架；可靠、平安、事务三个局部标准需要与效劳描述、发现相关标准结合起来工作，它们一定程度上是对根本的效劳描写、发现标准的补充，用以满足SOA实际应用的要求。

标准出自不同的标准组织，同一标准不同的厂商实现也可能不是完全一样，互操作标准将SOA标准中的二义性进行重新定义，在语义上确保交互的一致性，以实现不同实现平台的互操作。互操作性标准可以看作SOA标准体系的根底组成局部，利用它们即可以支撑构建出较完善的SOA系统。架构层业务流程标准建立起业务与效劳的桥梁，开发标准指导SOA系统的实施，它需要SOA标准体系中其它各类标准的支持。集成标准标准化基于不同技术构筑的系统的协作，管理标准方便SOA系统资源和效劳的管理，这几个标准都以构筑在标准体系根底组成局部之上的效劳为对象，因此它们需要根底组成局部标准对它们的支持。架构层质量保证标准是SOA构建后重要评估手段，需要从不同等级〔单个效劳、局部集成、整个系统〕来确保效劳质量，其内容涉及到架构层其他各类标准SOA系统。应用层标准是针对各行业制定的指南性标准，基于应用行业及企业的具体要求及规那么、对应各类SOA相关标准的具体应用。三Web效劳介绍Web效劳包含3种类型的角色：效劳请求者、效劳提供程序和效劳发现代理。请求者(requestor)--客户端--是需要数据或已执行效劳的商业软件，所以它发出执行某个Web效劳的请求。效劳提供程序(serviceprovider)响应Web效劳请求。请求者使用提供者提供的效劳。发现代理(discoveryagency)用作所有已发布的Web效劳的存储库。这种代理可能支持向其发送描述，或者可能轮询公共提供者以获得描述。计算平台可以承当这些角色中的一个或多个，例如同时作为请求者和提供程序，或者同时作为请求者、提供程序和效劳发现代理。一个或多个Web效劳可以被结合起来以执行一个完整的业务事务。图9-1说明了分别承当一个角色的计算平台之间的交互。

〔点击查看大图〕图9-1在执行这些角色的平台间可以发生3种类型的操作：获取、发布和绑定。效劳提供程序实现软件组件，把描述直接发布给请求者或效劳发现代理。效劳请求者尝试从本地或效劳发现代理定位/找到/获取效劳描述(这种获取操作可以在软件开发期间或请求者软件的执行期间发生)。平台间的通信以XML(eXtensibleMarkupLanguage，可扩展标记语言)形式的消息进行。这些消息的方向可以是单向、双向、播送或大量的消息。可以同步或异步发送消息。9.3

Web效劳体系结构Web效劳运行在一个通信根底设施之上，这个通信根底设施由由几层广泛使用的公共可用协议组成。Web效劳协议栈不存在标准定义，所以对这些协议的体系结构说明根据供给商或标准组织的不同而不同。尽管如此，图9-2给出了一个根底的协议栈图。UDDI、WSDL和SOAP都是得到批准的协议。

〔点击查看大图〕图9-29.3.1

网络层在商业组织内可能存在许多运行不同协议(如IBMMQSeries或CORBA)的私有内部网。与此相反，Web效劳使用行业内普遍接受的Web网络协议进行通信。因此，Web效劳可以用作各种专用内部网之间进行通信的媒介。虽然IT部门取缔和阻止了许多其他的网络协议(比方telnet、ftp等)，并把它们看做潜在的平安漏洞，但是却被用来支持Web浏览器的连续操作。这保证了以为根底的应用程序协议的较长生命期。在Web效劳中，Web效劳的消息通过这个网络层传递。9.3.2

XMLXML是一种格式，通过它文本可以以独立于平台的方式代表数据。处理XML的工具有很多。XML数据的格式和内容在XML模式中描述。XML模式使用XML语法描述XML文档中的元素、属性和实体之间的关系。XML模式的用途是定义一类必须符合特定的结构规那么和数据约束的集合的XML文档。这种XML数据要想有用，必须把XML传输给业务应用程序使用的编程语言所支持的应用程序数据结构。用于转换XML和数据结构的机制的技术术语称为数据绑定。对于根底数据类型(比方Java根本数据类型)已经存在执行这种转换的软件。然而，对于较为复杂的数据结构而言，可能需要开发自定义的代码。9.3.3

SOAPSOAP现在是XML消息的行业标准，这是一个围绕通过网络层传递的XML应用程序有效负载的瘦层(thinlayer)。SOAP独立于网络层的类型，它可以与许多协议一起使用，比方、JMS或FTP。交换SOAP最常用的方法是通过。通过它的消息头可以对它进行扩展，而业务应用程序可以对它的消息头进行填充或处理。SOAP消息提供了如下内容。通过Web对数据和效劳的访问通过Web在客户端和效劳之间传输数据对象的能力正是通过这两种能力业务才能与其他的业务或客户通信。SOAP消息可能包含3种不同类型的元素，而且它必须是结构良好的XML文档。这3种不同类型的元素分别如下。信封(必要)：这是SOAP消息的容器，所以它可以包含消息主体和任何消息头。它包含一个用于唯一身份标识的名称空间声明。消息头(可选)：这个可选元素用作容器，包含可用于扩展SOAP消息以支持身份验证或路由能力的额外信息。事实上，整个的WS-*功能集都使用消息头来实现扩展。消息主体(必要)：消息主体包含XML格式的有效负载，还可能包含SOAPRPC请求或以文档为中心的消息。在较早的RPC风格的Web效劳(称为rpc/end)中，效劳请求者使用必要的参数发送调用方法的名称，任何计算结果都将被返回。虽然这种风格有助于更简单地开发软件，但是它会带来互操作性上的问题，尤其在发送和接收复杂数据结构时更是这样。使用这种风格时，其内容的特殊性质使通信系统具有紧密地耦合性。这种风格代表了通信的一种同步形式。由于互操作性的问题，现在Web效劳互操作性组织的根本配置文件(WebServicesInteroperabilityOrganization'sbasicprofile，WS-IBP)不推荐这种风格。与之相反，得到推荐的是XML以文档为中心的风格--doc/lit风格。这是一种面向文档的风格，在其中效劳请求者发送完整的XML文档。效劳提供者可以也可以不返回消息。这种风格使用W3CXML模式定义来指定XML数据格式。9.3.4

WSDLWSDL就是对Web效劳软件的描述。具体来说，它描述所有公共可用的方法、交换方法、消息类型以及用在网络层的传输协议和Web效劳的地址。客户端应用程序可以为使用的特定传输协议找到Web效劳，以及调用任何公共方法。根本上，WSDL可以看作是效劳提供者和效劳请求者之间的契约。WSDL是XML格式的，所以它也具有平台无关性。WSDL和Java类似，因为它支持抽象和具体概念、以及接口。类似于Java，WSDL也支持抽象的接口。在WSDL下是一个效劳，这个效劳被描述为一个接受消息的终端的集合。再往下是一些根底的WSDL术语，图9-3显示了这些概念之间的关系。消息：消息由类型化的数据局部组成操作：效劳请求者和效劳提供者之间的一组消息portType：操作集合端口：portType的实现serviceType：portType的集合效劳：端口集合，这是serviceType的实现1.WSDL文档WSDL1.2文档由4个信息的根本元素组成，它们被称为Infoset，描述Web效劳。Infoset就是WSDL文档中使用的XML元素和属性。另外，WSDL支持一个组件模型，这个组件模型镜像Infoset并提供另一个抽象层。下面的列表定义了WSDL2中XMLInfoset的元素。

〔点击查看大图〕图9-3描述：这是第一个元素，它用作其他WSDL元素的容器。接口：这个元素定义了效劳具有的抽象行为。接口有名称，可以扩展其他的接口。接口可以包含操作以及错误。绑定：这个元素定义了访问效劳的方式。绑定有名称，是一个具体元素，它指定了消息的内容以及每个接口的传输协议。接口中存在的所有操作和错误都在这个元素中定义。效劳：这个元素定义了访问效劳的地方，它包含效劳的名称和一个或多个终端。终端：这是引出消息的目的地。2.WSDL绑定WSDL1.2是可以扩展的。通过使用一个称为扩展(extension)--或者具体来说是绑定扩展(bindingextension)--的机制，可以添加新的消息格式以及传输协议。扩展在WSDL的顶部为每个绑定扩展提供一个名称空间声明前缀。之后在WSDL中绑定扩展的前缀就可以用于元素和属性了。WSDL1.2包含支持SOAP1.2和SOAP1.1的绑定扩展。这些扩展允许定制SOAP消息，比方使用的版本、绑定、协议和SOAP消息头。扩展有一个默认值的集合，可以用在接口或操作级上。当使用作为传输协议时，绑定应该指出是否使用GET或POST。WSDL2.0也支持绑定扩展，以便在使用时不使用SOAP。9.3.5

UDDIUDDI是一个标准，它定义了与Web效劳相关的信息的发布、发现和管理。UDDI以2000年的1.0版本开始，现在UDDI的标准已经是3.0版本，它向后兼容以前的版本。该标准中存在3种类型的组件。第一种类型(节点)是UDDI效劳器，它确切地属于一个UDDI注册库。节点在UDDI数据上执行操作。对于API，标准区分了两种不同类型的节点：UDDI效劳器和UDDI客户端。组件的第二种类型，注册库，包含一个或多个节点。节点有3种类型：公有、附属和私有。公有注册库中的数据可以在其他注册库中共享。私有注册库中的数据不可以共享，并且也不允许对注册库和管理功能的访问。第三种组件，附属注册库，由通过使用策略在彼此间共享信息的注册库组成。UDDI3.0中的注册库可以被配置为分层次结构的、基于对等实体的、或受委托的配置。受管理的客户端对这些注册库有有限的访问权。标准有一个信息模型，它包括以下内容。业务实体：关于效劳发布者的信息。业务实体包含业务效劳。业务效劳：关于特定技术效劳组的信息。业务效劳包含绑定模板。绑定模板：关于如何与效劳交互的信息。绑定模板可以引用tModels。UDDI用作描述Web效劳的数据和元数据的存储库。9.4Web效劳交互9.4

Web效劳交互Web效劳的应用场合如下。(1)效劳请求者创立一个包含必要的效劳有效负载的SOAP消息。通常效劳请求者在运行时使用SOAP客户端，这有助于把输入和输出对象转换为XML消息。(2)在网络层的另一端，SOAP效劳器运行库接收到效劳请求，并把该XML消息转换为提供程序平台(Java、C#等)使用的编程语言所支持的数据结构。然后效劳提供程序说明响应并把它交给SOAP效劳器运行库以通过网络