Sams Teach Yourself .Net in 21 Days

By Jason Beres

• Table of Contents
  • Copyright
  • About the Author
  • About the Technical Editor
  • Acknowledgments
  • We Want to Hear from You
  • Introduction
  • Week 1: At a Glance
  • Day 1. Introduction to the Microsoft .NET Framework
  • Day 2. Introduction to Visual Studio .NET
  • Day 3. Writing Windows Forms Applications
  • Day 4. Deploying Windows Forms Applications
  • Day 5. Writing ASP.NET Applications
  • Day 6. Deploying ASP.NET Applications
  • Day 7. Exceptions, Debugging, and Tracing
  • Week 1. In Review
  • Week 2: At a Glance
  • Day 8. Core Language Concepts in Visual Basic .NET and C#
  • Day 9. Using Namespaces in .NET
  • Day 10. Accessing Data with ADO.NET
  • Day 11. Understanding Visual Database Tools
  • Day 12. Accessing XML in .NET
  • Day 13. XML Web Services in .NET
    • What Are XML Web Services?
    • Creating Your First Web Service
    • Consuming XML Web Services
    • Summary
    • Q&A
    • Quiz
    • Exercises
  • Day 14. Components and .NET
  • Week 2. In Review
  • Week 3: At a Glance
  • Day 15. Writing International Applications
  • Day 16. Using Macros in Visual Studio .NET
  • Day 17. Automating Visual Studio .NET
  • Day 18. Using Crystal Reports
  • Day 19. Understanding Microsoft Application Center Test
  • Day 20. Using Visual SourceSafe
  • Day 21. Object Role Modeling with Visio
  • Week 3. In Review

What Are XML Web Services?

XML Web services are application components that can expose functionality over hypertext transfer protocol (HTTP) using the simple object access protocol (SOAP). Using Web services, you have the ability to expose methods in your applications to anyone on the Internet.

Before .NET, one of the biggest challenges developers had to work around was getting data from their servers to another server without compromising security. If you had a component that returned customer information, and you wanted to let someone outside your network access that component, your task wasn't easy. You had to configure the distributed component object model (DCOM) and somehow manage to let the caller of the component authenticate on your server, create an instance of the component, and then call methods on the component. This wasn't easy to implement, so there was a lot of code written to work around the limitation of exposing application functionality in a safe way.

With XML Web services, these limitations are no longer an issue. By wrapping application logic into a Web service, anyone can access the methods in your components over port 80 using HTTP. No special configuration needs to be in place. When a call is made to a Web service, the information is passed back to the caller using XML. Yesterday, you learned how XML is the best way to pass data around the Internet because it's just plain text. Web services take advantage of this by using XML as the backbone of the core Web service infrastructure.

Besides the technical aspects of not having to open any special ports, risk security holes, or configure DCOM to allow others access to application functionality, Web services give you the ability to write cross-platform applications immediately. Any application running written in any language running on any operating system can make a Web service request. It's just like calling any URL on the Internet. How it's implemented is irrelevant; the fact that you can send and receive information in a simple and secure manner is what matters.

Understanding How Web Services Work

Web services are built on open Internet standards and protocols. The common protocols that make Web services work are HTTP and SOAP. Understanding the internals of these protocols isn't important. Like TCP/IP (transmission control protocol/Internet protocol) and IPX (internetwork packet exchange) define how data is transferred over a network, HTTP defines how data is passed over the Internet and SOAP defines how XML must look when being consumed as a Web service being transmitted over HTTP.

• Web services description language (WSDL) is an XML-based contract that defines what methods are contained in a Web service. WSDL can be compared to a type library for a COM component; it lets you know methods are available in the Web service to consume. Because WSDL files are XML based, any client can read them to find out what the Web service offers.
• DISCO, or discovery, files provide a mechanism to discover what Web services are available at a particular site. If you have a Web site and you want to expose a number of Web services, you can create a DISCO file that can be queried by others to find out what your site offers. Discovery files aren't required to make a Web service work; they just provide a mechanism to find out what's available on a specific Web site.
• Universal description, discovery, and integration (UDDI) is a distributed repository application programming interface (API) for Web services. The global community of the Internet needed a mechanism for people to find what Web services are available, so the UDDI repository was created. UDDI is the Yellow Pages for Web services. You can go to http://www.uddi.org and search for Web services by type, functionality, industry, or company. If your large corporation needs its own Web services Yellow Pages, you can write your own UDDI directory using the UDDI software development kits (SDKs) available from Microsoft.

To summarize, Web services are application components that can be consumed over the Internet using open standards. You can use tools of the UDDI repository to search for Web services, or you can discover what Web services are available at specific sites if the sites provide a DISCO file. When you find a Web service, you can inspect its functionality through its WSDL file. Every aspect of creating and consuming Web services uses XML, so they're both cross-platform and cross-language.

Share This