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.