Web Services: The Web's next Revolution

Web Services: The Web's next Revolution Presented by developerworks, your source for great tutorials Table of Contents If you're viewing this document online, you can click any of the topics below to link directly to that section. 1. Introduction 2 2. What are Web services, anyway? 4 3. Web services architecture 7 4. IBM's Web services development tools 10 5. Benefits of Web services 14 6. Resources 16 7. Feedback 17 Web Services: The Web's next Revolution Page 1

Section 1. Introduction Defining Web services Web services are a new breed of Web application. They are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. Web services perform functions that can be anything from simple requests to complicated business processes. A sample Web service might provide stock quotes or process credit card transactions. Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service. This tutorial is aimed at programmers, webmasters, and managers who want to learn more about Web services. We'll discuss how Web services work, how they will impact the Web, and how you can use this technology today. (For more information on building Web services themselves, a Building Web services tutorial is coming soon to developerworks.) Before we're through, we'll look at the basic ideas behind Web services. We'll show you how to install and run IBM's Web services development environment, and go through a simple demonstration of Web services. We'll also discuss IBM's Web services toolkit, a set of tools that give you complete control over the Web services development process. When you're done, you'll understand the basics, you'll have a complete development environment up and running, and you'll be ready to start developing your own Web services and using other Web services available today. Prerequisites To get the most from this tutorial, you need to understand the basics of how a Web server works, understand XML as a convenient way of exchanging data, and have a passing knowledge of Java. The more comfortable you are with these topics, the more you'll get out of this tutorial. In addition, you'll need to download and install IBM's XML and Web services development environment (WSDE). We discuss how to install and set up this environment in the section IBM's Web services development tools on page 10. Tutorial navigation Navigating through the tutorial is easy: * Select Next and Previous to move forward and backward through the tutorial. * When you're finished with a section, select Next section for the next section. Within a section, use the Section menu button to see the contents of that section. You can return to the main menu at any time by clicking the Main menu button. Web Services: The Web's next Revolution Page 2

* If you'd like to tell us what you think, or if you have a question for the author about the content of the tutorial, use the Feedback button. About the author Doug Tidwell is a good boy! Does he work for developerworks? Oh yes he does! Does he help people with Web services and XML? Yes yes yes! He is such a good boy! Who's my good dog? Who's my good dog? Is it Doug? Is it Doug the Dog? Oh yes it is! He is such a good boy! Good tutorial! Good boy! Actually, Senior Programmer Doug Tidwell is IBM's evangelist for Web services. He was a speaker at the first XML conference in 1997, and has been working with markup languages for more than a decade. His job is to help people use new technologies to solve business problems. He holds in his paws, uh, hands, a Bachelors Degree in English from the University of Georgia and a Masters Degree in Computer Science from Vanderbilt University. In his mythical spare time, he enjoys reading, traveling, and writing ludicrous autobiographies that are published, unedited, on developerworks. He can be reached at dtidwell@us.ibm.com. Web Services: The Web's next Revolution Page 3

Section 2. What are Web services, anyway? First, a little history... The Web is based on several technologies: * TCP/IP The universal networking protocol. Everything from pagers to mobile phones to laptops to mainframes can communicate through TCP/IP. * HTML The universal user interface. You can use HTML tags to render data on just about any device you can think of. * Java The language for universal code. Write your code once, and it runs flawlessly everywhere with great performance. (Yeah, you betcha. Send your sarcastic comments to dtidwell@us.ibm.com.) * XML The language for universal data. XML documents make it easy to move structured data across the Web. What do these technologies have in common? They're all open, cross-platform standards. It's openness that makes the Web possible; that openness is also the foundation for Web services. Where the Web is heading Looking at the future of the Web, there are several important trends: * Content is becoming more dynamic. The first Web pages were static. There were a few pages, and Web pioneers were thrilled to display those static pages on their browsers. Today, sites provide up-to-the-minute content, incorporating news headlines, stock quotes, and pages customized on a per-user and per-browser basis. * Bandwidth is getting cheaper. Some analysts predict that in a few years, there will be enough bandwidth for a full-motion video channel that chronicles the life of every person on Earth. (Apparently the currently pathetic proportion of decent content to available bandwidth will just get worse.) Whether that happens or not, bandwidth is growing exponentially cheaper year after year. * Storage is getting cheaper. The capacities of hard drives, DVDs, CD-ROMs, and removable storage media are far greater than they were a few years ago. That trend will continue. Web Services: The Web's next Revolution Page 4

* Pervasive computing is becoming more important. With hundreds of millions of devices such as mobile phones, pagers, and palmtop computers already in use, we're reaching the end of the days when PCs are the most common device on the Internet. As platforms become more diverse, technologies like XML become even more important. Where do Web services fit in? All of these trends taken together mean that the ability to intelligently process, manipulate, and aggregate content is crucial. Let's look at the four trends in terms of Web services: * Content is becoming more dynamic. A Web service has to be able to combine content from many different sources. That may include stock quotes, weather reports, or news headlines. In a legacy environment, that content may include inventory levels, purchase orders, or directory information, all from back-end systems. * Bandwidth is getting cheaper. A Web service can now deliver types of content (streaming video or audio, for example) unthinkable a few years ago. As bandwidth continues to grow, Web services must adapt to new content types. * Storage is getting cheaper. A Web service must be able to deal with massive amounts of data intelligently. That means using technologies such as databases, LDAP directories, caches, and load balancing software to make sure that scalability isn't an issue. * Pervasive computing is becoming more important. A Web service can't require that users run a traditional browser on some version of Windows. Web services have to serve all sorts of devices, platforms, and browser types, delivering content over a wide variety of connection types. XML and SOAP: Two enabling technologies For Web services to address all of these needs, two technologies are crucial: * XML XML is a great technology for moving structured data across the Web. If Web services are responsible for manipulating data in a reliable, automated way, HTML documents just don't fit the bill. If data is delivered as XML, Web services can process that data in a variety of useful ways. XML's separation of content and presentation is ideal. * SOAP SOAP, the Simple Object Access Protocol, uses XML messages to invoke remote Web Services: The Web's next Revolution Page 5

methods. A Web service could interact with remote machines through HTTP's post and get methods, but SOAP is much more robust and flexible. In the next section, we'll discuss service discovery. New technologies such as UDDI (Universal Discovery Description and Integration) and WSDL (Web Services Description Language) make service discovery possible, and these technologies work hand-in-glove with XML and SOAP. Web Services: The Web's next Revolution Page 6

Section 3. Web services architecture Overview Services are deployed on the Web by service providers. The functions provided by a given Web service are described using the Web Services Description Language (WSDL). Deployed services are published on the Web by service providers. A service broker helps service providers and service requestors find each other. A service requestor uses an API to ask the service broker about the services it needs. When the service broker returns results (think of them as search results), the service requestor can use those results to bind to a particular service. All of the communications we've discussed here can take place over any protocol. For simplicity's sake, however, we'll focus on SOAP Version 2.0 as the preferred protocol. SOAP is an XML-based protocol that allows applications to invoke methods on remote objects. (A SOAP tutorial is coming soon to dw; watch this space.) Web services components To review, there are three components in the Web services universe: * Service providers Provide services, and maintain a registry that makes those services available. * Service brokers Clearinghouses for services. Service brokers act as matchmakers between service providers and service requestors. * Service requestors Work with service brokers to discover Web services, then invoke those services to create applications. Web services operations There are three Web services operations: * Publish/Unpublish Publishing and unpublishing involves advertising services to a registry (publishing) or removing those entries (unpublishing). The service provider contacts the service broker to publish or unpublish a service. * Find The find operation is performed by service requestors and service brokers Web Services: The Web's next Revolution Page 7

together. The service requestors describe the kinds of services they're looking for, and the service brokers deliver the results that best match the request. * Bind The bind operation takes place between the service requestor and the service provider. The two parties negotiate as appropriate so the requestor can access and invoke services of the provider. UDDI - Universal Discovery, Description and Integration Universal Discovery Description and Integration is a specification for information registries of Web services. As we've already discussed, Web services themselves are discovered; a UDDI-based registry is where that discovery takes place. UDDI's approach to discovery is to have a registry of services distributed across the Web. In that distributed registry, businesses and services are described in a common XML format. The structured data in those XML documents is easily searched, analyzed, and manipulated. WSDL - Web Services Description Language If we're going to have all of these Web services out there, we need a common language for describing them. If I'm providing a service, I need to be able to describe it to the world, and if I want to use a service, I need to be able to describe what I'm looking for. WSDL was designed with this in mind. Here's an excerpt from a WSDL document that describes a Web service: <binding name="stockquoteservicebinding" type="stockquoteservicetype"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="getquote"> <soap:operation soapaction="http://www.getquote.com/getquote"/> <input> <soap:body type="inmessagerequest" namespace="urn:live-stock-quotes" encoding="http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <soap:body type="outmessageresponse" encoding="http://schemas.xmlsoap.org/soap/encoding/"/> </output> </operation> </binding> This is part of the definition of a stock quote service. It defines a method called getquote, with the associated SOAP information that enables a piece of code to find the service, invoke a method, and process the response. Web Services: The Web's next Revolution Page 8

Summary Taking all of these technologies together, we have all of the infrastructure we need for Web services to work. Service providers can describe themselves, service requesters can describe what they're looking for, and service brokers have an automated way of determining which requester-provider pairs are a good match. Once a match has been found, there are standard ways of finding the methods available for interacting with the service, along with any binding information necessary. Web Services: The Web's next Revolution Page 9

Section 4. IBM's Web services development tools Overview In this section, we'll discuss two significant tools from IBM, the Web services toolkit and the XML and Web services development environment (WSDE). The toolkit gives you complete control over the development process, as you'd expect. The WSDE automates much of the development process, but that means you won't learn as much about UDDI, WSDL, SOAP, and the related technologies. The Web services toolkit The toolkit, available at www.alphaworks.ibm.com/tech/webservicestoolkit, provides a number of valuable tools, including: * A UDDI Java API * Your very own UDDI registry, which allows you to deploy services locally * SOAP support for digital signatures and Enterprise Java Beans * A Web services browser tool that helps with publish, unpublish, and find operations * A Web services creation tool that simplifies converting existing code to Web services * A set of Java classes for working with WSDL documents programatically * The Apache SOAP 2.0 implementation * Demos, including the Gourmet2Go application and an application that combines several Web services. Because this is a higher-level tutorial, we won't go into the specifics of using the Web services toolkit here. Our next tutorial, Building Web services, will feature the Web services toolkit in all its glory. The WSDE IBM's new XML and Web services development environment (WSDE), available at www.alphaworks.ibm.com/tech/wsde, is a complete development environment for building Web services. Most importantly, it provides tools for: * Creating and transforming data - There are tools to help you create and transform data from existing XML, Java, and SQL applications. * Building Web services - You can take existing bean components, create SOAP wrappers for them, and describe them using WSDL. * Testing and deploying - You can test and deploy your newly-minted Web service. You can do this using Apache's Tomcat servlet engine, IBM's WebSphere Application Server, or a test server included with the tool. The WSDE comes with a comprehensive help facility, including tutorials to get you started. We'll go over the basics here, but you should definitely check out the tool's Web Services: The Web's next Revolution Page 10

documentation for the complete story. Installing the WSDE The WSDE isn't exactly petite; it's approximately 88MB. You'll definitely want to use a high-speed link to download the file. (We're working on other delivery methods, btw.) Download this as a single file, xml-wsde22.zip. Once you've downloaded the file, simply unzip it. If you unzip it in the root directory, it will create a directory called itp. Change to that directory and type the following exciting command: itp (If you're flushed with excitement at this point, feel free to lie down in a quiet place until you're feeling better.) You'll see a welcome screen like this: Choose the "Go to the desktop" option and click OK. Web Services: The Web's next Revolution Page 11

Building your first Web service To build your first Web service, go straight to the Help menu. Select the "Help contents" menu item: Selecting this item brings up the help system. When the help system appears, open the Getting Started tab, then expand the tab labeled "The StockQuote scenario." Click on the item "About the scenario" to get started: Follow the instructions to create the Web service. The scenario instructions lead you through all the steps of creating the service, the client, the proxy, etc. Web Services: The Web's next Revolution Page 12

Using your deployed Web service If you follow the directions for the StockQuote scenario, you do the following: * Import the StockQuoteService bean * Generate a SOAP wrapper for the bean, so the bean's methods can be invoked using SOAP * Generate a WSDL description of the service, so the service can be found and bound * Deploy the Web service * Generate a Java client to interact with the service * Deploy the Web service client to interact with the service and return results from it Along the way, you didn't have to write any code at all! This scenario builds a Web service on an existing Java bean. Because Web services are built on existing technologies, many of which you're probably using already, it's easy to take existing code and repurpose it as a Web service. If you test your Web service, you'll see a JSP that looks like this: This JSP, which was also generated by WSDE, allows you to type in a ticker symbol. When you do, the service connects to a Web site that provides stock quotes in XML. That XML data, retrieved via SOAP, is then converted into HTML and presented on the Web page. Congratulations! At this point, you've learned the basics of Web services, and you've actually created a Web service. Although we went through a relatively trivial example, this does show the power of Web services. We took an existing piece of code, converted it to a Web service, and have something that can be published to a Web services registry. Armed with these basic concepts, you're ready to figure out how to make your existing applications leverage the full power of the Web. Web Services: The Web's next Revolution Page 13

Section 5. Benefits of Web services Web services promote interoperability The interaction between a service provider and a service requester is designed to be completely platform and language independent. This interaction requires a WSDL document to define the interface and describe the service, along with a network protocol (usually HTTP). Because the service provider and the service requester have no idea what platforms or languages each other are using, interoperability is a given. Web services enable just-in-time integration As service requesters use service brokers to find service providers, the discovery takes place dynamically. Once the requester and provider have found each other, the provider's WSDL document is used to bind the requester and the service together. This means that requesters, providers, and brokers work together to create systems that are self-configuring, adaptive, and robust. Web services reduce complexity through encapsulation Service requesters and providers concern themselves with the interfaces necessary to interact with each other. As a result, a service requester has no idea how a service provider implements its service, and a service provider has no idea how a service requester uses its service. Those details are encapsulated inside the requesters and providers. That encapsulation is crucial for reducing complexity. Web services give new life to legacy applications It's relatively straightforward to take an application, generate a SOAP wrapper, then generate a WSDL document to cast the application as a Web service. This means that legacy applications can be used in interesting new ways. In addition, the infrastructure associated with legacy applications (security, directory services, transactions, etc.) can be "wrappered" as a set of services as well. Let's get started! Web services are the next revolution in e-business. Starting with the view that every useful piece of content and every useful application should be a self-describing, dynamically-discovered service, a whole new model of application development takes shape. All of this technology is built on existing Web standards, meaning that aspects of Web applications that seemed exciting not too long ago will now be taken for granted. Web Services: The Web's next Revolution Page 14

Does anyone know exactly how Web services will impact the Web? Does anyone have all the business models worked out? Does anyone know how this will shape the software and services industries? No, no, and no. These are interesting times; armed with your new knowledge of Web services and the changes, you're ready to take on the world! Web Services: The Web's next Revolution Page 15

Section 6. Resources Where to go for more information As you start to work with Web services, here are several useful sites: * IBM's Web services development environment is available at alphaworks. * Other alphaworks tools related to Web services include the Web services toolkit, which includes a Java-based UDDI registry, and the WSDL Toolkit, which generates client and server code from a WSDL document. * UDDI.org is the home for all things UDDI-related. Web Services: The Web's next Revolution Page 16

Section 7. Feedback Let us hear from you! Please let us know whether this tutorial was helpful to you and how we could make it better. We'd also like to hear about other tutorial topics you'd like to see covered. Thanks! Colophon This tutorial was written entirely in XML, using the developerworks Toot-O-Matic tutorial generator. The Toot-O-Matic tool is an XSLT stylesheet and several XSLT extension functions that convert an XML file into a number of HTML pages, a zip file, JPEG heading graphics, and two PDF files. Our ability to generate multiple text and binary formats from a single source file illustrates the power and flexibility of XML. (It also saves our production team a great deal of time and effort.) Web Services: The Web's next Revolution Page 17