Developers can implement Web services logic within their applications by incorporating available Web services without having to build new applications from scratch. The mechanism that makes this possible is the Proxy pattern. It enables developers to reference remote Web services and use their functionality within a local application as if the data the services return was generated in the local memory space.

Figure 9-1 below illustrates how WSDL is used to generate WSDL Web service description from the Web-service’s interface class. Given the WSDL document, both client- and server side use it to generate the stub and skeleton proxies, respectively. These proxies interact with the SOAP-based middleware.

In the Figure 9-1 above,

• Step 1: generate WSDL documents from interface classes or APIs.
• Step 2: generate server-side stub from the WSDL document.
• Step 3: generate client-side stub from the WSDL document.

WSDL code generator tools (one of which is reviewed later) allow automatic generation of Web services, automatic generation of WSDL documents, and invocation of Web services.

Non-functional Descriptions and Beyond WSDL

WDSL only describes functional characteristics of a particular Web service how to invoke it. But this is only part of the picture and will be sufficient only for standalone Web services that will be used individually. In some cases, non-functional characteristics (such as performance, security, reliability) may be important, as well. In a general case, the service consumer needs to know:

• How to invoke the service? (supported by WSDL, described above)
• What are the characteristics of the service? (not supported by WSDL)
  • Is a service more secure than the others are?
  • Does a particular provider guarantee a faster response or a more scalable and reliable/available service?
• In what order should related Web services and their operations be invoked? (not supported by WSDL)

---

---