1. Book Author: Nicolai M. Josuttis Chapter Sixteen: Web ServicesIT-Slideshareshttp://it-slideshares.blogspot.com/

2. 16.1 Motivation for Using Web Services Web Services are widely regarded as the way SOA should be realized in practice. [Gartner05] predicted: By 2006, more than 60 percent of the $527 billion IT professional services market will be based on the exploitation of Web services standards and technology. Developers needed ways to exchange information between applications that wereoften running in different locations, and under incompatibleplatforms/languages/systems Before Web Services, EAI (Enterprise Application Integration) was used instead. Developers created one-time, proprietary solutions for system integration. A new customized solution had to be created for each situation. Enter XML (Extensible Markup Language): Allowed developers to separate content from presentation Allowed data to be more easily exchanged between humans and between computers Public format (standard; it doesnt belong to any particular company) XML helped to simplify the EAI process. Web Services are the next step; they use XML to replace the EAI method. 3. 16.1.1 What Are Web Services? Web Services refers to a collection of standards that cover interoperability. In fact, these standards define both the protocols that are used to communicateand the format of the interfaces that are used to specify services and servicecontracts. 4. 16.1.2 History of Web Services HTTP protocol facilitates Human-to-Application (H2A) communications. There is an increasing demand for Application-to-Application communicationusing existing techniques. HTTP is not adequate for more complex operations. E.g., remote operation Late 1999, Microsoft published SOAP an XML-based protocol. IBM supports SOAP early 2000. May 2000 W3C Note: SOAP 1.1. The term Web services was coined several months later, when IBM, Microsoft,and Ariba jointly published the Web Services Description Language (WSDL). March 2001 W3C Note: WSDL1.1 2002, UDDI 1.0 (API 6/28; UDDI v1.0 XML schema; WSDL Service InterfaceDescription: UDDI Inquire API/UDDI Publish API) were also introduced, thuscompleting the set of standards and protocols that make up the basis of Webservices. 5. 16.2 Fundamental Web Services Standards There are five fundamental Web Services standards. XML is used as the general format to describe models, formats, and data types. Most other standards are XML standards. HTTP (including HTTPS) is the low-level protocol used by the Internet. WSDL is used to define service interfaces. 9/19/2005 Web Services Description Language (WSDL) Version 2.0 Part 0: Primer (Last Call Working Draft; review period ends 19 September 2005) SOAP is a standard that defines the Web Services protocol. June 2003: SOAP Version 1.2 released as a W3C Recommendation UDDI is a standard for managing Web Services (i.e., registering and finding services). 2/3/2005 UDDI v3.0 Ratified as OASIS standard. 6. 16.2.1 WSDL WSDL stands for Web Services Description Language. WSDL is an XML vocabulary for describing Web services. It allows developersto describe Web Services and their capabilities, in a standard manner. WSDL specifies what a request message must contain and what the responsemessage will look like in unambiguous notation. In other words, it is a contractbetween the XML Web service and the client who wishes to use this service. In addition to describing message contents, WSDL defines where the service isavailable and what communications protocol is used to talk to the service. 7. 16.2.1 WSDL Figure 16-1 shows the general structures for both versions, which are similar, but not the same. A WSDL document is just a simple XML document. It defines a web service using these major elements: port type - The operations performed by the web service. message - The messages used by the web service. types - The data types used by the web service. binding - The communication protocols used by the web service. A WSDL document can also contain other elements: Extension elements Service elements - make it possible to group together the definitions of several web services inone single WSDL document 8. 16.2.2 WSDL By Example In this example defines a service called CustomerService, which provides oneoperation called getCustomerAddress( ). Its input parameter is a customer ID of type long, and the output is a structureof three string attributes: the street, the city, and the zip code. A WSDL document is an XML document 9. 16.2.2 WSDL By Example element Acts like C/C++ #include , or Java import. Incorporates external namespaces 10. 16.2.2 WSDL By Example (Cont) Namespaces WSDL uses a number of different namespaces including XML Schema Namespaces http://www.w3.org/2000/10/XMLSchema http://www.w3c.org/2001/XML-Schema-instance WSDL Namespaces http://schemas.xmlsoap.org/wsdl/soap/ http://schemas.xmlsoap.org/wsdl/ SOAP Namespaces http://schemas.xmlsoap.org/soap/encoding http://schemas.xmlsoap.org/soap/envelope 11. 16.2.2 WSDL By Example (Cont) The The types element contains XML Schemas defining the datatypes that areto be passed to and from the web service 12. 16.2.2 WSDL By Example (Cont) The The element is used to define the messages that will beexchanged between the client and the service These message elements contain elements, which will be usingtypes defined in the types element All the parts are namespace qualified 13. 16.2.2 WSDL By Example (Cont) The The element is used to define the messages that will be exchangedbetween the client and the service This is done within and elements A portType is analogous to a class An operation is analogous to a method in that class 14. 16.2.2 WSDL By Example (Cont) Types of There are four distinct types of operation Synchronous Request-response - The service receives a message and sends a reply Solicit-response - The service sends a message and receives a reply message AsynchronousOne-way - The service receives a message Notification - The service sends a message All of these can be defined in WSDL Defining the type of operation Presence and order of input/output elements defines the type of operation. Request-response Solicit-response One-way only Notification only 15. 16.2.2 WSDL By Example (Cont) The element This element is used to define the mechanism that the client will actually use to interactwith the web service There are three possibilities SOAP HTTP MIME The most common choice is currently SOAP The binding element defines the protocol specific information for the portTypespreviously defined The binding tag The tag indicates that we will map a to a protocol Indicates we will be using the SOAP binding extensions to map the operations. The alternative to rpc is document. ( to use GET/POST use to use MIME use ) 16. 16.2.2 WSDL By Example (Cont) The example 17. 16.2.2 WSDL By Example (Cont) The The final component of a WSDL file is the element The element defines elements that specify whererequests should be sent The subelement identifies the URL of the service The precise content of elements will be dependent upon themechanism, i.e. SOAP, HTTP or MIME 18. 16.2.3 SOAP Introduction SOAP originally stood for "Simple Object Access Protocol" . Web Services expose useful functionality to Web users through a standardWeb protocol called SOAP. Soap is an XML vocabulary standard to enable programs on separatecomputers to interact across any network. SOAP is a simple markuplanguage for describing messages between applications. Soap uses mainly HTTP as a transport protocol. That is, HTTP messagecontains a SOAP message as its payload section. SOAP Characteristics SOAP has three major characteristics: Extensibility security and WS-routing are among the extensionsunder development. Neutrality - SOAP can be used over any transport protocol such as HTTP,SMTP or even TCP. Independent - SOAP allows for any programming model . 19. 16.2.3 SOAP (Cont) SOAP Building Blocks A SOAP message is an ordinary XML document containing the following elements: A required Envelope element that identifies the XML document as a SOAP message. An optional Header element that contains header information. A required Body element that contains call and response information. An optional Fault element that provides information about errors that occurred while processing the message. 20. 16.2.3 SOAP (Cont) SOAP Request POST /customer11 HTTP/1.1 Host: soa-in-practice.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: " http://soa-in-practice.com/getCustomerAddress" ... 12345678 21. 16.2.3 SOAP (Cont) SOAP Response HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn ... Gaussstr. 29BraunschweigD-38106 22. 16.2.4 UDDI UDDI stands for Universal Description, Discovery and Integration. UDDI is a directory for storing information about web services. UDDI is a directory of web service interfaces described by WSDL. The original idea was to introduce all three roles of a working marketplace:providers that offer services, consumers that need services, and brokers thatbring them together by advertising and locating services. This resulted in the famous triangle that is often shown when explaining WebServices (See Figure 16.2) 23. 16.2.4 UDDI (Cont) The intention behind the UBR was that it would be the central brokerfor a worldwide marketplace of Web Services. Providers could put any new Web Services into the UBR, and consumers could search the UBR to find any services they desired. UDDI was intended to be the protocol used to register and find WebServices. The failure of the UBR does not necessarily mean that UDDI alsofailed, but there are doubts about how important UDDI is in practice. There are now multiple versions of UDDI, and other upcoming WebServices standards that partially overlap with it. After all, the whole situation with UDDI looks like a mess. Time willshow how things evolve. 24. 16.3 Web Services in Practice 25. 16.3.1 Open Standardization The first problem with Web Services is that it is not just one standard definedby one standardization organization. As stated earlier, there are more than 50 different Web Services specifications,specified by three different standardization organizations (W3C, OASIS, andWS-I). Figure 16-3 gives a brief overview.* 26. 16.3.1 Open Standardization (Cont) Its a mess, and as a consequence interoperability is still a real problem. Even for the five fundamental standards mentioned previously (XML, HTTP, WSDL,SOAP, and UDDI), the goal of interoperability has traditionally been hard to attain. Even if you chose the same versions of these standards, the specifications were too sloppyor too broad. In 2002, several vendors (Accenture, BEA, Fujitsu, HP, IBM, Intel, Microsoft, Oracle, and SAP) got together and founded a standardization organization for standardizing the standards. This organization is called the Web Services Interoperability Organization (WS-I). One important thing WS-I creates is profiles, In 2004, the WS-I Basic Profile 1.1 was specified (for the five fundamental Web Services:XML 1.0, WSDL 1.1, SOAP 1.1, HTTP 1.1, and UDDI version 2) to provide interoperability forcalling Web Services. In practice, you should always follow these profiles, if theyre available. In general for Web Services, interoperability is still an issue you should take into account. 27. 16.3.2 Protocol Aspects Scenario and Issues Web Services are inherently point-to-point and protocol-driven. Protocol-Driven ESB A protocol-driven ESB has the advantage that each consumer and provider canuse individual tools to call and implement Web Services. The only thing that must be assured is that the protocols requirements areproperly met. Unfortunately, as just discussed, interoperability is still an issue for Web Services. Point-to-point protocols An important aspect of point-to-point protocols is that you need to ensure thatthe location of the service provider is not hard-coded in the consumer code You might use UDDI which has the flaws discussed previously) You might use another solution, but for scalability and fault tolerance, you need some solution. 28. 16.3.2 Protocol Aspects (Cont) Solutions The best solution is to make the fact that the ESB uses Web Services an implementationdetail of the infrastructure and give consumers and providers everything they need to calland implement services. A typical scalable approach for Web Services might look like Figure 16-4. With such an approach, you might also solve the inherent problems of security andreliability. Note that you can take an incremental approach. Providing value-added ESB services incrementally allows everyone to learn from experience what is necessary and appropriate. 29. 16.3.3 The WSDL Lifecycle Due to the different layers inside WSDL files, different teams may modify thecontents of those files at different times. From a development perspective : no one WSDL file describing a Web Service. From a consumers perspective you might see the final version of a WSDL file. So, at least from a development perspective WSDL files have a lifecycle, consisting of the steps shown in Table 16-1. (View Note For Details) Because a WSDL file for a service goes through different stages, you should set upyour processes, documentation, and configuration management procedures so thatyou cant easily confuse these stages. Part of this might be supported by generators and might be a step of the model-driven development process 30. 16.3.3 The WSDL Lifecycle (Cont) Figure 16-5 gives an example of what a WSDL lifecycle might look like inpractice. 31. 16.3.4 WSDL Deficits A WSDL file does not contain the full interface of a service, it doesnt containany semantic information. That means a WSDL file is not provided to manage the whole service contract. WSDL is simply a format for specifying the technical aspects of calling WebServices. It makes no sense to use this format for service repositories. Its provided onlyfor registries WSDL also has deficits regarding the technical attributes of services. One important constraint (at least up to WSDL 1.1) is the lack of nonfunctionalattributes and attributes for service-level agreements. A WSDL file does not specify how long a service usually runs, who is allowed to call it, how much a service call costs, and so on. All these aspects must usually be known in order to manage a service in a large SOA landscape. 32. 16.3.4 WSDL Deficits With future WSDL versions, this might change. For example, WSDL 2.0 provides the ability to extend WSDL files. ... 33. 16.3.4 WSDL Deficits Note that such attributes are not just semantic information providedfor documentation purposes only. Different code might get generatedaccording to these attributes. For example, for unsafe calls, code might get generated that makes service calls more reliable or writes a protocol entry. Some WSDL deficits might be solved soon by new WSDL standardversions. But what about those that arent, and what can you do in themeantime? You have three options: Use your own format for service descriptions and generate WSDL out of it when and where necessary. Extend WSDL files externally with supplementary files that specify missing attributes. Extend WSDL files internally with additional XML elements and attributes. 34. 16.3.5 So, Should You Use Web Services? You have read now about several problems (or challenges) involved in the application of Web Services: WSDL files have a lifecycle for which you need a process. WSDL files lack attributes. Too many standards hinder interoperability. Lack of interoperability necessitates verifications for each new combination of providerand consumer. The inherent point-to-point nature of Web Services protocols necessitates interceptors. The effort required for individual verifications and interceptors leads to an ESB that is API-based. You should abstain from using Web Services? Lets look at the alternatives: You can use a proprietary SOA infrastructure solution This might lead you to losecontrol and freedom of choice and to become dependent on a specific vendor. You can create everything on your own This means reinventing the wheel and makingthe same mistakes again. 35. 16.3.5 So, Should You Use Web Services? Knuckling down the whole SOA strategy under the Web Servicesstandard is a very risky and shortsighted approach. Web Services are only one possible infrastructure, and even if you dontstart out with multiple infrastructures for your SOA (see Section 5.2),you cant expect that Web Services will be the only infrastructure(standard) you ever implement. You should be wary of using Web Services standards on layers that areinfrastructure-independent. In fact, service contracts (the whole descriptions of services) should be described and managed in a format that is independent from any specific infrastructure. Note also that using Web Services doesnt automatically mean that youare implementing SOA. 36. 16.4 Closing Notes After all that, lets come back to the question of what Web Services really are. Web Services standards play two different roles: On the one hand, they specify standards for abstract descriptions of services. These might be interface descriptions, as in the first layer of a WSDL file, or service orchestrationsand workflows, as in the first layer of BPEL (see Chapter 7). On the other hand, they specify protocols for a particular implementation of a SOA infrastructure (ESB). Be sure to distinguish between these two roles. You can use BPEL to model workflows without using any specific Web Services protocol, and you can specify service interfaces (with the limitations discussed previously) with WSDL without saying anything about how to call these services. Recommendation that not using any Web Services infrastructure-specificaspects until infrastructure details really come into play. 37. 16.5 Summary Web Services are (evolving as) the de facto standard for SOA infrastructures. Based on the core protocols XML and HTTP, the most important protocols are WSDL, for thedescription of Web Services interfaces, and SOAP, as a protocol format for Web Servicescommunications. WSDL files have different layers for the service interface, bindings, and deployment details. For thisreason, you usually need processes to deal with the lifecycle of WSDL files. WSDL is not bound to SOAP. You can use other bindings, so the interface descriptions can (inprinciple) be used with any technology. WSDL as a standard defines only core properties for interoperability. Additional attributes forsecurity, SLAs, and so on are not provided or are provided by other standards. A lot of different Web Services standards and versions are specified by different standardizationorganizations. For this reason, interoperability can be a problem. The Web Services InteroperabilityOrganization (WS-I) tries to solve this issue by providing different profiles for certain sets ofstandards. In practice, to be interoperable you should usually use the WS-I Basic Profile and the SOAPdocument/literal wrapped binding. Web Services is a protocol-driven ESB standard with inherent point-to-point communications. Forthis reason, you might have to introduce interceptors. This also gives you the opportunity to use adifferent protocol or technology inside the ESB. For better synergy, you might consider implementing an API-driven ESB.