Describing a Web Service
To make a Web service useful, a service consumer who has discovered a set of useful services must be able to determine
-
How to invoke the service.
-
What is the service interface; that is, what are its methods, method signatures, and return values?
- Where is the service located?
- What protocol does the service understand?
-
- Which service offers superior quality of service (QoS) when multiple services advertise similar functional capabilities.
-
Is one service more secure than the others?
- Does a particular provider guarantee a faster response or a more scalable and available service?
- What legal agreements need to be in place for collaborating business partners?
-
- In what order should related services and their operations be invoked?
-
How can services be combined to create a macro service (often referred to as service orchestration)?
-
Although these three forms of description provide complete information regarding a service, a consumer may not require all three every time the service is used. It is quite probable, for example, that a consumer invoking a standalone service is uninterested in how the service is to be orchestrated or combined with other services. Also, where only one provider exists for a service, the nonfunctional characteristics (response performance, scalability, etc.), although important, may serve no useful purpose.
Only the first form of description, the functional (the "how to invoke") is always required before a service can be invoked. In this chapter, the focus is on explaining the most common, accepted form for functional description of Web services: WSDL. The WSDL specification is a submission to the World Wide Web Consortium (W3C) that addresses the first of these three forms and is the focus of this chapter. The latter two forms are discussed in s 6 and 7, respectively.