Web Services

The human-centric web

HTTP GET or POST

HTTP RESPONSE

machine-centric web

XML REQUEST

XML RESPONSE

machine-centric web

• machine-initiated– automated transactions– intelligent agents

• process bound– most time spent by machines processing

messages

• common language– high interoperability between machines

example

• online ordering system

• machine-centric approach

• intelligent agent searches for companies selling a required product

• agent negotiates with another intelligent agent belonging to the company– interrogate catalogue and check prices– place order (or recommend placement)– track order progress

web services

• available over the Internet

• uses XML as a messaging technique– receive data and perform functions

• platform independent– any machine can talk to any other

• self-describing– published service protocol

• discoverable

web service roles

serviceregistry

servicerequester

serviceprovider

1

2

Discover services

Invoke service

universally-accessible catalogue of available web services

a consumer of services

provider implements services on the Internet

web service protocol stack

Transport

Discovery

Description

XML messaging

HTTP, SMTP, FTP, BEEP

UDDI

WSDL

XML, XML-RPC, SOAP

XML RPC

• Remote Procedure Call– encodes commands for the web service

• request encoded in (very simple) XML

• sent via http POST

• web service– reads XML– executes commands– returns result as body of http response

Example - call

<?xml version=“1.0” encoding = “ISO-8859-1” ?><!-- simple XML-RPC call of the getWeather method from a weather web service -->

<methodCall>

<methodName> weather.getWeather </methodName>

<params><param>

<value>Aberdeen AB25</value></param>

</params></methodCall>

Example - response

<?xml version=“1.0” encoding = “ISO-8859-1” ?><!-- The web service generates a response --><!-- This is appended to the http response in the normal way after the header information-->

<methodResponse><params>

<param><value>Horrible and Wet</value>

</param></params>

</methodResponse>

SOAP

• Simple Object Access Protocol

• XML-based messaging protocol– general message format– transport through http, ftp, …

• normal use is RPCs through http

• more complex than XML-RPC, and heavier overhead

• self-describing

Example - call<?xml version=“1.0” encoding = “ISO-8859-1” ?><SOAP-ENV:Envelope xmlns:SOAP-ENV=http://..wc3.../soap-envelope/ xmlns:xsi=http://..wc3.../XMLSchema-instance xmlns:xsd=http://..wc3.../XMLSchema <SOAP-ENV:Body><ns1:getWeather xmlns:ns1 = “urn:weatherweb” SOAP-ENV:encoding-style=“http:..w3c..soap-encoding”> <address xsi-type=“xsd:string”>Aberdeen AB25

</address> </ns1:getWeather></SOAP-ENV:Body></SOAP-ENV:envelope>

Example - response<?xml version=“1.0” encoding = “ISO-8859-1” ?><SOAP-ENV:Envelope xmlns:SOAP-ENV=http://..wc3.../soap-envelope/ xmlns:xsi=http://..wc3.../XMLSchema-instance xmlns:xsd=http://..wc3.../XMLSchema <SOAP-ENV:Body><ns1:getWeatherResponse

xmlns:ns1 = “urn:weatherweb” SOAP-ENV:encoding-style=“…soap-encoding”> <return xsi-type=“xsd:string”>Horrible and Wet</return>

</ns1:getWeatherResponse></SOAP-ENV:Body></SOAP-ENV:envelope>

Description of Web Services

• web services need to be self-describing– what functions are available?– what input do they require?– what output will they provide?

• WSDL– Web Service Description Language– allows automatic invocation of a web service– allows clients to be designed independently

example

<?xml version=“1.0” encoding = “ISO-8859-1” ?><definitions name = “weatherweb” <!-- namespace definitions here --> > <message name = “getWeatherRequest”> <part name = “address” type = “xsd:string” />

</message> <message name = “getWeatherResponse”> <part name = “desc” type = “xsd:string” />

</message> <!-- other aspects of definition here --></definitions>

Discovery of Web Services

• UDDI– Universal Description, Discovery and

Integration– technical specification for a distributed

directory of businesses and web services

• UDDI Business Registry– Microsoft/IBM joint venture– implements UDDI– open for all to register web services

UDDI Business Registry

• white pages– general information about a company– name, address, business description

• yellow pages– business classification data– industry, product, geographical, …

• green pages– technical information about the web service– location, pointer to a specification

Web Service Transport

• http– simple, stable , widely deployed– gets through most firewalls easily

• good for integration• bad for security

– not sufficiently reliable for some purposes

• beep– blocks extensible exchange protocol– more efficient and reliable for RPC purposes

web services security issues

• confidentiality– is the request/response content secure?– over http can use SSL

• secure encryption• may break down with redirection

– W3C XML Encryption Standards• encrypt XML content• toolkits available from vendors, eg IBM

web services security issues

• authentication– who is using a web service?– are they authorised to do so?– W3C digital signature standard

• network security– http was not designed for RPC– RPC over http breaks through firewalls– similar risks to CGI

developing a web service

• toolkits available– Java Web Services Developer Pack (WSDP)– .NET Framework 2.0 SDK

• MVC architecture still relevant

• select service wrapper– XML-RPC or SOAP– interface to the model

developing a web service

• create a service description– WSDL for SOAP services– human-readable instructions for XML-RPC

• deploy on a server– existing web server or dedicated server

• publish the service– register with UDDI– private intranet UDDI

using a web service

• discover services of interest– use UDDI

• locate a service description– WSDL for SOAP– documentation for XML-RPC

• create a client application– for SOAP, can use WSDL invocation tool

• automatically create a client for the described service

• run the client to invoke the service

Example

• Huygen’s probe competition

• Best algorithm for solving problem– Black box problem– Limited number of samplings of a lunar

surface– Find lowest point

• Web services:– allow different algorithms to compete– simple monitoring of results

Case Study: OncoServe

Diane Campbell Honours project 2003-4

The Oncology Workbench

• Component-based architecture

• Web-based treatment design system to assist oncologists to design improved cancer chemotherapy

Oncologists not restricted to using simulations they have developed themselves.

Easier integration of new simulations.

Allows the Oncology Workbench to continue to develop as a loosely-coupled system.

Benefits of ProjectBenefits of Project

collaborativeweb

community

tumour models as web services

Client Application

Web Service

Treatment File

<< XML >>

Drug File

<< XML >>

Treatment File

<< XML >>

Web Service

Calculates tumour sizes

after treatment.

Requests Simulation based on treatment data in Treatment File

Drug infoReturns Simulation comprising tumour sizes