导 读：SOAP Toolkit 是微软提供的快速开发网络服务（Web Services）的工具包。本文提供了一些包括SOAP Toolkit 各个版本以及.NET 框架和Visual Studio.NET的资料，并告诉我们怎样去选择一个在现在和将来都非常适合你的微软SOAP Toolkit 版本。
翻译整理：51dotnet.com（微软.net技术网）
原文出处：http://msdn.microsoft.com/xml/general/soap1and2tech.asp
选择1.0版本或2.0版本
在选择SOAP Toolkit 版本前，请先在下边的三个选项中选择你自己是属于哪一类情况：
1．你已经打算要发布一个基于微软的SOAP Toolkit 1.0版本的网络服务（Web Services）产品。
2．你还在创建一个网络服务（Web Services）产品过程的早期。
3．你处于网络服务（Web Services）技术的评估阶段。
如果你是第一种情况，那么就不应该使用微软SOAP Toolkit 1.0版本代码样本，它只会使你的工作停止（或减慢），你应该用12月份发布的微软SOAP Toolkit 1.0版本，这个版本在稳定性和可执行性上都有所提高。如果你的一些服务客户正在使用基于微软的.NET 框架和Visual Studio.NET Beta 1客户程序，你也需要使用12月份发布的产品。一旦你能这样做，你就应该计划转移到微软支持的SOAP框架——或者是为应用程序设计的微软SOAP Toolkit 2.0版本，这个版本将于2001年秋季前或者在Visual Studio .NET和.NET框架正式发布前发布。当然，一旦它发布后而你却不能将之运用到已存在服务中的话，你将需要在并行方案中转移以维护你已存在的服务。使用同样的标准来讨论第二和第三种情况，你同样要考虑是否要转移到微软的SOAP的Toolkit 2.0版本还是到.NET框架和Visual Studio .NET。
如果你是第二种情况，处于创建网络服务（Web Services）产品过程的早期。你预期在2001年秋季将产品投放市场，你就需要决定是否能接受，与选择SOAP Toolkit 2.0版本技术相比，选择这些新的.NET产品的BETA 2版本去发布你的服务所要承担的风险。微软的SOAP Toolkit 2.0版本采用了网络发布方式，你可以期望在2001年秋天以前得到多次更新。另外一个方面，如果你的服务代码是基于.NET技术的话，你能得到生产力和战略上的优势，因为.NET技术代表了微软的一个SOAP的下部结构的长期投资。
如果你是第三种情况，并且仍在评估网络服务（Web Services）的潜力，那么你应该考虑不使用任何版本的SOAP Toolkit 去创造你的网络服务（Web Services）。这是因为微软为网络服务（Web Services）而提供一个快速的软件应用开发环境的长期战略是.NET和Visual Studio .NET，而你能等待我们继续我们的投资，使这些产品用最有效的生产方式去创建和使用网络服务（Web Services）。
从1.0版本转移到2.0版本
转换你的代码
微软SOAP Toolkit 1.0版本的开发者很少碰到类似于移植基于ROPE.Proxy对象的客户端代码到高级的2.0版本接口这样的问题。在这里仅仅众所周知的问题是在2.0版本中暂时缺少对客户端证书的支持——你需要去彻底除去那些使用12月份发布的1.0版本特性的代码。客户端证书将在最后发布的2.0 版本中被支持。
微软的SOAP Toolkit 1.0版本的开发者通过客户端代码使用低层的ROPE. Packager接口和直接访问SOAP消息的相关特性，将在2.0版本的低层接口中进一步改进这项任务的灵活性和程序可用性。同样的，那些使用ROPE.WireTransfer的开发者将会发现一个改进后的2.0版本的体系框架，它允许插入不同的连接器去连接SOAP端点并在它们之间传输消息，就象不同协议的处理器一样。不幸地，所有这些提高需要重写大部分或所有的低层代码。
那些使用ISAPI 监听器的微软SOAP Toolkit 1.0版本的开发者不会发现其和2.0版本、Visual Studio .NET BETA1版本有相同之处。你现在应该使用2.0版本中的ASP监听器，而 ISAPI监听器最终将包括在最后的版本中。微软SOAP Toolkit 2.0版本中的网络服务元语言(WSML)文件达到了类似于微软SOAP Toolkit 1.0版本的ISAPI 监听器使用的.SOD文件把消息名字映射到PROGID的目的。这种机制可以使单个的、普通的监听器为多种服务所使用；不象1.0版本的ASP监听器，如果使用2.0版本的ASP监听器也需要WSML文件。
另外，那些使用ISAPI监听器的微软SOAP Toolkit 1.0版本开发者需要移植glue代码，把它们添加到自动生成的interface. Asp中。
服务描述格式
微软SOAP Toolkit 1.0版本、.NET框架和Visual Studio.NET Beta 1是以旧的服务描述语言（SDL）来描述网络服务（Web Services）的功能的。微软SOAP Toolkit 2.0版本、.NET框架和Visual Studio.NET Beta 2版本支持新的WSDL服务描述格式。为了一个能支持那些要求WSDL合同的客户的服务，你需要移植到微软SOAP Toolkit 2.0版本或.NET框架和Visual Studio.NET Beta 2。在变迁的过程中，你需要去支持客户期望的SDL或WSDL服务合同，微软正在评估提供一个SDL到WSDL的“编译器”的可行性。这个编译器将允许使用微软SOAP Toolkit 2.0版本客户端去访问使用SOAP Toolkit 1.0版本或.NET框架和Visual Studio.NET创建的服务。如果这能帮助你移植到微软SOAP Toolkit 1.0版本，请访问如下地址news://msnews.microsoft.com/microsoft.public.xml.soapsdk.
XML Schema格式
微软SOAP Toolkit 1.0版本，.NET框架和Visual Studio.NET Beta 1是以旧的XML-DATA REDUCED（XDR）Schema格式为基础的。微软SOAP Toolkit 2.0版本或.NET框架和Visual Studio.NET Beta 2版本支持新的被W3C所提议的XML Schema定义（XSD）格式。
Schema格式是和服务描述相关的，在这里使用XDR定义SDL，而WSDL使用XSD。特别的是，XML原始的数据类型或被输入或输出参数类型的使用者定义Schema，必须在期望的XDR或XSD格式中指定。由于两个Toolkit 都可以用工具去生成服务描述，这仅仅对那些手写代码文件的开发者重要。
只要是SOAP Toolkit 1.0版本所支持的XML原始数据类型，微软SOAP Toolkit 2.0版本都支持。同样的，这些普通的原始数据类型映射了与之相对应的COM变量类型。
字符设置
用Windows code page 1252中的字符串变量编制的8位 ANSI字符来测试微软SOAP Toolkit 1.0版本。因为SOAP Toolkit 1.0版本信息序列化没有在XML声明中指定字符编码，缺省的SOAP信息是UTF-8编码(包括所有信息中的字符串变量)。实际上SOAP Toolkit 1.0版本是使用了UTF-8字符串编码（包括UTF-8字符的子集），而UTF-8编码与在Windows code page 1252中的8位ANSI编码是不能区别的。
SOAP Toolkit 2.0版本则可以同时接受UTF-8和UTF-16字符串编码，因此你使用SOAP Toolkit 1.0编写的使用Windows code page 1252中的8位ANSI编码的客户端程序在SOAP Toolkit 2.0版本中能够继续使用。
在SOAP Toolkit 2.0版本中的服务器端信息发送代码将会传送字符串到UTF-16码制的BSTR变量中。如果你的服务器端代码要求有8位的ANSI编码去编写，你将需要移植到SOAP Toolkit 2.0版本，它将更新你的编码到UTF-16码制。
总结
我们希望几乎每一个人都能马上开始使用微软的SOAP Toolkit 2.0版本，用来建立网络服务（Web Services）。随着开发者的支持，一个具有特色的扩展集和一个设计完美的体系结构的微软SOAP Toolkit 2.0版本已经为取代微软SOAP Toolkit 1.0版本作好准备。
我们知道，一些人还不能马上方便地从SOAP Toolkit 1.0版本转换过来，并且采用微软SOAP Toolkit 2.0版本将会是一个移植的过程。
本文地址：http://com.8s8s.com/it/it46354.htm