It has never been particularly easy to choose a Web Services stack on which to build your application. Microsoft has produced many over the years (for example, WCF and WSDAPI) and other software vendors produce even more. The feature sets of these stacks often overlaps, but rarely are they all exactly the same–so making a decision about which stack to use can be complicated and time-consuming.
And things are about to get even more complicated–but for very good reason–with the introduction of the Windows Web Services API (WWSAPI). Even though it means one more stack to choose from, I’m actually very excited about WWSAPI, because it brings WCF-like functionality to native non-managed Windows applications. This fills a big gap in the development story for Web Services.
So soon there will be at least three different stacks you can use to build WS applications.
- Web Services on Devices API (WSDAPI) is the one-stop shop for building applications on DPWS, WSD, or WS-Discovery. If you use any of these three technologies, use WSDAPI. (And if you’re lost in the acronyms, see this post.)
- Windows Communication Foundation (WCF) is the generic Web Services stack available in .NET. If you’re not communicating with devices but are using managed code, use WCF.
- Windows Web Services API (WWSAPI) is the generic Web Services stack available on Windows. If you’re not communicating with devices but are using native code, use WWSAPI.
Additionally, there are other technology-specific WS stacks available in Windows (such as WinRM for WS-Management) that I’m not listing here for brevity.
The short version is that if you’re using devices, WSDAPI is probably the first place to look for Web Services connectivity. For more generic Web Services applications, WWSAPI is a great solution if you’re writing native code.