xml and soap web services

CIS5930Internet Computing

XML Web Services Basics

Prof. Robert van Engelen

CIS 5930 Fall 2006 204/10/23

Web Services Basics

Interoperability has highest priority XML over HTTP Web services can be created regardless of the programming

language Reusable application components

Software can be reused as service components in a service-oriented architecture, i.e. to support the requirements of software users

Compositionality is realized with open standards Connect existing software

Publish the application as a service Applications connect and interact by encoding and decoding

data in XML

CIS 5930 Fall 2006 304/10/23

XML Web Services Protocols

SOAP “Simple Object Access Protocol” is an XML messaging protocol Typically remote procedure call (RPC) request-response messages Or XML-based messages (document/literal style)

WSDL “Web Service Description Language” is an XML document that defines

the service interface, protocol bindings, and service endpoint addresses Uses XML schema to define XML types Typically uses SOAP to bind the messaging protocol

UDDI “Universal Description, Discovery and Integration” is a

repository/database of services (e.g. defined by WSDLs) Not very popular, won’t discuss

CIS 5930 Fall 2006 404/10/23

WSDL

WSDL represents a contract between the service requestor and the service provider

WSDL is an XML specification that defines four critical pieces of information of an XML Web service:1. Interface information describing all publicly available functions

2. Data type information for all message requests and message responses

3. Binding information about the transport protocol to be used

4. Address information for locating the specified service

CIS 5930 Fall 2006 504/10/23

WSDL Specification The definitions root element defines the

name and namespace of the web service The types element contains a set of XML

schemas with all the data types (XML elements and types) used between the client and server

One or more message elements define the names of the messages, each contains zero or more message part elements, which can refer to message parameters or message return values

The portType element combines multiple message elements to form a complete one-way or round-trip operation

The binding element describes how the service will be implemented on the wire

The service element defines the endpoint address for invoking the service

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

CIS 5930 Fall 2006 604/10/23

Example WSDL

The HelloService service provides a single publicly available function sayHello

The function expects a single string parameter, and returns a single string greeting

Request-response message pattern over HTTP using HTTP POST



CIS 5930 Fall 2006 704/10/23

WSDL definition Root Element

Defines the name and targetNamespace:

<definitions name="HelloService” targetNamespace="http://www.ecerami.com/wsdl/HelloService.wsdl” xmlns="http://schemas.xmlsoap.org/wsdl/” xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/” xmlns:tns="http://www.ecerami.com/wsdl/HelloService.wsdl” xmlns:xsd="http://www.w3.org/2001/XMLSchema”>

Typically the xmlns namespace bindings are included in the root element and are used in the remainder of the WSDL

Note that the WSDL namespace is declared as the default namespace for all of the other WSDL elements (http://schemas.xmlsoap.org/wsdl/) so these elements are not explicitly namespace qualified

CIS 5930 Fall 2006 804/10/23

The WSDL message Elements

Two message elements are defined The first represents a request message, SayHelloRequest, and the

second represents a response message, SayHelloResponse:

<message name="SayHelloRequest"> <part name="firstName" type="xsd:string"/></message><message name="SayHelloResponse"> <part name="greeting" type="xsd:string"/></message>

For the request, the part specifies the function parameters For the response, the part specifies the function return values The type is a QName value, indicating the schema type of the part

CIS 5930 Fall 2006 904/10/23

Built-in XSD SimpleTypesSimple type Example Value(s)string Web Servicesboolean true, false, 1, 0float -INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaNdouble -INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaNdecimal -1.23, 0, 123.4, 1000.00integer -126789, -1, 0, 1, 126789nonPositiveInteger -126789, -1, 0negativeInteger -126789, -1long -1, 12678967543233int -1, 126789675short -1, 12678byte -1, 126nonNegativeInteger 0, 1, 126789unsignedLong 0, 12678967543233unsignedInt 0, 1267896754unsignedShort 0, 12678unsignedByte 0, 126positiveInteger 1, 126789date 1999-05-31time 13:20:00.000, 13:20:00.000-05:00

CIS 5930 Fall 2006 1004/10/23

The WSDL portType Element

The portType element defines a single operation, sayHello The operation consists of a single input message

(SayHelloRequest) and a single output message (SayHelloResponse):

<portType name="Hello_PortType"> <operation name="sayHello"> <input message="tns:SayHelloRequest"/> <output message="tns:SayHelloResponse"/> </operation></portType>

The input/output elements specify a message attribute of tns:SayHelloRequest or tns:SayHelloResponse

The tns prefix references the targetNamespace defined within the definitions element

CIS 5930 Fall 2006 1104/10/23

Message Exchange Patterns

The operation in portType uses input and/or output to define the message exchange pattern

WSDL supports four basic patterns of operation1. One-way

2. Request-response

3. Solicit-response

4. Notification The one-way and request-

response are most often used



CIS 5930 Fall 2006 1204/10/23

The WSDL binding Element

The binding element provides specific details on how a portType operation will actually be transmitted over the wire

Bindings can be made available via multiple transports Multiple bindings for a single portType can be specified The binding element itself specifies name and type

attributes:

<binding name="Hello_Binding" type="tns:Hello_PortType">

The type attribute references the portType

CIS 5930 Fall 2006 1304/10/23

WSDL SOAP Bindings

WSDL 1.1 includes built-in extensions for SOAP 1.1

<binding name="Hello_Binding" type="tns:Hello_PortType"> <soap:binding style="rpc"

transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="sayHello"> <soap:operation soapAction="sayHello"/> <input> <soap:body encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/” namespace="urn:examples:helloservice” use="encoded"/> </input> <output> <soap:body encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/” namespace="urn:examples:helloservice” use="encoded"/> </output> </operation> </binding>

CIS 5930 Fall 2006 1404/10/23

WSDL SOAP Bindings (cont’d)

The soap:binding element indicates a SOAP binding over HTTP transport The style attribute indicates rpc for an RPC format or document for

a document-oriented message format The transport attribute defines the transport mechanism

The soap:operation element indicates the binding of a specific operation to a SOAP implementation The soapAction attribute specifies that the SOAPAction HTTP header

should be used for identifying the service (SOAP 1.1 only) The soap:body element specifies the details of the input and

output messages The encodingStyle attribute defines the encoding format when the

use attribute is encoded (RPC encoded) and the namespace attribute defines the RPC message namespace

For document/literal messaging, the use attribute is literal

CIS 5930 Fall 2006 1504/10/23

SOAP Request Message

An RPC request message uses the encodingStyle and namespace:

<?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/’ xmlns:soapenc='http://schemas.xmlsoap.org/soap/encoding/’ soap:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'> <soap:Body> <n:sayHello xmlns:n='urn:examples:helloservice'> <firstName xsi:type='xsd:string'>World</firstName> </n:sayHello> </soap:Body></soap:Envelope>

CIS 5930 Fall 2006 1604/10/23

SOAP Response Message

An RPC request message:

<?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/1999/XMLSchema-instance’ xmlns:xsd='http://www.w3.org/1999/XMLSchema'> <SOAP-ENV:Body> <ns1:sayHelloResponse xmlns:ns1='urn:examples:helloservice' SOAP-ENV:encodingStyle= 'http://schemas.xmlsoap.org/soap/encoding/'> <greeting xsi:type='xsd:string'>Hello, World!</greeting> </ns1:sayHelloResponse> </SOAP-ENV:Body></SOAP-ENV:Envelope>

CIS 5930 Fall 2006 1704/10/23

Using WSDL

Most Web service development toolkits support WSDL Generate WSDL from server (interface) code Translate WSDL to server objects and client proxies

Dynamic invocation obtains the WSDL, select an operation, populate the parameters and send the request message Generic SOAP client: http://www.soapclient.com/soaptest.html http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl

Find more WSDLs and code at http://www.xmethods.com

CIS 5930 Fall 2006 1804/10/23

Generating WSDL and Server Code with gSOAP Suppose we implement a HelloService with one operation sayHello

that takes a string parameter s and returns the string “Hello s” To bind XML namespaces to C (and C++) code, gSOAP uses a

prefix convention for function names and type names:

prefix_ _name

The service interface is defined in a header file containing the line:

int ns__sayHello(char *firstName, char **greeting);

To generate WSDL and server code (-S) or client code (-C) in C (-c) for SOAP RPC encoding (-e):

$ soapcpp2 -S -c -e hello.h

input output

CIS 5930 Fall 2006 1904/10/23

Implementing a Web Service with gSOAP

Add directives to the header file specification to define the service name, namespace, and endpoint:

//gsoap ns service name: hello//gsoap ns service namespace: urn:hello//gsoap ns service location: http://www.cs.fsu.edu/~engelen/hello.cgiint ns__sayHello(char *firstName, char **greeting);

CIS 5930 Fall 2006 2004/10/23

Implementing a Web Service with gSOAP (cont’d) The following files are generated:

soapStub.h annotated copy of the header filesoapH.h XML serializer declarationssoapC.c XML serializers for C/C++ typessoapServer.c SOAP server skeleton and dispatcherhello.nsmap XML namespace mapping tablehello.wsdl the service WSDLhello.sayHello.req.xml sample request messagehello.sayHello.res.xml sample response message

To complete the service, we create a C implementation of the sayHello function with the following parameters:

int ns__sayHello(struct soap *soap, char *firstName, char **greeting);

The first arg is the gSOAP engine context (runtime environment)

CIS 5930 Fall 2006 2104/10/23

Implementing a Web Service with gSOAP (cont’d) Implementation of the sayHello function in hello.c:

int ns__sayHello(struct soap *soap, char *firstName, char **greeting){ if (!firstName) return soap_sender_fault(soap, “No name!”, NULL); *greeting = (char*)soap_malloc(soap, strlen(firstName)+8); strcpy(*greeting, “Hello ”); strcat(*greeting, firstName); strcat(*greeting, “!”); return SOAP_OK;}

For a simple CGI-based service, add the service dispatcher:

#include “hello.nsmap”int main(){ return soap_serve(soap_new());}

Compile with gcc -o hello.cgi hello.c stdsoap2.c soapC.c soapServer.c

CIS 5930 Fall 2006 2204/10/23

Implementing a Web Service with gSOAP (cont’d) Deploy hello.cgi as a service in Apache (e.g. cgi-bin dir) and publish

hello.wsdl on the Web site To test the service over stdin/stdout, modify hello.sayHello.req.xml to

include a name string and run hello.cgi from the command line:$ ./hello.cgi < hello.sayHello.req.xml

To deploy as an iterative stand-alone service, use the following:#include “hello.nsmap”int main(){ struct soap *soap = soap_new(); soap_bind(soap, NULL, 8080, 100); for (;;) { if (soap_accept(soap) < 0) break; soap_serve(soap); soap_destroy(soap); soap_end(soap); } soap_print_fault(soap, stderr); soap_done(soap); free(soap); return 0;}

CIS 5930 Fall 2006 2304/10/23

Implementing a Concurrent Web Service with gSOAP #include “hello.nsmap”

int main(){ pthread_t tid; struct soap *soap = soap_new(); soap_bind(soap, NULL, 8080, 100); for (;;) { if (soap_accept(soap) < 0) break; pthread_create(&tid,NULL,(void*(*)(void*))serve,(void*)soap_copy(soap)); } soap_print_fault(soap, stderr); soap_done(soap); free(soap); return 0;}void *serve(void *soap){ pthread_detach(pthread_self()); soap_serve((struct soap*)soap); soap_destroy((struct soap*)soap); soap_end((struct soap*)soap); soap_done((struct soap*)soap); free(soap); return NULL;}int ns__sayHello(struct soap *soap, char *firstName, char **greeting) { … }

CIS 5930 Fall 2006 2404/10/23

Implementing a Client with gSOAP

Since we already have a gSOAP header file with the service definitions, we can also create a client from it:

$ soapcpp2 -C -c -e hello.h The client uses the stub call defined in soapClient.c:

#include “hello.nsmap”int main(){ struct soap *soap = soap_new(); char *s; if (soap_call_ns__sayHello(soap, NULL, NULL, “Robert”, &s)) soap_print_fault(soap, stderr); else printf(“The response is %s\n”, s); soap_destroy(soap); soap_end(soap); soap_done(soap); free(soap); return 0;}

Compile with gcc -o client client.c stdsoap2.c soapC.c soapClient.c

CIS 5930 Fall 2006 2504/10/23

Implementing a Service with ASP.NET in VB <%@ WebService Language="VB" Class="TempConvert" %>

Imports SystemImports System.Web.Services

Public Class TempConvert :Inherits WebService<WebMethod()> Public Function FahrenheitToCelsius(ByVal Fahrenheit As Int16) As Int16 Dim celsius As Int16 celsius = ((((Fahrenheit) - 32) / 9) * 5) Return celsiusEnd Function

<WebMethod()> Public Function CelsiusToFahrenheit(ByVal Celsius As Int16) As Int16 Dim fahrenheit As Int16 fahrenheit = ((((Celsius) * 9) / 5) + 32) Return fahrenheitEnd FunctionEnd Class

CIS 5930 Fall 2006 2604/10/23

Implementing a Client with SOAP::Lite for Perl

Example in Perl using the SOAP::Lite package:

use SOAP::Lite; print "Connecting to Hello Service...\n";print SOAP::Lite -> service('http://www.cs.fsu.edu/~engelen/hello.wsdl') -> sayHello ('World');

The program generates the following output:Connecting to Hello Service...Hello World!

CIS 5930 Fall 2006 2704/10/23

SOAP Fault messages

The gSOAP service may return a SOAP Fault: return soap_sender_fault(soap, “description”, detail);

If the problem is at the receiving side (SOAP-ENV:Server) use: return soap_receiver_fault(soap, “description”, detail);

Example SOAP Fault message:HTTP/1.1 500 Internal Server ErrorServer: gSOAP/2.7Content-Type: text/xml; charset=utf-8Content-Length: 520Connection: close

<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/” xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/” xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd="http://www.w3.org/2001/XMLSchema” xmlns:ns="urn:hello"> <SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Client</faultcode> <faultstring>No name!</faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body></SOAP-ENV:Envelope>

CIS 5930 Fall 2006 2804/10/23

SOAP 1.1 Faults

The SOAP Fault element has the following sub elements: <faultcode> A code for identifying the fault <faultstring> A human readable explanation of the fault <faultactor> Information about who caused the fault to happen (opt) <detail> Holds application specific error information

The faultcode values defined below must be used in the faultcode element when describing faults: VersionMismatch: Invalid namespace for the SOAP Envelope element MustUnderstand: An immediate child element of the Header element,

with the mustUnderstand attribute set to "1", was not understood Client: Message was incorrectly formed or contained incorrect info Server: There was a problem with the server and processing could not

proceed Note: SOAP 1.2 differs slightly (mostly element naming)

CIS 5930 Fall 2006 2904/10/23

WSDL and SOAP Faults

Faults in portType operations specify which faults may be returned:<message name="AuthenticationFault"> <part name="AuthenticationFault” element=”f:AuthenticationFault"/></message><portType name=“myPort”> <operation name=“getStatus”> <input message=“tns:getStatusRequest”/> <output message=“tns:getStatusResponse”/> <fault name=“fault” message=“tns:AthenticiationFault”/> </operation></portType><binding name=“myBinding” type=“myPort”> <operation name="getStatus"> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> <wsdl:fault name="AuthenticationFault"> <soap:fault name="AuthenticationFault" use="literal"/> </wsdl:fault> </operation></binding>

CIS 5930 Fall 2006 3004/10/23

SOAP Headers

The optional SOAP Header element contains SOAP processing information in one or more subelements, such as addressing and authentication, for example:

<SOAP-ENV:Envelope …> <SOAP-ENV:Header> <wsse:Security SOAP-ENV:mustUnderstand="1"> <wsse:UsernameToken wsu:Id="User"> <wsse:Username>engelen</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">/u5faawcfIeve1yHCsdXAWyIlbU=</wsse:Password> <wsse:Nonce>NDU0MGE5YjljYTUzYzAzZjA2MTc=</wsse:Nonce> <wsu:Created>2006-10-26T12:27:37Z</wsu:Created> </wsse:UsernameToken> </wsse:Security> </SOAP-ENV:Header> <SOAP-ENV:Body> … </SOAP-ENV:Body></SOAP-ENV:Envelope>

CIS 5930 Fall 2006 3104/10/23

SOAP Headers (cont’d)

The optional actor attribute may be used to address the Header element to a particular endpoint:

<SOAP-ENV:Header> <m:Transaction SOAP-ENV:actor=”endpoint URL” SOAP-ENV:mustUnderstand=“1”> … </m:Transaction> <wsse:Security>…</wsse:Security></SOAP-ENV:Header>

This allows the header information to be targeted at any intermediate SOAP processors for which this information is intended

The SOAP mustUnderstand attribute is used to indicate whether a header entry is mandatory or optional for the recipient to process

CIS 5930 Fall 2006 3204/10/23

SOAP Headers (cont’d)

The SOAP Header is a struct in gSOAP, defined in the header file:

#import “wsse.h” // get WSSE Security elementsstruct SOAP_ENV__Header{ mustUnderstand _m__Transaction *m__Transaction; mustUnderstand _wsse__Security *wsse__Security;};

and accessible in the soap context, for example:

soap.header.m__Transaction = new _m__Transaction();

CIS 5930 Fall 2006 3304/10/23

SOAP RPC Encoding

SOAP RPC encoding defines rules on representing primitive types, xs:simpleTypes (e.g. enumerations), array, and records (structs) as xs:complexTypes in XML

Closer to the notion of programming language types Full XML schema support is not possible

XML attributes not supported No element repetitions with maxOccurs=“unbounded” Only xs:sequence and xs:all, no xs:choice

CIS 5930 Fall 2006 3404/10/23

SOAP RPC Encoding (cont’d)

Primitive types Built-in XSD types, such as xs:string (see Schema specification) Schema xs:simpleTypes for elements, such as enumerations

<xs:simpleType name=”switch"> <xs:restriction base="xsd:token"> <xs:enumeration value=”on"/> <xs:enumeration value=”off"/> </xs:restriction></xs:simpleType>

Base64 (xs:base64Binary) and hex (xs:hexBinary) types

CIS 5930 Fall 2006 3504/10/23


Arrays are “SOAP encoded” arrays:

<xs:complexType name="ArrayOfstring"> <xs:complexContent> <xs:restriction base="SOAP-ENC:Array"> <xs:sequence> <xs:element name="item" type="xsd:string” minOccurs="0" maxOccurs="unbounded”/> </xs:sequence> <xs:attribute ref="SOAP-ENC:arrayType” wsdl:arrayType="xsd:string[]"/> </xs:restriction> </xs:complexContent> </xs:complexType>

Arrays are encoded in SOAP messages follows:

<inputStringArray SOAP-ENC:arrayType="xsd:string[2]"> <item xsi:type=“xsd:string”>hello</item> <item xsi:type=“xsd:string”>world!</item> </inputStringArray>

CIS 5930 Fall 2006 3604/10/23


Struct are just xs:complexTypes with xs:sequence (or xs:all):

<xs:complexType name=”lightSwitch"> <xs:sequence> <xs:element name=“light” type=“tns:switch”/> <xs:element name=“level” type=“xs:int”/> <xs:element name=“image” type=“xs:base64Binary”/> </xs:sequence> </xs:complexType>

CIS 5930 Fall 2006 3704/10/23

RPC versus Doc/lit in WSDL

Document/literal SOAP messages don’t include encodingStyle and XML types for request/responses are not constraint by the SOAP RPC encoding rules

Document style and literal use are declared in the bindings:

<binding type="glossaryTerms" name="b1"><soap:binding style="document” transport="http://schemas.xmlsoap.org/soap/http"/> <operation> <soap:operation soapAction="http://example.com/getTerm"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation></binding>

CIS 5930 Fall 2006 3804/10/23

RPC versus Doc/lit in WSDL (cont’d) The parts in messages now refer to elements, which will be the

request/response elements in the SOAP Body

<definitions xmlns:m=“urn:examples:tempservice” …>

<message name="getTermRequest"> <part name="term" element=”m:getTemp"/> </message>

<message name="getTermResponse"> <part name="value" element=”m:getTempResult"/> </message>

<portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation> </portType>

CIS 5930 Fall 2006 3904/10/23

RPC versus Doc/lit in WSDL (cont’d) The parts in messages refer to elements that define the request and response

elements in the SOAP Body of a message:

<types> <xs:schema xmlns:xs=“http://www.w3.org/2001/XMLSchema” targetNamespace=“urn:examples:tempservice” … elementFormDefault=“qualified” attributeFormDefault=“unqualified”> <xs:element name=“getTemp”> <xs:complexType> <xs:sequence> <xs:element name=“zipCode” type=“xs:string”/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=“getTempResult”> <xs:complexType> <xs:sequence> <xs:element name=“temp” type=“xs:float”/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> </types>

CIS 5930 Fall 2006 4004/10/23

SOAP Request Message in Doc/Lit Style Note the absence of SOAP-ENC:encodingStyle and xsi:type in the

message:

<?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> <n:getTemp xmlns:n='urn:examples:tempservice'> <n:zipCode>32306</n:zipCode> </n:getTemp> </soap:Body></soap:Envelope>

CIS 5930 Fall 2006 4104/10/23

SOAP Multi-ref Encoding

SOAP operation (request/response)

The XSD type system to represent values of primitive types in XML, such as bool, integer, float, string, base64

A SOAP array type to encode sparse and partial arrays

Id-href XML attributes to implement graph edges to encode multi-ref objects

<env:Envelope> <env:Body env:encodingStyle=“…”> <ns:myRemoteOp> <arg1 xsi:type=“xsd:int”>123</arg1> <arg2 enc:arrayType=“xsd:string[5]”> <item>abc</item> <item href=“#_1”/> <item href=“#_1”/> <item href=“#_2”/> <item enc:position=“[5]”>xyz</item> </arg2> </ns:myRemoteOp> <mref id=“_1”>abc</mref> <mref id=“_2”>def</mref> </env:Body></env:Envelope>

CIS 5930 Fall 2006 4204/10/23

Static Structure Analysis forSOAP RPC Encoding

Structure

XML Schema

<complexType name=“X”> <sequence> <element name=“y” type=“tns:Y”/> <element name=“z” type=“tns:Z”/> </sequence> …</complexType>

<complexType name=“X”> <sequence>…</sequence></complexType><complexType name=“Y”> <sequence>…</sequence></complexType

<complexType name=“X”> <sequence>…</sequence></complexType

Example XML Instance

<x> <y>…</y> <z>…</z> …</x>

<x> <y href=“#123”/> … <y href=“#123”/> …</x>…<mref id=“123”>…</mref>

<x> <x href=“#456”/> … <x href=“#456”/> …</x>…<mref id=“456”>…</mref>

X

Y Z

X

Y

X X

X

X

CIS 5930 Fall 2006 4304/10/23

gSOAP Constructs a Plausible Object Model for Serialization

typedef int SSN;

struct Node{ int val; int *ptr; float num; struct Node *next;};

val ptr num next

Node

SSN

Data model graph(arcs denote all possible

pointer references)

Source code typedefinitions

CIS 5930 Fall 2006 4404/10/23

Generating an XML Schema Definition for Serialized XML

val ptr num next

Node

SSN

<simpleType name=“SSN”> <restriction base=“int”/></simpleType>

<complexType name=“Node”> <sequence> <element name=“val” type=“int”/> <element name=“ptr” type=“int” minOccurs=“0”/> <element name=“num” type=“float”/> <element name=“next” type=“tns:Node” minOccurs=“0”/> </sequence></complexType>Data model graph

CIS 5930 Fall 2006 4504/10/23

Generating Code for Runtime Points-To Analysis

serialize_pointerToint(int *p){ if (p != NULL) { // lookup and mark (p,TYPE_int) // as target in ptr hash table }}

serialize_Node(struct Node *p){ if (p != NULL) { // lookup and mark (p,TYPE_Node) // as target in ptr hash table mark_embedded(&p->val,TYPE_int); serialize_pointerToint(p->ptr); // skip p->num serialize_pointerToNode(p->next); }}

val ptr num next

Node

SSN

Data model graph

CIS 5930 Fall 2006 4604/10/23

Generating Serialization Codeput_pointerToint(int *p){ if (p != NULL) { // lookup (p,TYPE_int) // if embedded, then output “ref” // if single, then output value // if multi, then output value // with “id” and mark embedded }}

put_Node(struct Node *p){ if (p != NULL) { // lookup (p,TYPE_Node) // if embedded, then output “ref” // if single, then output value // if multi, then output value // with “id” and mark embedded put_int(&p->val); put_pointerToint(p->ptr); put_float(&p->num) put_pointerToNode(p->next); }}

val ptr num next

Node

SSN

CIS 5930 Fall 2006 4704/10/23

Serialization Example

val=123

ptr=B

num=1.4

next=B

=789

Nodeloc=A

SSNloc=C

val=456

ptr=C

num=2.3

next=A

Nodeloc=B

ID PtrLoc PtrType PtrSize PtrCount RefType

1 A Node 16 2 multi

2 B int 4 1 embedded

3 B Node 16 1 single

4 C int 4 1 single

Ptr hash table after runtime points-to analysis by thegenerated algorithm constructed from the data model

CIS 5930 Fall 2006 4804/10/23

Serialization Example (cont’d)

val=123

ptr=B

num=1.4

next=B

=789

Nodeloc=A

SSNloc=C

val=456

ptr=C

num=2.3

next=A

Nodeloc=Bembedded, id=2

multi, id=1

single

single

multi, id=1

CIS 5930 Fall 2006 4904/10/23


val=123

ptr=B

num=1.4

next=B

=789

Nodeloc=A

SSNloc=C

val=456

ptr=C

num=2.3

next=A

Nodeloc=B

<Node id=“_1”> </Node>

embedded, id=2

multi, id=1

single

single

multi, id=1

CIS 5930 Fall 2006 5004/10/23


val=123

ptr=B

num=1.4

next=B

=789

Nodeloc=A

SSNloc=C

val=456

ptr=C

num=2.3

next=A

Nodeloc=B

<Node id=“_1”> <val>123</val> </Node>

embedded, id=2

multi, id=1

single

single

multi, id=1

CIS 5930 Fall 2006 5104/10/23


val=123

ptr=B

num=1.4

next=B

=789

Nodeloc=A

SSNloc=C

val=456

ptr=C

num=2.3

next=A

Nodeloc=B

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> </Node>

embedded, id=2

multi, id=1

single

single

multi, id=1

CIS 5930 Fall 2006 5204/10/23


val=123

ptr=B

num=1.4

next=B

=789

Nodeloc=A

SSNloc=C

val=456

ptr=C

num=2.3

next=A

Nodeloc=B

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> <num>1.4</num> </Node>

embedded, id=2

multi, id=1

single

single

multi, id=1

CIS 5930 Fall 2006 5304/10/23


val=123

ptr=B

num=1.4

next=B

=789

Nodeloc=A

SSNloc=C

val=456

ptr=C

num=2.3

next=A

Nodeloc=B

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> <num>1.4</num> <next>

</next> </Node>

embedded, id=2

multi, id=1

single

single

multi, id=1

CIS 5930 Fall 2006 5404/10/23


val=123

ptr=B

num=1.4

next=B

=789

Nodeloc=A

SSNloc=C

val=456

ptr=C

num=2.3

next=A

Nodeloc=B

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> <num>1.4</num> <next> <val id=“_2”>456</val> </next>

</Node>

embedded, id=2

multi, id=1

single

single

multi, id=1

CIS 5930 Fall 2006 5504/10/23


val=123

ptr=B

num=1.4

next=B

=789

Nodeloc=A

SSNloc=C

val=456

ptr=C

num=2.3

next=A

Nodeloc=B

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> <num>1.4</num> <next> <val id=“_2”>456</val> <ptr>789</ptr> </next>

</Node>

embedded, id=2

multi, id=1

single

single

multi, id=1

CIS 5930 Fall 2006 5604/10/23


val=123

ptr=B

num=1.4

next=B

=789

Nodeloc=A

SSNloc=C

val=456

ptr=C

num=2.3

next=A

Nodeloc=B

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> <num>1.4</num> <next> <val id=“_2”>456</val> <ptr>789</ptr> <num>2.3</num> </next>

</Node>

embedded, id=2

multi, id=1

single

single

multi, id=1

CIS 5930 Fall 2006 5704/10/23


val=123

ptr=B

num=1.4

next=B

=789

Nodeloc=A

SSNloc=C

val=456

ptr=C

num=2.3

next=A

Nodeloc=B

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> <num>1.4</num> <next> <val id=“_2”>456</val> <ptr>789</ptr> <num>2.3</num> <next ref=“#_1”/> </next>

</Node>

embedded, id=2

multi, id=1

single

single

multi, id=1

CIS 5930 Fall 2006 5804/10/23


val=123

ptr=B

num=1.4

next=B

=789

Nodeloc=A

SSNloc=C

val=456

ptr=C

num=2.3

next=A

Nodeloc=B

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> <num>1.4</num> <next> <val id=“_2”>456</val> <ptr>789</ptr> <num>2.3</num> <next ref=“#_1”/> </next></Node>

embedded, id=2

multi, id=1

single

single

multi, id=1

CIS 5930 Fall 2006 5904/10/23

Deserialization Example

<Node id=“_1”> </Node>

val=?

ptr=?

num=?

next=?

Node

id=1

Recursive descent parsingwith object deserializationoperations as semantic actions

CIS 5930 Fall 2006 6004/10/23

Deserialization Example (cont’d)

val=123

ptr=?

num=?

next=?

Node

<Node id=“_1”> <val>123</val> </Node>

id=1


CIS 5930 Fall 2006 6104/10/23


val=123

ptr=?

num=?

next=?

Node

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> </Node>

id=1

ref=2(unresolved)


CIS 5930 Fall 2006 6204/10/23


val=123

ptr=?

num=1.4

next=?

Node

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> <num>1.4</num>

</Node>

id=1

ref=2(unresolved)


CIS 5930 Fall 2006 6304/10/23


val=123

ptr=?

num=1.4

next=B

Node

val=?

ptr=?

num=?

next=?

Node

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> <num>1.4</num> <next> </next></Node>

id=1

ref=2(unresolved)


CIS 5930 Fall 2006 6404/10/23


val=123

ptr=B

num=1.4

next=B

Node

val=456

ptr=?

num=?

next=?

Node

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> <num>1.4</num> <next> <val id=“_2”>456</val> </next></Node>

id=1

id=2


CIS 5930 Fall 2006 6504/10/23


val=123

ptr=B

num=1.4

next=B

=789

Node

val=456

ptr=C

num=?

next=?

Node

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> <num>1.4</num> <next> <val id=“_2”>456</val> <ptr>789</ptr>

</next></Node>

id=1

id=2


CIS 5930 Fall 2006 6604/10/23


val=123

ptr=B

num=1.4

next=B

=789

Node

SSN

val=456

ptr=C

num=2.3

next=?

Node

<Node id=“_1”> <val>123</val> <ptr ref=“#_2”/> <num>1.4</num> <next> <val id=“_2”>456</val> <ptr>789</ptr> <num>2.3</num>

</next></Node>

id=1

id=2


CIS 5930 Fall 2006 6704/10/23


val=123

ptr=B

num=1.4

next=B

=789

Node

SSN

val=456

ptr=C

num=2.3

next=A

Node


id=1


CIS 5930 Fall 2006 6804/10/23


val=123

ptr=B

num=1.4

next=B

=789

Node

SSN

val=456

ptr=C

num=2.3

next=A

Node


id=1


CIS 5930 Fall 2006 6904/10/23

Converting a WSDL to Code with gSOAP The wsdl2h tool converts a (set of) WSDL files and schemas to a header file The header file is then processed by soapcpp2 as before

CIS 5930 Fall 2006 7004/10/23

WS-* Protocols and Plugins

CIS 5930 Fall 2006 7104/10/23

SOAP With MTOM Attachments

Raw binary data can be transported in a SOAP message as base64 MTOM (Message Transmission Optimization Mechanism) using

MIME attachments to carry binary data with a SOAP message Supports embedding of type and other information Allows streaming (attachments produced on demand) Example HTTP header for SOAP with MTOM:

POST / HTTP/1.1Host: www.example.comContent-Type: multipart/related;

boundary=”mimeboundary";type="application/xop+xml";start="<soapmsg>";start-info="application/soap+xml;charset=utf-8"

CIS 5930 Fall 2006 7204/10/23

SOAP With MTOM Attachments (cont’d) Example HTTP body with SOAP message and MTOM attachment:

--mimeboundaryContent-Type: application/xop+xml;charset=utf-8;type=application/soap+xmlContent-Transfer-Encoding: binaryContent-ID: <soapmsg>

<SOAP-ENV:Envelope xmlns:SOAP-ENV=”…” xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:xmlmime="http://www.w3.org/2004/11/xmlmime" <SOAP-ENV:Body> <m:PutImage xmlns:m="http://www.example.com/test.wsdl"> <m:data xmlmime:contentType=”image/jpeg"> <xop:Include href="cid:image"/> </m:data> </m:PutImage> </SOAP-ENV:Body></SOAP-ENV:Envelope>--mimeboundaryContent-Type: image/jpegContent-Transfer-Encoding: binaryContent-ID: <image>

… image data …--mimeboundary--

CIS 5930 Fall 2006 7304/10/23

WS-Addressing

WS-Addressing is a Web services protocol for routing messages (request, response, and faults)

Supports message transmission through networks with processing nodes such as endpoint managers, firewalls, and gateways

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> <S:Header> <wsa:MessageID> uuid:6B29FC40-CA47-1067-B31D-00DD010662DA </wsa:MessageID> <wsa:ReplyTo> <wsa:Address>http://business456.example/client1</wsa:Address> </wsa:ReplyTo> <wsa:To>http://fabrikam123.example/Purchasing</wsa:To> <wsa:Action>http://fabrikam123.example/SubmitPO</wsa:Action> </S:Header> <S:Body> ... </S:Body></S:Envelope>

CIS 5930 Fall 2006 7404/10/23

WS-Addressing (cont’d)

WS-Addressing header elements within the SOAP Header: <wsa:MessageID> xs:anyURI </wsa:MessageID>

defines a unique message ID, e.g. UUID (optional) <wsa:RelatesTo RelationshipType="..."?> xs:anyURI </wsa:RelatesTo>

conveys the message ID of the related message, e.g. the request message ID when this is a reply message (required for responses)

<wsa:To> xs:anyURI </wsa:To>the destination address (required)

<wsa:Action> xs:anyURI </wsa:Action>conveys the SOAP action property (required)

<wsa:From> endpoint-reference </wsa:From>the source endpoint information (optional)

<wsa:ReplyTo> endpoint-reference </wsa:ReplyTo>the reply endpoint (required for request with an expected reply)

<wsa:FaultTo> endpoint-reference </wsa:FaultTo> the fault endpoint (optional)

CIS 5930 Fall 2006 7504/10/23

WS-Security

WS-Security provides message-level security HTTPS provides end-to-end transport-level security

Authentication Username and (digest) password (with nonce, timestamps)

Digital signatures XML DSig with DSA, HMAC, … Can sign all or specific parts of the message Embedding of security tokens such as certificates Support for SAML

Encryption XML Enc with RSA, …

CIS 5930 Fall 2006 7604/10/23

Username Token

The Username token security header in wsse:Security contains a username and password in plain text or a digest password:

<SOAP-ENV:Envelope xmlns:SOAP-ENV=“…” xmlns:wsse=“…” xmlns:wsu=“…”> <SOAP-ENV:Header> <wsse:Security SOAP-ENV:mustUnderstand="1"> <wsse:UsernameToken wsu:Id="User"> <wsse:Username>engelen</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">/u5faawcfIeve1yHCsdXAWyIlbU=</wsse:Password> <wsse:Nonce>NDU0MGE5YjljYTUzYzAzZjA2MTc=</wsse:Nonce> <wsu:Created>2006-10-26T12:27:37Z</wsu:Created> </wsse:UsernameToken> </wsse:Security> </SOAP-ENV:Header> <SOAP-ENV:Body> … </SOAP-ENV:Body></SOAP-ENV:Envelope>

CIS 5930 Fall 2006 7704/10/23

Security Timestamps

A timestamp can be included to define the lifetime of a message The timestamp will only be tamper proof when digitally signed,

hence the wsu:Id which is referenced by the signature info

<SOAP-ENV:Envelope …> <SOAP-ENV:Header> <wsse:Security> <wsu:Timestamp wsu:Id="timestamp"> <wsu:Created>2001-09-13T08:42:00Z</wsu:Created> <wsu:Expires>2001-10-13T09:00:00Z</wsu:Expires> </wsu:Timestamp> ... </wsse:Security> ... </SOAP-ENV:Header> <SOAP-ENV:Body> ... </SOAP-ENV:Body></SOAP-ENV:Envelope>

CIS 5930 Fall 2006 7804/10/23

Signatures

The wsse:BinarySecurityToken contains the public key The ds:Signature element contains signature info with digest value for

each signed message part and the signature value

<wsse:Security> <wsse:BinarySecurityToken wsu:Id=“X509Token” …> public key </wsse:BinarySecurityToken> <ds:Signature> <ds:SignedInfo> what is signed: reference URI to signed part with digest of that XML message part how it is signed: digests algorithms and canonicalization of XML </ds:SignedInfo> <ds:SignatureValue> signature </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Token"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature></wsse:Security>

CIS 5930 Fall 2006 7904/10/23

Signature Example<wsse:Security> <wsse:BinarySecurityToken …> … </wsse:BinarySecurityToken> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#myBody"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>EULddytSo1...</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>BL8jdfToEb1l/vXcMZNNjPOV...</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Token"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature></wsse:Security>

CIS 5930 Fall 2006 8004/10/23

List of WS-* Protocols

Messaging SOAP SOAP with Attachments (SwA) SOAP with MTOM (Message Transmission Optimization

Mechanism) XML-RPC: a simpler XML RPC format (no WSDL or schemas) WS-Addressing: routing, endpoints, and addressing properties

Service description WSDL WS-MetadataExchange: how an endpoint can request the

various types of metadata it may need to effectively communicate with the service

WS-Policy: describes the capabilities, requirements, and general characteristics of a service

CIS 5930 Fall 2006 8104/10/23

List of WS-* Protocols

Directory access and discovery UDDI (Universal Description, Discovery, and Integration) v2/v3 WS-Discovery: a multicast discovery protocol to locate services on a

network Managing services

WS-Management: for management of servers, devices, applications Transaction-based services

WS-Transaction: describes the coordination types atomic transaction (TA) and business activity (BA)

Publish/subscribe WS-Eventing WS-Notification

Security and reliability HTTPS (transport-level) WS-Security (message-level) WS-ReliableMessaging

CIS 5930 Fall 2006 8204/10/23

Other Notable WS-* Protocols

Managing resources: Web Services Resource Framework (WSRF) WS-ResourceProperties: defines are resource’s properties WS-ResourceLifetime: inspect and monitor the lifetime of a resource WS-ServiceGroup: defines how resources are grouped together for a

domain specific purpose (service classification and constraints) WS-BaseFaults: defines faults related to resource management

Managing resources WS-Transfer: operations for sending and receiving the representation of

a given resource and operations for creating and deleting a resource Best practices

Provide additional information to improve interoperability between vendor implementations

WS-I Basic profile (BP1.0a, BP1.1) WS-I Basic security profile

CIS 5930 Fall 2006 8304/10/23

Other Notable WS-* Protocols

Device Profile for Web Services (DPWS) Goals similar to universal plug and play (UPnP) Seamless integration and discovery of devices over the Internet

Printing, scanning, etc. over Internet by discovering these services Uploading images from camera to PC over the (wireless) Internet

Microsoft Vista natively integrates DPWS Builds on

WS-Eventing (publish/subscribe) WS-Discovery WS-Addressing WS-Security WS-Policy WS-MetaExchange

CIS 5930 Fall 2006 8404/10/23

To be continued…

xml and soap web services

Documents

wsdl wsdl

wsdl message elements

request message

wsdl soap bindings wsdl

wsdl namespace

service provider wsdl

wsdl porttype element

wsdl binding element