What Are XML Web Services and How Do They Fit into the .NET Framework?
See all Sams Teach Yourself on InformIT Web Development Tutorials.
XML Web Services represent an exciting new method for distributing application functionality. The Web Services model allows applications to make calls to centralized functionality through the use of standard internet protocols such as HTTP and SOAP. This centralized functionality, the XML Web Services themselves, then return data to the calling application in the form of XML documents.
Perhaps the most exciting benefit of utilizing XML Web Service is that the standard protocols utilized in communicating with Web Services means that cross-platform interoperability is easily achieved. An application written in VB.Net and running on Windows 98 can make use of services written in C++ or Perl and running on Unix as easily as they can call services written in C# and running on NT.
The chapters presented here on InformIT define the very basic steps of creating your own XML Web Services. After reading these examples you should be able to create and test your own XML Web Services using Visual Studio.NET. When you are finished, you will be ready to move on and create more complex services and utilize the advanced techniques outlined in "Sams Teach Yourself .NET XML Web Services in 24 Hours."
— Mark Augustyniak
This chapter is from the book
This chapter is from the book
This chapter is from the book
Welcome to Teach Yourself XML Web Services with .NET in 24 Hours. XML Web services represent an exciting new tool in software creation, and this first hour will introduce you to the technologies and tools behind it. You will become familiar with the protocols used in the XML Web services model, and you will also learn about the .NET framework and how XML Web services fit into it.
In this chapter we will discuss the following:
-
What XML Web services really are
-
Where to apply XML Web services technology
-
The infrastructure behind .NET and XML Web services
-
The programming model used in creating Web services
What Are XML Web Services?
An XML Web service is simply a unit of programming functionality that is exposed to client applications via the Internet. At its simplest, an XML Web service is any programming component or object that makes information available via standard Internet protocols such as HTTP.
Distributed Computing
In the past, developers started to move away from the "all in one" style of development, in which all of an application's functionality was contained in one code module. Developers began to move code into objects, called components, which existed outside of the initial project. These components could be updated independently of each other and the main program, thus making for smaller and more efficient tasks.
With code now being developed from these component building blocks, it became easier to build a project in teams and to reuse code. Components from one project could be combined with new components to form different applications. It wasn't long before third-party companies began selling components to software developers for use in their own projects.
With the rise of networking and technologies such as DCOM, developers also began to move these components onto different machines across the network. This gave users access to great processing power, via the distribution of tasks to varying machines, and it gave developers the ability to change one component and simultaneously affect all users.
NOTE
DCOM, or Distributed Component Object Model, is Microsoft's network communication protocol that allows components to be accessed over a network.
Now, with XML Web services, you have the ability to distribute your application across not only a network but also the Internet. Components can be built and hosted anywhere in the world and consumed by other components. Third-party companies no longer just create and sell components; they host them as well.
For a small example, think of a DLL or function library that contains spell-checking software. If you were writing several applications to handle your company's word processing and e-mail capabilities, you would want to add this component into all of your applications.
Now, if someone created this spell-checking component as a Web service, you could simply use that component in all of your applications. If the component were ever to be updated—say an expanded word list were added—none of your applications would be impacted at all. They would all simultaneously have access to the expanded word list.
Achieving Platform Independence with XML Web Services
One of the most important factors in the future of XML Web services technology is its role in creating platform-neutral systems. By "platform-neutral" we mean that XML Web services built and running on one platform, say Unix, can be called on by applications built on and running on a completely unrelated platform—for example, Mac OS 7.0. This is true even for systems that are not running the .NET platform. In Hour 9, you will see some examples of clients that are built on non-.NET platforms. However, XML Web services built on .NET platforms will not be covered in this book.
XML Web services help create platform-neutral systems by using the same set of standards as the Internet. Today, many applications— such as Web browsers, e-mail clients, and FTP programs— are able to utilize Web protocols such as HTML, SMTP, and FTP to trade information seamlessly, without ever being aware of the platform where the information originated.
Using the HTTP protocol, requests are sent from client applications, in an XML standard format, to XML Web services for processing. When the request is processed, another XML document is generated, this one containing any requested data, and sent back to the client application.
Leading up to .NET
The road to XML Web services has been a long one. Probably the first major step in the development of the distributed model seen in XML Web services was the creation of object technologies such as COM and CORBA. The introduction of these object design technologies allowed developers to build programs in smaller components and allowed these components to be reused in other programs.
From COM sprang DCOM and other, similar technologies that allowed these components to be moved off the user's machine and onto servers. This allowed components to be simultaneously used by multiple users and multiple applications.
The rise of the Internet and Internet-enabled applications took the concept of distributing applications one step further by allowing components to be called by Web applications written in ASP or CGI and being used all over the world. Since the rise of the Internet, developers have searched for better ways to expose functionality and services to their user community.
ASP, briefly mentioned above, was another big step in the move toward more distributed applications. ASP allowed developers to write applications using a stripped-down version of the Visual Basic programming language known as VBScript. Previous to ASP, Web programming was done primarily with CGI, or Common Gateway Interface, written in languages such as Perl and C++. ASP provided a much easier method of development, used a commonly known language, and also provided a rich set of built-in objects to help developers quickly put together applications.
The last piece to fall into place in the creation of XML Web services was XML itself. Finally, developers had a standard way in which to describe data and services. From there it was not long before someone, actually several someones, began to write applications that communicated with each other by passing XML documents. These were the first Web services.
XML Messaging Between Systems with SOAP
As you were reading about XML Web services' role in creating platform-independent applications and their use of HTTP protocols to communicate with other applications, you probably noticed the need for a standard format in which clients can actually send requested data, such as method calls with parameters, and receive Web service data, such as strings, arrays, and record sets. Well, that formatting issue was solved with XML.
An XML subset called SOAP, or Simple Object Access Protocol, which you will learn about in Hour 4, is used as the medium by which XML Web services accept and transmit information to the rest of the world. SOAP documents are simply a way of marking up a call to an XML Web service method or function, including all of its required arguments. SOAP is also used to mark up all of the returned results so that the client can understand what is being sent back to it.
A simple SOAP document can be sent to the URL of an XML Web service and, if formatted properly, will cause the service to run a method and send back its results in another SOAP document.
Data is marked up with XML tags denoting the type of data being sent back, such as string or long, and the variable name to which the data was sent, in the case of parameters. This helps XML Web services and their client applications maintain type safety even across differing platforms.
The Basic Components of an XML Web Service
When you develop an XML Web service, you will generate more than just the code that provides the functionality you wish to expose. You will also be creating a host of files, and in the case of UDDI, entries in existing files that will help support your service and describe it to the intended user community. Some of the files that you will create or edit when working with Web services are
ASMX. ASMX files are ASP.NET application files. These are files that are created either by you using a simple text editor or, if you are using Visual Studios .NET, from the code that you develop within the IDE.
ASAX. This is the global file of your XML Web services. This file handles application-level events such as requests and sessions, both of which you will learn more about as you progress through this book.
Disco. XML is also used to help prospective users find a given Web service. Disco files, short for discovery files, are created and exposed to the Internet as the primary way of advertising a service. Disco files contain links that point to the service and the service's WSDL files. Hour 5 covers the syntax and usage of Disco files.
UDDI. UDDI, which stands for Universal Description, Discovery, and Integration, is a registry for developers to register their Web services. This repository allows developers looking to consume Web services to search for functionality that matches their needs and to contact the Web service owner about its use. In Hour 5, you will see how to use UDDI for both finding and publishing XML Web services.
WSDL. WSDL documents list the exposed methods of a service and any parameters and return types that those methods expose. The contract is a promise that the listed methods will exist in the format described by the WSDL document. The WSDL can be used either by developers or, as is more likely the case, by tools such as Visual Studios to create consumers (client applications) for the service and guarantee that requested services both exist and function in the manner that the client developer expects them to. You will learn more about WSDL in Hour 3.
Using a Component Model
Another key feature of the XML Web services framework is that they are built as components. What that means is that XML Web services are not built as complete, stand-alone programs, but rather as small building blocks to be used in the creation of other programs. Many such blocks can be used from all over the Internet, an intranet, or both in order to create a single application. In fact, an XML Web service itself may make use of several other Web services in providing its functionality.
Suppose you wished to develop an application that allowed users to track sports scores. You build your application and utilize a Web service that provides updated listings of game scores for several major sports.
Next, you decide that you also wish to provide player statistics for every player in each of the major American sports. You search around and find one that provides such statistics for football and baseball, and you decide to use it in your application. Later, you discover two additional services, one that provides basketball statistics and another that provides statistics for NHL games. You decide to use these as well.
Using this type of component model means that the developer of an application need not worry about every facet of its design. The developer need only worry about what a component does and the data that it returns; he or she does not need to bother with the inner workings of the component. This eliminates the need to duplicate the development efforts of others and greatly reduces the time required to create new applications.