Why Service Descriptions?

Let's look at this problem from the service requestor 's perspective. A customer of SkatesTown wants to invoke the POSubmission service. How does the customer know what kind of message to send? Sure, they know to use SOAP, but SOAP is the format of the envelope; SOAP itself does not clarify what message to actually put into the envelope. The customer needs to understand what XML to put into the body of the SOAP envelope, what format the response message might come in, and whether a response is to be expected. The customer also needs to know what messaging protocol to use to send the message and what network address to send the message to.

One way for the customer to determine what XML to send is to examine a textual description of the service published on the SkatesTown Web site. Although doing so is simple, it does allow some potential problems. The textual description might not be terribly precise and can allow the customer's developers to misinterpret the specification. This results in too much trial and error on the customer's part to get the message format right.

Another approach is to include sample message formats in the documentation. The developer can then observe the samples and modify them to suit his/her company's needs. This approach is slightly better in that the developer can get the message format correct with fewer iterations, but the customer still must do too much hand-crafted code development. If each Web service required analysis, design, and coding to invoke, the Web services approach would quickly pass into the dustbin of technology history.

To make the job of invoking Web services easier for the service requestor, we need a formal mechanism to describe the service. This formal approach provides unambiguous specification of what the service requestor needs to do in order to invoke the Web service. As a result of the formality of the service description, software tool developers can provide tooling to automate the development of code to invoke Web services.