web services: xml & soap presented by: davor svetinovic date: july 22, 2002
TRANSCRIPT
Web Services:XML & SOAP
Presented by: Davor SvetinovicDate: 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]
ServiceRegistry
ServiceProvider
ServiceRequester
Service
ServiceDescription
Find
WSDL, UDDI
ServiceDescription
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
Secu
rity
Man
agem
ent
Qu
ality of S
ervicesWSFL
Static UDDI
WSDL
SOAP
HTTP, FTP, e-mail, MQ, IIOP, etc.
Direct UDDI
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:Envelopexmlns: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.1Host: www.stockquoteserver.comContent-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "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 OKContent-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