A Look Into Web Services

Introduction

When I first started working on the web and developing websites, the Web Service was a new concept that was still being developed. Today, whether you realize it or not, websites all around the world use web services to distribute and receive data. In this article we will take a look at what web services are and the basic concepts on how they are implemented and used.

The XML Foundation

In a nutshell, Web Services allow you to receive and/or distribute data via a web-based platform independent manner using XML (eXtensible Markup Language). Simply put, that means that whatever technology you choose to build your web applications in (ASP, PHP, etc.), you can use web services to communicate with applications that use different technologies. This is possible because Web Services are based on technology neutral XML.
So, what does the XML look like? Let’s take a look at a real world example. Say I have a website that has famous quotes and I want to create a Web Service that allows anyone to get my “quote of the day” and display it on their website. My Web Service might then distribute the quote, the name of the author of the quote and a link back to my website so that I can use this service to build traffic to my website. In this case my Web Service would generate a different quote each day, and that XML might look something like this:

<?xml version="1.0">
	<DailyQuote>
		<Quote> The greatest lesson in life is to know that even fools are right sometimes.</Quote>
	<Author>Sir Winston Churchill</Author>
<WebsiteUrl>www.MyWebsite.com</WebsiteUrl>

The beauty of XML is its simplicity and readability. It’s easy to see at a glance what information in being passed along. This also makes it simple for applications to interpret the well organized data.

Clean Communication with SOAP

Given the solid XML foundation, you now need a method or protocol for communicating that XML across the web. Currently, this is primarily done using SOAP (Simple Object Access Protocol). Like XML, SOAP is designed to be technology agnostic and work with different operating systems, technologies and programming languages. In short, SOAP is the piece that allows your application to talk to a Web Service and then for that Web Service to then in turn talk back to your application.

In the real world this may be something like a web service requesting a user id and password before transmitting data to an application. In our quote website example, we may want to set up our Web Service to ask for the domain name of where it will be displayed before we send along the quote. We can then save this information to a database so that we can review websites where our quotes are being displayed to make sure they comply with our terms of use.

There are different development environments and tools available that handle most of the heavy lifting when it comes to configuring SOAP for your Web Services. There are also multiple flavors of SOAP which have subtle but important differences. In order to give you an idea of how the XML would look for a SOAP 1.1 request that includes the domain name we require before we respond with our daily quote, take a look at this example:

  <?xml version="1.0"?>
   <SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">
	<SOAP-ENV:Body>
	<m:getDomianName xmlns:m="http://www. MyWebsite.com/">
	<domainname xsi:type="xsd:string">www.SomeWebsite.com</domainname>
	</m:getDomainName>
	</SOAP-ENV:Body>
  </SOAP-ENV:Envelope>

It’s easy to see, even in this simple example, why you need a server application to handle all of your SOAP requests and a development tool that allows you to easily configure your Web Service. Imagine if we required 20 instead of 1 input value.

WSDL While You Work

The third basic element of the Web Service is WSDL (Web Services Descriptive Language). This is the part that tells exactly what your Web Service requires and returns. It wouldn’t do much good for you to create a Web Service that web applications couldn’t figure out how to use. That is where WSDL comes in. Like all other pieces in the Web Service puzzle, it too is XML-based. An example of part of the WSDL piece (.wsdl file) using our example service above would look like:

	<message name="getDomianNameRequest">
		<part name=" domainname " type="xs:string"/>
	</message>

	<portType name="DailyQuote">
		<operation name="getDomianName">
			<input message=" getDomianNameRequest "/>
		</operation>
	</portType>

	<binding type="DailyQuote" name="b1">
	<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
		<operation>
		<soap:operation soapAction="http://www.MyWebsite.com/getDailyQuote"/>
		<input><soap:body use="literal"/></input>
		</operation>
	</binding>