Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download new layer of abstraction
Document related concepts
no text concepts found
Transcript
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-toapplication 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 Description Service Registry Find WSDL, UDDI Service Requester Publish WSDL, UDDI Bind Service Service Description Provider Service Web Services roles, operations, and artifacts Intro: Web Services Stack [2] UDDI Service Discovery Direct UDDI Service Publication WSDL Service Description SOAP XML-Based Messaging Interoperable base Web Services stack HTTP, FTP, e-mail, MQ, IIOP, etc. Network Quality of Services Static Management Service Flow Security WSFL 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-byreference) 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://www106.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
