This is the third article in the WSDAPI 101 series. You'll learn the most by starting at the beginning, although it's not required to understand the content in this article.
Now that we understand the layering presented in WSDAPI 101: Part 2, we can dig into the magical goodness that is generated code--if Web Services had a caramel-filled center, this would be it. It's also the middle layer in the diagram at right.
The most important characteristic of generated code is that it works like an adapter between the generic WS stack and the application-layer interface, defined by the wire contract. It's OK if you don't understand everything in that last sentence--just remember that generated code is specific to the WS stack, and it's also specific to your application.
Because it's specific to the WS stack, the generated layer for WSDAPI looks remarkably different from the generated layer for Windows Communication Foundation (WCF) or any other stack. The concepts I describe in this article apply across the board, but are told from the WSDAPI perspective.
Let's take a look insideOK, time to dive into the code. WSDAPI's generated layer can be organized into five different components:
With the exception of the "everything else" category, the items above are listed in order of decreasing importance. As a client or service developer, you'll probably have to know a lot about your types and interfaces, but very little about your proxy classes and typically nothing about stub functions. This is why I omit stub functions above: in WSDAPI-land, you shouldn't ever have to deal directly with a stub function.
I've added two diagrams at right: the first shows how these generated items are organized if you're building a client application; the second shows the same for a service application. In both cases, all of the generated content (red boxes) are contained in a handful of files, but they end up getting pulled into different layers in your application stack, so that's why they appear all over the place.
How these five items are arranged in filesSo first, let's talk about how you generate this code. Generated code for WSDAPI-based applications comes from the WsdCodeGen tool the WSDAPI team publishes. The following is a slight oversimplification, but you can run the WsdCodeGen tool on a set of WSDLs, and it will produce a bunch of C++ and IDL files. And for those of you who don't already know, WsdCodeGen is available in the various iterations of the Windows SDK (Vista SDK, Server 2008 SDK, etc.).
So let's say you've got your Webcam WSDL and you've run it through WsdCodeGen. You'll end up with six core files:
Of course, WsdCodeGen automatically chooses these filenames so they're somewhat appropriate for your application, so if you're building a network-attached blender, then it's unlikely you'll end up with files starting with "Webcam."
Can I look inside the generated code?Absolutely. In fact, I was originally going to post the contents of the proxy code for one of our sample applications, but this post has since grown to be way longer than I originally expected, so I won't bloat it even more by including code you can read on your own.
So since I'm not including code wholesale, I'll direct you to the two WSDAPI samples in the Windows SDK (StockQuote and FileService). I don't recall if generated code is included directly in the same (uhh...I feel like I should know that), but you can generate it easily enough from the included WSDLs.
That's great. Now how do I use all of this?Alas, this is where things get beyond the scope of this article. Generated code is (on the surface) pretty simple stuff, so all you should need to use it is a basic understanding of the few fundamental WSDAPI control objects: specifically the IWSDDeviceProxy, IWSDServiceProxy, and IWSDDeviceHost. They're fairly straightforward and you probably won't have difficulty understanding them on your own, but you'll have to wait until the next installment of WSDAPI 101 if you want to hear what I've got to say about them.
So with that, see you next time!