Reading the Request

Server Implementation and WSDL

Will your implementation be able to serve the Web Services you create? If so, your code will need to be able to send and receive HTTP requests. Your executable will need to bind to a particular port and listen for requests. The XML that comes in will need to be routed to the appropriate executable and parsed to get to its information. Then the appropriate response will need to be assembled and sent back to the client.

Many times developers create clients so that a particular environment has access to the outside world. For example, the Apache group will be releasing a C++ client for Axis sometime soon. It only works on the client side because Java can access C++ through the Java Native Interface (JNI) from an Axis service. The client is useful if there is information that C++ needs from Java. It’s more difficult to go in the other direction.

For your server code to be useful, you need to consider how to describe it to clients. If you don’t involve the WSDL standard, you may find yourself having to create a specialized client that is not available to standard implementations such as .NET and Axis. Even though it may appear that using WSDL is the easy way to compatibility with other implementations, it is still possible to create a perfectly valid WSDL document that .NET and Axis would be unable to read. That’s just a natural danger with XML; it is so loosely structured by design that two documents can follow the same rules and still be incompatible.

It is not a requirement that your Web Service generate WSDL. However, if WSDL is not generated, it is more difficult for your Web Service to communicate with other distributions. In addition, clients that don’t require WSDL will need to have more lines of code to call your service. Thus, it becomes somewhat inconvenient for the developer.

Another note to consider with WSDL is that many Web Service implementations didn’t catch on until WSDL came in and the proxy was created, thus making it much easier to instantiate a Web Service. Therefore, WSDL is a feature you definitely want to employ with any Web Service tools you create. Figure 13.4 shows how acting as a server opens Web Service software possibilities.

Figure 13.4: How implementing Web Services software as a server implementation opens access to other platforms.