WCF和HTTP應用編程

HTTP應用場景
當你使用IE或者FireFox或者其他瀏覽器瀏覽新浪、搜狐等新聞網站時…
當你在網上瀏覽各種購物網站時…
當你在網上發表各種帖子時，…
…
當你用瀏覽器通過（Http：//www………）的時候，都離不開HTTP協議；

HTTP簡介

1.HTTP（HyperText Transfer Protocol，超文本傳輸協議）在TCP/IP體系結構中，HTTP屬於應用層協議，位於TCP/IP的頂層。

2.目前常見的HTTP標準是HTTP/1.1;
3.HTTP定義Web客戶端（一般是瀏覽器）如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。
4.HTTP用於在客戶端與服務器之間傳遞超文本文件。

HTTP的特點

HTTP以TCP方式工作。
HTTP客戶端首先與服務器建立TCP連接，然後客戶端通過套接字發送HTTP請求，並通過套接字接收HTTP響應。

HTTP是無狀態的
“無狀態”的含義是，客戶端發送一次請求後，服務器並沒有存儲關於該客戶端的任何狀態信息。即使客戶端再次請求同一個對象，服務器仍會重新發送這個對象，而不管原來是否已經向該客戶端發送過這個對象。

HTTP使用元信息作爲標頭
HTTP通過添加標頭（Header）的方式向服務器提供本次HTTP請求的相關信息，即在主要數據前添加一部分信息，稱爲元信息（Metainformation）。
例如，傳送的對象屬於哪種類型，採用的是哪種編碼等。

HTTP的請求與響應

1．HTTP請求
設置請求方式：可以用HttpWebRequest的【Method】屬性設置請求的方法。如果不設置【Method】屬性，系統默認請求的方法爲“GET”。

例如，下面的代碼設置HTTP請求的方法爲“POST”：
string uri = “http://www.google.cn”;
HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(uri);
request.Method = “POST”;

當客戶端將HTTP請求發送到服務器時，其內部發送格式如下所示：
＜request-line＞ ：第1行必須是一個請求行（request line），說明請求的類型、要訪問的資源及使用的HTTP版本
＜headers＞ ：標頭（header）部分，說明服務器要使用的附加信息，這部分一般由多行組成。
＜blank line＞ :標頭之後是一個空行（blank line）
[＜request-body＞] :空行之後是請求的主體（request-body），主題中可以包含任意的數據

（1）GET請求
GET請求是最爲常見的一種請求，表示客戶端告訴服務器獲取哪些資源。

GET請求後面跟隨一個網頁的位置。除了頁面位置作參數之外，這種請求還可以跟隨協議的版本如HTTP/1.0等作爲參數，以發送給服務器更多的信息。

（2）POST請求
POST請求要求服務器接收大量的信息。與GET請求相比，POST請求不是將請求參數附加在URL後面，而是在請求主體中爲服務器提供附加信息。

POST請求一般用於客戶端填寫包含在Web表單（Form）中的內容後，將這些填入的數據以POST請求的方式發送給服務器。

對於ASP.NET網頁，當用戶通過客戶端瀏覽器在Web頁面中填入數據，然後單擊提交按鈕時，客戶端向服務器發送的就是POST請求。

（3）HEAD請求
HEAD請求在客戶端程序和服務器端之間進行交流，而不會返回具體的文檔。

因此HEAD方法通常不單獨使用，而是和其他的請求方法一起起到輔助作用。

典型應用：一些搜尋引擎使用的自動搜索機器人採用這個方法來獲得網頁的標誌信息，或者進行安全認證時，使用這個方法來傳遞認證信息等，也可以判定某個網頁資源是否可用，這些功能均可用通過HEAD請求來實現的。

2．HTTP響應
客戶端向服務器發送請求後，服務器會回送HTTP響應。

HTTP響應的一般格式爲：
＜status-line＞
＜headers＞
＜blank line＞
[＜response-body＞]

注意：對於HTTP響應來說，它與HTTP請求相比，唯一的區別是第1行中用狀態信息代替了請求信息。狀態行（Status Line）通過提供一個狀態碼來說明所請求的資源情況。

所有HTTP響應的第一行都是狀態行,該行內容依次是當前HTTP版本號、3位數字組成的狀態碼以及描述狀態的短語，各項之間用空格分隔。例如：HTTP/1.1 200 OK ;//狀態行
狀態碼的第一個數字代表當前響應的類型，具體規定如下
1xx 消息——請求已被服務器接收，繼續處理。
2xx 成功——請求已成功被服務器接收、理解、並接受
3xx 重定向——需要後續操作才能完成這一請求。
4xx 請求錯誤—請求含有詞法錯誤或者無法被執行。
5xx 服務器錯誤—服務器在處理某個正確請求時發生錯誤

HTTP應用編程的技術選擇

1. WebRequest類和WebResponse類

請求/響應模型的抽象（abstract）基類。用於訪問Internet數據。它允許使用該請求/響應模型的應用程序可以用協議不可知的方式從Internet請求數據。

2.HttpWebRequest類和HttpWebResponse類
HttpWebRequest和HttpWebResponse是針對於HTTP的特定實現。該類通過HTTP協議和服務器交互。

3.使用WCF來實現HTTP應用編程，程序員只需要處理業務邏輯即可，其他工作細節讓WCF內部去完成就行了。因此，用WCF和基於任務的編程模型實現HTTP應用編程是建議的做法

WCF中與HTTP相關的綁定

基本HTTP綁定（BasicHttpBinding類）

基本HTTP綁定用BasicHttpBinding類來實現，在配置文件中用basicHttpBinding元素來配置。

利用BasicHttpBinding，可輕鬆實現類似傳統的Web服務實現的功能。

默認配置和自定義配置
默認值及可選參數
安全模式
消息編碼(messageEncoding)消息文本字符編碼(textEncoding)
傳輸方式（transferMode）
是否支持會話、事務、雙工
其他

其他常用的HTTP綁定

安全HTTP綁定（WSHttpBinding類）
WSHttpBinding定義一個適合於非雙工服務的安全、可靠且可互操作的綁定。該綁定實現了WS-ReliableMessaging規範（保證了可靠性）和WS-Security規範（保證了消息安全性和身份驗證）。

雙工安全HTTP綁定（WSDualHttpBinding類）
WSDualHttpBinding類也是使用HTTP作爲基礎傳輸協議，在服務端和客戶端配置文件中用wsDualHttpBinding元素來配置。該綁定也是使用“文本/XML”作爲默認的消息編碼。但是，它僅支持SOAP安全模式，且需要可靠的消息傳遞。

WCF客戶端和服務端的消息交換模式

請求應答模式（Action/Reply）

“請求/應答”模式：客戶端向WCF服務端發送請求後，服務端執行服務操作，並將操作結果返回到客戶端。客戶端如果不是通過異步操作來調用的，在服務端返回服務操作結果之前，客戶端代碼將處於阻塞狀態。這種模式也叫“請求/答覆”模式。

單向模式（IsOneWay）

單向模式：
客戶端調用WCF服務操作時，服務端不向客戶端返回操作結果。即使服務端出現執行錯誤，它也不會向客戶端返回結果。
單向模式的優缺點:
優點：速度比“請求/應答”模式快。
缺點：當服務端執行過程中出現錯誤時，由於客戶端接收不到任何返回的消息，因此也無法發現服務端是否正確執行了操作方法。

雙工通信

雙工（duplex）是指客戶端和服務端都可以主動呼叫對方。在這種通信模式中，WCF利用雙向綁定實現服務端和客戶端相互公開終結點的信息。
雙工通信的主要設計思想
1、配置服務端綁定讓其支持雙工
在Web.config中的節點添加支持
2、在服務端聲明和實現接口
一個接口用於服務（客戶端調用、在服務端實現）
一個接口用於回調（服務端調用、在客戶端實現）
3、在客戶端實現回調接口

同步操作和異步操作

在WCF基本用法的例子中，我們大部分使用的都是同步調用。實際上，當客戶端用【添加服務引用】的辦法生成客戶端代理類時，默認情況下，生成的所有調用操作既包含同步調用的方法，也包含基於任務的異步調用的方法。

WCF和HTTP編程示例

五子棋遊戲規則描述

服務端和客戶端通信接口

客戶端發送給服務端的請求
服務端發送給客戶端的命令

服務端編程

1.定義和實現協定（IGobangService接口和GobangService類）
2.創建與遊戲室管理相關的其他文件
User類：封裝每個遊戲玩家信息
GameTable類：封裝每個遊戲桌的信息
CC類：保存連接用戶以及每桌遊戲的情況。
3.修改服務端配置

客戶端編程

添加服務引用
創建客戶端遊戲界面
棋盤：Image控件
產生棋子的事件：Image_MouseDown
修改主界面