[MUSIC] In order for a web service to be invoked, a service requester makes a request to the service provider in a way that it understands. In web services, a service requester must send a properly formatted SOAP message. Let's think about what a web service interface looks like for our example of a currency exchange rate service. Assume that it follows an RPC-style interaction rather than a document style interaction. This means that the SOAP XML document will look something like a method call, with a method name and parameters. The SOAP message will look something like this. The two parameters that are passed in are the two currencies which you want to compare, this is fairly easy if you already know how to invoke the service. What if you are searching for a service to give you a currency exchange rate? Or you found a service provider but don't know how to interact with the service? How do you learn what the method name is or what parameters it needs? Compare a web service to a method in object oriented programming. How would you find out how to call a particular method? Well, you could look at the method signature. Here's what a method signature might look like for a currency exchange rate method. This would tell you what kind of data the method returns. In this case, it's a BigDecimal number type. But it could be a boolean or an enum or an abstract data type created by the developer. It would also tell you parameters it takes. In the case of our currency exchange, two strings that would represent the two currencies, like CAD, for Canadian dollars and USD for American dollars. In web services, WSDL plays a similar role to a method signature. WSDL stands for Web Service Description Language. It was created by Microsoft, IBM, and Ariba by combining some previous attempts at standardization. Like SOAP, WSDL descriptions are written in XML. The role of a WSDL description is to describe the interface of a web service. It will include, for example, how to structure a request, the input parameters required, and the data the service will output. It describes this all in a machine-readable way. A service requestor can read a WSDL description to determine how to request the service, because the WSDL description is machine-readable. The service requestor can even generate the necessary code automatically. The process of generating the necessary code to interface with a service provider is called binding, whether it is done automatically or by the developer. Only after binding can the service requestor invoke the service using SOAP messages. Because web services are more complex than methods, a WSDL description needs more information. It will have to describe the location where the service requestor will send SOAP messages. The transport protocol it will be sent on and more. Some of the most important parts of WSDL 2.0 description are types. Types describe the data types that are used. This is where the developer can define abstract data types in XML. This part is not necessary if the interactions only use basic data types that are already available in XML. Interfaces, interfaces were formally called port types in WSDL 1.2. This section describes interfaces to the services provided in terms of what operations can be performed and in what order. The order of operations can be described by one of the message exchange patterns covered in the SOAP lesson. Request response, solicit response, one way or notification. The interfaces are abstract, they cannot be used until they are bound to the concrete implementations that are needed to use web service. The bindings and service categories serve to bind the interfaces to concrete implementations. Bindings, the bindings will dictate the form of the messages. This includes specifying between document style and our PC style interactions. As well as specifying the transport protocol on top of which the SOAP messages are sent. The Bindings section also determines how the message is translated into XML. Services, services are defined concretely by bringing together interfaces and bindings. And assigning them to endpoints or ports located with URIs. As you can see, a WSDL description is broken down into very fine descriptions. This fine grain separation allows developers to reuse parts of the WSDL specifications in different ways. For example, the same service could be used with different bindings provide an interface over different communications protocols. So that the service is available in more ways. This might happen if some potential service requestors use SMTP instead of HTTP. Reuse is also enabled by the fact that WSDL documents can import other WSDL documents, gaining them access to, for example, the data types in the imported WSDL description or the interfaces. Let's relate it back to our example of a simple currency exchange service. We don't need to define any new data types, since basic data types will suffice. The currency codes will be strings, and the ratio between their values will be a decimal. The interface, there is only one in our example, will be a request response style interaction. This action will define the messages that make up the interaction. In this case, one input and one output. Since this is from the point of view of the service, an input is a request while the output is the response. These would also define what data is needed by the request and response. The binding part in this example uses SOAP, and also specifies the transport protocol, HTTP. Finally, the service section brings all these parts together to define how the service is exposed as a web service located at a URI. This description is lacking some detail, but you can see the general form of a web service and how it is described with WSDL 2.0. Previous versions of WSDL used different terminology and structure, but the concepts are largely the same. With a WSDL description like the example, a service requestor can now be bound to the service by reading this WSDL description and generating the code necessary to bind with the interface of the service. WSDL is a standard based on XML for describing web services and their interfaces. WSDL descriptions can be read by potential service requestors, either programmatically or by developers. The service requestor can then bind to the service interface and begin invoking services using SOAP messages that they structured with the help of the WSDL description. WSDL is modular. It's made up of different components that can be combined to define the desired interface, or multiple interfaces. WSDL descriptions can even import other WSDL specifications. Importing the descriptions and using them to combine into new interface descriptions. This XML based approach, like the other aspects of web services, allows for interoperability between different platforms over the Internet. WSDL is often used with other XML-based standards, but can even describe non-XML-based services, like we saw with SOAP. And coding and parsing XML imposes computational costs. This is the main downside to XML-based standards. So, whether you're using SOAP-based interactions or other methods to provide or request services in service-oriented architectures, consider WSDL for a robust, modular, and extensible service description language.
