CP3024 Lecture 10

CP3024 Lecture 10

Web Services

What are Web Services?

“encapsulated, loosely coupled, contracted software objects offered via standard protocols”

ZapThink Research

Web Services

Encapsulated– Web Service implementation is invisible to

entities outside the service– Exposes an interface but hides details

Loosely Coupled– Service and consumer software can be

redesigned independently

Web Services

Contracted– Description of service is available to consumer

Standard Protocols– TCP/IP

– HTTP

– XML

– SOAP

– WSDL

– UDDI

Self-describing

Every web service has a published public interface– Minimum of human readable documentation– SOAP services should have interfaces written

in XML

Discoverable

Simple mechanism for publishing details about a web service

Simple mechanism for finding a service and its interface

Mechanism could be completely decentralised or centralised registry

A Web Service ..

Is available over networkUses standardised XML messagingIs independent of any given OS or

languageIs self describing via XMLIs easily discoverable

Web Usage Shift

Human-centric Web– Majority of web transactions initiated by a

human

Application-centric Web– Inter-application interchanges– E.g. credit card approval

A Web Service In Action

XML

XML

Possible Protocols

HTTP POST/GETXML-RPCSOAP

– Simple Object Access Protocol

Example Service

Return a set of keys given a set of functional dependencies

Service called keyserviceMethod called getCandidateKeysString argument fdSetArgument sent “{{a}->{b}}”

XML-RPC Service Invocation

<?xml version="1.0" encoding="ISO-8859-1"?>

<methodCall>

<methodName>

keyservice.getCandidateKeys

</methodName>

<params>

<param>

<value>{{a}-&gt;{b}}</value>

</param>

</params>

</methodCall>

XML-RPC Response

<?xml version="1.0" encoding="ISO-8859-1"?>

<methodResponse>

<params>

<param>

<value>

{{a}}

</value>

</param>

</params>

</methodResponse>

SOAP

SOAP envelope specification– Rules for encapsulating the data being

transferred

Data encoding rules– Rules for encoding data types

RPC conventions– Rules for invoking remote methods

Example Service Request

<?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV=

http://schemas.xmlsoap.org/soap/envelope/xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body> <ns1:getCandidateKeys

xmlns:ns1="urn:examples:keyservice" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<fdSet xsi:type="xsd:string">{{a}-&gt;{b}}</fdSet></ns1:getCandidateKeys> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Example Service Reply

<?xml version='1.0' encoding='UTF-8'?><SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <ns1:getCandidateKeysResponse

xmlns:ns1="urn:examples:keyservice" SOAP-ENV:encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/"> <return xsi:type="xsd:string">{{a}}</return></ns1:getCandidateKeysResponse></SOAP-ENV:Body> </SOAP-ENV:Envelope>

Soap Message

Structure of SOAP Messages

Envelope (required)

Header (optional)

Body (required)

Fault (optional)

Fault Response

<?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV=

"http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode><faultstring>Exception from service object: FD:

Unexpected end of input</faultstring><faultactor>/soap/servlet/rpcrouter</faultactor></SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Web Services Definition Language (WSDL)

Uses XML to describe a web service– Describes the interface of available functions– Specifies data type information for all requests

and responses– Holds binding information about the transport

protocol– Contains address information to locate the

service

Major Elements

definitions– types– message– portType– binding– ports– service

WSDL definitions

<definitions name="KeyService"targetNamespace=

"http://localhost:8080/wsdl/Lucchesi.wsdl"

xmlns="http://schemas.xmlsoap.org/wsdl/"xmlns:soap=

"http://schemas.xmlsoap.org/wsdl/soap/"xmlns:tns=

"http://localhost:8080/wsdl/Lucchesi.wsdl"xmlns:xsd="http://www.w3.org/2001/XMLSchema">

WSDL types

Optional elementDefines complex types e.g. arrays and

structuresNot used in the example

WSDL message

<message name="CandidateKeyRequest">

<part name="FDSet" type="xsd:string"/>

</message>

<message name="getKeys">

<part name="return" type="xsd:string"/>

</message>

WSDL portType

<portType name="Key_PortType">

<operation name="getCandidateKeys">

<input message="tns:CandidateKeyRequest" name="Request"/>

<output message="tns:getKeys“

name="Response"/>

</operation>

</portType>

WSDL binding

<binding name="Key_Binding" type="tns:Key_PortType"><soap:binding style="rpc"

transport="http://schemas.xmlsoap.org/soap/http"/><operation name="getCandidateKeys">

<soap:operation soapAction="Generate keys"/> <input name="Request"> <soap:body

encodingStyle=

http://schemas.xmlsoap.org/soap/encoding/ namespace="urn:examples:keyservice"

use="encoded"/> </input>

WSDL Binding

<output> <soap:body encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:keyservice" use="encoded"/>

</output> </operation></binding>

WSDL Service

<service name="Key_Service"> <documentation> WSDL File for KeyService </documentation> <port binding="tns:Key_Binding" name="Key_Port"> <soap:address location= “http://localhost:8080/soap/servlet/rpcrouter” /> </port></service>

WSDL In Action

Can use WSDL description to generate client code

Can use WSDL description to automatically invoke a service

Can generate WSDL from server code

Available WSDL Services

Generic Soap Client

UDDI

Universal Description, Discovery and Integration

Specification for distributed directory of businesses– Data stored in an XML format

UDDI business registry– Launched May 2001 by IBM and Microsoft

UDDI Development

Developed by IBM, Microsoft and Ariba– Ariba/IBM collaboration on B2B– IBM/Microsoft collaboration on SOAP– Microsoft/Ariba collaboration on BizTalk and

cXMLThree revisions and then transfer to

standards bodyLaunched September 2000

UDDI Development

Version 2.0 announced July 2001– Internationalisation

– Complex organisations

– Better searching mechanisms

Version 3.0 announced July 2002– Increased security

– Improved WSDL support

– Multi-registry topologies

– Proactive notifications

UDDI Technical Architecture

UDDI data model– XML schema describing businesses and web services

UDDI API– SOAP based API for publishing and searching UDDI

data

UDDI cloud services– Sites implementing UDDI which synchronise

regularly

UDDI Data Model

businessEntity– Information about a business

businessService– Information about a web service

bindingTemplate– Information about accessing a service

tModel– Pointer to external technical specification

businessService

Relationships

businessEntity

bindingTemplate

tModel

UDDI Inquiry API

find_binding find_business find_service find_tModel

get_bindingDetailget_businessDetailget_serviceDetailget_tModelDetail

UDDI Publishing API

get_authTokendiscard_authToken save_binding save_business save_service save_tModel

delete_bindingdelete_businessdelete_servicedelete_tModel

Use Of UDDI

Publishing– Advertise services– Allow discovery of standards in use

Searching– Locate details about electronic services of

business partners– Search for suppliers

Summary

Web Services– Mechanism for electronic business on the Web

Based on XMLSOAPWSDLUDDI