SOA.docx
《SOA.docx》由会员分享，可在线阅读，更多相关《SOA.docx（15页珍藏版）》请在冰豆网上搜索。
SOA
1.SOA的定义
面向服务的体系结构（service-orientedarchitecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务，Service），通过这些服务之间定义良好的接口和契约（Contract）联系起来。
接口采用中立的方式定义，独立于具体实现服务的硬件平台、操作系统和编程语言，使得构建在各种这样的系统中的服务可以使用统一和标准的方式进行通信。
这种具有中立接口的定义（没有强制绑定到特定的实现上）的特征被称为服务之间的松耦合。
松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。
而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。
我们称能够灵活地适应环境变化的业务为按需（Ondemand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
从这个定义中，我们看到下面两点：
●它是一种软件系统架构。
SOA不是一种语言，也不是一种具体的技术，更不是一种产品，而是一种软件系统架构。
它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它其实更像一种架构模式（Pattern），是一种理念架构，是人们面向应用服务的解决方案框架。
●服务（service）是整个SOA实现的核心。
SOA架构的基本元素是服务，SOA指定一组实体（服务提供者、服务消费者、服务注册表、服务条款、服务代理和服务契约），这些实体详细说明了如何提供和消费服务。
遵循SOA观点的系统必须要有服务，这些服务是可互操作的、独立的、模块化的、位置明确的、松耦合的，并且可以通过网络查找其地址。
2．SOA三种角色的关系
图1是W3C给出的SOA模型中三种不同角色的关系示意图。
其中：
服务是一个自包含的、无状态（stateless）的实体，可以由多个组件组成。
它通过事先定义的界面响应服务请求。
它也可以执行诸如编辑和处理事务（transaction）等离散性任务。
服务本身并不依赖于其他函数和过程的状态。
用什么技术实现服务，并不在其定义中加以限制。
服务提供者（serviceprovider）提供符合契约（contract）的服务，并将它们发布到服务代理。
服务请求者（serviceconsumer）也叫服务使用者，它发现并调用其他的软件服务来提供商业解决方案。
从概念上来说，SOA本质上是将网络、传输协议和安全细节留给特定的实现来处理。
服务请求者通常称为客户端，但是，也可以是终端用户应用程序或别的服务。
服务代理者（servicebroker）作为储存库、电话黄页票据交换所，产生由服务提供者发布的软件接口。
这三种SOA参与者：
服务提供者、服务代理者以及服务请求者通过3个基本操作：
发布（publish）、查找（find）、绑定（bind）相互作用。
服务提供者向服务代理者发布服务。
服务请求者通过服务代理者查找所需的服务，并绑定到这些服务上。
服务提供者和服务请求者之间可以交互。
所谓服务的无状态，是指服务不依赖于任何事先设定的条件，是状态无关的（state-free）。
在SOA架构中，一个服务不会依赖于其他服务的状态。
它们从客户端接受服务请求。
因为服务是无状态的，它们可以被编排（orchestrated）和序列化（sequenced）成多个序列（有时还采用流水线机制），以执行商业逻辑。
编排指的是序列化服务并提供数据处理逻辑。
但不包括数据的展现功能。
3．SOA的特征
基于上面的讨论，我们给出SOA的下面一些特征：
●服务的封装（encapsulation）。
将服务封装成用于业务流程的可重用组件的应用程序函数。
它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。
封装隐藏了复杂性。
服务的API保持不变，使得用户远离具体实施上的变更。
●服务的重用（reuse）。
服务的可重用性设计显著地降低了成本。
为了实现可重用性，服务只工作在特定处理过程的上下文（context）中，独立于底层实现和客户需求的变更。
●服务的互操作（interoperability）。
互操作并不是一个新概念。
在CORBA、DCOM、webservice中就已经采用互操作技术。
在SOA中，通过服务之间既定的通信协议进行互操作。
主要有同步和异步两种通信机制。
SOA提供服务的互操作特性更有利于其在多种场合被重用。
●服务是自治的（Autonomous）功能实体。
服务是由组件组成的组合模块，是自包含和模块化的。
SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。
传统的组件技术，如.NETRemoting、EJB、COM或者CORBA，都需要有一个宿主（Host或者Server）来存放和管理这些功能实体；当这些宿主运行结束时，这些组件的寿命也随之结束。
这样当宿主本身或者其他功能部分出现问题的时候，在该宿主上运行的其他应用服务就会受到影响。
SOA架构中非常强调实体自我管理和恢复能力。
常见的用来进行自我恢复的技术，比如事务处理（Transaction）、消息队列（MessageQueue）冗余部署（RedundantDeployment）和集群系统（Cluster）在SOA中都起到至关重要的作用。
●服务之间的松耦合度（LooslyCoupled）。
服务请求者到服务提供者的绑定与服务之间应该是松耦合的。
这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台，等等。
服务请求者往往通过消息调用操作，请求消息和响应，而不是通过使用API和文件格式。
这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。
在一个极端的情况下，服务提供者可以将以前基于遗留代码（如COBOL）的实现完全用基于Java语言的新代码取代，同时又不对服务请求者造成任何影响。
这种情况是真实的，只要新代码支持相同的通信协议。
●服务是位置透明的（locationtransparency）。
服务是针对业务需求设计的。
需要反映需求的变化，即所谓敏捷（agility）设计。
要想真正实现业务与服务的分离，就必须使得服务的设计和部署对用户来说是完全透明的。
也就是说，用户完全不必知道响应自己需求的服务的位置，甚至不必知道具体是哪个服务参与了响应。
4．三个抽象级别
从概念上讲，SOA中有三个主要的抽象级别：
●操作：
代表单个逻辑工作单元（LUW）的事务。
执行操作通常会导致读、写或修改一个或多个持久性数据。
SOA操作可以直接与面向对象（OO）的方法相比。
它们都有特定的结构化接口，并且返回结构化的响应。
同方法一样，特定操作的执行可能涉及调用附加的操作。
●服务：
代表操作的逻辑分组。
服务可以分层，以降低耦合度和复杂性。
一个服务的粒度（granularity）大小也与系统的性能息息相关。
粒度太小，会增加服务间互操作通信的开销；粒度太大，又会影响服务面对需求变化的敏捷性。
●业务流程：
为实现特定业务目标而执行的一组长期运行的动作或活动。
业务流程通常包括多个业务调用。
在SOA中，业务流程包括依据一组业务规则按照有序序列执行的一系列操作。
操作的排序、选择和执行称为服务或流程编排。
典型的情况是调用已编排服务来响应业务事件。
从建模的观点来看，由此带来的挑战是如何描述设计良好的操作、服务和流程抽象的特征，以及如何系统地构造它们。
这些涉及服务建模、特征抽取的问题已经成为现阶段人们关注的焦点。
SOA应用系统总体框架及相关概念
看到SOA的一堆名词，读者可能会感到迷惑，有必要结合实际的应用环境进一步阐释SOA的相关概念。
总体框架
图1所示的就是一个SOA应用系统的大体框架结构。
它大体上可以分为五个部分：
●展现层（presentation）：
图1中5区，通过portal等技术建立展现平台，方便用户在这个界面上提出服务请求。
●业务处理建模（businessprocessmodeling）：
图1中的4区，SOA元模型从MDA中继承了平台无关模型来对业务处理过程建模。
这一部分独立于服务设计和部署层。
模型驱动架构MDA（ModelDrivenArchitecture）的主要缺陷是在模型设计阶段就对需求有完整的描述，而且没有需求变更的反馈机制。
SOA通过添加敏捷方法AM来应对需求变更的情况。
●服务层（Services）:
图1中的3区，整个SOA的核心层，它承上启下，对上响应业务模型，对下调用相关组件群完成业务需求,形成“业务驱动服务、服务驱动技术”的SOA事务处理格局。
服务可以根据粒度分层。
虽然细粒度提供了更多的灵活性，但同时也意味着交互的模式可能更为复杂。
粗粒度降低了交互复杂性，但敏捷性却下降。
●企业组件层（enterprisecomponents）：
图1中的2区，这里是相关组件发挥作用的场所。
这些组件是平台相关的。
因为到了这一层，许多底层软硬件平台的特性已经不再透明了。
●系统软件层（OperationalSystem）:
图1中的1区，这一层包括操作系统、数据库管理系统、CRM、ERP、商业智能（BI）等异构系统，是一个集成的平台。
除此之外，诸如QoS、安全性等（图1中7区）也是SOA架构的组成部分。
在上面的介绍中，自上而下有一条线，如图2所示，由业务建模开始，通过定义业务过程，得到服务模型，它是平台无关的，实现了模型与实现的分离。
再通过设计组件群，得到平台相关的组件模型。
实施原则
JasonBloomberg在其《PrinciplesofSOA》中指出，SOA的实践必须遵循以下原则：
●业务驱动服务，服务驱动技术。
从本质上说，在抽象层次上，服务位于业务和技术中间。
面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系;另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。
●业务敏捷是基本的业务需求。
SOA考虑的是下一个抽象层次：
提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。
从硬件系统以上的整个架构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。
●一个成功的SOA总在变化之中。
SOA工作的场景，更像是一个活的生物体，而不是像传统所说的“盖一栋房子”。
IT环境惟一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。
对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求有崭新的思维方式。
SOA的基础还是一些类似的架构准则。
与其他概念的关系
1.SOA与WebServices的关系
SOA构架是独立于技术实现的。
SOA并不必用WebServices来实现，相反，WebServices也并不一定遵循SOA标准。
不过，WebServices的特性十分适合用来实现SOA架构。
WebServices之间能够交换带结构的文档（比如XML），这些文档可能包含完全异构的数据信息。
这些文档可以同时附带关于数据的数据：
元数据（metadata）。
换句话说，WebServices可以有较粗的粒度，这样较粗的粒度正好可以构成SOA中服务的粒度。
说到底，两者是相交的圆，SOA服务和WebServices之间的区别还在于设计。
SOA概念并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解。
其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。
而另一方面，WebServices在需要交互的服务之间如何传递消息有具体的指导原则；从战术上实现SOA模型是通过HTTP传递的SOAP消息中最常见的SOA模型。
因而，从本质上讲，WebServices是实现SOA的具体方式之一。
2.SOA中的服务与组件对象（ComponentsObjects）的关系
相似之处在于：
都有一个或多个接口，并且，服务发布者和使用者都遵守这些接口。
不同之处在于：
SOA是关于模式（schemas）的，组件对象是关于对象类型（objecttypes）的；SOA通过像SOAP这样的标准消息机制（messages）来实现通信，而组件对象通过方法调用（methodcalls）来交互。
与CORBA中的接口定义语言IDL（InterfaceDefinitionLanguage）相比，SOA在WSDL（WebServicesDefinitionLanguage）中采用XML，会显得更加普遍和通用。
联系之处在于：
服务最终还是通过类和组件对象来实现的。
SOA被认为是传统紧耦合的、面向对象的模型的替代者。
像通用对象代理架构CORBA（CommonObjectRequestBrokerArchitecture）和分布式组件对象模型DCOM（DistributedComponentObjectModel）。
在SOA中，单个服务可以用面向对象方法来设计，但是，整个SOA的设计却是面向服务的。
下面的表格中给出了SOA与分布式组件架构的不同点。
3.SOA与网格计算（GridComputing）的关系
网格计算（GridComputing）是利用互联网技术，把分散在不同地理位置的计算机组成一台虚拟超级计算机。
每一台参与的计算机就是其中的一个“节点”，所有的计算机就组成了一张节点网——网格。
从实质上来说“网格计算”是一种分布式应用，网格中的每一台计算机只是完成工作的一个小部分，虽然单台计算机的运算能力有限，但成千上万台计算机组合起来的计算能力就可以和超级计算机相比了。
网格计算基于因特网，提供了资源整合和共享的平台。
十分适合作为SOA架构的实施平台。
我们来具体地看一下：
SOA的构建策略：
创建一个面向服务的计算SOC（service-basedcomputing）环境；可以用类似于webservices的技术来设计服务：
使用SOAP通信机制；采用XML数据格式；强调服务的重用和互操作；最大化的应用现有资源；希望有一个类似于网格计算环境的基础平台。
网格作为平台的基本特点：
网格被视为一个由各种计算资源组成的统一环境，其管理软件将网格整合成一个完整而协调的透明计算整体；网格是一个虚拟的应用服务器;是一个应用实现和数据处理的理想平台；服务在网格中部署和调用执行；商业逻辑和服务调用被当成网格程序一样在平台上运行；网格为SOC计算的有效性、快速性、灵活性、伸缩性和计算环境的管理提供便利。
SOA带给企业什么？
作为需要构建SOA应用的企业来说，究竟有些什么好处呢？
我们来看一下：
●集成现有系统，不必另起炉灶。
面向服务的体系结构可以基于现有的系统投资来发展，而不需要彻底重新创建系统。
通过使用适当的SOA框架并使其用于整个企业，可以将业务服务构造成现有组件的集合。
使用这种新的服务只需要知道它的接口和名称。
服务的内部细节以及在组成服务的组件之间传送的数据的复杂性都对外界隐藏了。
这种组件的匿名性使组织能够利用现有的投资，从而可以通过合并构建在不同的机器上、运行在不同的操作系统中、用不同的编程语言开发的组件来创建服务。
遗留系统可以通过Web服务接口来封装和访问。
●服务设计松耦合，带来多方面优点。
服务是位置透明的，服务不必与特定的系统和特定的网络相连接。
服务是协议独立的，服务间的通信框架使得服务重用成为可能。
对于业务需求变化，SOA能够方便组合松耦合的服务，以提供更为优质和快速的响应，允许服务使用者自动发现和连接可用的服务。
松耦合系统架构使得服务更容易被应用所集成，或组成其他服务，同时提供了良好的应用开发、运行时服务部属和服务管理能力。
提供对服务使用者的验证（authentication）授权（authorization），来加强安全性保障，这一点也优于其他紧耦合架构。
●统一了业务架构，可扩展性增强。
在所有不同的企业应用程序之间，基础架构的开发和部署将变得更加一致。
现有的组件、新开发的组件和从厂商购买的组件可以合并在一个定义良好的SOA框架内。
这样的组件集合将被作为服务部署在现有的基础构架中，从而使得可以更多地将基础架构作为一种商品化元素来加以考虑，增强了可扩展性。
又由于面向服务的敏捷设计，在应对业务变更时，有了更强的“容变性”。
●加快了开发速度，减少了开发成本。
组织的Web服务库将成为采用SOA框架的组织的核心资产。
使用这些Web服务库来构建和部署服务将显著地加快产品的上市速度，因为对现有服务和组件的新的创造性重用缩短了设计、开发、测试和部署产品的时间。
SOA减少了开发成本，提高了开发人员的工作效率。
研究表明，一般系统的接口的开发费用占到整个开发费用的33%，最高的竟达到了70%。
在SOA中，接口的重用会节省费用60%。
而且节省的费用不是一次性的，而是每年。
随着业务需求的发展和新的需求的引入，通过采用SOA框架和服务库，为现有的和新的应用程序增强和创建新的服务的成本大大地减少了。
同样，开发团队的学习难度也降低了，因为他们可能已经熟悉了现有的组件。
●持续改进业务过程，降低激变风险。
SOA允许清晰地表示流程流，这些流程流通过在特定业务服务中使用的组件的顺序来标识。
这给商业用户提供了监视业务操作的理想环境。
业务建模反映在业务服务中。
流程操纵是以一定的模式重组部件（构成业务服务的组件）来实现的。
这将进一步允许更改流程流，而同时监视产生的结果，因此促进了持续改进。
重用现有的组件降低了在增强或创建新的业务服务过程中带来的风险，也减少了维护和管理支持服务基础架构的风险。
实现SOA的相关技术
图1是一张SOA技术实施的示意图，其中涉及的主要技术包括以下几个：
1．XML
XML1.0（可扩展标记语言，ExtensibleMarkupLanguage）标准是一个基于文本的WorldWideWeb组织（W3C）规范的标记语言。
与HTML使用标签来描述外观和数据不同，XML严格地定义了可移植的结构化数据。
它可以作为定义数据描述语言的语言，如标记语法或词汇、交换格式和通信协议。
2．SOAP
简单对象访问协议（SimpleObjectAccessProtocol）是一个基于XML的，用于在分布式环境下交换信息的轻量级协议。
SOAP在请求者和提供者对象之间定义了一个通信协议，这样，在面向对象编程流行的环境中，该请求对象可以在提供的对象上执行远程方法调用。
因为SOAP是平台无关和厂商无关的标准，因此尽管SOA并不必须使用SOAP，但在带有单独IT基础架构的合作伙伴之间的松耦合互操作中，SOAP仍然是支持服务调用的最好方法。
W3CSOAP1.2规范在服务请求者和服务提供者之间定义使用XML格式的消息进行通信。
将应用程序请求（在XML中）放入SOAP信封中（也是XML），并从请求者到提供者发送应用程序请求，提供者发回的响应也采用相同的形式。
最近SOAP被称为面向服务的架构协议（Services-OrientedArchitectureProtocol）。
SOAP的优点在于它完全和厂商无关，相对于平台、操作系统、目标模型和编程语言可以独立实现。
另外，传输和语言绑定以及数据编码的参数选择都是由实现决定的。
3．WSDL
Web服务描述语言WSDL（WebServicesDescriptionLanguage）是一个提供描述服务IDL标准方法的XML词汇。
Web服务描述语言（WSDL）规范定义了一个XML词汇表，该词汇表依照请求和响应消息，在服务请求者和服务提供者之间定义了一种契约。
我们能够将Web服务定义为软件，这个软件通过描述SOAP消息接口的WSDL文档来提供可重用的应用程序功能，并使用标准的传输协议来进行传递。
WSDL描述包含必要的细节,以便服务请求者能够使用特定服务：
●请求消息格式
●响应消息格式
●向何处发送消息。
WSDL是基于XML的，因此WSDL文档是计算机可读的（machine-readable）。
这样开发环境使用WSDL将集成服务的流程自动处理到请求者应用程序。
例如WebSphereStudio产生一个Java的代理对象，它能够像本地对象一样实现服务，但是实际上代理对象仅仅处理请求的创建和响应消息的解析。
不管服务是否用Java、C#或者其他的语言实现，生成的Java代理对象都能够从WSDL描述中调用任何的Web服务。
实际上，WSDL不能像编程语言那样描述实现细节。
4．UDDI
统一描述、发现和集成（UniversalDescription,DiscoveryandIntegration）规范提供了一组公用的SOAPAPI，使得服务代理得以实现。
UDDI为发布服务的可用性和发现所需服务定义了一个标准接口（基于SOAP消息）。
UDDI实现将发布和发现服务的SOAP请求解释为用于基本数据存储的数据管理功能调用。
为了发布和发现其他SOA服务，UDDI通过定义标准的SOAP消息来实现服务注册（ServiceRegistry）。
注册是一种服务代理，它是在UDDI上需要发现服务的请求者和发布服务的提供者之间的中介。
一旦请求者决定使用特定的服务，开发者通常借助于开发工具（如MicrosoftVisualStudio.NET）并通过创建以发送请求并处理响应的方式访问服务的代码来绑定服务。
SOA不需要使用UDDI，但由于UDDI是建立在SOA上来完成自身工作的，所以UDDI是服务发现的一个好的解决方案。
5．ESB
如图2所示，企业服务总线ESB（EnterpriseServiceBus）是SOA架构的一个支柱技术。
作为一种消息代理架构它提供消息队列系统，使用诸如SOAP或JMS（JavaMessageService）等标准技术来实现。
有人把ESB描述成一种开放的、基于标准的消息机制，通过简单的标准适配器和接口，来完成粗粒度应用（比如服务）和其他组件之间的互操作。
ESB的主要功能有：
通信和消息处理、服务交互和安全性控制、服务质量和服务级别管理、建模、管理和自治、基础架构智能等。
SOA的不足
作为一个具有发展前景的应用系统架构，SOA尚处在不断发展中，肯定存在许多有待改进的地方。
随着标准和实施技术的不断完善，这些问题将迎刃而解，SOA应用将更加广泛。
缺憾之一:
可靠性（Reliability）
SOA还没有完全为事务的最高可靠性——不可否认性（nonrepudiation）、消息一定会被传送且仅传送一次（once-and-only-oncedelivery）以及事务撤回（rollback）——做好准备，不过等标准和实施技术成熟到可以满足这一需求的程度并不遥远。
缺憾之二:
安全性（Security）
在过去，访问控制只需要登录和验证；而在SOA环境中，由于一个应用软件的组件很容易去与属于不同域的其他组件进行对话，所以确保迥然不同又相互连接的系统之间的安全性就复杂得多了。
缺憾之三:
编排（Orchestration）
统一协调分布式软件组件以便构建有意义的业务流程是最复杂的，但它同时也最适合面向服务类型的集成，原因很
升级会员 