As businesses have embraced the Internet as a means for communicating with
each other, the need for easy to implement, Internet-based information exchange
has grown. Businesses need to be able to exchange information, whether it be
sales data, order information, or any other business data we can think of, in
an efficient, and preferable entirely electronic format. Over the past few years
many technologies have been used for this, such as Microsoft's Distributed Component
Object Model (DCOM) and Sun's Remote Machine Integration (RMI), but none of
them was particularly easy to implement, and they did not address the needs
of disparate systems using different operating system, language and architectures.
The concept of Internet-based data exchange has been growing, and XML Web Services
are the newest technology in this arena.
XML Web Services are designed to enable disparate systems the ability to communicate
and exchange data with one another, regardless of their operating system, language,
or architecture. Essentially, a Unix-based system could easily exchange data
with a Microsoft .NET-based system.
Microsoft's .NET Framework enables the easy construction of XML Web Services
that can be consumed by any application that has access to the URL of the XML
Web Service. The consuming application could be a Web application, a Windows
application, a console application, or anything else we can dream up that can
access the XML Web Service URL.
Where Do XML Web Services Fit In
XML Web Services are a part of the .NET Framework, specifically a part of the
ASP.NET Framework. At the base of the .NET Framework is the Common Language
Runtime (CLR). The .NET base classes sit on top of the CLR, providing all of
the basic API's to any .NET application running on the system. On top of the
.NET base classes are two sub-frameworks, the ASP.NET Framework and the Windows
Forms Framework. The ASP.NET Framework is divided into the base-application
services, which handle all common Web application functions, such as HttpRequest,
HttpResponse, etc. On top of the ASP.NET base-application
services are XML Web Services and Web Forms. This is shown in Figure 1.
Figure 1
XML Web Services function within the ASP.NET Framework, which enables them
to function with all the same capabilities as a Web application, such as using
Session state, and interacting with the HttpRequest
and HttpResponse classes.
XML Web Services derive from the System.Web.Services.WebService
class.
How XML Web Services Work
XML Web Services are pieces of program logic that are exposed publicly, either
on an intranet, extranet, or the Internet. They enable disparate systems to
exchange data using Internet standards such as HTTP, XML and SOAP. The integration
of these Internet standards is critical to the acceptance and success of XML
Web Services. By implementing the use of standards, XML Web Services become
accessible to any client, regardless of their system or architecture. This infrastructure
supports the exchange of data is a format that can be used by .NET applications
and non-.NET applications, since the data exchange is done using XML, which
is text-based, and can be used (to some degree) by any system. Since XML is
self-describing, the data exchanged is immediately useful, and easily interpreted.
Basically XML Web Services are black boxes of programming logic that abstract
the functionality away from the consuming application. The consuming application
only needs to know how to invoke the XML Web Service, and what to expect in
return. Beyond that the consuming application is oblivious to what is happening
in the XML Web Service. As developers we can build applications that expose
methods over the Internet, in the form of XML Web Services. The implementation
of these methods is done through cross-Internet calls to the method using HTTP
or HTTPS, and accepting the return values as XML. The data exchange can occur
using one of three protocols:
- HTTP GET - XML Web Services are invoked using a basic GET request
over HTTP. Any inputs are passed in the query string. The results are returned
as an XML document.
- HTTP POST - XML Web Services are invoked using a basic POST request
over HTTP. Any input values are passed in the HTTP POST body. The results
are returned as an XML document.
- SOAP - XML Web Services can be invoked using a SOAP message passed
over HTTP. Any inputs are passed in the SOAP message body, and the return
values are passed in the body of a new SOAP message.
For XML Web Services that take in or return simple data types, such as strings
or integers, any input arguments can be passed to the method as HTTP GET (query
string), HTTP POST (form post) values, or in the body of a SOAP message. For
XML Web Services that either take in or return complex types, such as DataSets,
images, or objects, method arguments are serialized to XML and sent and received
in the body of a SOAP message.
An XML Web Service can be exposed for the intended user, whether that is the
world as a whole, a private client, or for use internally on an intranet, by
either telling the client where to find the XML Web Service (the URL), or by
registering the XML Web Service in the Universal Description, Discovery and
Integration (UDDI) database. UDDI is a global organization trying to broaden
the acceptance and use of XML Web Services; UDDI is essentially a registry for
XML Web Services. Potential clients can search the UDDI registry to find XML
Web Services that match their business needs.
To learn more about UDDI, visit http://www.uddi.org
or http://uddi.microsoft.com/.
When an XML Web Service is created, a Web Service Description Language (WSDL)
document is created with it. The WSDL is essentially a contract that a consumer
agrees to, which specifies the exposed methods of invoking the XML Web Service,
the inputs expected, and the outputs that will be returned. The URL for the
WSDL is listed in the UDDI registry; so potential clients can discover it. If
we are privately informing a client about the XML Web Service, the URL for the
WSDL is all they need to implement the XML Web Service (although a document
explaining what the XML Web Service is for may be nice). The WSDL contains all
the information needed to invoke the XML Web Service.
A partial WSDL is shown here (parts were taken out for demonstration purposes
only):
<?xml version="1.0" encoding="utf-8"?>
<definitions xmlns:s0=http://www.dotnetjunkies.com
targetNamespace=http://www.dotnetjunkies.com
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<s:schema attributeFormDefault="qualified"
elementFormDefault="qualified"
targetNamespace="http://www.dotnetjunkies.com">
<s:element name="ConvertMoney">
<s:complexType>
<s:sequence>
<s:element
minOccurs="1" maxOccurs="1"
name="Amount"
type="s:float" />
<s:element
minOccurs="1" maxOccurs="1"
name="FromCountryAbv"
nillable="true" type="s:string" />
<s:element
minOccurs="1" maxOccurs="1"
name="ToCountryAbv"
nillable="true" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="ConvertMoneyResponse">
</s:element>
<s:complexType name="Conversion">
<s:sequence>
<s:element
minOccurs="1" maxOccurs="1"
name="FromMoneyType"
type="s:string" />
<s:element
minOccurs="1" maxOccurs="1"
name="FromAmount"
type="s:float" />
<s:element
minOccurs="1" maxOccurs="1"
name="ToMoneyType"
type="s:string" />
<s:element
minOccurs="1" maxOccurs="1"
name="ToAmount"
type="s:float" />
<s:element
minOccurs="1" maxOccurs="1"
name="ConversionDate"
type="s:string" />
</s:sequence>
</s:complexType>
</s:schema>
</types>
<message name="ConvertMoneySoapIn">
<part name="parameters" element="s0:ConvertMoney"
/>
</message>
<message name="ConvertMoneySoapOut">
<part name="parameters" element="s0:ConvertMoneyResponse"
/>
</message>
<message name="ConvertMoneyHttpGetIn">
<part name="Amount" type="s:string" />
<part name="FromCountryAbv" type="s:string"
/>
<part name="ToCountryAbv" type="s:string"
/>
</message>
<message name="ConvertMoneyHttpGetOut">
<part name="Body" element="s0:Conversion"
/>
</message>
<message name="ConvertMoneyHttpPostIn">
<part name="Amount" type="s:string" />
<part name="FromCountryAbv" type="s:string"
/>
<part name="ToCountryAbv" type="s:string"
/>
</message>
<message name="ConvertMoneyHttpPostOut">
<part name="Body" element="s0:Conversion"
/>
</message>
<service name="MoneyUtilities">
<port name="MoneyUtilitiesSoap" binding="s0:MoneyUtilitiesSoap">
<soap:address location="http://www.dotnetjunkies.com/services/MoneyUtilities.asmx"
/>
</port>
<port name="MoneyUtilitiesHttpGet" binding="s0:MoneyUtilitiesHttpGet">
<http:address location="http://www.dotnetjunkies.com/services/MoneyUtilities.asmx"
/>
</port>
<port name="MoneyUtilitiesHttpPost" binding="s0:MoneyUtilitiesHttpPost">
<http:address location="http://www.dotnetjunkies.com/services/MoneyUtilities.asmx"
/>
</port>
</service>
</definitions> |
The WSDL describes the inputs, including data type and name, and the outputs,
also including data type and name, for HTTP GET, HTTP POST and SOAP invocation.
As long as the XML Web Service interfaces do not change, the WSDL will remain
the same. This means that the XML Web Service provider can make changes to the
logic, as long as the inputs and outputs don't change, and the client will not
be affected. For example, as a provider of an XML Web Service, we can change
what database we are connecting to, or how the logic performs, provided the
expected inputs and outputs do not change, and the client will never know we
made the change.
Providers and Consumers
XML Web Services are based around the concept of a provider and a consumer.
The provider is the application that exposes the XML Web Service, and the consumer
is an application that uses the XML Web Service. The user of an application
should never see the XML document returned from an XML Web Service. Rather,
the application consumes the XML Web Service, and uses the data to provide output
to the application user. For example, an XML Web Service that converts currency
from one type to another would return an XML document that looks like this:
<?xml version="1.0" encoding="utf-8" ?>
<Conversion
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.dotnetjunkies.com">
<FromMoneyType>US Dollar</FromMoneyType>
<FromAmount>100</FromAmount>
<ToMoneyType>British Pound</ToMoneyType>
<ToAmount>69.66214</ToAmount>
<ConversionDate>10/28/2001</ConversionDate>
</Conversion> |
The application user shouldn't ever see the XML document that is returned.
In the application we would write code to invoke the XML Web Service, and display
the returned values to a user in a format appropriate to our application, as
seen in Figure 2.
Figure 2
The Web application acts as the consumer, invokes the XML Web Service, receives
the XML data returned, and displays it appropriately for the user.
How It Works
Lets take a high-level look at how the provider and consumer interact. Figure
3 shows the communication between the consumer and the provider.
Figure 3
In Figure 2 we see a consumer application connecting to an XML Web Service
provider. The steps that occur are as follows:
- The consumer finds an available XML Web Service either in the UDDI registry,
or directly from the provider (not shown).
- The consumer makes a request to the provider for the WSDL document.
- The provider returns the XML-based WSDL document.
- The provider makes a request to the XML Web Service in the WSDL document,
passing in any required arguments as defined in the WSDL.
- The provider processes the request, performing any functions necessary to
complete the request, and returns the result to the consumer as either an
XML document, or a SOAP message.
Summary
XML Web Services provide the infrastructure for exchanging data between disparate
systems, enabling the automation of simple functionality, or critical business
processes. An XML Web Service is basically a black box, abstracting functionality
away from a consuming application by exposing only the necessary interfaces,
and performing all of the processing on the provider system. XML Web Services
are built on top of the ASP.NET Framework, enabling a quick development time,
and higher performance over previous Web development technologies.