消费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端
有一个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;
}
1、 TwoWayMethod方法
方法签名：public string[] TwoWayMethod(float a,Person person)
有两个输入参数：简单类型float 和自定义的类Person。Person类有三个公开字段，其中有一个字段的类型是自定义类型Contact，Contact类又包括四个公开字段。
返回参数为一个字符串的数组。
2、 查看web services的WSDL
一个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的结构需要按照从下面往上面的顺序看。
2.1. portType标签
portType标签用来描述整个的web services，portType的name属性即为这个web services类的类名。这个标签下包含了所有的可用方法，每个operation标签表示一个方法。
2.2. operation标签
每一个operation标签表示web services里的一个webmethod方法，operation标签的name属性是这个webmethod的方法名。
2.3. Input和output标签
Input和output标签分别表示一个operation（webmethod方法）的输入和输出的参数集合，这里叫做消息，不管输入参数有几个，每个参数有多么复杂，只有一个表示这些输入参数的消息，就是input标签的message属性表示的那个消息。对于输出消息也一样。
2.4. Message标签
方法的输入输出参数都用一个消息来表示，message标签表示一个这样的消息，message标签按下面有个part标签，用来具体指示这个消息在schema中的类型，类型以element形式表现出来，即part标签的element属性指定的那个element。
对于输入参数消息，part标签的element属性命名同webmethod方法名。
对于输出参数消息，part标签的element属性命名同webmethod方法名 + response。
表示类型的element都被集中放置在types标签内。
2.5. 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:element minOccurs="0" maxOccurs="1" name="person" type="tns:Person" />
</s:sequence>
</s:complexType>
</s:element>
其中a元素是简单的float类型，不需要另加说明。
person元素是Person类型，Person类型又是个complex类型，在types标签里还包括了这个Person类型的定义。只要是消息中引用到的非简单类型，都需要在types中进行定义描述。
二、 Biztalk消费Web services的一般方法
这个Web services中的TwoWayMethod方法是个比较复杂的方法，具有两个输入参数，其中一个参数是自定义的类，并且嵌套了另一个自定义的类，返回的参数也是字符型的数组，相对比较复杂。
1、 新建biztalk项目
新建一个biztalk项目，用来测试Web services的TwoWayMethod方法。
2、 引用Web services
跟一般的应用项目要调用一个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架构文件。分别看一下这两类文件都生成了什么。
2.1. xsd架构文件
2.1.1. 每个复杂参数类型被生成一个schema文件
web services中的每个webmethod的参数，不管是输入参数还是输出参数，只要不是简单数据类型，每个参数类型就会被生成一个schema文件，所有类型都将都被转成schema类型，这就意味着，参数类型必须是可以被xml序列化的。
public string[] TwoWayMethod(float a,Person person)
这个webmethod方法，参数person和返回的string[]类型的参数都不是简单数据类型，所以这两个参数类型分别被形成schema文件，表现为在Reference.map下的Reference.xsd和Reference1.xsd文件。
2.1.2. 简单参数类型不需要生成schema
简单数据类型（int、string、float等等）这些schema本身支持的简单类型，不需要另外用schema进行定义。比如上面那个webmethod方法中的a参数。
2.2. odx流程文件
Figure 3. biztalk项目引用web services后形成的odx流程文件
引用web services后形成的odx流程文件是把web services的方法转变成orchestration的端口类型和消息类型，实际上反映的也就是每个webmethod的方法签名。
2.2.1. Web Port
一个web端口类型代表了一个web services的类。
每个端口类型下可以有多个操作（operation），每个操作就是web services的类里的一个webmethod方法。
每个操作都有两个消息，分表表示输入消息Request，输出消息Response。不管输入参数或输出参数有多少，所有的输入参数都被放入到一个消息中，同样所有的输出参数也都被放入到一个消息中。
每个消息都是一个多部分消息类型。这些多部分消息类型由Web Message Types部分定义。
注意：
如果webmethod方法没有返回值（void），webmethod仍要生成返回消息，在biztalk的web 端口类型中仍要生成返回的response部分。
2.2.2. Web Message Types
Web消息类型定义web端口的每个操作使用的消息，都为多部分消息。
如果一个操作的输入参数有多个参数，则每个参数在多部分消息中作为一个消息部分出现。
每个参数的参数名就是消息中一个消息部分的部分名。
Webmethod方法的retuen返回参数没有名称，默认就是“Webmethod方法名＋Result”做为消息部分名。
注意：
如果webmethod方法没有返回值（void），webmethod的response部分对应的web多部分消息类型，就是一个只有消息上下文而没有消息部分的web消息类型。
2.3. 引用web services后的作用
Biztalk项目引用web services形成的odx流程文件是只读的，不能单独使用这个odx文件。Odx的作用是在新建的自定义orchestration流程中，这个odx的web端口类型和web消息类型都会被自动的加入到进去，只是这些端口类型和消息类型不能被修改。
在自定义orchestration流程中要消费引用的web services的webmethod就需要使用这些端口类型，通过这些类型的端口跟物理soap的发送端口绑定。
2.4. biztalk项目引用web services不生成代理类吗？
这是个问题，一般的应用项目在引用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同样也是需要通过这个代理类来调用（后面还会继续谈到这个问题）。
3、 建立orchestration消费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:postalcode>10</ns0:postalcode>
</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端口写入到另一个文件夹。
4、 部署设置消费web services的biztalk项目
编译部署biztalk项目。
部署好后，查看项目配置，可以看到消费web services的双向发送端口来已经跟一个SOAP发送端口绑定。
剩下的添加两个file适配器的端口，分别设置为读取person xml文件的输入端口和保存最后结果的发送端口。
5、 SOAP端口的设置
一般按照部署后的默认配置，这个SOAP已经能够很好的工作了，但是为了更深一步的了解SOAP端口，来看看SOAP端口的各个设置。
5.1. General标签
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传送身份验证》。
5.2. Proxy标签
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端口使用的代理服务器。
5.3. Web services 标签
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规范的。
但是实际测试这个选项好像不起作用。