SOA with WebService 基础.docx
《SOA with WebService 基础.docx》由会员分享，可在线阅读，更多相关《SOA with WebService 基础.docx（18页珍藏版）》请在冰点文库上搜索。
SOAwithWebService基础
序：
面向服务的架构（SOA）是一种设计方式，它为机构提供关于创建和使用业务服务的各个方面，包括构思、建模、设计、开发、部署、管理、版本化、停用等指导。
它可以始终如一地提供健壮的、可重用的服务，这样的服务不但可以满足如今的业务需求，而且可以适应不断变化的业务需求。
可以把SOA看做工厂里的产品装配线。
它是一笔对将来业务运营的投入。
所以在这笔投入发挥效益之前，需要做相当多的计划、设计与开发的工作。
SOA的主要优势是逐渐展现出来的。
可以先构建一个小的SOA系统，然后再将其逐渐构建为完备的SOA.
SOA可以让你更容易地集成IT系统，为能够提供多渠道服务以及实现业务流程自动化。
介绍：
服务与对象或过程不同，服务是由它与其他服务交换的消息来定义的。
服务和应用之间是松耦合的，这令服务可以更容易地在整个部门、企业或者Internet范围内共享数据。
面向服务的架构定义了部署和管理服务的方式，采用面向服务的架构可以提高可重用性，降低总成本，提高快速修改与演化IT系统的能力。
现在采用应用集成问题的方法是采用一种基于Web服务技术的SOA。
SOA可以容易且直接地映射到业务运营流程，而且为技术与业务人员的分离提供了更好的支持，SOA采用了能将现有系统与新系统统一起来的描述模型。
如果Web服务描述在整个部门或企业范围内都可用的话,面向服务的集成项目便可关注于进行Web服务合成，而不是处理不同计算机上的不同应用、不同编程语言以及不同套装应用软件之间的复杂性。
无论你使用任何语言或者任何开发平台都可以采用SOA作为架构，并且采用Web服务作为统一的粘合剂。
Web服务标准更易于理解和使用，由Web服务标准被广泛采纳容易设想这样一种局面：
所有应用都具有服务接口，由此可以想象。
IT人员将通过Web服务接口来执行大多数活动。
服务与SOA的优点是：
所开发的服务，不但可以实现互操作性，而且可以隐藏背后执行环境的细节。
尤其是对于Web服务，这意味着可以在人和开发平台、中间件、操作系统或硬件类型上使用XML格式的数据。
公司需要IT系统具有以下的灵活性：
可以实现专门的运作；可以像业务运营一样易于改变；可以对内外部环境的变化做出快速的相应；能够取得或保持一定的竞争力。
软件业正朝着“改善人们与计算机交互的容易程度”以及“不断提高计算机语言的抽象程度以易于被更多的人掌握”的方法发展。
这一发展方向上的变化的目的是令软件系统更易于、更直接适用于人们与机构的需要。
基于Web服务的SOA有助于解决谁能够衔接业务与技术之间的鸿沟，哪位项目成员将有相当的能力来确保业务问题可以很好的理解并且以技术实现之。
因为其更好的分离了业务分析师和服务开发者的关注点---服务开发者可以负责实现满足业务需求的服务，而业务分析师可以负责定义如何将服务组合起来以实现业务流程。
通过面向服务的架构将新应用和现有应用集成起来，需要定义基本的Web服务互操作层和企业级服务质量层。
以衔接各个当前应用中所使用的特性与性能。
另外还需要在SOA就为之后定义Web服务的自动化业务流程执行流。
多种关键技术正在融合，促使着IT在面向服务的概念与实现上发生重大的改变。
可扩展的标记语言（XML）。
一种跨企业（或更广泛）的、公共的、中立的数据格式：
它提供了：
●与编程语言、开发环境和软件系统无关的标准数据类型与结构。
●用于业务文档定义和业务信息交换的通用技术
●广泛的XML处理软件。
Web服务（WebServices）。
基于Xml的技术，用于传递消息、描述服务、发现服务以及其他的一些扩展功能，它提供了：
●各种被广泛采纳的、用于分布式计算的接口描述，以及通过消息进行文档交换的开发标准。
●与下层技术和应用平台的无关性。
●企业级服务质量（比如安全性、可靠性、事务性等）的可扩展性。
●对合成应用（比如业务流程流、多渠道服务、快速集成等）的支持。
面向服务的架构（Services–OrientedArchitectureSOA）。
一套用于实现应用间互相操作以及重用IT资产的方法，它具有以下特征：
●对架构方面（比如治理、过程、建模和工具等）的强烈关注。
●具有恰当的抽象层次，有利于促进业务需求与技术能力的配合和协调，和创建可重用的、粗粒度的服务。
●是一种快速、方便地构建新应用的部署基础设施。
●一个用于常见业务于IT功能的可重用服务库。
业务流程管理（BussinessProcessManagementBPM）。
用于自动化业务操作的方法和技术。
●清晰地描述了业务流程，以便理解、改进和优化。
●易于针对业务需求的变更而快速修改业务流程。
●将原来由人工完成的业务流程自动化，并实施业务规则。
●为决策者提供有关业务流程的实时信息与分析。
面向服务开发的优点：
●重用—创建可重用于各种应用的服务能力。
●效率—通过组合现有服务以快速创建新的服务与应用的能力，以及集中精力于数据共享而非底层实现。
●与技术的松耦合—独立于服务的执行环境进行服务建模（比如定义服务能够收发的消息）的能力。
●职责的划分—令业务人员和技术人员分别关注业务问题和技术问题、两组人员通过服务契约进行协同的能力。
服务和对象的区别：
一个服务是由它与其他服务交换的消息而不是由一个方法的型构来定义的；服务定义所在的抽象层次必须比对方定义所在的抽象层次要高，因为这样可以把一个服务的定义映射到某种面向过程的语言、消息排队系统或面向对象系统上。
服务定义粗粒度的接口，相对于对象的调用来说，对服务的单次调用会接收到更多的数据，消耗更多的计算资源，因为它需要进行到执行环境的映射和Xml处理的工作，而且对服务的访问通常都是远程的。
当然，对象的接口也可以是粗粒度的。
关键在于，服务是用来解决应用间的互操作问题以及用于组合新应用或新的应用系统，而不是为应用创建具体的业务逻辑的。
服务的执行消息交换模式：
●请求响应
●单向异步
●发布/订阅
Web服务中的Xml作用：
●可以将服务的定义和执行明确的分离。
●利用XmlSchema来表达服务中的数据类型和数据结构，令开发者在处理传递于服务间的数据时，可以不必考虑特定服务的具体实现细节。
IT部门的职责：
●创建服务—处理部署服务所涉及的下层技术的复杂性，并确保XML/WEB服务的描述与服务消费者的需要一致，而且双方共享着应有的数据。
●使用服务—组装新的合成应用与业务流程流，确保共享数据及流程能够准确反映业务的运营和战略需求。
服务抽象：
服务就是具有机器可读的消息（接收和返回的）描述的网络位置，即服务是由它所支持的消息交换模式定义的。
消息中包含的数据具有相应的模式，模式用于在服务请求者与服务提供者之间建立契约。
其他一些元数据项分别描述了服务的网络地址、所支持的操作，以及对可靠性、安全性以及事务性方面的要求。
任何可提供Web服务支持的执行环境都可作为服务的实现。
服务的实现也被称作可执行的代理，它负责实现各种web服务规范中定义的Web服务处理模型，可执行代理在执行环境中运行，这里的执行环境通常是某种软件系统或编程语言。
服务定义一个重要方面是：
服务描述与其可执行代理是相分开的。
一个服务描述可以有多个不同的可执行代理与之相关联。
而一个可执行代理也可以支持多个服务描述。
服务描述通过一个映射层实现与执行环境的分离。
应是层通常以代理或桩的形式实现。
映射层负责接收消息、转换XML数据到本地格式、将数据派送到可执行代理。
Web服务角色
●服务请求者：
通过向服务提供者发送一个消息来启动服务的执行。
●服务提供者：
收到消息后便执行服务，然后将结构返回给服务请求者。
一个服务请求者可以同时也是一个服务提供者，反之亦然。
也就是说，可执行代理可以具有者两种角色中的任一中或者同时兼两种角色。
服务抽象的好处
●易于访问各种不同类型的服务，比如新开发的服务、经包装的传统应用或其他服务合成的应用等。
服务的定义
确保业务运营的流畅，并有助于实现战略目标。
可重新合成。
面向服务架构的定义
是一种设计方式，它指导着业务服务在其生命周期（构思到停止使用）中包括创建和使用的方方面面。
是一种定义和提供IT基础设施的方式，它允许不同应用互相交换数据、参与业务流程，无论它们各自背后使用何种操作系统或采用了何种编程语言。
可被看做一种构建It系统的方案，它将业务服务作为协调It系统与业务需求的关键组织原则。
相反，早期构建IT系统的方案，大多是直接使用特定的实现环境来处理这些业务的问题，结果造成It系统依赖于具体执行环境的特性和功能。
面向服务架构竞争的优势
针对战略性业务目标构建的服务可以对不断变化的业务需求做出更快的相应，而那些针对具体执行环境所构建的It系统则不可能做到。
易于进行Web服务的合成及改变Web服务合成的方式。
修改Web服务以及Xml数据的代价，比修改执行环境的代价低。
用于应用集成、业务流程管理及多渠道服务，可以令企业创建更具战略性的It环境、以更符合业务的运营特征。
更专注于业务本身的描述，先前的开发方法则要求更关注特定执行环境技术的使用。
面向服务开发比先前技术更面向业务问题的解决。
在部署以后的各个阶段中，那时就可以通过组合现有的服务来开发整个或近乎整个新应用。
一旦可以通过现有的可重用服务来组合新应用，便可实现最低成本、最短时间以及最大投资收益率。
但是，实现这一点是需要一些时间的，并且需要在服务开发上相当大的投资。
在出现面向服务开发环境之前，重用的功能是通过新应用中可使用重用的代码库或者类库完成的。
而在基于SOA的应用中，这些通用功能以及常见的系统功能是通过服务来实现的。
不过使用服务比使用可重用的代码库要消耗更多的计算资源。
实现SOA的关键：
是为可重用的服务库中的每个服务确定正确的设计与功能。
这些服务一定要反映机构的运营特点，SOA要将业务运营特性自动化，而成功的SOA项目应可确保可重用的软件服务与实际的业务流程完全一致。
业务流程与其软件实现的良好配合与协调，令业务的运营流程可以根据外界环境的编程做出快速的判断。
影响SOA被接受的因素
必须投入足够的人员进行训练，并保持相当的能力，才能确保所开发的服务是可重用的。
任何技术，都有被误用的可能。
服务的开发，应该考虑长期的利益。
各个服务的单独存在并无太大的价值，除非这些服务能与其他服务一起被其他应用所使用，并能用于合成各种新的应用。
另外，为重用服务进行准确的定义也并非很容易的。
短期成本的考虑。
构建一个SOA的成本很高，对现有系统进行再工程的耗费是巨大的。
某些应用可能还没有可以支持服务调用的接口，有些应用仅能通过文件传输或通过对数据输入、输出进行批处理来访问，因此需要借助与另外的程序才能融入Soa.
BPM
业务流程是现实世界的一种活动，它由一些列在逻辑上相关的任务组成。
若根据恰当的顺序和正确的业务逻辑来执行这些任务，便可产生业务效果。
业务流程管理是一套软件系统、工具和方法的统称。
它关注机构如何识别、建模、开发、部署和管理上述业务流程。
业务流程也包括IT系统与人的交互。
从最初的工作流系统到现在的Web服务编制。
都在此列。
BPM可以以Soa为基础，利用SOA在架构上的成果。
投资基于Web服务的SOA的重要原因之一就是:
Web服务有利于轻而易举低完成Bpm的目标。
BPM的目标
BPM系统的目标是协助达到“业务流程与期望业务结果的一致”。
并确保It系统能够支持这些业务流程。
令业务用户可以在图形化的界面下，以便于it部门实现的方式为业务流程建模。
所有的it系统都是以某种形式来支持和实现业务流程的。
而Bpm的独特之处在于，它显式的将业务流程逻辑从其他应用程序代码中分离出来，这与其他形式的系统开发构成的鲜明的对比，在那些系统中。
业务流程逻辑是深入在应用程序代码中的。
如果能够根据业务流程的图形化描述生成一个可执行的流程规约，那么效率可以得到进一步的提高。
将BPM作为Soa与web服务的消费者。
各种业务流程比如考虑到各种运营特征，有一些人来进行。
、不能完成自动化的操作，但是流程中的许多其他部分可以被自动化的。
就理想来说，希望尽可能在更多方面提高运营效率，保持最少的It系统花费。
基于Soa的基础设施能够帮助你实现这一点。
流程流由多种多种独立的任务组成，其中每个任务都是一个Web服务。
流程流会根据一项任务的执行结果来选择不同的分支以继续执行。
可以在流程流分支处进行错误处理。
元数据管理：
Web服务的元数据是关于Web服务的描述信息，这些描述信息用于构造消息主体和报头。
服务请求者需要根据这些描述来调用服务。
服务提供者发布元数据；服务请求者发现元数据，并据此构造可被服务提供者正确处理的消息。
在进行服务调用时，不仅要发送数据类型和数据结构，还要发送关于补充服务质量的信息，比如安全性、可靠性、事务性等信息。
如果消息中缺少某些这类信息，消息处理可能会失败。
元数据规范：
XMLSchema–用以定义消息中的数据类型与数据结构，用于表达策略信息。
WSDL–用于将消息和消息交换模式与服务名称及网络地址相关联。
WS-Addressing–用于包含与端点相关的端点寻址属性和端点引用属性。
许多其他补充规范需要WS-Addressing来支持定义通信模式中的端点寻址与端点引用属性。
WS-Policy–用于将服务质量需求与WSSDL的定义相关联。
WS-Policy是一个包含安全性、可靠性、事务性等策略断言的框架。
WS-MetadataExchange—用于查询和发现与Web服务关联的元数据，包括获取WSDL文件及相关WS-Policy定义的能力。
寻址：
寻址是补充的Web服务规范的重要需求之一,因为Web上不存在Web服务端点地址的目录。
在几乎所有的消息交换模式中,SOAP消息中都必须包含端点地址信息。
WS-Addressing取代了之前提出的WS-Routing和WS-Referral.
如果没有寻址方案，在服务提供者收到你发送的Web服务请求时，一般只知道一个地址，即请求者的返回地址，而该地址是仅在当前会话期间有效的。
回复过程中一旦发生错误，将无法进行重试。
并且,也没有一种用于制定”除请求者地址以外的其他返回地址”的好方案。
最终的结果是，无法为复杂的消息交换模式或多点传输定义地址规划或标识端点地址。
策略：
策略在表达Web服务的补充特性时是必要的。
有了策略,请求者便可对Web服务的安全性、事务性和可靠性做出规定，而不是仅在WSDL文档中提出关于消息的数据请求。
服务提供者可以用一组机器可读的断言来表达策略，并向服务请求者提出：
必须符合这些断言才能调用其服务。
服务是否对安全性有要求？
是否支持事务性？
对于运行时间长而且复杂的交互，断定它是否支持事务或事务能否跨越多个Web服务是非常重要的。
WS-Policy对于实现补充特性的互操作来说是必要的,因为策略断言是请求者唯一能够用以确定”提供者是否要求某些或者全部补充特性”的方式。
以安全性为例，各个服务提供者支持的安全令牌种类会有所不同。
WS-Security是一种能够携带任何令牌类型的开发框架。
但是，如果提供者没有声明它所期望的令牌类型，请求者无法确信提供者的要求是什么。
获取元数据：
请求者将用WS-MetadataExchange或其他类似的机制，直接查询WSDL及其相关的策略文件。
以获取它所需要的元数据。
WS-MetadataExchange使用了WS-Addressing中的一种叫做活动的特性来访问服务提供者发布的元数据。
安全性
Web服务规范每个栈都设计安全性问题，在Web服务的SOA中，评估是否需要在网络层、消息层以及对消息中数据进行保护是特别重要的。
基本的安全性保护是建立在加密、认证和授权机制上的。
WS-Security用于为Web服务消息提供端到端的消息层安全性，常见的基于HTTP的安全机制仅为传输层提供点对点的保护。
有时通过使用其他传输映射也可以获得额外的安全性。
WS-Security报头可以包含像Kerberos票据和X.509证书这样的强身份认证格式，也能使用XMLEncryption和XMLSignature技术对消息内容做进一步保护。
由于Web服务都是Xml应用，Xml自身存在着安全问题，因此，用基于XML的安全技术来保护装入SOAP消息之前和之后的XMl也是很重要的。
XMLEncryption通过使用加密算法，来提供部分或全部文档的机密性。
XMLSignature:
通过使用加密和签名机制来提供完整性。
以确保服务提供者能够确定文档没有在传输过程中被修改。
事务:
对持久数据的多个操作，要么全部完成，要么什么都不做。
Web服务事务规范扩展了事务协调器的概念，为Web服务修改了通用的两阶段提交协议，并为更加松耦合的Web服务以及编制流定义了扩展的事务协议。
协调是一种为合成的Web服务应用确定一致的、预定义结果的通用机制。
协调器模型包括两个阶段。
第一阶段为获取阶段，参与合成的Web服务各自向协调器登记一个特定的协议，在第二阶段，当参与合成的各个服务分别执行结束后，协调器启动约定好的协议来完成事务。
如果发生错误，协调器应启动恢复协议。
Web服务编制
在具有异常处理、分支和并行执行的长期运行的业务流程中，可以使用编制引擎的方式创建较复杂的交互模型，而不是令Web服务用SOAP和WSDL支持下的一种或多种消息交换模式进行彼此调用。
但要支持这一点，编制引擎必须保持上下文，并提供多个服务之间的关联机制。
可以将Web服务编制本身作为Web服务来发布，通过它提供封装一组其他Web服务的接口。
通过使用MEPs的组合以及编制机制，整套应用可以由不同封装层次的Web服务建立起来。
BPEL假定Web服务使用WSDL与策略断言来定义的。
一个流程流因某个XML文档的到达而启动。
所以，在对流程流的入口点进行建模时，往往采用面向文档式的Web服务。
通常，流程流中的各个任务需要取文档中的不同部分加以操作。
这意味着,流程流中的各个步骤可以通过组合请求、响应与面向文档的Web服务来实现。
BPEL规范与其他扩展规范的不同之处在于，它所定义的是一种可执行语言，而且能够与各种促使业务流程自动化的软件系统相兼容，Web服务编制，通过说明性的方式表达了进行Web服务合成的需求。
服务的种类：
●通过人提供的服务
●自助服务
●系统到系统的服务
SOA的目标
●促使IT能力与业务目标的配合与协调。
●提供一种机动的IT基础设施，即能够便捷地根据需求变化进行重新配置的基础设施。
SOA的关键概念正是服务，SOA定义的流程、原则和方法都是面向服务的，选择的开发工具是面向创建和部署服务的，SOA提供的运行时基础设施也是面向执行和管理服务的。
服务是用作下列用途的基本单元
●进行跨部门和应用便捷的业务信息共享。
●进行跨部门和应用边界的业务信息更新。
SOA专注的是有关服务的各个方面，而不负责属于其他企业架构范畴的应用架构、集成架构、信息架构等专注的问题。
SOA代表了不同的组织系统的方式，是企业架构的一个独特的因素。
服务的定义：
服务是对应于真实的业务活动或可识别的业务功能的IT资产，而服务策略规定了哪些人或事务可以通过使用该服务、何时可以使用该服务、使用该服务的代价、该服务的可靠性登记、该服务的安全等级、该服务的性能等级等等，可以从策略断言中获取服务策略。
服务是粗粒度的、可重用的IT资产。
，良好的接口定义令服务的外部访问接口和内部技术实现相分离，接口与实现的分离消除了业务请求者与服务提供者间的耦合。
于是，只要服务契约不变，请求者和提供者各自的变化，不会影响到服务的调用。
业务服务的粒度随着机构与流程不同而变换。
将业务服务直接映射到机构向顾客、客户以及合作伙伴提供的服务。
业务服务仅实现对特定业务任务的自动化。
可重用的技术服务
可重用的技术服务层定义的服务，不是特定于某类业务营运的，而是可在多个业务营运间重用的。
比如说日志记录，身份管理等等。
这种服务脱离了对业务服务的关注，但他们对业务是非常重要，因为他们处理的是一个非常重要的业务需求-降低风险。
SOA的一个核心有点是，它允许机构将业务逻辑与基础设施的功能分离，提高业务的机动性。
服务契约：
每个服务都有一个良好的接口，称服务契约。
它实现了服务的外部访问接口与实现的分离。
Web服务平台。
定义了用于所有服务的标准和运行时设施，以便这些服务能够以一致的、与下层技术无关的方式进行交互与操作。
SOAP,WSDL,UDDI,WS-Policy,WS-Security,WS-ReliableMessaging
服务请求者和服务提供者
服务提供者：
按照服务契约实现了服务的软件模块。
服务请求者：
调用了服务提供者所实现的服务，能完成某些任务的软件模块。
SOA的原则和准则
●服务是SOA中心组织的概念。
●每个服务通过一个正式契约来定义，该契约将服务提供的功能和服务的技术实现明确分离开。
●服务应只通过明确定义的公共接口与其他服务交互。
●应通过大多数环境支持的标准化技术来使用服务。
●应在抽象层次上定义服务，更好地作到服务需求与技术能力的相互配合。
●服务对服务请求者是有意义的，避免根据已有系统和实现细节来规定服务和服务契约。
●服务是松耦合的。
●相关的一组服务应使用相同的Xml文档类型，以促进在相关服务间交换信息，而且文档的结构和语义必须是已经约定很好理解。
●服务应当执行独立的任务，并提供简单的访问接口，意促进重用和松耦合。
●服务应当提供定义服务能力与服务约束的元数据，而且元数据应当存放在某个可以通过服务来访问的仓库中，不必访问服务本身便可查阅服务的定义，而且服务请求者可以动态地找到并调用服务。
这种间接方式提供了位置透明性。
服务设计、实现和服务应用的特性
●松耦合
●定义良好的服务契约
●对服务请求者有意义。
●基于标准
●预期服务水平协议
●动态的、可发现的、元数据驱动的
●设计服务契约时考虑到相关服务
●独立与其他服务的实现
●可考虑到对补偿事务的需要。
●设计多个调用方式
●无状态的
●设计服务考虑到效率。
松耦合服务：
接口耦合:
服务请求者与服务提供者之间的耦合。
接口耦合衡量的是服务提供者要求服务请求者对它的依赖性—依赖性越小，耦合越松。
理想情况时,服务请求者和服务仅根据已发布的服务契约和服务水平协议来使用一个服务；并且无论在何种情况，服务请求者都不需要关于服务提供者所提供的服务内部实现的信息。
技术耦合：
衡量服务对额定技术、产品和开发平台的依赖程度.
●流程耦合：
衡量的是服务与特定业务流程的依赖程度。
理想的情况是，服务不应与具体的流程相关，以便被重用与多个不同的流程和应用。
服务契约：
每个服务都有一个良好定义的服务契约接口。
明确分离服务的外部调用接口与服务的技术实现。
一般来说，服务契约比服务实现更有价值，服务契约契约体现了重要的业务只是。
服务契约和服务必须在对服务请求者有意义的抽象层次上进行定义，合适的层次是：
●体现所提供业务服务的本质，而不会限制将来的服务使用或服务实现。
●从业务服务领域获得一个面向业务的词汇表，用它来定义业务服务和业务服务的输入、输出文
升级会员 