Introduction to web services (lecture 8)
Written by: Jonathan Briggs
November 21, 2004 [5254 views]
Most of the module so far has looked at how organizations can build e-business applications by building (or buying), owning and controlling all the software and hardware components involved (just like a conventional software project). Within the last couple of years there has been a growing interest in distributed applications (or web services) in which either part of an application relies on external 3rd party services or part or all of your application is made available to others inside or outside your organization (perhaps for a fee). This interest has been stimulated by the massive investment that Microsoft is putting behind its .NET initiative.
In order to begin to appreciate the opportunities offered by web services it is important to understand some of the contributing technologies including XML, XML-RPC, SOAP, UDDI, WSDL as well as .NET. It would be completely unrealistic to try and learn all of these technologies in a module but this session should lay the foundations for exploring them.
According to Ethan Cerami, a web service is any service that is available over the Internet, uses a standardized XML messaging system, and is not tied to any one operating system or programming language.
Imagine a web service that returns a set of latest industry headlines
Server A requests sports headlines from Server B using standard XML format (perhaps Simple Object Access Protocol, SOAP or XML-RPC). Server B processes the request and returns package (again in agreed format) from its database perhaps charging Server A for the service.
Services
Here are a few examples of webservices:
*Send SMS from a Website
*Perform a Google search from inside a server application
*Verify a customer address within an ecommerce shopping process
www.remotemethods.com - A directory of some available web services
www.xmethods.net - and another
It each of these cases, a third party is used to provide part of the functionality (the service). Each of these relationships could be designed specifically for the partnership but it is much more efficient if standard protocols can be established between the players. This is where the emerging web services standards come in.
www.google.com/froogle - Here are information formatting instructions for Froogle. This demonstrates why a standard is required.
Standards are defined in XML
XML is a formalized meta-language that allows structured (and typed) data to be passed between applications. It extends the notion of tags familiar from HTML by allowing you to define your own tag sequences or use those defined by a third party (such as an industry group). The definitions of what is allowed in these new tag sequences are defined in Document Type Definitions, DTDs or Schemas.
<?xml version=”1.0” encoding=”UTF-8” ?>
<person>
<name>
<familyname>Briggs</familyname>
<firstname>Jonathan</firstname>
</name>
<address>
…
</address>
</person>
When designing a web service we will define the messages that can be passed between the players in this way; agreeing to the format in order to understand each other.
www.xml.com - Case study on how Amazon.com Web Services were designed
www.amazon.com - More details on Amazon's Web Services
When accessing an existing service you will need to discover how it allows communication. This is where other formalised protocols come in: WDSL, UDDI and SOAP
SOAP
SOAP and REST are alternative XML defined standards that describe how your application can talk to external applications. You should see SOAP as a wrapper around your application that provides a standard interface independent of the implementation language or system. This means that your PHP mapping application or a .NET payment processing system could both talk SOAP and be integrated into a J2EE e-commerce store.
webservices.xml.com - A good starting point for SOAP
Web service disclosure
Another protocol is used to describe the service to developers: WSDL (Web Service Description Language). This is another XML format that defines the public interface to the service.
www.w3schools.com - Here are a set of tutorials on WSDL
Service directory
Web services are developed and information about the services is published to centralized directories using UDDI (Universal Description, Discovery and Integration).
www.webservicesmall.com - A good set of pointers to UDDI
Putting it all together
Find the service you require by searching a directory of web services via UDDI, find out how to query that service using WSDL, create a client using any programming language that uses SOAP/XML-RPC to issue requests to the service and interprets the returned results. Run the service.
RSS: a simple syndication service
One of the easiest web services to understand and experiment with is the Rich Site Summary or Really Simple Syndication. This has become a standard for making news headlines published by one site available by another. Instead of rendering a web page the site publishes its content using XML. Other sites can read this and republish (including the links to the orginal site). Many blogs now inlcude an RSS feed. This allows hundreds of blogs to monitored quite easily using specialist RSS Newsreader software.
www.webreference.com - Another intro to RSS
A list of RSS Newsreaders for Mac and PC
www.moreover.com - Very useful newsfeeds in RSS from Moreover
Developing a service
1. Create an application (in Java/Enterprise Java Beans/J2EE, VisualBasic.NET or any other language) that runs on a server. These applications might interrogate databases using JDBC/ADO or make requests to other services.
2. Wrap the application in a service wrapper using SOAP or similar. This provides a standard interface independent of the development language. SOAP is an XML defined protocol that formally defines how requests should be made to the application (so is XML-RPC) and how results will be returned.
3. Next, describe your service in WSDL so that other people know how to call it and how it returns results.
4. Once the system is up and running (on a server), announce its presence using UDDI to a web services directory inside your organization or out in the wider world.
www.systinet.com - Some useful tutorials on Web Services
www.webservicesarchitect.com - A final link that you may find interesting
What do you think?
