《WCF技术内幕》翻译12：第1部分_第2章_面向服务:概念汇总-白红宇

概念汇总

　　我希望从本章的这个小节你能对面向服务有个清晰的认识。接下来的一些章节，让我们看看这些概念根本上如何在WCF系统里工作的。在我们的例子里，我讲构建一个简单的接受客户订单的订单处理服务。为了保证概念的简洁明了，这里有2个消息参与者，如图2-3所示。

这个示例代码的作用就是加强你对面向服务的认识和提供WCF的介绍，不会详细描述WCF的方方面面或者建立一个完整功能的订单处理系统。例子里的类型和机制会在这本书将会详细介绍。

契约

　　显然地，面向服务系统开发首先应该是创建契约。为了例子简单，一个订单包含一个产品ID（product ID）、数量（quantity）和状态消息（status message）。有了这三个字段，一个订单可以使用下面的伪schema代码表示：

<Order>

<ProdID>xs:integer</ProdID>

<Qty>xs:integer</Qty>

<Status>xs:string</Status>

</Order>

　　从我们消息自治和配置地址的讨论，我们知道消息需要更多的地址结构，如果我们想使用WS-Addressing。在我们的订单处理服务里，消息发送者和接收者统一使用遵守WS-Addressing规范的SOAP消息来限制消息的结构。有了这个规则，下面就是一个结构合理的消息例子：

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://

schemas.xmlsoap.org/ws/2004/08/addressing">

<s:Header>

<wsa:Action s:mustUnderstand="1">urn:SubmitOrder</wsa:Action>

<wsa:MessageID>4</wsa:MessageID>

<wsa:ReplyTo>

<wsa:Address> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous

</wsa:Address>

</wsa:ReplyTo>

<wsa:To s:mustUnderstand="1">http://localhost:8000/Order</wsa:To>

</s:Header>

<s:Body>

<Order>

<Status>order placed</Status>

</Order>

</s:Body>

</s:Envelope>

　　在创建完描述我们的消息的schema之后，下一个步骤就是定义接受消息的终结点。为此，我们要先看一下WSDL的概念。你也许会想：“我没心情去处理原始的schema和WSDL。”那好，你不会孤单（MJ的一首歌）。WCF团队已经为我们在Microsoft .NET Framework提供了使用我们选择语言（本书里，使用C#）去表示契约的方法（schema和WSDL）。基本上，C#描述的契约都可以根据需要转化为机遇XSD和基于WSDL的契约。

　　当使用C#表示契约的时候，我们可以选择定义一个类或者接口。下面是用C#接口定义一个契约的例子：

// file: Contracts.cs

using System;

using System.ServiceModel;

using System.ServiceModel.Channels;

// define the contract for the service

[ServiceContract(Namespace =

"http://wintellect.com/ProcessOrder")]

public interface IProcessOrder {

[OperationContract(Action="urn:SubmitOrder")]

void SubmitOrder(Message order);

}

　　注意

ServiceContractAttribute

和

OperationContractAttribute

属性标记。我们将在第

章：契约（

）里详细讨论这

个属性。现在这个接口与其它

.NET Framework

的接口不同，因为它们可以定制属性。另外也注意一下

SubmitOrder

方法的签名。这个方法的唯一参数类型是

System.ServiceModel.Message

。这个参数代表任何来自初始发送者和中介者的消息。这个消息类型非常有趣，并且优点复杂，我们将会在第五章：消息（

）里详细讨论。当前，假设初始发送者发送的消息可以被

System.ServiceModel.Message

表示。

　　无论我们选择什么方式表达契约，它都应该在发送者和接收者程序进一步开发以前确定。实际上，接收者定义需要的消息结构契约，发送者通常尝试按照这个契约构建和发送消息。

　　没什么能阻止发送者不按照消息接收者定义的契约来发送消息。因此，接收者第一个任务应该是验证接收到的消息是否符合契约。这个方法保证了接收者的数据结构不会被破坏。这些观点经常在分布式开发社区里讨论。

　　这个契约可以被编译为一个程序集。一旦编译完成，程序集可以指派给发送者和接收者。这个程序集代表了发送者和接收者之间的契约。当契约还会变化确定的次数的时候，我们应该认为在共享以后它是不可变的。我们会在第

章讨论契约的版本问题。

　　选择我们有了自己的契约，让我们建立一个接收者程序。第一个商业订单应该构建一个实现我们定义好的契约的接口。

// File: Receiver.cs

// Implement the interface defined in the contract assembly

public

sealed

class MyService : IProcessOrder {

public

void SubmitOrder(Message order) {

// Do work here

}

　　因为这是一个简单的例子，所以我们打算在

Console

里打印消息并且写到文件里。

// File: Receiver.cs

using System;

using System.Xml;

using System.IO;

using System.ServiceModel;

using System.ServiceModel.Channels;

// Implement the interface defined in the contract assembly实现程序集里定义的契约接口

public

sealed

class MyService : IProcessOrder {

public

void SubmitOrder(Message order) {

// Create a file name from the MessageID根据MessageID创建文件名

String fileName =

"Order" + order.Headers.MessageId.ToString() +

".xml";

// Signal that a message has arrived提示消息到达

Console.WriteLine(

"Message ID {0} received",

order.Headers.MessageId.ToString());

// create an XmlDictionaryWriter to write to a file创建一个XmlDictionaryWriter去写文件

XmlDictionaryWriter writer = XmlDictionaryWriter.CreateTextWriter(

new FileStream(fileName, FileMode.Create));

// write the message to a file写消息到文件里

order.WriteMessage(writer);

writer.Close();

}

　　我们下一个任务就是让

MyService

类型去接受请求消息。为了接受消息：

MyService

必须加载进AppDomain

。

MyService(

或者另外一个类型)

必须侦听内部消息。

适当的时候，比如创建一个此类型的实例，并且只要需要就要引用它（为了阻止垃圾收集器

释放对象的内存）。

当一个消息到来时，它必须被分发给

MyService

的

实例，激活

SubmitOrder

方法。

　　这些任务通常由宿主（

Host

）来执行。我们将在第

章里详细介绍宿主（

Host

），但是现在，假设我们的

AppDomain

托管在一个控制台程序里，管理和分发消息到

MyService

对象的类型是

System.ServiceModel.ServiceHost

。我们的控制台应用代码如下:

// File: ReceiverHost.cs

using System;

using System.Xml;

using System.ServiceModel;

internal

static

class ReceiverHost {

public

static

void Main() {

// Define the binding for the service定义服务绑定

WSHttpBinding binding =

new WSHttpBinding(SecurityMode.None);

// Use the text encoder

binding.MessageEncoding = WSMessageEncoding.Text;

// Define the address for the service定义服务地址

Uri addressURI =

new Uri(

@"http://localhost:4000/Order");

// Instantiate a Service host using the MyService type使用MyService实例化服务宿主

ServiceHost svc = new ServiceHost(typeof(MyService));

// Add an endpoint to the service with the给服务增加一个终结点

// contract, binding, and address

svc.AddServiceEndpoint(typeof(IProcessOrder),

binding,

addressURI);

// Open the service host to start listening打开服务宿主开始侦听

svc.Open();

Console.WriteLine("The receiver is ready");

Console.ReadLine();

svc.Close();

}

　　在我们的控制台程序里，必须在托管之前设置服务的一些属性。正如你将在后续章节里看到的一样，每个服务包含一个地址、一个绑定和一个契约。这些机制常常被成为

WCF

的

ABC

。现在，假设如下：

一个地址描述了服务侦听请求消息的地方

一个绑定描述了服务如何侦听消息

一个契约描述了服务会将会接收什么样的消息

　　在我们的例子里，我们将使用

WSHttpBinding

绑定去定义服务如何侦听请求消息。第8

章我们会消息讨论绑定（Binding

）。

我们的服务也会使用

Uri

类型来定义服务侦听的地址。我们的服务会创建一个

ServiceHost

实例去托管

MyService

。

ServiceHosts

没有缺省的终结点，所以我们必须通过

AddServiceEndpoint

方法

增加自己的终结点。这样，我们的控制台程序就准备开始在

方

法的调用启动了循环侦听。

　　你也许想知道当一个消息到达

时会发生什么。答案取决于到达终结点的消息类型。就此来说，我们来做个简单的例子。更高层次上，我们的消息发送者必须要知道下面三点：

服务在哪里（地址

address

）

服务期望消息如何被传递（绑定

binding

）

服务期望什么类型的消息（契约

contract

）

假设这些大家都知道，下面就是一个合格的消息发送应用：

// File: Sender.cs

using System;

using System.Text;

using System.Xml;

using System.ServiceModel;

using System.Runtime.Serialization;

using System.IO;

using System.ServiceModel.Channels;

public

static

class Sender {

public

static

void Main(){

Console.WriteLine(

"Press ENTER when the receiver is ready");

Console.ReadLine();

// address of the receiving application接受程序的地址

EndpointAddress address =

new EndpointAddress(

@"http://localhost:4000/Order");

// Define how we will communicate with the service定义一个我们通信的服务

// In this case, use the WS-* compliant HTTP binding这个例子里，我们可以使用WS的HTTP绑定

WSHttpBinding binding = new WSHttpBinding(SecurityMode.None);

binding.MessageEncoding = WSMessageEncoding.Text;

// Create a channel创建通道

ChannelFactory<IProcessOrder> channel =

new ChannelFactory<IProcessOrder>(binding, address);

// Use the channel factory to create a proxy使用通道工厂创建代理

IProcessOrder proxy = channel.CreateChannel();

// Create some messages创建一些消息

Message msg = null;

for (Int32 i = 0; i < 10; i++) {

// Call our helper method to create the message调用我们的helper方法创建消息

// notice the use of the Action defined in注意使用在IProcessOrder契约里定义的Action

// the IProcessOrder contract

msg = GenerateMessage(i,i);

// Give the message a MessageID SOAP headerSOAP消息头里加MessageID

UniqueId uniqueId = new UniqueId(i.ToString());

msg.Headers.MessageId = uniqueId;

Console.WriteLine("Sending Message # {0}", uniqueId.ToString());

// Give the message an Action SOAP headerSOAP消息头里加Action

msg.Headers.Action = "urn:SubmitOrder";

// Send the message发送消息

proxy.SubmitOrder(msg);

}

// method for creating a Message创建消息的方法

private static Message GenerateMessage(Int32 productID, Int32 qty) {

MemoryStream stream = new MemoryStream();

XmlDictionaryWriter writer = XmlDictionaryWriter.CreateTextWriter(

stream, Encoding.UTF8, false);

writer.WriteStartElement("Order");

writer.WriteElementString("ProdID", productID.ToString());

writer.WriteElementString("Qty", qty.ToString());

writer.WriteEndElement();

writer.Flush();

stream.Position = 0;

XmlDictionaryReader reader = XmlDictionaryReader.CreateTextReader(

stream, XmlDictionaryReaderQuotas.Max);

// Create the message with the Action and the body使用Action和body创建消息

return Message.CreateMessage(MessageVersion.Soap12WSAddressing10,

String.Empty,

reader);

}

　　不要被

ChannelFactory

类型吓到，我们将会在第 4

章里剖析这个类型。现在，注意 for

循环里的代码。循环体里代码会生成 10

个消息，并且每个消息会指定一个假的唯一的 ID

和一个 Action

（动作，这里专有名词，不做翻译）。

　　这里，我们应该有

个可执行文件（

ReceiverHost.exe and Sender.exe

）表示最终接收者和初始发送者。如果我们运行

个控制台程序，等待接收者初始化完毕，在发送程序里按回车（

ENTER

）键，我们应该可以在接受程序看到下面的结果：

The receiver is ready

Message ID 0 received

Message ID 1 received

Message ID 2 received

Message ID 3 received

Message ID 4 received

Message ID 5 received

Message ID 6 received

Message ID 7 received

Message ID 8 received

Message ID 9 received

　　恭喜！你已经使用

WCF

完成了一个面向服务的程序。记住服务把内部消息写进文件里。如果我们检查服务写过的文件，会看到如下：

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">

<s:Header>

<a:Action s:mustUnderstand="1">urn:SubmitOrder</a:Action>

<a:MessageID>1</a:MessageID>

<a:ReplyTo>

<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>

</a:ReplyTo>

<a:To s:mustUnderstand="1">http://localhost:4000/Order</a:To>

</s:Header>

<s:Body>

<Order>

</Order>

</s:Body>

</s:Envelope>

　　消息头应该和我们在

WS-Addressing

规范里看到的一样看起来有些奇怪，并且它们的值应该与我们在消息发送应用里设置的属性很一样。事实上，

System.ServiceModel.Message

类型暴露了一个叫做

Headers

的属性，它是属于

System.ServiceModel.MessageHeaders

类型。这个

MessageHeaders

类型暴露的其它属性可以表示

WS-Addressing

的消息头。这里的想法就是我们可以使用

WCF

面向对象的编程模型去影响面向服务的

SOAP

消息。

本文转自 frankxulei 51CTO博客，原文链接：

http://blog.51cto.com/frankxulei/318616

，如需转载请自行联系原作者