亞瑟‧阿斯狼

WCF最精華的部份並不只是專注在程式碼而已，更多的玄奧之處是在它的組態檔。組態檔的設定可以達成許多意想不到的效果，但也是讓許多學習WCF的好手扼腕之處，本篇主旨在於快速帶領基礎組態檔的設定。

 

我們先建立一個WCF的專案，取其名為MyFirstWCF。

 

接下來我們先看一下設定前的組態檔內容

 

 

WCF的組態採用XML格式，因此，修改時只要符合XML格式規範就可以直接在Web.config上做修改，但是WCF組態太多又太廣，人腦要全數記住實在是有其困難度，為此，微軟提供了一個GUI的WCF組態編輯工具，而我們本篇文章將圍繞在這個工具。

要使用這個工具之前，需要有一段前置作業，而這段前置作業就是要先行打開一次WCF組態編輯工具，然後再關閉！(啥?!看到這段或許大家會有很多疑問，不過待會我會慢慢解釋)

 

路徑為:工具->WCF服務組態編輯器

 

打開之後就會跳出一個WCF服務組態編輯器的視窗了。

接著我們關掉它，然後在Web.config檔案上按滑鼠右鍵，可以看到多了一個選項。

在這邊就要解釋一下為什麼我要這麼做了。一般打開WCF服務組態編輯器，必須要使用檔案瀏覽的方式找到這個專案的Web.config檔案所在的位置，然後才能進行編輯，其實我個人是覺得這樣做實在是太麻煩了，所以才會以這種方式來進行WCF的組態編輯。

 

甫一打開的組態檔編輯器本身並不具有任何服務，因此我們必須手動設定來進行組態的編輯，不過組態編輯也沒有想像中那麼的困難，因為這項GUI工具有提供精靈可以帶大家一步步設定好服務以及服務的端點(EndPoint)，不過在進行編輯之前，請先編譯建置過專案。

編譯建置成功之後，我們就開始一步步的進行WCF服務的組態設定了。但在進行組態的編輯之前，必需要先說明一下WCF的組態基本架構。由於WCF是微軟新一代的分散式系統解決方案，因此其實力和內容必定不容小覷，過去其實微軟也有提出不少分散式系統的解決方案，像是大家耳熟能詳的: Web Service、Remoting、COM+等等技術，但是這些技術都只是微軟的里程碑，微軟吸收過去開發者的回饋，逐步修改和更新新一代的解決方案，最終在近期推出了WCF，其實微軟也把WCF定位成SOA的解決方案，確實，WCF具有不少SOA開發模式所必需具備的特性，並且可以以非常輕鬆的方式就能夠達成，但是我這裡所指的輕鬆….  就是組態設定啦！

 

學習WCF組態其實是一項很重要的課題，也是我目前正努力的目標及方向，因此我在這邊向大家分享一下我在學習WCF組態上的成果，其實WCF組態設定的基礎是圍繞在端點(EndPoint)上，附帶一題，學習WCF另一個痛苦就是”名詞”！WCF有一堆名詞要去瞭解，初期光是那些名詞就可以把你弄到快昏倒甚至是想打退堂鼓。

 

 

上圖是一個WCF的抽象概念圖，圖中的那些中文字正是精華之所在。我們則分別介紹這些名詞：

1. 寄宿程式：

其實WCF本身無法單獨執行，所以它需要一個可以讓它寄宿的程式，其實我們可以想像成是”帶子狼”(其實用狼狽為奸感覺比較象形一點)，所以WCF的書籍必定有一章節是在討論”寄宿”(Hosting)，因為寄宿在不同的程式上會有不同的狀況和效果，其利弊必須由開發者或是架構師仔細考量。

可供WCF寄宿的有下列幾項：

• IIS
• Process
• Windows Service
• WAS

微軟比較推荐寄宿在WAS，不過事實上的確也是絕大多數的WCF會需要寄宿在WAS，較少寄宿在Windows Service。至於Process…. 似乎藏有一些神秘的東西，應有大用只是我目前還想不到。WCF誘人的一點就在於寫一次程式開多個端點(EndPoint)提供給不同環境和各種Process Viwe需求使用，這實在是利多的一點，因為許多狀況下，Process View的需求會弄到開發人員想自盡或是殺了答應這項需求的SA，如今WCF僅需設定一下組態就可以達到了，這是不是很誘人呢？

     2.  類別or介面：

WCF畢竟還是程式，所以難免會需要寫一些程式碼，這個部份也比較貼近Implementation View，開發者可以在這裡盡情揮灑所學的Design Pattern，並且把持住SOA的開發原則，那麼這個服務就可以達到相當高的Reuse了。

     3.  服務：

WCF的程式撰寫的目標就是要提供服務給其它開發者使用，所以在設計上，必須以服務為導向的開發模式，不該把它當成是一個Sub Function，要小心粒度的切割是否過或不及，只要把持的好(開發者總是耐不住中規中矩…)就是一個好用的服務。每個服務可以提供多個端點(EndPoint)給外界。

    4.  端點：

端點其實是由三點成一個面，這三點分別是A(Address)，B(Binding)，C(Contract)，接著來分別介紹這三點：

• Address：亦即服務所在的位址。一個服務一定要有一個固定的位址才行，不得玩躲躲貓遊戲，否則這種別人用不到的服務一點撰寫的意義也沒有。位址共有兩種，其一為基底位址，另一個則為相對位址，這在後續的文章中會討論到。
• Binding：上文中則提及WCF可以解決Process View上的問題，其實是靠Binding來達成，並且WCF支援Binding堆疊，也就是說，就像是在堆積木一樣，你可以自由拼湊出你想要的Binding堆疊，以應付各種不同的Process View需求。
• Contract：這一項其實比較偏向Implementation View；合約潛藏的含義就是約束力和公信力，所釋放出的所有Contract不得在後續修改，這是軟體開發的一個Common Sense，雖然感到不方便，但也讓系統開發達到低耦合性和高內聚力。雖然沒有強制要求一定要用Interface，但是微軟比較建議採用Interface而不是直接使用Class。[直接用在Class後患無窮]

一個服務可以有多個端點，也就是說，當日後系統需要在Process View方面做需求變動時，僅需增加幾個端點即可，而增加端點就是針對ABC三元素打轉，所以得小心應付ABC才行。[ABC…狗咬豬]

既然已經講了那麼多，那麼接下來就讓我們一步步使用微軟所提供的WCF組態設定精靈來走過這一遭吧！

 

    

 

這個步驟是精靈請你告訴它你要針對那個服務進行設定，講白一點就是講你把你這個專案編譯建置完後所產出的*.dll檔找出來。如果沒有特別額外設定，通常是會放置在bin資料底下。

 

 

如果待會打開bin資料夾後裡面空空如也，則代表你忘記要先編譯建置專案了，請先編譯建置專案再重新回到這裡，就可以看見下圖。

 

 

接著再繼續連點MyFirstWCF.dll兩下，就可以看見服務型態了。[在這邊會小小Lag一下，但是是正常，也可能不會，因為我電腦太爛才會這樣]

選好並按下開啟按鈕。

 

 

接著就按下一步吧！待會會需要你選擇Contract。[遇到ABC中的第一個了]

 

 

 

如果服務是實作多個介面，這個步驟可能就需要考慮一下是要放出那一個Contract了。如果僅實做一個介面，那就不需要再考慮什麼了，直接按下下一步吧！

 

 

這個畫面相當重要，因為它這是讓你決定你的Binding；微軟提供了不少現成的Binding，數量雖多但是並非無跡可循，而這個畫面正是其中的關竅，我們可以藉由這個畫面來進行Binding的分類，以方便我們記憶和瞭解微軟所提供的所有Binding。在這個範例中，我們採用較簡單的Http通訊模式。

 

 

 

微軟在Http通訊中，提出了兩種Binding：

• BasicHttpBinding
• WSHttpBinding

 

而BasicHttpBinding正是對應到上圖中的”基本Web服務互通性”，而WSHttpBinding對應到”進階Web服務互通性”。由圖中的描述不難看出這兩者最大的差異在那裡，其實BasicHttpBinding是具有最強的跨平台特性，但是也由於這項特性讓它失去了許多特異功能；而WSHttpBinding則提供了許多誘人的功能，例如交易以及Session，只要彼此平台都是微軟的，就能夠大大方方使用這項Binding進行交易和Session的處理。

 

本範例則是使用BasicHttpBinding，就直接按下下一步的按鈕吧！

 

 

 

來到ABC的最後一關-A了，這個方框就是請你填入你服務的位址，本範例採用Localhost並且埠號是9001。

 

 

這個畫面代表已經設定完成了，按下完成按紐吧！

 

 

完成之後，可以看到原本沒有任何服務和端點的WCF服務組態，現在已經有了，不過這不代表Web.config檔也同步更新了呦！所以別忘了要儲存。

 

 

 

一回到VS2010之後，馬上就會被詢問是否要重新載入，就按下全部皆是。

 

 

Web.config組態檔中多了不少內容，其實這些內容都是我們剛剛所做的成果！接下來我們就要執行一下這個專案，但是別忘了我們有指定我們的服務所用的埠號是9001，所以請在專案上按右鍵->屬性。

 

接著請依步驟操作。

 

 

設定都結束之後，就可以按下執行按鈕，讓VS2010啟動虛擬IIS，並且WCF程式會自動寄宿在這個虛擬IIS上。如果成功編譯無誤，會跳出一個網頁，請點擊Service1.svc，就可以看到…..錯誤畫面。

 

 

 

依錯誤描述我們回到我們的Web.config檔。

 

 

這個項目只支援採用Http通訊的Binding，很不巧…我剛剛正是挑選了BasicHttpBinding作為我端點的Binding，不過這並不是無解，如果我不需要MultipleSiteBindingsEnabled，那麼我直接把它設定改成”false”即可，但是目前我需要這項功能，所以只好把目標轉向了。

我曾提到過Address有兩種，一種是基底位址，另一種則是相對位址；在多種寄宿方式中，若以IIS作為寄宿的宿主，則IIS會自動提供一個基底位址，因此，若我們在端點上設定了完整的Url格式的資料，就會出現錯誤。要解決這項錯誤，必須從WCF的Address基本功下手。Address其實是基底位址+相對位址，舉個例來說：

 

基底位址為：http://localhost:9001/MyFirstWCF

某端點的相對位址為：Basic

那麼這個端點的Address即為：http://localhost:9001/MyFirstWCF/Basic

 

感覺上好像很麻煩，其實不然，微軟這麼限制是有其原因的，因為一個服務可以有多個端點，因此，端點的維護和叫用就成了一個問題，該如何識別端點又不會造成維護上的困難呢？我覺得微軟這一手下的絕妙，以基底位址配合相對位址就可以解決這惱人的問題，又可以把複雜變得簡單。

 

我們只需要把我們端點的Address清空或是改個名字即可。

 

 

再次編譯和建置專案，接著就可以看到下面畫面。

 

接著我們要測試這個服務是否可用，所以叫喚出WcfTestClient。[請參考前兩篇，在文未都有提到如何召喚]

 

 

 

本篇示範就到此結束，感謝大家看到這句。