Bind

clappingknaveSoftware and s/w Development

Dec 14, 2013 (7 years and 7 months ago)

257 views




Web Services:

XML & SOAP

Presented by: Davor Svetinovic

Date: July 22, 2002


Outline


Web Services Intro


XML


SOAP

Intro: Definition


What is a web service?


Everyone has a definition



One possible definition:


Web services are a mechanism for application
-
to
-
application collaboration over internet.


Another one:


“A Web service is a collection of functions that are
packaged as a single entity and published to the
network for use by other programs.” [1]

Intro: Analogy


What are web services similar to?


Different component technologies?


Not
really!


Different component infrastructure aspects such
as runtime environment, web application
servers, etc.?


More similarity!


Different adapters and connectors used to
merge non
-
interoperable software entities?


YES!

Intro: Componentization


Unlike different attempts to develop new
component models from scratch, web services
provide a
new layer of abstraction
that allows the
integration and communication of different
software entities over internet.


This abstraction allows us to achieve many of the
goals of component
-
based design.


Result: web services are not replacement for
anything but a complementary technology


everything becomes a component!

Intro: Basic Functionality


Applications that interact on the web must
be able to:


Find each other.


Obtain the information required in order to
interact (interface).


Obtain the information about the required
interaction mechanisms (interaction protocol).


Satisfy qualities such as security, reliability,
scalability, etc.


Intro: Basic Technologies


Extensible Markup Language (XML)


Simple Object Access Protocol (SOAP)


Web Services Description Language (WSDL)


Universal Description, Discovery, and
Integration (UDDI)


Not yet standardized, but essential: flow control,
security, reliability, quality of service, etc.

Intro: Web Services Model [2]


The Web Services architecture describes three
roles


Service provider


Service requester


Service registry


It describes three basic operations


Publish


Find


Bind

Intro: Web Services Model [2]

Service

Registry

Service

Provider

Service

Requester

Service

Service

Description

Find

WSDL, UDDI

Service

Description

Publish

WSDL, UDDI


Web Services roles, operations, and artifacts

Bind

Intro: Web Services Stack [2]

Service Flow

Service

Discovery

Service

Publication

Network

Service

Description

XML
-
Based


Messaging

Security

Management

Quality of Services

WSFL

Static

††††
啄䑉

W卄S

协SP

䡔HPⰠ䙔PⰠ,

浡楬Ⱐ

䵑Ⱐ䥉IPⰠ整挮


䑩牥捴D

† †††
啄䑉

Interoperable base

Web Services stack

XML: What is XML?


EXtensible Markup Language (XML).


XML is a markup language (similar to HTML).


XML is designed to describe data (HTML


display data).


XML uses a Document Type Definition (DTD) or
an XML Schema to describe the data.


XML tags are not predefined


they must be
defined.


XML with a DTD or XML Schema is designed to
be self
-
descriptive.

XML: Simple Example

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

<note date="12/11/99">

<to>Tove</to>

<from>Jani</from>

<heading>Reminder</heading>

<body>Don't forget me this weekend!</body>

<!
--

This is a comment
--
>

</note>

XML: Elements


An XML element is everything from the element's
start tag to the element's end tag (tags included).


Elements are extensible.


Elements have parent
-
child relationships.


Elements have different content types: empty,
simple, element, and mixed.


Elements have attributes.


Elements vs. attributes


chose elements if content
“feels” like data!



XML: Attributes


Following are problems with attributes:


cannot contain multiple values (child elements can)


not easily expandable (for future changes)


cannot describe structures (child elements can)


more difficult to manipulate by program code


not easy to test against a DTD or Schema


Don’t use attributes as containers for data!


Use elements to describe data!

XML: Namespaces


Namespaces are used to avoid different element name
conflicts.


Since element names are not fixed, conflicts occur when 2
or more documents use same names to describe different
data.


Use prefixes: <h:table> </h:table> vs. <a:table> </a:table>


Use namespace attribute: <h:table xmlns:h=“namespace
(URI)”></h:table>


Default namespace


no prefixes for children elements
<element xmlns="namespace">


Real example: <xsl:stylesheet
xmlns:xsl="http://www.w3.org/TR/xsl">

XML: XML Schema Definition
(XSD)


An XML Schema is used to describe the structure of an
XML document.


XML Schema defines:


elements that can appear in a document


attributes that can appear in a document


which elements are child elements


the order of child elements


the number of child elements


whether an element is empty or can include text


data types for elements and attributes


default and fixed values for elements and attributes


Successor of the DTDs (XML based, extensible, etc.)

XML: Schema (cont.)


Greatest advantage: supports data types!


It makes it easier to:


describe permissible document content


validate the correctness of data


work with data from a database


define restrictions on data


define data patterns (data formats)


convert data between different data types

XML: Schema (cont.)

<?xml version="1.0"?>

<note

xmlns="http://www.w3schools.com"

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

xsi:schemaLocation="http://www.w3schools.com note.xsd">


<to>Tove</to>

<from>Jani</from>

<heading>Reminder</heading>

<body>Don't forget me this weekend!</body>

</note>

XML: Schema (cont.)

<?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://www.w3schools.com"

xmlns="http://www.w3schools.com"

elementFormDefault="qualified">


<xs:element name="note">


<xs:complexType>


<xs:sequence>


<xs:element name="to" type="xs:string"/>


<xs:element name="from" type="xs:string"/>


<xs:element name="heading" type="xs:string"/>


<xs:element name="body" type="xs:string"/>


</xs:sequence>


</xs:complexType>

</xs:element>

</xs:schema>

XML: Other Technologies


XHTML
-

Extensible HTML


XSL
-

Extensible Style Sheet Language


XSLT
-

XML Transformation


XLink
-

XML Linking Language


XPointer
-

XML Pointer Language


DTD
-

Document Type Definition


DOM
-

Document Object Model


XQL
-

XML Query Language


SAX
-

Simple API for XML

SOAP: Intro


SOAP is a lightweight protocol for exchange of
information in a decentralized, distributed environment.


SOAP provides a simple and lightweight mechanism for
exchanging structured and typed information between
peers in a decentralized, distributed environment using
XML.


In other words:


SOAP is a communication protocol.


SOAP is a format for sending messages.


SOAP is designed to communicate via Internet.


SOAP is platform and language independent.


SOAP is simple and extensible.


SOAP solves many of problems of traditional communication
protocols (e.g., firewalls issue).


SOAP is standardized.

SOAP: Intro


SOAP is simple!


No support for:


Distributed garbage collection


Boxcarring or batching of messages


Objects
-
by
-
reference (which requires
distributed garbage collection)


Activation (which requires objects
-
by
-
reference)

SOAP: Basic Components


SOAP consists of following three parts:


The SOAP envelope construct which defines an overall framework
for expressing
what

is in a message;
who

should deal with it, and
whether

it is optional or mandatory.


The SOAP encoding rules which define a serialization mechanism
that can be used to exchange instances of application defined data
types.


The SOAP RPC representation which defines a convention that
can be used to represent remote procedure calls and responses.


Every SOAP message consists of following parts:


SOAP envelope


SOAP header (optional)


SOAP body


SOAP: Basic Rules


A SOAP message MUST be encoded using XML


A SOAP message MUST have a SOAP Envelope


A SOAP message CAN have a SOAP header


A SOAP message MUST have a SOAP Body


A SOAP message MUST use the SOAP Envelope
namespace


A SOAP message MUST use the SOAP Encoding
namespace


A SOAP message must NOT contain a DTD reference


A SOAP message must NOT contain XML Processing
Instructions

SOAP: Message Template

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap
-
envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap
-
encoding">



<soap:Header>


... ...


</soap:Header>



<soap:Body>


... ...


<soap:Fault>


... ...


</soap:Fault>


</soap:Body>

</soap:Envelope>

SOAP: Basic Attributes


SOAP
encodingStyle

attribute is used to indicate the
serialization rules used in a SOAP message.


SOAP
actor

attribute is used to indicate the recipient of a
header element. Its value is an URI, and
"
http://schemas.xmlsoap.org/soap/actor/next
" is a special
value that indicates that message should be processed by a
very next recipient on the message path.


SOAP
mustUnderstand

attribute is used to indicate
whether a header entry is mandatory or optional for the
recipient to process. The value of the mustUnderstand
attribute is either "1" or "0". The absence of the SOAP
mustUnderstand attribute is semantically equivalent to its
presence with the value "0".


SOAP: Fault element


The SOAP Fault element is used to carry error
and/or status information. It can appear only once.
It has following subelements:


faultcode
-

intended for use by software to provide an
algorithmic mechanism for identifying the fault.


faultstring
-

intended to provide a human readable
explanation of the fault.


faultactor
-

intended to provide information about who
caused the fault.


detail
-

intended for carrying application specific error
information.

SOAP: Data Types


SOAP provides a full range of data types as
specified by XML specification. Some of
them are:


Simple types (int, float, negativeInteger, etc.)


Strings


Enumerations


Compound types (Arrays and Structs)

SOAP: RPC Emulation


SOAP provides a flexible way of
performing RPC communication. In order to
make an RPC call following info is needed:


URI of the target object


Method name


Method signature (optional)


Method parameters


Header data (optional)

SOAP: RPC Request


RPC requests and responses constructed as a part
of SOAP body. Request is constructed as follows:


A method invocation is modeled as a struct.


The method invocation is viewed as a single struct
containing an accessor for each [in] or [in/out]
parameter. The struct is both named and typed
identically to the method name.


Each [in] or [in/out] parameter is viewed as an
accessor, with a name corresponding to the name of the
parameter and type corresponding to the type of the
parameter. These appear in the same order as in the
method signature.

SOAP: RPC Response


Response is constructed as follows:


A method response is modelled as a struct.


The method response is viewed as a single struct containing an
accessor for the return value and each [out] or [in/out] parameter.
The first accessor is the return value followed by the parameters in
the same order as in the method signature.


Each parameter accessor has a name corresponding to the name of
the parameter and type corresponding to the type of the parameter.
The name of the return value accessor is not significant. Likewise,
the name of the struct is not significant. However, a convention is
to name it after the method name with the string "Response"
appended.


A method fault is encoded using the SOAP Fault element.

SOAP: Example Request


POST /StockQuote HTTP/1.1

Host: www.stockquoteserver.com

Content
-
Type: text/xml; charset="utf
-
8"

Content
-
Length: nnnn

SOAPAction: "Some
-
URI"


<SOAP
-
ENV:Envelope


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


SOAP
-
ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>


<SOAP
-
ENV:Header>


<t:Transaction


xmlns:t="some
-
URI"


SOAP
-
ENV:mustUnderstand="1">


5


</t:Transaction>


</SOAP
-
ENV:Header>


<SOAP
-
ENV:Body>


<m:GetLastTradePrice xmlns:m="Some
-
URI">


<symbol>DEF</symbol>


</m:GetLastTradePrice>


</SOAP
-
ENV:Body>

</SOAP
-
ENV:Envelope>

SOAP: Example Response


HTTP/1.1 200 OK

Content
-
Type: text/xml; charset="utf
-
8"

Content
-
Length: nnnn


<SOAP
-
ENV:Envelope


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


SOAP
-
ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>


<SOAP
-
ENV:Header>


<t:Transaction


xmlns:t="some
-
URI"


xsi:type="xsd:int"

mustUnderstand="1">


5


</t:Transaction>


</SOAP
-
ENV:Header>


<SOAP
-
ENV:Body>


<m:GetLastTradePriceResponse


xmlns:m="Some
-
URI">


<Price>34.5</Price>


</m:GetLastTradePriceResponse>


</SOAP
-
ENV:Body>

</SOAP
-
ENV:Envelope>

References


The Web services (r)evolution: Part 1,
http://www
-
106.ibm.com/developerworks/


Web Services Conceptual Architecture (WSCA 1.0), By
Heather Kreger, Presention by Bahman Kalali,
http://www.math.uwaterloo.ca/~bkalali/webService.ppt


XML Tutorial,
http://www.w3schools.com/xml/default.asp


XML Schema Tutorial,
http://www.w3schools.com/schema/


Simple Object Access Protocol (SOAP) 1.1,
http://www.w3.org/TR/SOAP/



SOAP Tutorial,
http://www.w3schools.com/SOAP/default.asp