Defining a Web Service’s Abstract Interface

Chapter 8 • Web Services 285 • Message Triggers Fault—any message, including the first in the pattern, may trigger a fault message, which must have opposite direction and be delivered to the originator of the triggering message • No Faults—faults must not be propagated pattern=http:www.w3.orgnswsdlin-out This line specifies that this operation will use the in-out pattern as described above. WSDL 2.0 uses URIs to identify message exchange patterns in order to ensure that the identifiers are globally unambiguous, while also permitting future new patterns to be defined by anyone. However, just because someone defines a new pattern and creates a URI to identify it, that does not mean that other WSDL 2.0 processors will automatically recognize or understand this pattern. As with any other extension, it can only be used among processors that do recognize and understand it.

8.3.3 Binding a Web Service Implementation

Several service providers may implement the same abstract interface. Client Service input In-Only no faults Client Service input Robust In-Only message triggers fault Client Service output Out-Only no faults Client Service output Robust Out-Only message triggers fault Client Service output input Out-In fault replaces message Client Service output Out-Optional-In message triggers fault Client Service input output In-Out fault replaces message Client Service input In-Optional-Out message triggers fault A one-way operation: A request-response operation: A notification operation: A solicit-response operation: output opt input opt c d c c c c c c c d d d Figure 8-13: WSDL Message Exchange Patterns MEPs with their fault propagation rules. Ivan Marsic • Rutgers University 286 Figure 8-14 Service Each endpoint must also reference a previously defined binding to indicate what protocols and transmission formats are to be used at that endpoint. A service is only permitted to have one interface . Figure 8-15 port describes how a binding is deployed at a particular network endpoint

8.3.4 Using WSDL to Generate SOAP Binding

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 design pattern, which is described in Section 5.2.2 above and already employed for distributed computing in Section 5.4. Proxy classes enable 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 8-16 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 wsdl: BindingOperationType outfault infault output input ∗ ref other:any wsdl: BindingType operation wsdl: binding wsdl: binding ∗ fault other:any type name ? interface Figure 8-14: The XML schema for WSDL 2.0 binding element. wsdl: EndpointType ∗ wsdl: ServiceType wsdl: service wsdl: service + other:any interface name ? endpoint other:any other:any other:any binding name address Figure 8-15: The XML schema for WSDL 2.0 service element. Chapter 8 • Web Services 287 generate the stub and skeleton proxies, respectively. These proxies interact with the SOAP-based middleware. WSDL code generator tools one of which is reviewed in Section 8.5 below allow automatic generation of Web services, automatic generation of WSDL documents, and invocation of Web services.

8.3.5 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 reliableavailable service? - If there is a fee for the service, how does billing and payment processing work? Service requestor Service provider WSDL document of service provider Application object client SOAP-based middleware Stub Application object Web service SOAP-based middleware Skeleton 1 3 2 WSDL compiler client side WSDL compiler server side WSDL generator Figure 8-16: From a Programming Interface to WSDL and back to the Program: Step n: generate WSDL documents from interface classes or APIs. Step o: generate server-side stub from the WSDL document. Step p: generate client-side stub from the WSDL document.