17 WCF和NET服务如何实现SOA模式.docx

17 WCF和NET服务如何实现SOA模式.docx

《17 WCF和NET服务如何实现SOA模式.docx》由会员分享，可在线阅读，更多相关《17 WCF和NET服务如何实现SOA模式.docx（38页珍藏版）》请在冰豆网上搜索。

17WCF和NET服务如何实现SOA模式

1

第章

设计原理与设计模式

本章主要内容：

●探讨服务与SOA

●理解通信与集成模式

●使用业务流程模式

本章介绍与面向服务、集成和业务流程有关的一些原理和模式。

通过本章的学习，读者将掌握这些原理与WCF之间的关系，以及如何用WCF实现这些模式。

1.1SOA简介

SOA（Service-OrientedArchitecture，面向服务架构）既是一种编程模式，也是软件开发的一种架构方法。

根据这种架构方法，应用程序是由具有一定行为（称为“服务”）的功能单元组成的。

服务是一组具有相同要求和功能目标的方法。

根据它们的结果（如数据、运算结果等），其他部分可以调用相应的服务来执行其逻辑。

这些函数都有一个明确定义且公开的签名，因此其他代码（服务的客户端程序）可以把这些服务中的函数当作黑盒子那样调用。

服务的具体操作是不可见的——它们与用户之间没有直接的交互，而是根据输入参数的要求来运行。

SOA架构允许用户以一定的方式组织分布式应用程序。

分布式是指服务的使用者（服务的客户端程序）可以运行在与服务不同的计算机上。

这使得业务逻辑与用户界面可以集中处理，而使用者则可以分布在网络的各个位置。

为了在SOA中实现这个功能，需要在计算机之间传送包含数据的结构化消息。

SOA的基本思想是构建一个松散耦合的系统，在这个系统中，服务的使用者与服务的实现唯一共同拥有的东西，就是公开的服务操作列表和参数的结构定义。

客户端只知道用来描述服务函数的名称输入参数名称及类型，以及函数返回类型的签名。

除此之外，不存在其他依赖性，不管是客户端还是服务，都可以采用不同的开发平台和编程语言。

显而易见，这种依赖性只是功能上的，而并不基于技术基础架构，这使得不同的开发平台可以很容易与服务进行交互。

SOA架构的技术基础是SOAP标准。

SOAP用XML语言来定义一个服务操作所发送和接收消息的内容。

消息是由参数的值或返回值形成的，而且数据需要转换成SOAP格式。

每个开发平台都有一个SOAP栈，因此服务的调用会得到很多平台的支持，支持多平台是SOA架构的主要目标。

这种方法使得用户可以通过服务来创建系统。

服务是应用程序的组成模块，从服务操作可以生成应用程序。

不管是终端用户应用程序还是另一个服务，都可以利用这些组成模块。

有了SOA架构，就可以定义业务流程的工作流，在业务流程中可以调用服务操作。

在这种架构中，实现一个应用程序就是使代码和代码的功能行为可以在未来不可知的情景中重用。

由于解除了业务逻辑与用户界面的某种技术之间的耦合，因此对于未来使用更新界面创建技术的客户端来说，仍然可以访问这些服务操作。

不需要考虑业务逻辑与界面之间的关系，这本身就是一种优势。

当为某个项目组建一个开发团队时，可以给服务边界的两侧分配不同的小组或成员。

其中一个小组只考虑建立用户界面，不需要考虑业务逻辑和数据访问。

UI小组接收服务接口，根据服务接口设计代码；而另一个小组只需要实现已定义好的服务接口，不需要考虑用户界面（UI）。

这意味着一个开发人员不需要负责一个项目的全部过程，包括用户界面、业务逻辑和针对某个特定需求的数据访问。

其结果是，每个开发人员都可以把自己的专业知识应用于整个项目开发中的某一个层面。

不需要考虑依赖关系也意味着UI和服务的开发可以同时进行，即直接从经双方同意的服务接口的公布日期开始。

这带来的最大好处是，可以把UI的开发工作外包给其他公司，而实际的业务逻辑则由公司内部完成。

SOA是构建分布式系统的一个方法。

在这种分布式系统中，自治逻辑是通过松散耦合的消息和严格定义的接口调用的。

每个服务接口都需要一个可靠的定义，只有当服务契约被多方认可，且在开发过程中不再发生变化，SOA架构的优点才能表现出来。

业务和需求分析要对系统的功能十分明确。

这需要用到功能结构，它在技术层面上定义接口。

这一切并不容易，甚至是不可能的，因为对于大多数情形，业务需求总是经常变化的。

为了解决这个矛盾，最好经过一个持续时间为1~4周的业务迭代过程。

每次迭代，都要清楚地分析服务接口未发生变动和已发生变动的部分，并把修改结果报告给开发小组。

当应用程序和软件系统越来越大、越来越复杂时，就需要一个严密的开发架构。

这种架构通过大量可重用的组件，来实现更好的可维护性。

在当前看到的比较分散的环境中——大多应用程序是在不同的平台中实现的，十分需要一个简单的支持互连的开发方法。

对于仅采用面向对象方法通过对不同组件集成无法解决的大型系统，必须使用SOA架构。

对现有组件的集成，需要一个经过深思熟虑且适用于整个行业的模式，这就是SOA架构。

1.2SOA架构的4条原则

为了使读者对SOA架构有一个更深入的理解，下面详细地讨论SOA架构的几条基本原则。

在软件行业中，基本原则就是执行准则。

在SOA架构中，面向服务有4条原则。

这4条原则是：

●边界是显式定义的

●服务是自动的

●多个服务共享模式和契约，而不是共享类

●服务的兼容性是基于策略的

1.2.1边界显式定义

在使用SOA架构开发产品时，必须显式定义用户访问实现时必须跨越的边界。

服务运行时所处的进程和内存空间必须独立于引用服务的客户端程序所在的进程和内存空间。

定义边界时需要有超前的思想，并且必须与每个可能的参与者进行通信。

边界可以用契约和地址的方式来定义，服务通过这些地址可以被访问到。

这些信息非常重要，必须要容易访问。

没有契约和地址就无法执行服务中的逻辑。

只能通过一种办法执行服务中的逻辑，即通过调用契约，因此也称契约为边界。

边界必须是显式定义的，是指客户端程序只需要知道服务中存在的函数，通过契约运行这些函数即可。

这条原则也意味着，必须对所有可能发生的异常事件进行描述，一个方法只有当以显式获知的数据结构形式，或者以一个包含异常事件详细信息的结构的形式，给出所需要的答案时才会停止执行。

没有明确的允许，数据既不可以进入服务操作，也不可以离开服务操作。

1.2.2服务自动化

服务是不依赖于其他服务的行为的独立程序模块。

服务不需要显式实例化就可以直接引用。

服务必须经过部署，而且每个服务的版本相互独立，安装了某个服务的新版本不会影响其他服务的行为。

类在编译后的可执行文件中是相互耦合的，而服务则不同。

服务使用一种松散耦合的架构。

1.2.3服务共享的是模式和契约，而不是类

模式是对服务操作的定义，它以一种独立于平台的方式来描述签名：

函数的名称、参数类型和返回值类型。

契约是服务的元数据，是服务作为黑盒子的对外接口，模式则是对参数结构的定义。

这条原则明确表示，类本身（不管是代码意义上的类，还是UML意义上的类）不可以被服务及服务的客户端共享。

由于SOA架构的目标是实现不同组件跨平台配合使用，因此把类的代码嵌入到其他组件中就没有什么价值。

对于很多情形，这样的代码是毫无意义的。

类的内部机制（即代码的行为）与使用者无关。

使用服务的应用程序（或其他服务）只对服务操作的输出结果感兴趣。

客户端程序向服务操作发送的消息，必须符合服务契约的要求才可以得到这个结果。

客户端必须通过显式定义的公开接口访问服务。

每个服务都必须有这个接口的一个版本。

对于一个产品级接口，最好不要对它进行修改，因为接口的修改会导致一个新的版本。

1.2.4基于策略的服务兼容性

这条原则意味着由服务决定在满足什么条件的情况下才处理消息。

为了通过协商确定通信中的元素，如消息的格式和对安全方面的要求，必须使用策略。

策略用来进一步明确服务的语义和客户端对服务行为的期望。

1.3服务的内部结构

从解剖上讲，服务与人类机体相似，都是由各个不同部件组成的。

每个部件在系统中都有各自的作用和相应的行为模式。

这种解剖模式有助于读者理解服务的工作原理。

借助这个模式可以深入SOA实现的技术细节，如图1-1所示。

图11

一个服务包含若干个方法，这些方法通过一个通道来与服务的使用者建立通信。

服务的使用者也使用一个与服务通道相匹配的通道来实际地调用服务的方法，向服务发送所需要的数据。

一方面，通道是模式、契约和策略的结合；另一方面，通道在运行时就是使用的协议。

消息可以在通道中双向传递。

通道总是与某一个协议捆绑在一起，定义对服务的访问方式和访问过程。

协议（如HTTP或MSMQ）用来传送数据，需要得到服务实现时所在操作系统平台的支持。

通道相当于一个管道，消息在其中流动。

客户端（或其他类型的服务使用者）把消息放在通道的一端，发布服务的平台所在的宿主栈在另一端读取消息。

通道将被绑定到由契约定义的模式上。

在模式和契约中，如果没有对服务操作的元数据的定义，那么通道是不完整的。

通道还需要知道服务使用者必须要实现的策略。

服务的生态系统

从更高的角度来看，服务是某生态系统中的一个有机体。

来自该生态系统的一些概念组成了SOA架构的一部分。

这个生态系统描述了这些概念的作用以及它们之间的相互关系，如图1-2所示。

图12

1.应用程序由服务组成

这个生态系统的核心是服务，服务是组成模块，由它们可以构建应用程序。

应用程序可以是终端用户的工具，具有清晰的用户界面部分或以预定顺序访问服务的业务流程部分。

由于SOA架构允许读者把服务看成行为的单元，因此读者可以根据需要选择构建软件解决方案另一个部分所需的服务模块，进而构建应用程序。

2.服务的管理状态

服务的任务和操作经常把数据持久性地保存在数据库中，之后再从数据库中读取数据。

实际上，大多数服务都有一个状态，虽然也有无状态的服务，即它们没有在内存中保存数据，但是它们通过调用数据库来持久地保存状态。

服务不能直接调用数据库，但是在一个设计良好的架构中，服务依赖于其他层与数据库进行通信。

3.服务实施策略

服务有权制定与服务逻辑用法有关的策略。

策略描述了服务使用者行为模式的先决条件。

读者不妨把策略当作在客户端与服务通信之前必须达成的协议。

对于绝大多数情形，它是关于安全的协议。

4.策略实施操作要求

通过定义策略，服务可以实施调用平台的操作要求。

策略必须以如下这样的方式进行组织：

在客户端必须实现某种安全措施。

5.服务是由契约绑定的

只有当描述服务操作签名的契约存在时，服务才存在。

这个契约是客户与服务之间达成的约定。

契约必须显式定义，并且在运行时要绑定到服务。

建立客户层的代理类时，需要这个契约，这样一来，客户端程序就可以像本地类那样调用服务了。

没有契约，客户端程序就无法使用服务。

6.契约描述了消息交换模式

消息交换模式是对消息从一方到另一方传送过程和传送方法的定义。

消息交换模式确定了是同步还是异步调用服务，决定了是否需要返回结果。

消息交换模式可以是：

●请求-响应模式：

这是最常用的模式，每个调用都直接返回另一个消息。

●单向模式：

服务调用没有返回结果，因此服务可以异步调用。

●双向模式：

在调用方法的过程中，服务操作可以回调给客户端，服务操作在返回最终结果之前，可以向客户端程序请求更多的信息。

消息交换模式在功能层是可见的，因此开发人员可以实现服务操作。

在协议更深的技术层，消息交换模式虽然也存在，但是大多数情况是不可见的。

当读者用wsHttpBinding绑定调用一个服务操作时，客户端和服务将不只交换消息数据。

首先是进行功能性调用，然后是其他一些技术消息。

读者可以认为这些消息是握手消息，它们是WS协议的一部分，通过这些消息协商出一个安全环境。

此外，还要确保服务能收到所需要的数据，同时服务需要确信客户能接收到所需要的响应。

这些额外的通信是通过协议来实现的，不是由开发人员来实现。

7.契约包含模式，而模式定义消息的结构

模式定义了所操作参数的结构。

模式采用XSD文档格式来描述参数。

XSD是元数据语言，用来描述传入服务操作的参数和服务操作返回的结果。

定义完模式之后，服务操作的使用者就可以格式化数据了。

当调用时XSD能够被服务理解，因此用户可以再次访问数据。

这就是所谓的序列化和反序列化。

8.消息交换模式是一个消息集

消息的组合和调用顺序可以用一个更加复杂的交换模式来描述。

这样一来，消息交换模式就可以定义哪个操作必须先调用，哪个操作必须最后调用，以及决定是否可以定义操作的一个完整工作流。

9.服务交换消息

交换消息是服务生态系统的最重要组成部分。

交换消息意味着调用一个操作和接收来自此操作的响应（或产生一个异常）。

交换消息是从另一台计算机调用服务的一种方式。

一个消息把客户端的输入参数传输给服务，另一个消息把响应传回给调用者。

1.4组织业务流程中的服务

图13

在面向服务的架构中，服务是应用程序的组成模块，工作流可以调用服务中的操作。

工作流是对传入调用与传出调用之间的调用顺序及相互依赖关系的定义。

为了实现某个业务流程，工作流负责组织使用者与服务之间的交互动作。

工作流知道自身正在调用和实现的服务的契约和模式。

工作流就像程序中的顺序结构和分支结构，它们与接收操作和调用其他服务的操作有关。

但这些顺序结构和分支结构并不是用编程语言来编写，而是对工作流用元语言进行显式定义。

元语言可以理解为应用程序运行时各个组件之间的集成。

工作流就是以这种方式来描述一个功能化且复杂的消息交换模式。

SOA的主要目的是构建应用程序中可重用的组件，而工作流则是集成逻辑与业务流程的实现者。

业务流程的需求构成是契约和模式定义的基础。

分析这些需求是系统分析过程的第一步。

图1-3是组织业务流程的一个示例。

1.5SOA的底层技术

为了实现一个SOA应用程序，需要掌握相关的支持技术和协议。

由于SOA专门用来建立分布式和跨平台的应用程序，因此这些技术和协议必须符合业界标准。

下面将描述SOA领域中最常使用的标准。

1.5.1SOAP

SOAP（SimpleObjectAccessProtocol，简单对象访问协议）是一种XML规范，用来交换消息中结构化信息中的数据。

SOAP可以标准化网络上交换的数据。

由于是基于XML的，因此独立于平台。

一个SOAP消息只携带数据消息。

一个SOAP信封包含一个消息头（可选的）和一个消息体（必需的）。

消息头包含了与底层技术基础设施有关的信息，而与业务功能无关。

消息体包含了有用的数据，因此又称为“有效载荷”（payload）。

服务操作的每个参数都以数据的序列化形式出现在消息体中，下面是SOAP消息的一个示例。

Envelope

xmlns:

soap="http:

//www.w3.org/2001/12/soap-envelope"

soap:

encodingStyle="http:

//www.w3.org/2001/12/soap-encoding">

Bodyxmlns:

m="http:

//www.example.org/stock">

GetStockPrice>

StockName>XYZ

StockName>

GetStockPrice>

Body>

Envelope>

1.5.2WS-*Protocols

SOAP只是一个规范，描述了如何格式化地表示消息体中的有效数据和消息头中的技术性数据。

SOAP本身并没有给出消息头的明确定义。

WS-*是一系列标准协议，它们规定了在使用SOAP消息实现分布式消息传递时如何实现某个需求和行为。

这些协议描述了如何通过SOAP消息中的头元素实现安全、可靠、事务性的消息交换。

WS-*协议组中的每个协议都有各自的作用。

在WCF中，利用WSHttpBinding绑定可以实现WS-*协议。

此绑定利用了WS-*协议组中的某些协议，并添加了所要求的行为，如事务消息调用、可靠性、发现和寻址。

1.5.3WSDL

WSDL是对契约的XML格式的定义，包括了服务接口的全部元数据，如函数的名称、参数的名称及数据类型，以及函数的返回值类型。

WSDL文档的作用是按跨平台方式定义契约，因为这些类型是用XML格式来描述的。

在非.NET开发环境中，可以用自己的编程语言（如J2EE）根据WSDL文件中的描述来建立类，这些类将作为实际使用的集中实现类的代理。

图1-4是WSDL文件的一个示例。

用浏览器访问这个专用的URL地址时就会看这个文件。

WCF服务通过这个专用URL地址来公开元数据。

图14

1.6契约优先原则

为某个应用程序设计服务，首先是要进行需求分析。

不要一开始就打开VisualStudio立刻编写代码。

系统分析师首先要与需要这个应用程序的人们一起进行分析，认真理解他们对服务需求的描述。

为了准确地定义服务的功能和逻辑，必须与所有服务相关人员进行交谈。

首先需要明确定义服务的契约。

分析面向服务的应用程序不是绘出用户界面，也不是定义一些表格以及它们的关系图，而是先定义契约。

当然，功能分析的最后结果是应用程序的3个基本层面：

●UI层：

包含界面、验证逻辑和用户控件之间的交互。

●逻辑层：

实现需求、业务规则、计算和报告生成。

●数据库层：

存储数据，并保证表之间引用的完整性。

显然在SOA方法中，UI层和数据库层并不是需要分析的最先两层。

SOA的重点是在业务方面，关注于业务逻辑、界面感观与数据库存储的分离。

实际上，UI层和数据库层都与业务需求没有关系。

对于大多数情形，业务处理对数据如何存储、如何提供服务给终端用户等问题都不感兴趣。

我们希望服务中的逻辑模块可以供多个用户界面访问。

用户界面是由另一个团队开发的，此团队只对UI层感兴趣，与业务没有任何关系。

记住，服务相当于黑盒子，可以从它们中得到所需要的结果。

我们希望逻辑模块独立于数据库存储。

DBA管理员的职责是设计表，除非数据库已经准备好。

这就引出了契约优先的原则。

第一个需要分析的是契约。

你必须清楚了解：

从服务能够得到什么样的结果，服务有哪些方法，这些方法的参数需要哪些数据结构。

契约的设计受业务影响很大，而且必须由业务来驱动。

契约的定义是软件分析师或业务分析师的工作。

1.7WCF和.NET服务如何实现SOA模式

模式是对典型情况下某个众所周知问题的可重用解决方案的描述。

设计模式的思想是：

在问题的解决方案转换为代码之前，用某种易于理解的语言对它进行描述。

可以说，设计模式是设计蓝图或问题解决方案的模板。

在使用某种编程语言编写代码之前，可以用设计模式分析问题。

设计模式对开发栈或使用的技术来说是未知的。

1.7.1模式

模式是架构师或集成方案设计人员使用的语言，他们在交谈或讨论中经常使用模式这个术语。

像“我建议在把消息发送给中间人之前使用一个富集模式”，“对于这里的功能性需求，我并不认为需要一个关联模式”，都是他们在分析面向服务或基于集成的解决方案时经常使用模式的几个典型示例。

这些语句对于流程设计人员和架构师而言是明白易懂的，而且也是开发之前的一种有效的交流方式。

当他们在设计上意见达成一致后，就用模式描述他们的设计思想。

与模式相对应的是样式，它用图表描述通信和集成的整个过程。

在这里，模式是多个样式的组合，它是开发人员编写代码和系统工程师生成实现的理想基础。

1.7.2解耦契约：

接口与实现

WCF通过把接口当作C#或VB.NET语言的一部分，来支持接口定义与接口实现的分离。

所有操作，以及服务的参数类型和返回值类型都可以用接口来表示。

这些接口可以创建到一个单独的类库项目中。

描述参数或返回值结构的数据契约也可以用类来定义。

通常，这些接口和类都保存在一个类库中，但类库中并不包含它们的实现。

读者只需要在实际项目中引用所需要的接口，或者用.NET语言支持的传统方法实现接口即可。

接口的定义与实现相分离，将允许多个项目共享一个所需要的接口，但并不像客户端应用程序那样提供实现。

必须给接口和它们的操作签名添加元数据，这样WCF才承认它们是契约，契约是服务生态系统的一部分。

这些元数据要放在代码元素的开头，它们形成了额外一层的元数据，只有WCF运行时能够理解这些元数据，WCF运行时以契约和模式的形式给出代码的意义。

由于定义这些契约和模式的元数据出现在特性（Attribute）中1，因此它们与接口是分离的，接口的实现只知道接口本身。

这就解除了契约与实现之间的耦合。

在元数据中定义操作名称和SOAP消息的XML结构，服务的实现不需要知道它们。

这些特性是[ServiceContract]、[OperationContract]、[DataContract]和[DataMember]。

1.7.3代理模式

WCF采用了代理模式，即允许在项目中创建并使用一个使用了服务的类。

这个类看起来像是一个实现，但实际上它就是一个类，它与真实逻辑的实现一样，实现了同一个共享的接口。

由于可以在客户端项目中同时使用这个接口以及SOAP消息定义中的额外元数据，因此这个代理类可以通过实现这个接口来模仿这个实现。

WCF提供了ClientBase类，由这个类可以派生出代理类。

这个基类拥有与服务建立通信和转换操作调用所需要的全部逻辑。

使用者可以通过代理发送SOAP消息，并用定义的绑定把消息发送给服务。

ClientBase是一个泛型类，它需要知道这个接口的类型。

这个类有一个保护属性，这个属性只有在派生类中才是可见的。

这个属性就是通道，它属于代理使用的泛型。

这意味着这个通道拥有与服务器端相同的逻辑实现方法列表。

1.7.4OperationContext模式

OperationContext模式的作用是把方法的输入参数与这个方法执行时需要的技术信息相分离。

WCF提供了一个名为System.ServiceModel.OperationContext的类，在实现方法的执行过程中，可以利用这个类获取当前方法的执行和消息上下文。

这个类能够向正在执行的方法提供有关的调用信息，如会话ID、SOAP信封中的传信消息头、调用者身份以及如何进行调用验证。

这个上下文包含大量的非功能性信息，因此它们不是被调用方法的DataContract参数的一部分。

当工作在双向通信模式时，OperationContext提供了在调用期间回调客户端的通道。

WCF还支持另外一个名为WebOperationContext的上下文，它以HTTP属性的形式向一个方法提供更多有关请求的信息。

1.7.5并发契约

WCF允许同时实现多个接口，并且允许为一个服务配置多个终结点，从而支持并发契约。

每个终结点的配置都有自己的地址，并能在其中一个接口中引用它，这导致的结果是由单个服务负责实现一组来自多个接口的操作。

在这个接口中，有些操作专为某个接口保留，而有些操作则在多个接口中都有定义。

一个接口可以访问的操作列表由终结点配置来定义，因为这个配置知道自己公开的接口。

1.7.6数据保密性

安全与数据保密性在WCF中得到了很好的实现，WCF利用消息级安全的WS-*协议栈实现了跨平台安全。

此外，除了这些WS-*增强型协议提供的安全外，还可以在更高层上使用传输安全。

安全级别由选取的绑定确定。

1.7.7Web服务原子事务

由于WCF实现了Web服务原子事务（WS-AtomicTransaction，WS-AT）协议，因而支持事务处理。

大多数时候，服务层的事务会引发数据库层的事务。

WCF通过与数据库分布式事务协调工具的通信来建立事务。

WS-AT规范定义了跨服务边界执行事务的机制，允许事务跨越来自一个客户端的多个调用，因此事务可以分布在会话外观之外，这使得客户端可以启动事务，调用同一个服务的不同操作，以及把所有操作调用看成一个事务。

从客户端到服务的事务流以及服务中的操作都参与（有时也表示为“跟从”（follow））了由客户端启动的事务中。

这意味着服务一直使事务处于存活状态，直到客户端决定事务结束为止。

当事务结束时，服务向分布式事务协调工具发送信号，表示需要提交事务。

分布式事务也意味着在客户端启动一个调用期间，当客