Web service A Web service is a method of communication between two electronic devices over a network.

The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processible format (specifically Web Services Description Language, known by the acronym WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards." Web Services can convert your application into a Web-application. Web Services are published, found, and used through the Web. The basic Web Services platform is XML + HTTP.

Web services are application components Web services communicate using open protocols Web services are self-contained and self-describing Web services can be discovered using UDDI Web services can be used by other applications XML is the basis for Web services

Web services platform elements:

SOAP (Simple Object Access Protocol) UDDI (Universal Description, Discovery and Integration) WSDL (Web Services Description Language)

When all major platforms could access the Web using Web browsers, different platforms could interact. For these platforms to work together, Web-applications were developed. Web-applications are simple applications that run on the web. These are built around the Web browser standards and can be used by any browser on any platform. By using Web services, your application can publish its function or message to the rest of the world. Web services use XML to code and to decode data, and SOAP to transport it (using open protocols). With Web services, your accounting department's Win 2k server's billing system can connect with your IT supplier's UNIX server. Web Services have Two Types of Uses Reusable application-components: There are things applications needs very often. So why make these over and over again? Web services can offer application-components like: currency conversion, weather reports, or even language translation as services. Connect existing software: Web services can help to solve the interoperability problem by giving different applications a way to link their data. With Web services you can exchange data between different applications and different platforms. Any application can have a Web Service component. Web Services can be created regardless of programming language.

A Web Service Example In the following example we will use ASP.NET to create a simple Web Service that converts the temperature from Fahrenheit to Celsius, and vice versa: This document is saved as an .asmx file. This is the ASP.NET file extension for XML Web Services. <%@ WebService Language="VBScript" Class="TempConvert" %> Imports System Imports System.Web.Services Public Class TempConvert :Inherits WebService <WebMethod()> Public Function FahrenheitToCelsius (ByVal Fahrenheit As String) As String dim fahr fahr=trim(replace(Fahrenheit,",",".")) if fahr="" or IsNumeric(fahr)=false then return "Error" return ((((fahr) - 32) / 9) * 5) end function <WebMethod()> Public Function CelsiusToFahrenheit (ByVal Celsius As String) As String dim cel cel=trim(replace(Celsius,",",".")) if cel="" or IsNumeric(cel)=false then return "Error" return ((((cel) * 9) / 5) + 32) end function end class Note: To run this example, you will need a .NET server. The first line in the example states that this is a Web Service, written in VBScript, and has the class name "TempConvert". The next lines import the namespace "System.Web.Services" from the .NET framework. The next line defines that the "TempConvert" class is a WebService class type. The next steps are basic VB programming. This application has two functions. One to convert from Fahrenheit to Celsius, and one to convert from Celsius to Fahrenheit. The only difference from a normal application is that this function is defined as a "WebMethod()". Use "WebMethod()" to convert the functions in your application into web services. Then, end the class. Publish the .asmx file on a server with .NET support.

Put the Web Service on Your Web Site

<form action='tempconvert.asmx/FahrenheitToCelsius' method="post" target="_blank"> <table> <tr> <td>Fahrenheit to Celsius:</td> <td> <input class="frmInput" type="text" size="30" name="Fahrenheit"> </td> </tr> <tr> <td></td> <td align="right"> <input type="submit" value="Submit" class="button"> </td> </tr> </table> </form> <form action='tempconvert.asmx/CelsiusToFahrenheit' method="post" target="_blank"> <table> <tr> <td>Celsius to Fahrenheit:</td> <td> <input class="frmInput" type="text" size="30" name="Celsius"> </td> </tr> <tr> <td></td> <td align="right"> <input type="submit" value="Submit" class="button"> </td> </tr> </table> </form> Substitute the "tempconvert.asmx" with the address of your web service like: http://www.example.com/webservices/tempconvert.asmx

SOAP 1.1 The following is a sample SOAP 1.1 request and response. The placeholders shown need to be replaced with actual values. POST /webservices/tempconvert.asmx HTTP/1.1 Host: www.w3schools.com Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://tempuri.org/FahrenheitToCelsius" <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <FahrenheitToCelsius xmlns="http://tempuri.org/"> <Fahrenheit>string</Fahrenheit> </FahrenheitToCelsius> </soap:Body> </soap:Envelope>

WSDL: The Web Services Description Language (WSDL, pronounced 'wiz-dul') is an XMLbased language that is used for describing the functionality offered by a Web service. A WSDL description of a web service (also referred to as a WSDL file) provides a machine-readable description of how the service can be called, what parameters it expects and what data structures it returns. It thus serves a roughly similar purpose as a Method signature in a programming language. WSDL is often used in combination with SOAP and an XML Schema to provide Web services over the Internet. A client program connecting to a Web service can read the WSDL file to determine what operations are available on the server. Any special data types used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the operations listed in the WSDL file using XML or HTTP.

Representation of concepts defined by WSDL 1.1 and WSDL 2.0 documents.

Objects in WSDL 1.1 / WSDL 2.0 WSDL 1.1 Term WSDL 2.0 Term Service Service Port EndPoint

Binding

Binding

PortType

Interface

Operation

Operation

Description Contains a set of system functions that have been exposed to the Web-based protocols. Defines the address or connection point to a Web service. It is typically represented by a simple HTTP URL string. Specifies the interface and defines the SOAP binding style (RPC/Document) and transport (SOAP Protocol). The binding section also defines the operations. Defines a Web service, the operations that can be performed, and the messages that are used to perform the operation. Defines the SOAP actions and the way the message is encoded, for example, "literal." An operation is like a method or function call in a traditional programming language.

Message

n/a

Typically, a message corresponds to an operation. The message contains the information needed to perform the operation. Each message is made up of one or more

Types

Types

logical parts. Each part is associated with a message-typing attribute. The message name attribute provides a unique name among all messages. The part name attribute provides a unique name among all the parts of the enclosing message. Parts are a description of the logical content of a message. In RPC binding, a binding may reference the name of a part in order to specify binding-specific information about the part. A part may represent a parameter in the message; the bindings define the actual meaning of the part. Messages were removed in WSDL 2.0, in which XML schema types for defining bodies of inputs, outputs and faults are referred to simply and directly. Describes the data. XML Schema is used (inline or referenced) for this purpose.

Example Code <?xml version="1.0" encoding="UTF-8"?> <description xmlns="http://www.w3.org/ns/wsdl" xmlns:tns="http://www.tmsws.com/wsdl20sample" xmlns:whttp="http://schemas.xmlsoap.org/wsdl/http/" xmlns:wsoap="http://schemas.xmlsoap.org/wsdl/soap/" targetNamespace="http://www.tmsws.com/wsdl20sample"> <!-- Abstract type --> <types> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.tmsws.com/wsdl20sample" targetNamespace="http://www.example.com/wsdl20sample"> <xs:element name="request"> <xs:complexType> <xs:sequence> <xs:element name="header" maxOccurs="unbounded"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="name" type="xs:string" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="body" type="xs:anyType" minOccurs="0"/> </xs:sequence>

<xs:attribute name="method" type="xs:string" use="required"/> <xs:attribute name="uri" type="xs:anyURI" use="required"/> </xs:complexType> </xs:element> <xs:element name="response"> <xs:complexType> <xs:sequence> <xs:element name="header" maxOccurs="unbounded"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="name" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="body" type="xs:anyType" minOccurs="0"/> </xs:sequence> <xs:attribute name="status-code" type="xs:anySimpleType" use="required"/> <xs:attribute name="response-phrase" use="required"/> </xs:complexType> </xs:element> </xs:schema> </types> <!-- Abstract interfaces --> <interface name="RESTfulInterface"> <fault name="ClientError" element="tns:response"/> <fault name="ServerError" element="tns:response"/> <fault name="Redirection" element="tns:response"/> <operation name="Get" pattern="http://www.w3.org/ns/wsdl/in-out"> <input messageLabel="In" element="tns:request"/> <output messageLabel="Out" element="tns:response"/> </operation> <operation name="Post" pattern="http://www.w3.org/ns/wsdl/in-out"> <input messageLabel="In" element="tns:request"/> <output messageLabel="Out" element="tns:response"/> </operation> <operation name="Put" pattern="http://www.w3.org/ns/wsdl/in-out"> <input messageLabel="In" element="tns:request"/> <output messageLabel="Out" element="tns:response"/> </operation> <operation name="Delete" pattern="http://www.w3.org/ns/wsdl/in-out"> <input messageLabel="In" element="tns:request"/> <output messageLabel="Out" element="tns:response"/> </operation> </interface>

<!-- Concrete Binding Over HTTP --> <binding name="RESTfulInterfaceHttpBinding" interface="tns:RESTfulInterface" type="http://www.w3.org/ns/wsdl/http"> <operation ref="tns:Get" whttp:method="GET"/> <operation ref="tns:Post" whttp:method="POST" whttp:inputSerialization="application/x-www-form-urlencoded"/> <operation ref="tns:Put" whttp:method="PUT" whttp:inputSerialization="application/x-www-form-urlencoded"/> <operation ref="tns:Delete" whttp:method="DELETE"/> </binding> <!-- Concrete Binding with SOAP--> <binding name="RESTfulInterfaceSoapBinding" interface="tns:RESTfulInterface" type="http://www.w3.org/ns/wsdl/soap" wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/" wsoap:mepDefault="http://www.w3.org/2003/05/soap/mep/request-response"> <operation ref="tns:Get" /> <operation ref="tns:Post" /> <operation ref="tns:Put" /> <operation ref="tns:Delete" /> </binding> <!-- Web Service offering endpoints for both bindings--> <service name="RESTfulService" interface="tns:RESTfulInterface"> <endpoint name="RESTfulServiceHttpEndpoint" binding="tns:RESTfulInterfaceHttpBinding" address="http://www.example.com/rest/"/> <endpoint name="RESTfulServiceSoapEndpoint" binding="tns:RESTfulInterfaceSoapBinding" address="http://www.example.com/soap/"/> </service> </description> SOAP: SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on Extensible Markup Language (XML) for its message format, and usually relies on other Application Layer protocols, most notably Hypertext Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission. SOAP can form the foundation layer of a web services protocol stack, providing a basic messaging framework upon which web services can be built. This XML based protocol consists of three parts: an envelope, which defines what is in the message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing procedure calls and responses. As an example of how SOAP procedures can be used, a SOAP message could be sent to a web-service-enabled web site such as a real-estate price database, with the parameters needed for a search. The site would then return an XML-formatted document with the resulting data, e.g., prices, location, features. With the data being returned in a standardized machineparseable format, it can then be integrated directly into a third-party web site or application.

SOAP Specification The SOAP specification defines the messaging framework which consists of:

The SOAP processing model defining the rules for processing a SOAP message The SOAP extensibility model defining the concepts of SOAP features and SOAP modules The SOAP underlying protocol binding framework describing the rules for defining a binding to an underlying protocol that can be used for exchanging SOAP messages between SOAP nodes The SOAP message construct defining the structure of a SOAP message

Processing model: The SOAP processing model describes a distributed processing model, its participants, the SOAP nodes and how a SOAP receiver processes a SOAP message. The following SOAP nodes are defined: SOAP sender A SOAP node that transmits a SOAP message.

SOAP receiver A SOAP node that accepts a SOAP message.

SOAP message path The set of SOAP nodes through which a single SOAP message passes.

Initial SOAP sender (Originator)

The SOAP sender that originates a SOAP message at the starting point of a SOAP message path.

SOAP intermediary

A SOAP intermediary is both a SOAP receiver and a SOAP sender and is targetable from within a SOAP message. It processes the SOAP header blocks targeted at it and acts to forward a SOAP message towards an ultimate SOAP receiver.

Ultimate SOAP receiver

The SOAP receiver that is a final destination of a SOAP message. It is responsible for processing the contents of the SOAP body and any SOAP header blocks targeted at it. In some circumstances, a SOAP message might not reach an ultimate SOAP receiver, for example because of a problem at a SOAP intermediary. An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message. SOAP is platform independent SOAP is language independent

Transport methods Both SMTP and HTTP are valid application layer protocols used as Transport for SOAP, but HTTP has gained wider acceptance as it works well with today's Internet infrastructure; specifically, HTTP works well with network firewalls. SOAP may also be used over HTTPS (which is the same protocol as HTTP at the application level, but uses an encrypted transport protocol underneath) with either simple or mutual authentication. Example message POST /InStock HTTP/1.1 Host: www.example.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: 299 SOAPAction: "http://www.w3.org/2003/05/soap-envelope" <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Header> </soap:Header> <soap:Body> <m:GetStockPrice xmlns:m="http://www.example.org/stock"> <m:StockName>IBM</m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope>

UDDI UDDI is a directory service where companies can register and search for Web services.

UDDI stands for Universal Description, Discovery and Integration UDDI is a directory for storing information about web services UDDI is a directory of web service interfaces described by WSDL UDDI communicates via SOAP UDDI is built into the Microsoft .NET platform