WSDL is used to create documents that describe the methods supported by a Web service, the arguments that the methods accept, and what the Web service returns. The WSDL document tells the program (or the programmer) what’s needed to consume a Web service. The format of a WSDL document is an XML-schema—XML that specifies the format of an XML document. As I said before, the .NET development environment hides the details of building the WSDL document, but if you are interested in obtaining more information, go to www.w3.org/TR/wsdl12/.
With UDDI, we know what Web services are available for use. If you want others to use a Web service you’ve built, you would use UDDI to list your service so that others can find it. Similarly, you would use UDDI to find Web services to use in your own applications. A word of caution: In some discussions, UDDI can divert people from the real issues, such as the need for careful performance design when building a distributed application.
FACTORS AFFECTING THE PERFORMANCE OF WEB SERVICES
Face it, Web services is remote computing, so its performance is affected by many factors, including latency and bottlenecks in the network; intermediaries (if present); and your service provider. Some of these factors are out of your control, especially network servers not under your control. However, because XML is used as a message format, it is likely that the main contributing factor to elongated response time is XML.
XML, more than any other specification, is key to Web services, especially in large organizations, such as governments, retailers, and banks that might best exploit XML technologies. In addition, developers are increasingly using XML in non-Web services environments.
Unfortunately, XML performance is not discussed much in the industry literature. Thus, a comprehensive and detailed overview would be extremely valuable, but that is beyond the scope of this introductory article. XML is humanreadable and verbose, being both textencoded and metadata-encoded (metadata is “descriptive” data that describes the “real” data). While XML is great in terms of flexibility and maintainability, it’s just terrible in terms of performance. The use of XML presents several performance challenges:
- TRANSMISSION: The longer the SOAP message, the longer the transmission time.
- PROCESSING: The parsing, binding, validation, and transformation of XML/SOAP messages will add to the response time.
- PERSISTENCE: RDBMS/XML databases— the databases referenced by XML—must stay “resident” for the life of the SOAP message. This might imply that the XML message might have to “live” beyond the life of a process.
The killer in this is transmission: An XML message can be 10 to 20 times larger than the equivalent binary representations. For example, if we need to pass the values of a single point on a graph—an xposition and a y-position—we would merely pass the binary values (-1 and -2, in this case) to an “ordinary” called procedure. However, for a Web services method, we must encode the parameters with self-defining metadata to describe the actual parameter values (see Figure 1).
XML processing refers to several XML activities, such as parsing, schema validation, binding, and transformation. XML processing is quite CPU-, memory-, and I/O-intensive. Parsing and schema validation involves a lot of character encoding/decoding and string processing, which can require significant system resources. XML validation ensures that an XML document follows a predefined structure, which is an absolute necessity. However, it is usually three to four times slower than XML parsing!