Reckless

Rebecca Dias - Product Manager, Microsoft Corporation

SOAP Toolkit - Listening to Customers

Over a year and half ago, I started working with Matt Powell and the MSDN folks to update up a lot of the content on the Web services spoke.  During this process, we found that the SOAP Toolkit was actually getting a lot of downloads without folks really understanding that it was not the recommended approach for building Web service solutions on the Microsoft platform.

The SOAP Toolkit was deprecated by the .NET Framework.  The toolkit was originally released to demonstrate basic Web services capabilities with COM components and applications.

As a result, we chartered a series of articles to help customers understand the best practices for Web services development using the .NET Framework COM interop support and to help folks migrate off the SOAP toolkit.

The support for the toolkit was originally slated to retire on July 1, 2004 (yes, next month); however, we had a lot of customer feedback that they had actually built production apps using the toolkit.  Pat Beahan championed a process by which we identified who our customers were and spent time understanding their project timelines.  As a result, we have extended the support lifecycle to more closely align with Visual Studio 6.0.

Standard support for the toolkit will now expire 4/2005 with extended support ending 4/2008.  The Microsoft Website will be updated shortly to reflect these dates.  For the latest on supported technologies for developing Web services, visit the Web Services Developer Center on MSDN.  To understand the benefits of building Web services solutions on the .NET Framework and to leverage the latest advanced Web services capabilities, vist the Web services spoke on MSDN http://msdn.microsoft.com/webservices.

 

Published Wednesday, June 02, 2004 7:01 PM by rdias

Comments

 

Commonality said:

After reading Rebecca Dias' entry on the future of SOAP Toolkit, I'm a bit baffled by all this. Quite honestly,...
June 2, 2004 11:53 PM
 

Memi Lavi said:

I always thought the SOAP Toolkit was destined to help create web services in a non-.NET (AKA VB6, VBScript) environment. Is there any better methodology of doing it in those environment?
June 3, 2004 2:32 AM
 

RichB said:

"however, we had a lot of customer feedback that they had actually built production apps using the toolkit."

I mean, Duh, wasn't this the aim of the game?
:-)
June 3, 2004 4:25 AM
 

BradK said:

Well, a short reprieve. What Microsoft seems to not realize is the toolkit is a great way to interop a COM client with a .Net web service. I never use the server side pieces of the toolkit, but the client side stuff, with late binding, is a sweet spot for me. I really don't want to have to create a project to wrap a .Net web service proxy for COM interop just so I can call a web service in VBScript without the toolkit. If you want me to migrate my client to .Net, then implement COM in .Net so I don't have to re-write 4 years of code :-).
June 3, 2004 11:02 AM
 

Scott Hanselman said:

Wow, does this mean that PocketSoap.com is the only answer for the VB6 developer?
June 3, 2004 1:11 PM
 

Rebecca Dias said:

The purpose of my entry was to tell folks that the lifecycle was extended. This is suppossed to make customers happy. Ideally VB6 developers will use the COM/Interop capabilities in the Framework; alternatively, they can continue to use the SOAP toolkit.

How many of you have investigated the COM/Interop support? Why do you feel it is not sufficient? Have you read articles on this?

For the folks using the late binding functionality, are you assuming that you will not need any of the more advanced WS functionality provided by WS-*? Why is the late binding stuff a sweet spot?
June 3, 2004 1:40 PM
 

BradK said:

Sure, and not trying to sound ungrateful or irreverent, but I think posters here are still shouting out their production use cases. As far as late binding, that's just a specific case for my app, and it's just more convenient to register the toolkit on 40 servers once than to create a bunch of interop assemblies and do GAC registrations every release. Toolkit is an elegant solution for me for interal web service access (we don't use WS-* internally). Thanks for extending the support.
June 3, 2004 6:20 PM
 

PeterO said:

So, given all of this, what are the options in the unmanaged case? We've started using web services in our projects, but in our case the client is a lightweight app...where "lightweight" means we can't require the .NET Framework. We've been using the ATL Server templates on the unmanaged side. This came about because:

1) The SOAP Toolkit didn't seem (on the surface) to be significantly better than ATL Server. At the time, ATL Server seemed to serve our purposes well enough. Due its template nature, ATL Server seemed like it might be more flexible as well.

2) Using the SOAP Toolkit would require redistributing it (doesn't help in being lightweight, though I know it's not huge by any means).

3) Prior to this announcement, it looked like SOAP Toolkit didn't have much life left in it, so it didn't seem smart to start using it in a new project.

Unfortunately, using ATL Server on the client has not gone well. It works "okay" for the simple web service. But, when we wanted to start using WS-Security and other more advanced things, it got ugly real fast. Overall, it's been buggy and hard to work with. It's to the point where it would be easier to just write a solution from scratch.

So, all that to ask: What is the unmanaged Web Services story from Microsoft (for clients in particular)? My apologies if this is not the right place to ask.
June 4, 2004 8:56 AM
 

The XML Files said:

June 9, 2004 4:08 PM
 

Niklas E said:

When are you going to release a new SQLXML, which doesn't require SOAP Toolkit? A new SQLXML should it auto-wrap com-components to .NET RCWs? BizTalk 2004 requires SQLXML and should also be updated then.

June 20, 2004 7:52 PM
 

German Marin's Blog said:

April 29, 2005 5:48 PM
Anonymous comments are disabled

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker