Web Services. Distributed Object Systems 11. Web Services, SOAP and NET. Web Applications. Web Services. Web services vs Distributed Objects

Full text


Distributed Object Systems

– 11 –

Web Services, SOAP and ·NET

Piet van Oostrum Oct. 16, 2007


Web Services

Some Definitions

I “A Web Service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically 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.” (W3C)

I “Web Services are Web-based enterprise applications that use open, XML-based standards and transport protocols to exchange data with calling clients.” (Sun)

Piet van Oostrum DOS-11 1


Web Services

More Definitions

I “Web Services is a technology that allows applications to communicate with each other in a platform- and programming language-independent manner. A Web Service is a software

interface that describes a collection of operations that can be accessed over the network through standardized XML messaging. It uses protocols based on the XML

language to describe an operation to execute or data to exchange with another Web Service. A group of Web services interacting together in this manner defines a particular Web service application in a Service-Oriented Architecture (SOA).” (IBM)

I “Often, the term Web Services is used to generate hype rather than to describe real technological advances.” (Aaron Skonnard, Microsoft)

Piet van Oostrum DOS-11 2


Web Applications

Web Application:

I Programs and resources embedded in, or accessed through, a

Web server Two kinds:

I Presentation oriented, built around (dynamic) HTML pages

intended for people

I Service oriented, a Web Service made available to other applications through XML and HTTP protocols

intended for computers/programs

⇒ A Web Service is software on local or remote machine with a set of well defined interfaces (ports) specified in XML (WSDL)

Piet van Oostrum DOS-11 3


Web Services/SOA

Used for

I EAI (Enterprise Application Integration): integrating the various applications in an enterprise with each other. I B2Bi (Business-to-Business Integration): the business

interactions between different enterprises.

I “Service-Oriented Architecture (SOA) is a component model

that inter-relates an application’s different functional units, called services, through well-defined interfaces and contracts between these services. The interface is defined in a neutral manner that should be independent of the hardware platform, the operating system, and the programming language in which the service is implemented. This allows services, built on a variety of such systems, to interact with each other in a uniform and universal manner.” (IBM)

Piet van Oostrum DOS-11 4


Web services vs Distributed Objects

I Web Services (WS) and Distributed Objects (DO) are similar

but there are differences

I Both involve distributed entities but Web Services are more loosely coupled

I Both are (more or less) based on the RPC paradigm

I WS interact with messages; DO with RPC

I DO have âĂIJfactoriesâĂİ; WS manage instances internally

(not really OO)

I DO have explicit state (stateful services)

I WS use context in the messages to link interactions (stateful interactions)



Web Services structure

UDDI Universal Description, Discovery

and Integration

WSDL Web Services Description Lan-guage

SOAP Simple Object Access Protocol

XSD language neutral type descriptions

XML eXtensible Markup Language

Piet van Oostrum DOS-11 6



I WSDL – Web Services Description Language

I Uses XML to describe Web Services I Used as an IDL for SOAP

I Can be used as a more general description mechanism I Uses XML schemas for types (XSD)

I UDDI - Universal Description, Discovery and Integration I Kind of telephone directory for Web Services (yellow pages) I WS-I (Web Services Interoperability) organisation maintains


Piet van Oostrum DOS-11 7


Current Java standard support

I Java Platform, Enterprise Edition (Java EE) provides the APIs and tools

I Java API for XML-based RPC (JAX-RPC) uses SOAP and


I client programs can make XML-based remote procedure calls.

I supports WSDL

I with JAX-RPC and a WSDL, can interoperate with clients

and services running on Java-based or non-Java-based platforms such as .NET.

I The SOAP with Attachments API for Java (SAAJ) enables to

produce and consume messages conforming to the SOAP 1.1 specification and SOAP with Attachments.

I JAX-RPC is now called JAX-WS (it is not only RPC).

I Some people think it is quite bad

Piet van Oostrum DOS-11 8


SOAP request body

I The SOAP request body contains an XML document

I The document has a SOAP envelope, SOAP headers and a

SOAP body

I These are all XML elements

I It uses namespaces

I The namespace of the SOAP envelope determines the SOAP


I Namespaces used:

I SOAP message (envelope, header, body) namespace I SOAP Encoding namespace

I namespace for the methods

I XML Schema namespace (for schema tags) I XML Schema types (for standard types)

I maybe namespaces for transactions, own types and marshalling


Piet van Oostrum DOS-11 9


SOAP use

I SOAP is not yet a mature system like Corba or COM

I No (general) support for object creation, object references etc.

I How to use:

I Write your own support

I Microsoft .NET uses SOAP internally I Microsoft SOAP SDK

I SOAP for Java: Apache or Axis I Apache SOAP:

I originally developed by IBM I uses special objects and methods, e.g.

I org.apache.soap.rpc.Call object

I Python support is available (but not standard)

Piet van Oostrum DOS-11 10


SOAP styles

There are different ways in which SOAP can be used I RPC - like remote procedure call:

request and response

I Message oriented:

Only one message is sent

Response message may be sent asynchronously and processed independently

Corresponding to this there are different styles of encoding the input and/or output:

I RPC style:

data is encoded (in XML) as methodname + list of parameters I document style:

data is encoded as an XML document



RPC style encoding

public void myMethod(int x, float y); WSDL example:

<message name="myMethodRequest"> <part name="x" type="xsd:int"/> <part name="y" type="xsd:float"/> </message> <message name="empty"/> <portType name="MyPort"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType> <binding style="rpc" .../>

Piet van Oostrum DOS-11 12


Port Type / Service / Binding

I A port type component describes a set of messages that a service sends and/or receives. It does this by grouping related messages into operations. An operation is a set of input and output messages, a port type is a set of operations. I A port type can optionally extend one or more other port

types. In such cases the port type contains the operations of the port types it extends, along with any operations it defines. (So port types are similar to interfaces in COM and Corba) I A service component describes the set of port types that a

service provides and the ports they are provided over. I A binding component described a concrete binding of a port

type component and associated operations to a particular concrete message format and

transmission protocol.

Piet van Oostrum DOS-11 13



<wsdl:binding name="MyBinding" ...> <wsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="myMethod"> <wsoap:operation soapAction="urn:MyInterface#myMethod"/> <wsdl:input>

<wsoap:body use="encoded" namespace="..." encodingStyle="..."/> </wsdl:input> ... </wsdl:operation> </wsdl:binding> <wsdl:service name="MyService"> <wsdl:port name="MyPort" binding="..."> </wsdl:port> </wsdl:service>

Piet van Oostrum DOS-11 14


SOAP message

Namespaces used: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" SOAP message: <soap:envelope> <soap:body> <myMethod> <x xsi:type="xsd:int">5</x> <y xsi:type="xsd:float">5.0</y> </myMethod> </soap:body> </soap:envelope>

Piet van Oostrum DOS-11 15



I This is called the RPC/encoded style, because it contains type info

I The operation name appears in the message (easy for receiver to dispatch)

I The type encoding info (such as xsi:type="xsd:int") is maybe just overhead

I But it may be useful for overloading

I You cannot easily validate this message since there is no schema defining the message (only the x and y part)

I RPC/encoded is not WS-I compliant.

Piet van Oostrum DOS-11 16


RPC/literal style

WSDL is almost the same, except there is a use="literal" instead of use="encoded" in the binding part.

SOAP message: <soap:envelope> <soap:body> <myMethod> <x>5</x> <y>5.0</y> </myMethod> </soap:body> </soap:envelope>

The type info has disappeared.



Document/literal style



<element name="xElement" type="xsd:int"/> <element name="yElement" type="xsd:float"/> </schema>


<message name="myMethodRequest"> <part name="x" element="xElement"/> <part name="y" element="yElement"/> </message> <message name="empty"/> <portType name="MyPort"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType>

Piet van Oostrum DOS-11 18



I Document/encoded style is not used.

We use only Document/literal style.

I There is a schema definition in the WSDL

I The parameters have an element name


<element name="xElement" type="xsd:int"/> <element name="yElement" type="xsd:float"/> </schema>


<part name="x" element="xElement"/>

Piet van Oostrum DOS-11 19


SOAP message

<soap:envelope> <soap:body> <xElement>5</xElement> <yElement>5.0</yElement> </soap:body> </soap:envelope> Notes:

I There is no type encoding info. I You can validate this message

Everything within the soap:body is defined in a schema.

I The operation name in the SOAP message is lost.

I WS-I only allows one child of the soap:body in a SOAP


This example’s soap:body has two children.

Piet van Oostrum DOS-11 20


Document/literal wrapped

This style wraps a document root with the method name around the parameters

<message name="myMethodRequest">

<part name="parameters" element="myMethod"/> </message>

<message name="empty">

<part name="parameters" element="myMethodResponse"/> </message>

Piet van Oostrum DOS-11 21


Document/literal wrapped

<types> <schema> <element name="myMethod"> <complexType> <sequence>

<element name="x" type="xsd:int"/> <element name="y" type="xsd:float"/> </sequence> </complexType> </element> <element name="myMethodResponse"> <complexType/> </element> </schema> </types>

Piet van Oostrum DOS-11 22


SOAP message

<soap:envelope> <soap:body> <myMethod> <x>5</x> <y>5.0</y> </myMethod> </soap:body> </soap:envelope>

I Looks like the RPC/literal style I in RPC it is the method name

I here it is the root element of the document

I Document style can be used to pass any type of XML

document, not only a parameter list

I The message can be validated (there is a schema)

I No type info in the message (difficult in case of overloading)

I There is a method name



Advantages of document style

I You can use any XML document as input or output

I You are not bound to a fixed interface (in the IDL sense) I Gives more flexibility

I Good for asynchronous processing

Piet van Oostrum DOS-11 24


Python example

I Python has callable objects

I Class can override the call () operator

I Undefined method names and attributes can be intercepted

I SOAPpy and ZSI (Zolera SOAP Infrastructure) are two

open-source SOAP libraries for Python

I These are not yet complete (mainly RPC style)

I (http://www.xmethods.com/ contains a list of free SOAP


I E.g. currency exchange (how many dollars per euro?)

Piet van Oostrum DOS-11 25


Python example

from SOAPpy import SOAPProxy

url = "http://xurrency.com/servidor_soap.php" namespace = "http://xurrency.com/api.wsdl" server = SOAPProxy(url, namespace)

server.config.dumpSOAPOut = True server.config.dumpSOAPIn = True print server.getValue(100,"eur","usd") Using WSDL:

from SOAPpy import WSDL

WSDLFILE=’http://xurrency.com/servidor_soap.php?wsdl’ server=WSDL.Proxy(WSDLFILE)

server.soapproxy.config.dumpSOAPOut = True server.soapproxy.config.dumpSOAPIn = True print server.getValue(100,"eur","usd")

Piet van Oostrum DOS-11 26


WSDL extract

<message name="getValueRequest">

<part name="amount" type="xsd:float" /> <part name="base" type="xsd:string" />

<part name="target" type="xsd:string" /></message> <message name="getValueResponse">

<part name="return" type="xsd:float" /></message> ... <portType name="xurrencyPortType"> ... <operation name="getValue"> <input message="tns:getValueRequest"/> <output message="tns:getValueResponse"/> </operation> </portType>

Piet van Oostrum DOS-11 27


WSDL extract

<binding name="xurrencyBinding" type="tns:xurrencyPortType">

<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> ... <operation name="getValue"> <soap:operation soapAction="http://xurrency.com/servidor_soap.php/getValue" style="rpc"/> <input><soap:body use="encoded" namespace="http://xurrency.com/xurrency.wsdl" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output>...</output> </operation> </binding> <service name="xurrency">

<port name="xurrencyPort" binding="tns:xurrencyBinding">

<soap:address location="http://xurrency.com/servidor_soap.php"/> </port>


Piet van Oostrum DOS-11 28



*** Outgoing SOAP ****************************************************** <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" > <SOAP-ENV:Body>

<ns1:getValue xmlns:ns1="http://xurrency.com/xurrency.wsdl" SOAP-ENC:root="1"> <v1 xsi:type="xsd:int">100</v1> <v2 xsi:type="xsd:string">eur</v2> <v3 xsi:type="xsd:string">usd</v3> </ns1:getValue> </SOAP-ENV:Body> </SOAP-ENV:Envelope> ************************************************************************




*** Incoming SOAP ****************************************************** <?xml version="1.0" encoding="ISO-8859-1"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <ns1:getValueResponse xmlns:ns1="http://xurrency.com/xurrency.wsdl"> <return xsi:type="xsd:float">136.2500</return> </ns1:getValueResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> ************************************************************************ 136.25

Piet van Oostrum DOS-11 30


SOAP servers

I SOAP services run in an HTTP server (when protocol is


I Could be standard HTTP server, like Apache, Tomcat

I Often run in Application server like IBM Websphere or JBoss (together with EJB)

I Or run server with its own HTTP request processing

I Some of these frameworks have a HTTP server built in

Piet van Oostrum DOS-11 31


Example CGI scripts (using Python ZSI)

def hello():

return "Hello, world" def echo(*args):

return args def average(*args):

sum = 0

for i in args: sum += i return sum / len(args) from ZSI import dispatch dispatch.AsCGI()

This makes all the methods (functions) in the module available as Web Services.

Piet van Oostrum DOS-11 32



Piet van Oostrum DOS-11 33



I What is .NET?

I Collection of software (libraries, programming languages,

compilers, tools, protocols) for interoperability

I Both local and distributed

I Why?

I Difficult to connect different programming languages I calling conventions are different

I data types are different I memory management doesn’t fit I No inheritance between different languages I Difficult to connect remote systems

I DCOM/Corba etc require special code

Piet van Oostrum DOS-11 34


.NET solutions

I Common Language Runtime

I One runtime system for all languages I share libraries

I share memory management



Intermediate code

I All .NET compilers compile to an intermediate code

I MSIL = Microsoft Intermediate Language

I Can also be ported to other systems

(Mono is an open source project cloning .NET)

I Compare Java or Python Bytecode

I MSIL contains a lot of information about source (types, names, etc)

I MSIL can be interpreted

I Usually MSIL is compiled to native code “just in time” (JIT) I Probably for future systems (64-bit)

Piet van Oostrum DOS-11 36



Piet van Oostrum DOS-11 37


Common Type System

I A type system for all programming languages in .NET

I Different programming languages can use each other’s types I Including inheritance

System Value


User Value Types

Value Types Reference Types

Pointers Interfaces Self-describing Types Arrays Enumerations Types

Delegates Boxed values User Defined


Piet van Oostrum DOS-11 38



I Value types

I Are passed by value

I Usually allocated on the stack I Copy semantics

I Like Corba value types RMI, value parameters I Includes standard types int, bool, float . . .

I These areboxedorunboxed(Put into an object) if necessary I Can define own value types, with methods

I Reference types

I Are passed by reference I Usually allocated on the heap I Pointer semantics

I Some are garbage collected

Piet van Oostrum DOS-11 39


Managed/unmanaged pointers

I Managed pointers

I are under control of the CLR I This includes garbage collection I Meta information (type) is put into IL I Can only be used safely

I Unmanaged pointers

I Are unsafe

I under complete control of the program I E.g. old-fashioned C/C++ pointers I Necessary for e.g. the garbage collector

Piet van Oostrum DOS-11 40


Managed/unmanaged code

I Managed code

I Uses managed pointers I Is safe for the CLR I Supports garbage collection I Full access to all .NET facilities

I Unmanaged code

I Can use unmanaged pointers I Is unsafe

I Do your own mewmory management




I C#

I Java-like

I Specially designed for .NET I Big libraries (like Java)

I Libraries can be used by other (managed) code I Java classes can be translated to C# I Visual Basic

I new version that has comparable facilities as C#

I C/C++ etc.

I Special MS extensions for managed code I Normal C/C++ is of course unsafe

I For .NET programming managed extensions (MC++) are


I But other vendors’ compilers have to be modified

Piet van Oostrum DOS-11 42



I Interoperability between (D)COM and .NET

I COM objects can disguise themselves as CLR objects

I CLR object can act as COM components

I Distributed calls by SOAP

I All this is (more or less) transparently done by the CLR I Special pragma’s inserted in source code

I Compilers can generate WSDL.