|
|
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 Chapters 6 and 7, respectively.
|
|
|