消費Web services允許把現有的Web services加入到業務流程，可以在一個orchestration整合進多個Web services。
可以在orchestration用Web ports消費（調用）Web service，為了在orchestration調用一個Web service，需要建立一個Web port和構造一個Web messages
本文以一個比較典型的實例來說明biztalk如何消費一個web services，深入分析biztalk消費web services的一些內部機制。
有一個Web services，很簡單，代碼如下：
[WebService(Namespace = "http://chnking.com/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class SAMPLEService : System.Web.Services.WebService
{
[WebMethod]
public string[] TwoWayMethod(float a,Person person)
{
return new string[] { "1", "2", "3","4" };
}
}
public class Person
public string firstname;
public string lastname;
public Contact contact;
}
public class Contact
{
public string telpohone;
public string fax;
public string address;
public int postalcode;
}
方法簽名：public string[] TwoWayMethod(float a,Person person)
有兩個輸入參數：簡單類型float 和自定義的類Person。Person類有三個公開字段，其中有一個字段的類型是自定義類型Contact，Contact類又包括四個公開字段。
返回參數為一個字符串的數組。
一個web services要被其它應用調用，就必須告訴其它應用如何去調用web services中的webmethod，比如這個web services中包含哪些可以調用的方法，每個方法的方法簽名是怎樣的，方法是用的輸入輸出參數的類型又是什麼等等，這些都是通過web services的WSDL來進行描述的。
要查看一個web services的WSDL可以向web services所在的asmx文件的URL發送http請求，並附帶?wsdl參數即可，比如：http://biztalkr2:81/WSTest/Service1.asmx?WSDL
來查看一下上面這個web services的WSDL中跟TwoWayMethod相關的部分：
Figue 1. WSDL中跟TwoWayMethod相關的部分
這個WSDL的結構需要按照從下面往上面的順序看。
portType標簽用來描述整個的web services，portType的name屬性即為這個web services類的類名。這個標簽下包含了所有的可用方法，每個Operation標簽表示一個方法。
每一個operation標簽表示web services裡的一個webmethod方法，Operation標簽的name屬性是這個webmethod的方法名。
Input和output標簽分別表示一個Operation（webmethod方法）的輸入和輸出的參數集合，這裡叫做消息，不管輸入參數有幾個，每個參數有多麼復雜，只有一個表示這些輸入參數的消息，就是input標簽的message屬性表示的那個消息。對於輸出消息也一樣。
方法的輸入輸出參數都用一個消息來表示，message標簽表示一個這樣的消息，message標簽按下面有個part標簽，用來具體指示這個消息在schema中的類型，類型以element形式表現出來，即part標簽的element屬性指定的那個element。
對於輸入參數消息，part標簽的element屬性命名同webmethod方法名。
對於輸出參數消息，part標簽的element屬性命名同webmethod方法名 + response。
表示類型的element都被集中放置在types標簽內。
此標簽用來描述所有webmethod所要用到的類型，都以element來描述類型。比如：
public string[] TwoWayMethod(float a,Person person)
這個webmethod的輸入參數有兩個：float a,Person person，在WSDL的中的類型表現是這樣的：
<s:element name="TwoWayMethod">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="a" type="s:float" />
</s:sequence>
</s:complexType>
</s:element>
其中a元素是簡單的float類型，不需要另加說明。
person元素是Person類型，Person類型又是個complex類型，在types標簽裡還包括了這個Person類型的定義。只要是消息中引用到的非簡單類型，都需要在types中進行定義描述。
這個Web services中的TwoWayMethod方法是個比較復雜的方法，具有兩個輸入參數，其中一個參數是自定義的類，並且嵌套了另一個自定義的類，返回的參數也是字符型的數組，相對比較復雜。
新建一個biztalk項目，用來測試Web services的TwoWayMethod方法。
跟一般的應用項目要調用一個Web services一樣，首先在項目中引用這個Web services。但是在biztalk項目中引用一個Web services跟一般的應用引用Web services表現不一樣。
Figure 2. biztalk項目和Windows項目引用同一個web services的不同表現
Windows項目引用web services後，在引用目錄下Reference.map生成一個Reference.cs文件，這個文件是被引用的web services在本地生成的代理類，派生自System.Web.Services.Protocols.SoapHttpClIEntProtocol類。
Biztalk項目引用web services後，在引用目錄Reference.map下生成兩類文件，一個odx類型的orchestration文件，和數量不定的xsd架構文件。分別看一下這兩類文件都生成了什麼。
web services中的每個webmethod的參數，不管是輸入參數還是輸出參數，只要不是簡單數據類型，每個參數類型就會被生成一個schema文件，所有類型都將都被轉成schema類型，這就意味著，參數類型必須是可以被XML序列化的。
public string[] TwoWayMethod(float a,Person person)
這個webmethod方法，參數person和返回的string[]類型的參數都不是簡單數據類型，所以這兩個參數類型分別被形成schema文件，表現為在Reference.map下的Reference.xsd和Reference1.xsd文件。
簡單數據類型（int、string、float等等）這些schema本身支持的簡單類型，不需要另外用schema進行定義。比如上面那個webmethod方法中的a參數。
Figure 3. biztalk項目引用web services後形成的odx流程文件
引用web services後形成的odx流程文件是把web services的方法轉變成orchestration的端口類型和消息類型，實際上反映的也就是每個webmethod的方法簽名。
一個web端口類型代表了一個web services的類。
每個端口類型下可以有多個操作（Operation），每個操作就是web services的類裡的一個webmethod方法。
每個操作都有兩個消息，分表表示輸入消息Request，輸出消息Response。不管輸入參數或輸出參數有多少，所有的輸入參數都被放入到一個消息中，同樣所有的輸出參數也都被放入到一個消息中。
每個消息都是一個多部分消息類型。這些多部分消息類型由Web Message Types部分定義。
Web消息類型定義web端口的每個操作使用的消息，都為多部分消息。
如果一個操作的輸入參數有多個參數，則每個參數在多部分消息中作為一個消息部分出現。
每個參數的參數名就是消息中一個消息部分的部分名。
Webmethod方法的retuen返回參數沒有名稱，默認就是“Webmethod方法名＋Result”做為消息部分名。
Biztalk項目引用web services形成的odx流程文件是只讀的，不能單獨使用這個odx文件。Odx的作用是在新建的自定義orchestration流程中，這個odx的web端口類型和web消息類型都會被自動的加入到進去，只是這些端口類型和消息類型不能被修改。
在自定義orchestration流程中要消費引用的web services的webmethod就需要使用這些端口類型，通過這些類型的端口跟物理soap的發送端口綁定。
這是個問題，一般的應用項目在引用web services後會生成一個從System.Web.Services.Protocols.SoapHttpClIEntProtocol類繼承的本地代理類，應用程序通過調用代理類來調用web services。
但是從上面biztalk引用web services的過程，在生成的引用文件中似乎沒有發現生成本地代理類。是不是biztalk引用web services並不生成本地代理類呢？
我們來分別看一下Windows應用項目和biztalk項目引用這個web services後生成的惡exe和dll裡的內容。
Figure 4. 用ildasm看Windows應用項目引用web services後的exe文件
Windows應用引用web services後，在引用web services的名稱空間下生成本地代理類，代理類的名稱跟web services類名一樣。
除了代理類，webmethod方法中用到的參數如果不是簡單的數據類型，也會在本地生成參數類型（參數類型在WSDL中以schema形式描述），Windows項目引用web services會把參數類型從schema形成轉成class類形式。
Figure 5. 用ildasm看biztalk項目引用web services後的dll文件
可以看到，biztalk項目引用web services後，在生成的dll中同樣有繼承自System.Web.Services.Protocols.SoapHttpClIEntProtocol的本地代理類，說明biztalk項目引用web services後也要生成本地代理類，並且biztalk如果調用web services同樣也是需要通過這個代理類來調用（後面還會繼續談到這個問題）。
設計一個流程消費上述的那個web services。
Figure 6. 消費web services的orchestration
流程很簡單，Port_1從一個文件夾中讀取Person格式的XML文件：
<ns0:Person XMLns:ns0="http://chnking.com/">
<ns0:firstname>firstname_0</ns0:firstname>
<ns0:lastname>lastname_0</ns0:lastname>
<ns0:contact>
<ns0:telpohone>telpohone_0</ns0:telpohone>
<ns0:fax>fax_0</ns0:fax>
<ns0:address>address_0</ns0:address>
</ns0:contact>
</ns0:Person>
賦值形狀MessageAssignment_1把讀取進來的person消息賦給要發送到web services的多部分消息的person消息部分，同時給多部分消息的a消息賦一個浮點數的值：
Message_WSRequest.a = (System.Single)3.1416;
Message_WSRequest.person = Message_person;
建立消費web services的端口。
新建一個端口，端口類型選引用web services後生成的那個web端口類型。如圖所示：
Figure 7. 新建消費web services的端口
綁定方式默認為現在指定，biztalk會把引用web services的URI和需要采用的SOAP適配器記錄下來，部署後根據這些信息生成物理SOAP發送端口並跟這個雙向發送端口綁定。
Figure 8. 雙向發送端口的綁定
從web services返回的消息通過Port_2端口寫入到另一個文件夾。
編譯部署biztalk項目。
部署好後，查看項目配置，可以看到消費web services的雙向發送端口來已經跟一個SOAP發送端口綁定。
剩下的添加兩個file適配器的端口，分別設置為讀取person XML文件的輸入端口和保存最後結果的發送端口。
一般按照部署後的默認配置，這個SOAP已經能夠很好的工作了，但是為了更深一步的了解SOAP端口，來看看SOAP端口的各個設置。
Figure 9. SOAP端口的General標簽設置
Web services URL:
引用web services的URL
Authentication type：
web services方的驗證方式。
Anonymous – 匿名驗證，web services服務端允許匿名訪問可以設置為Anonymous。
Basic – 基本身份驗證，web services服務端采用基本身份驗證時采用，需要客戶端提供用戶名和密碼，在Credentials中輸入用戶名和密碼。此用戶名和密碼被轉換成base64編碼連同SOAP的http請求一起發送到服務端。
NTLM – 在web services服務端設置了windows集成驗證時采用，Windows集成驗證的客戶端可以選用NTLM驗證和Kerberos兩種驗證方式，但SOAP只使用NTLM驗證，並且使用客戶端登錄帳戶的用戶名和密碼進行驗證憑據的傳送。關於IIS的身份驗證的詳細討論請參看《IIS的各種身份驗證詳細測試》《應用程序向IIS傳送身份驗證》。
Figure 10. SOAP端口的Proxy標簽設置
用於設置訪問web services是否要使用代理服務器。
Use Handler’s default proxy configuration ：
使用SOAP handler級別的代理設置。
在Biztalk Group下打開Platform Setting目錄，在其下選擇Adapters，展開，所有的適配器都列在其中，選擇SOAP，看右邊窗口的顯示。
雙擊發送handler的那一條，在彈出的SOAP – Adapter Handler Properties窗口中，點PropertIEs按鈕，在這裡設置handler級別的代理設置，如下圖：
Figure 11. SOAP端口handler級別的Proxy設置
Dot not use proxy：
調用web services不使用代理服務器。
Use proxy：
設置這個SOAP端口使用的代理服務器。
Figure 12. SOAP端口的Web services標簽設置
這個標簽設置使用哪個代理類訪問實際的web services。
SOAP端口也是需要使用從SoapHttpClIEntProtocol繼承的本地代理類訪問web services。這裡就是指定使用哪個代理類的。
Orchestration Web port：
Biztalk項目引用web services後形成了web端口類型和web消息類型，這些在biztalk項目編譯後就會生成一個本地代理類，跟一般Windows項目引用web services後形成的代理類基本一致。本設置就是選擇這個SOAP使用引用biztalk項目編譯後自己形成的代理類。
The following setting：
選擇其他的代理類，但是這個代理類必須是從SoapHttpClIEntProtocol繼承的。
Assembly name： 包含了代理類的assembly
Type name：在assembly中選擇這個SOAP適配器要使用的那個代理類
Method name： 選擇這個SOAP要調用的web services中的方法。
Use SOAP 1.2：
設置發送到web services服務端的SOAP消息使用SOAP1.2規范的。
但是實際測試這個選項好像不起作用。
