參考資料:http://www.javashuo.com/article/p-dunodtqq-bu.htmlhtml
一、首先明確一點,就是無論怎樣,finally必定會執行,即便程序有異常,而且在catch中thorw 了 ,finally仍是會被執行。ios
二、當try和catch中有return時,finally仍然執行。程序員
三、finally是在return後面的表達式運算完以後執行的,在執行完return時 ,程序並無跳出,而是進入到finally中繼續執行,web
若是在finally若是對返回值進行了從新賦值,分爲兩種狀況:編程
(1)當返回值是值類型(包括string類型,雖然是引用類型,這是特殊的個例)時,返回的值不受影響,c#
就是在trycatch時,返回的值已經肯定了。數組
public static string[] TestYinYong()
{
string[] arr = { "one", "two" };
try
{
throw new Exception();
}
catch (Exception)
{
return arr;
}
finally
{
arr[1] = "three";
}
}
此時返回的值是:{ "one", "three" };瀏覽器
四、finally中不能有return語句,編譯都沒法經過,提示:控制不能離開finally子句主體服務器
MSDN的定義:網絡
lock 關鍵字能夠用來確保代碼塊完成運行,而不會被其餘線程中斷。這是經過在代碼塊運行期間爲給定對象獲取互斥鎖來實現的。
先來看看執行過程,代碼示例以下:
假設線程A先執行,線程B稍微慢一點。線程A執行到lock語句,判斷obj是否已申請了互斥鎖,判斷依據是逐個與已存在的鎖進行object.ReferenceEquals比較(此處未加證明),若是不存在,則申請一個 新的互斥鎖,這時線程A進入lock裏面了。
這時假設線程B啓動了,而線程A還未執行完lock裏面的代碼。線程B執行到lock語句,檢查到obj已經申請了互斥鎖,因而等待;直到線程A執行完畢,釋放互斥鎖,線程B才能申請新的互斥鎖並執行
lock裏面的代碼。
接下來講一些該lock什麼對象。
爲何不能lock值類型,好比lock(1)呢?lock本質上Monitor.Enter,Monitor.Enter會使值類型裝箱,
每次lock的是裝箱後的對象。lock實際上是相似編譯器的語法糖,所以編譯器直接限制住不能lock值類型。
退一萬步說,就算能編譯器容許你lock(1),可是object.ReferenceEquals(1,1)始終返回false(由於
每次裝箱後都是不一樣對象),也就是說每次都會判斷成未申請互斥鎖,這樣在同一時間,別的線程照樣能
夠訪問裏面的代碼,達不到同步的效果。同理lock((object)1)也不行。
那麼lock("xxx")字符串呢?MSDN上的原話是:
鎖定字符串尤爲危險,由於字符串被公共語言運行庫 (CLR)「暫留」。 這意味着整個程序中任何給定字符串
都只有一個實例,就是這同一個對象表示了全部運行的應用程序域的全部線程中的該文本。所以,只要在應用
程序進程中的任何位置處具備相同內容的字符串上放置了鎖,就將鎖定應用程序中該字符串的全部實例。
一般,最好避免鎖定 public 類型或鎖定不受應用程序控制的對象實例。例如,若是該實例能夠被公開訪問,
則 lock(this) 可能會有問題,由於不受控制的代碼也可能會鎖定該對象。這可能致使死鎖,即兩個或更多個線
程等待釋放同一對象。出於一樣的緣由,鎖定公共數據類型(相比於對象)也可能致使問題。並且lock(this)
只對當前對象有效,若是多個對象之間就達不到同步的效果。
lock(typeof(Class))與鎖定字符串同樣,範圍太廣了。
某些系統類提供專門用於鎖定的成員。例如,Array 類型提供 SyncRoot。許多集合類型也提供 SyncRoot。
而自定義類推薦用私有的只讀靜態對象,好比:
private static readonly object obj = new object();
爲何要設置成只讀的呢?這是由於若是在lock代碼段中改變obj的值,其它線程就暢通無阻了,由於互斥鎖的
對象變了,object.ReferenceEquals必然返回false。
參考資料:https://www.cnblogs.com/jintianhu/archive/2010/11/19/1881494.html
許多應用程序使用多個線程,但這些線程常常在休眠狀態中耗費大量的時間來等待事件發生。其餘線程可能進入休眠狀態,而且僅按期被喚醒以輪詢更改或更新狀態信息,而後再次進入休眠狀態。爲了簡 化對這些線程的管理,.NET框架爲每個進程提供了一個線程池,使應用程序可以根據須要來有效地利用多個線程。一個線程監視排到線程池的若干個等待操做的狀態。當一個等待操做完成時,線程池中 的一個輔助線程就會執行對應的回調函數。線程池中的線程由系統進行管理,程序員不須要費力於線程管理,能夠集中精力處理應用程序任務。
線程池是一種多線程處理形式,處理過程當中將任務添加到隊列,而後在建立線程後自動啓動這些任務。線程池線程都是後臺線程。每一個線程都使用默認堆棧大小,以默認的優先級運行,並處於多線程單元 中。若是某個線程在託管代碼中空閒(如正在等待某個事件),則線程池將插入另外一個輔助線程來使全部處理器保持繁忙。若是全部線程池線程都始終保持繁忙,但隊列中包含掛起的工做,則線程池將在 一段時間以後建立另外一個輔助線程。但線程的數目永遠不會超過最大值。超過最大值的其餘線程能夠排隊,但它們要等到其餘線程完成後才啓動。
線程池特別適合於執行一些須要多個線程的任務。使用線程池可以優化這些任務的執行過程,從而提升吞吐量,它不只可以使系統針對此進程優化該執行過程,並且還可以使系統針對計算機上的其餘進程 優化該執行過程。若是須要啓動多個不一樣的任務,而不想分別設置每一個線程的屬性,則可使用線程池。
若是應用程序須要對線程進行特定的控制,則不適合使用線程池,須要建立並管理本身的線程。
在如下幾種狀況下,適合於使用線程池線程:
(1)不須要前臺執行的線程。
(2)不須要在使用線程具備特定的優先級。
(3)線程的執行時間不易過長,不然會使線程阻塞。因爲線程池具備最大線程數限制,所以大量阻塞的線程池線程可能會阻止任務啓動。
(4)不須要將線程放入單線程單元。全部 ThreadPool 線程均不處於多線程單元中。
(5)不須要具備與線程關聯的穩定標識,或使某一線程專用於某一任務。
在多線程的程序中,常常會出現兩種狀況:一種是在應用程序中,線程把大部分的時間花費在等待狀態,等待某個事件發生,而後才能給予響應,這通常使用ThreadPool(線程池)來解決;另外一種狀況是 在線程平時都處於休眠狀態,只是週期性地被喚醒,這通常使用Timer(定時器)來解決。下面對ThreadPool類進行詳細說明。
ThreadPool類提供一個線程池,該線程池可用於發送工做項、處理異步 I/O、表明其餘線程等待以及處理計時器。該類提供一個由系統維護的線程池(能夠看做一個線程的容器),該容器須要Windows 2000以上系統支持,由於其中某些方法調用了只有高版本的Windows纔有的API函數。
下面介紹一下該類所提供的方法,如表1所示。
方法 |
描述 |
BindHandle |
將操做系統句柄綁定到ThreadPool |
GetAvailableThreads |
檢索由GetMaxThreads方法返回的最大線程池線程數和當前活動線程數之間的差值 |
GetMaxThreads |
檢索能夠同時處於活動狀態的線程池請求的數目。全部大於此數目的請求將保持排隊狀態,直到線程池線程變爲可用 |
GetMinThreads |
檢索線程池在新請求預測中維護的空閒線程數 |
QueueUserWorkItem |
將方法排入隊列以便執行。此方法在有線程池線程變得可用時執行 |
RegisterWaitForSingleObject |
註冊正在等待WaitHandle的委託 |
SetMaxThreads |
設置能夠同時處於活動狀態的線程池的請求數目。全部大於此數目的請求將保持排隊狀態,直到線程池線程變爲可用 |
SetMinThreads |
設置線程池在新請求預測中維護的空閒線程數 |
UnsafeQueueNativeOverlapped |
將重疊的 I/O 操做排隊以便執行 |
UnsafeQueueUserWorkItem |
註冊一個等待 WaitHandle 的委託 |
UnsafeRegisterWaitForSingleObject |
將指定的委託排隊到線程池 |
經過以上方法,能夠對線程池進行設置以及相應的操做,那麼,咱們何時使用線程池呢?咱們在用Thread類調用線程時,一次只能使用一個線程來建立和刪除線程,這種方式的創建和刪除線程對CPU 的使用是很頻繁的,爲了節省CPU的負荷,可使用線程池對線程進行操做,爲了使讀者更深刻的瞭解Thread類與ThreadPool類的差異。
在如下狀況下,應使用ThreadPool類:
ThreadPool類會在線程的託管池中重用已有的線程。使用完線程後,線程就會返回線程池,供之後使用。ThreadPool有25個可用的線程(每一個處理器)。
在使用線程池時,通常調用ThreadPool類的QueueUserWorkItem方法。
用戶並不須要自已創建線程,只須要把要進行的操做寫成函數,而後做爲參數傳遞給ThreadPool類的QueueUserWorkItem方法就好了,傳遞的方法是依靠WaitCallback代理對象,而線程的創建、管理、運 行等工做都是由系統自動完成的,用戶無須考慮那些複雜的細節問題。ThreadPool類的用法:首先程序建立了一個ManualResetEvent對象,該對象就像一個信號燈,能夠利用它的信號來通知其它線程
1.在多線程中線程池能夠減小咱們建立線程,併合理的複用線程池中的線程。由於在線程池中有線程的線程處於等待分配任務狀態。
2.沒必要管理和維護生存週期短暫的線程,不用在建立時爲其分配資源,在其執行完任務以後釋放資源。
3.線程池會根據當前系統特色對池內的線程進行優化處理。
咱們把任務交給線程池去完成後,沒法控制線程的優先級,設置線程的一些名稱等信息。[不過咱們能夠在放入線程池以前加一層來完善這些工做]
1 int workerThreads, completionPortThreads; 2 3 ThreadPool.GetMaxThreads(out workerThreads, out completionPortThreads); 4 Console.WriteLine("線程池中輔助線程的最大數目:{0}.線程池中異步 I/O 線程的最大數目:{1}", workerThreads, completionPortThreads); 5 6 ThreadPool.GetMinThreads(out workerThreads, out completionPortThreads); 7 Console.WriteLine("線程池根據須要建立的最少數量的輔助線程:{0}.線程池根據須要建立的最少數量的異步 I/O 線程:{1}", workerThreads, completionPortThreads); 8 9 //設置線程池默認參數 10 ThreadPool.SetMaxThreads(100, 100); 11 ThreadPool.SetMinThreads(2, 2); 12 13 ThreadPool.GetMaxThreads(out workerThreads, out completionPortThreads); 14 Console.WriteLine("線程池中輔助線程的最大數目:{0}.線程池中異步 I/O 線程的最大數目:{1}", workerThreads, completionPortThreads); 15 16 ThreadPool.GetMinThreads(out workerThreads, out completionPortThreads); 17 Console.WriteLine("線程池根據須要建立的最少數量的輔助線程:{0}.線程池根據須要建立的最少數量的異步 I/O 線程:{1}", workerThreads, completionPortThreads); 18 19 ThreadPool.GetAvailableThreads(out workerThreads, out completionPortThreads); 20 Console.WriteLine("可用輔助線程的數目:{0}.可用異步 I/O 線程的數目:{1}", workerThreads, completionPortThreads);
參考資料:http://www.javashuo.com/article/p-nfktvxku-ca.html
參考資料:http://www.javashuo.com/article/p-srrkwiew-bn.html
A、在這個應用程序的Global.asax文件中建立一個Application_Error過程去處理ASP.NET代碼錯誤。
B、在這個應用程序的Web.config文件中建立一個applicationError節去處理ASP.NET代碼錯誤。
C、在這個應用程序的Global.asax文件中建立一個CustomErrors事件去處理HTTP錯誤。
D、在這個應用程序的Web.config文件中建立一個CustomErrors節去處理HTTP錯誤。
E、在這個應用程序的每一頁中添加一個Page指示符去處理ASP.NET 代碼錯誤。
F、 在這個應用程序的每一頁中添加一個Page指示符去處理ASP.NET HTTP錯誤。
答案:CD
一、jQuery 事件 - ready() 方法
當 DOM(文檔對象模型) 已經加載,而且頁面(包括圖像)已經徹底呈現時,會發生 ready 事件。
因爲該事件在文檔就緒後發生,所以把全部其餘的 jQuery 事件和函數置於該事件中是很是好的作法。正如上面的例子中那樣。
ready() 函數規定當 ready 事件發生時執行的代碼。
ready() 函數僅能用於當前文檔,所以無需選擇器。
容許使用如下三種語法:
$(document).ready(function)
$().ready(function)
$(function)
二、window.onload和$(document).ready(function(){})的區別
一、執行時間上的區別:window.onload必須等到頁面內(包括圖片的)全部元素加載到瀏覽器中後才能執行。而$(document).ready(function(){})是DOM結構加載完畢後就會執行。
二、編寫個數不一樣:window.onload不能同時寫多個,若是有多個window.onload,則只有最後一個會執行,它會把前面的都覆蓋掉。$(document).ready(function(){})則不一樣,它能夠編寫多個,而且每個都會執行。
三、簡寫方法:window.onload沒有簡寫的方法,$(document).ready(function(){})能夠簡寫爲$(function(){})。
另外:因爲在$(document).ready()方法內註冊的事件,只要DOM就緒就會被執行,所以可能此時元素的關聯文件未下載完,例如與圖片有關的HTML下載完畢,而且已經解析爲DOM樹了,但頗有可能圖片還未加載完畢,因此例如圖片的高度和寬度這樣的屬性此時不必定有效。
要解決這個問題,可使用JQuery中另外一個關於頁面加載的方法---load()方法。load()方法會在元素的onload事件中綁定一個處理函數。若是處理函數綁定在元素上,則會在元素的內容加載完畢後觸發。如:$(window).load(function(){})=====window.onload = function(){}...
三、$(function(){}) 和 $(document).ready(function(){})
這兩個方法的效果都是同樣的,都是在dom文檔樹加載完以後執行一個函數,
一、
1 public class A 2 { 3 public A() 4 { 5 Print(); 6 } 7 public virtual void Print() 8 { 9
10 } 11 } 12 public class B : A 13 { 14 int x = 25; 15 int y; 16 public B() 17 { 18 y = -1; 19
20 } 21 public override void Print() 22 { 23 x = x + y; 24 y = x + 1; 25 Console.WriteLine("x={0},y={1}", x, y); 26 } 27 }
當使用 B b = new B(),輸出:25,26
當使用 B b = new B(),b.Print() 輸出: 24,25
參考資料:https://www.cnblogs.com/lhws/articles/1827330.html
一、using 命名空間名字。
例如:
using System
二、using別名
using 別名 = 包括詳細命名空間信息的具體的類型。
using aClass = NameSpace1.MyClass;
三、using語句
只要離開了這個代碼段就自動調用這個類實例的Dispose
using (MemoryStream ms = new MemoryStream(arr)) { }
參考資料:http://www.cnblogs.com/yuilin/archive/2011/10/28/2227881.html
在C#中推薦使用throw;來拋出異常;throw ex;會將到如今爲止的全部信息清空,認爲你catch到的異常已經被處理了,只不過處理過程當中又拋出新的異常,從而找不到真正的錯誤源。
第一種(不推薦使用,惋惜不少人都一直這麼用的,包括俺,嘻嘻),這樣適用會吃掉原始異常點,重置堆棧中的異常起始點:
try { } catch (Exception ex) { throw ex; }
第二種,可追溯到原始異常點,不過編譯器會警告,定義的ex未有使用:
try { } catch (Exception ex) { throw; }
第三種,不帶異常參數的,這個同第二種其實同樣,可捕獲全部類型的異常,IDE不會告警:
try { } catch { throw; }
第四種:通過對異常從新包裝,可是會保留原始異常點信息。推薦使用。
try { } catch (Exception ex) { throw new Exception("通過進一步包裝的異常", ex); }
例子:
1 class Program 2 { 3 static void Main(string[] args) 4 { 5 ExceptionClass ec = new ExceptionClass(); 6
7 try
8 { 9 ec.ExceptionThrow1(); 10 } 11 catch (Exception ex) 12 { 13 Console.WriteLine(ex.ToString()); 14 } 15
16 Console.WriteLine("---------------------------------------------------------------------"); 17
18 try
19 { 20 ec.ExceptionThrow2(); 21 } 22 catch (Exception ex) 23 { 24 Console.WriteLine(ex.ToString()); 25 } 26
27 Console.WriteLine("---------------------------------------------------------------------"); 28
29 try
30 { 31 ec.ExceptionThrow3(); 32 } 33 catch (Exception ex) 34 { 35 Console.WriteLine(ex.ToString()); 36 } 37
38 Console.WriteLine("---------------------------------------------------------------------"); 39
40 try
41 { 42 ec.ExceptionThrow4(); 43 } 44 catch (Exception ex) 45 { 46 Console.WriteLine(ex.ToString()); 47 } 48
49 Console.WriteLine("---------------------------------------------------------------------"); 50
51 Console.ReadKey(); 52 Console.WriteLine("------------"); 53
54
55 } 56 } 57 /// <summary>
58 /// 該Class用來測試異常拋出時相關上下文棧的調用狀況 59 /// </summary>
60 public class ExceptionClass 61 { 62 /// <summary>
63 /// 拋出異常方法 64 /// </summary>
65 public void ExceptionThrow1() 66 { 67 try
68 { 69 // 調用原始異常拋出方法來拋出異常
70 this.ExceptionMethod(); 71 } 72 catch (Exception ex) 73 { 74 throw ex; 75 } 76 } 77
78 /// <summary>
79 /// 拋出異常方法1 80 /// </summary>
81 public void ExceptionThrow2() 82 { 83 try
84 { 85 this.ExceptionMethod(); 86 } 87 catch (Exception ex) 88 { 89 throw; 90 } 91 } 92
93 /// <summary>
94 /// 拋出異常方法2 95 /// </summary>
96 public void ExceptionThrow3() 97 { 98 try
99 { 100 this.ExceptionMethod(); 101 } 102 catch
103 { 104 throw; 105 } 106 } 107
108 /// <summary>
109 /// 拋出異常方法3 110 /// </summary>
111 public void ExceptionThrow4() 112 { 113 try
114 { 115 this.ExceptionMethod(); 116 } 117 catch (Exception ex) 118 { 119 throw new Exception("通過進一步包裝的異常", ex); 120 } 121 } 122
123 /// <summary>
124 /// 原始異常拋出方法 125 /// </summary>
126 private void ExceptionMethod() 127 { 128 throw new DivideByZeroException(); 129 } 130 }
運行結果:
從運行的結果能夠看到,第一種用法已經吃掉了原始異常信息。而其它3種用法均可以追溯到原始異常,推薦使用第四種用法
參考資料:http://www.cnblogs.com/JerryTian/archive/2012/09/24/2699459.html
1、什麼是Web Service
1. 什麼是Web Service呢?從表面上看,WebService就是一個應用程序,它向外界暴露出一個可以經過Web進行調用的API。這就是說,你可以用編程的方法經過Web調用來實現某個功能的應用程序。從 深層次上看,Web Service是一種新的Web應用程序分支,它們是自包含、自描述、模塊化的應用,能夠在網絡(一般爲Web)中被描述、發佈、查找以及經過Web來調用。
2.Web Service即是基於網絡的、分佈式的模塊化組件,它執行特定的任務,遵照具體的技術規範,這些規範使得Web Service能與其餘兼容的組件進行互操做。它可使用標準的互聯網協議,像超文本傳 輸協議HTTP和XML,將功能體如今互聯網和企業內部網上。WebService平臺是一套標準,它定義了應用程序如何在Web上實現互操做性。你能夠用你喜歡的任何語言,在你喜歡的任何平臺上寫Web Service。
3.WebService 爲Internet 上的組件服務•經過網絡提供,以URL 定位方法調用•以Internet技術爲基礎•未來的分散式應用程序
2、Web Service的標準
1. SOAP(Simple Object Access Protocol)
2. UDDI(UnviversalDescription ,Discovery,andIntegration) 統一描述發現和集成協議–公開的,或是企業本身的註冊與查詢
3. WSDL(Web Service Description Language)–WebService 描述語言
3、Web Service的標準
1. XMLWeb Service 經過標準的Web 協議向Web 用戶提供有用的功能。多數狀況下使用SOAP 協議。
2. XMLWeb Service 能夠很是詳細地說明其接口,這使用戶可以建立客戶端應用程序與它們進行通訊。這種說明一般包含在稱爲Web 服務說明語言(WSDL)文檔的XML 文檔中。
3. XMLWeb Service 已通過註冊,以便潛在用戶可以輕易地找到這些服務,這是經過通用發現、說明和集成(UDDI)來完成的。
4.XMLWeb Service 體系結構的主要優勢之一是:容許在不一樣平臺上、以不一樣語言編寫的各類程序以基於標準的方式相互通訊。
5.咱們將XMLWeb Service 定義爲:經過SOAP 在Web 上提供的軟件服務,使用WSDL 文件進行說明,並經過UDDI 進行註冊。
4、SOAP
•Soap 是XML Web Service 的通訊協議。
•SOAP 是一種規範,用來定義消息的XML 格式 。包含在一對SOAP 元素中的、結構正確的XML 段就是SOAP 消息。
•SOAP 規範的其餘部分介紹如何將程序數據表示爲XML,以及如何使用 SOAP 進行遠程過程調用 (RPC)。這些可選的規範部分用於實現 RPC 形式的應用程序,其中客戶端將發出一條 SOAP 消息(包含可調用函數,以及要傳送到該函數的參數),而後服務器將返回包含函數執行結果的消息。目前,多數 SOAP 實現方案都支持 RPC 應用程序。SOAP 還支持文檔形式的應用程序,在這類應用程序中,SOAP 消息只是 XML 文檔的一個包裝。文檔形式的 SOAP 應用程序很是靈活,許多新的 XML Web Service 都利用這一特色來構建使用 RPC 難以實現的服務
5、SOAP
•SOAP 規範的最後一個可選部分定義了包含SOAP 消息 的 HTTP 消息的樣式。此 HTTP 綁定很是重要,由於幾乎全部當前的OS(以及許多之前的 OS)都支持HTTP. HTTP 綁定雖然是可選的,但幾乎全部 SOAP 實現方案都支持HTTP 綁定,由於它是SOAP 的惟一標準協議。因爲這一緣由,人們一般誤認爲 SOAP 必須使用 HTTP。其實,有些實現方案也支持 MSMQ、MQ 系列、SMTP 或 TCP/IP 傳輸,但因爲 HTTP 很是廣泛,幾乎全部當前的XML Web Service 都使用它。因爲 HTTP 是 Web的核心協議,所以大多數組織的網絡基礎結構都支持HTTP。
• 到目前爲止,SOAP 最引人注目的特徵是它能夠在許多不一樣的軟件和硬件平臺上實現。這意味着SOAP 可用於連接企業內部和外部的不一樣系統。
• HTTP 的普及和SOAP 的簡單性使您幾乎能夠從任何環境調用它們,所以成爲XMLWeb Service 的理想基礎。 SOAP 的用戶並不直接編寫SOAP 消息,而是使用SOAP 工具包來建立和分析SOAP 消息。這些工具包一般將函數調用從某種語言轉換爲SOAP 消息。
5、UDDI
•UDDI 目錄條目是介紹所提供的業務和服務的XML 文件。UDDI 目錄條目包括三個部分。
「白頁」介紹提供服務的公司:名稱、地址、聯繫方式等等;
「黃頁」包括基於標準分類法的行業類別;
「綠頁」詳細介紹了訪問服務的接口,以便用戶可以編寫應用程序以使用 Web 服務。
服務的定義是經過一個稱爲類型模型(或 tModel)的 UDDI文檔來完成的。多數狀況下,tModel包含一個WSDL 文件,用於說明訪問 XMLWeb Service 的SOAP 接口,可是tModel很是靈活,能夠說明幾乎全部類型的服務。
•UDDI 目錄還包含若干種方法,可用於搜索構建您的應用程序所需的服務。例如,您能夠搜索特定地理位置的服務提供商或者搜索特定的業務類型。以後,UDDI目錄將提供信息、聯繫方式、連接和技術數據,以便您肯定能知足須要的服務。
•UDDI 容許您查找提供所需的Web 服務的公司。若是您已經知道要與誰進行業務合做,但尚不瞭解它還能提供哪些服務,這時該如何處理呢?WS-Inspection規範(英文)容許您瀏覽特定服務器上提供的XML Web Service 的集合,從中查找所需的服務。
5、wsdl
•Web Service Description Language (WSDL):用來定義WebService交換的文件格式以及提供服務方式的說明文件
•WSDL 表示 Web服務說明語言,是一個 XML文檔,用於說明一組 SOAP 消息以及如何交換這些消息。WSDL對於 SOAP 的做用就象TLD 對於Tiglib的做用。因爲WSDL 是 XML 文檔,所以很容易進行閱讀和編輯;但大多數狀況下,它由軟件生成和使用。
•要查看 WSDL 的值,能夠假設您要調用由您的一位業務夥伴提供的SOAP 方法。您能夠要求對方提供一些 SOAP消息示例,而後編寫您的應用程序以生成並使用與示例相似的消息。WSDL 經過明確的表示法指定請求消息必須包含的內容以及響應消息的樣式。
•WSDL 文件用於說明消息格式的表示法以XML 架構標準爲基礎,這意味着它與編程語言無關,並且以標準爲基礎,所以適用於說明可從不一樣平臺、以不一樣編程語言訪問的XML Web Service 接口。除說明消息內容外,WSDL 還定義了服務的位置,以及使用什麼通訊協議與服務進行通訊。WSDL 文件定義了編寫使用 XML Web Service 的程序所需的所有內容。
•當前,許多 SOAP工具包都包括從現有程序接口生成 WSDL 文件的工具,但卻幾乎沒有直接用於編寫WSDL 的工具,並且 WSDL的工具支持也很不完整。但不久就會出現編寫 WSDL 文件的工具,接着還會有生成代理和存根的工具(與 COMIDL 工具很類似),這些工具將成爲多數SOAP 實現方案的一部分。到那時,WSDL將成爲建立 XML Web Service 的 SOAP接口的首選方法。 •由W3C制定的標準