想象一下，你的CEO刚与他的对手共进午餐回来，他的脑子里充满了关于Web服务的其思妙想，而且他可能还会想将你的应用软件改变成作为Web服务来换取大量的资金。但障碍是你的工作团队仍然紧固地确立在VB6之上而没有可行的移植计划。
这听起来可能无法想象，但是我知道很多的公司的运作模式是“先卖出去，然后再去实现”的做法，我确信与此类似的情景现在就会发生在某地某人身上。怎么办？保持冷静并看一下Microsoft's SOAP toolkit 。除了少数的例外情况，它可以非常容易地实现像真实的Web服务那样的运行现有的COM功能。
如果当你听到SOAP的时候想到的是“香波”，那你该清醒一下了，SOAP代表Simple Object Activation Protocol，他指定当一个客户应用程序请求在远程服务器上激活一个对象并进行工作时要用到的消息格式。SOAP只指定与服务器往来之消息的格式，他不指定这些消息如何到达他们所到去的地方。大多数时间，HTTP是SOAP消息的传输协议，就是说Web服务器涉及到hosting远程对象或递送请求至真实主机。
SOAP Toolkit为客户提供了两种应用软件编程界面(APIs)来利用Web服务进行工作：高级API和低级API。高级API提供了一个代理对象来给客户应用程序一个信号，使它在本地存储对象上确实产生调用。低级API要求程序员人工地建构并解码与服务器之间往来的SOAP消息。很明显，高级API更加的方便一些。但他并不提供低级API中所具有的对处理过程直接控制。然而这在进入Web服务而不是COM组件进行现有客户代码的二次工作时是很有用的。
从服务器组件的角度来讲，工具包实际上是透明的。他为COM服务提供了完全的包装。在一些情况下，你可以通过简单地回答向导提出的问题来产生你在发布组件时所需要的Web Services Description Language (WSDL) 和Web Services Meta Language (WSML)文件。（假设你在运行IIS）
WSDL和WSML有什么不同的地方？很简单，事实上WSDL是一个定义在Web服务中的操作（对象方式）和消息（参数）的XML用语。WSML则是由微软公司创建的在WSDL文件中定位操作和消息的规格。
工具包包括几个应用程序实例。DocSample1是与我上面所述情况最相近的。他要用到一个简单的VB6 COM DLL并指导你将其作为Web服务进行展示。不过，客户端代码是使用VBScript编写的，使用后期捆绑。但这可能不是你创建VB6客户机程序的方式，所以这里我们来运行一个实例。
假设你在表A中有一个组件包含Invoice类，处于简易性的考虑，Invoice只有一个方式GetInvoiceAmount，他负责查找发票号码（假设它从数据库中抽取出这个数据）并返回数量。将GetInvoiceAmount展示为Web服务，你需要依照下面的步骤：
1.创建一个IIS 虚目录来储存DLL。
2.拷贝DLL和它的类型库到1中创建的虚目录中。
3.在DLL上运行WSDL产生向导。指定"Invoice"为服务名称，选定Invoice类并提供一个合理的URL（例如http://localhost/Invoice 如果你计划从服务器上运行这个例子）给接收者。
你将以在同一个目录中储存DLL的Invoice.WSDL和Invoice.WSML文件来结束。对于一个测试客户机程序，你要使用表B中在VB6工程里引用微软SOAP类型库(MSSOAP1.dll)的代码。
这很简单，不是吗？这当然很简单，但是问自己一个问题：如果我要返回一个对象会怎么样？比如Invoice对象？这简直是不可能的。虽然他转换绝大多数非对象类型到WSDL的能力很强，但WSDL Generator不能自动地转换对象类型，例如Collection，到对等的complexType WSDL元素。
没什么大不了的，对吗？你值需要掌握一些WSDL，这能有多难？为了将对象类型作为SOAP消息发送，你还需要在发送端将其序列化和在接收端将其反序列化。
如果你正处于如下情况，SOAP工具包将提供可以实现序列化事项的解决方案：
欢迎评论或投稿
