Chapter 4. Shaping the WSDL, XML, and SOAP Message
IN THIS CHAPTER
So far, we have covered how to write a basic server and client, and covered the basics behind SOAP, WSDL, and UDDI. To write self-documenting WSDL files, state the exact form your objects will take and publish that data to the Internet, you will need a bit more knowledge of what tools are available.
.NET includes a number of attributes that let you control every aspect of your WSDL file. Because your messages must follow the interfaces and types that appear in your WSDL file, you also end up modeling the way that messages appear on the wire. If you need to augment the attributes provided by .NET, you can write your own. This can allow you to do something as simple as writing the message out to a log file. Attributes can also be used to modify the SOAP message itself. You could encrypt individual elements, handle specific headers, or anything else that you want. Custom attributes give you all the access you will need for your own objects.
An important thing to know about attributes is that an attribute class always ends with the text Attribute. Visual Studio .NET uses this fact to allow for a shorthand that omits this part of the attribute classname. The exception to this rule is any attribute whose classname contains the word Attribute twice in a row. For example, the class to set the name of an XML attribute is called XmlAttributeAttribute. The naming rules state that the attribute name has to be spelled out in full within the code. You can use shorthand in all other situations. This chapter avoids using the shorthand. I only explain this confusing bit because you will see examples in other venues that use the shorthand instead of the complete name.
The .NET Framework SDK comes with a tool called WSDL.EXE. While this tool is commonly used to create proxies based on a WSDL file, it can also create stub implementations of a server that implements the WSDL. This can allow you to define the interface of a Web Service in WSDL before implementing it. You can also create implementations for other, existing WSDL files.
At the end of the chapter, we will take a look at how to use the UDDI support included in Visual Studio .NET to register your Web Services. As you can tell, this chapter covers a lot of somewhat unrelated topics. I believe that you do need to know about these topics sooner rather than later. Understanding how they all fit together will allow you to create more effective Web Services.
Before proceeding, make sure to grab the code from the companion Web site. This is one chapter that should be read with these files handy so that you can follow along and experiment as the chapter moves along.