Networks and Services (NETW-903)

Transcription

1 Networks and Services (NETW-903) Dr. Mohamed Abdelwahab Saleh IET-Networks, GUC Fall 2018

2 Table of Contents 1 XML Namespaces 2 XML Schema 3 The SOAP Protocol and RPC 4 SOAP Messages

3 Name Conflicts A name conflict occurs when two different entities, e.g. functions, classes, xml elements, have the same name. Consider two different xml-based languages for describing geometric objects. Both languages define an element called point Language A: Language B: <point x="5" y="10" /> <point> <x> 5 </x> <y> 10 </y> </point> We need to be able to differentiate (by name) between the two point elements.

4 Namespaces and Name Conflicts Namespaces are used to avoid name conflicts. A namespace is just a group of names of XML elements or attributes. The name of a namespace is any unique Uniform Resource Idenifier (URI). The Fully Qualified Name (FQN) of an element is written as: X : Y where X is the namespace name and Y is the element s name. So, to solve the name conflict between the two point elements, we give them different namespace names, e.g., NS1 and NS2. Now the FQN s of the point elements will be NS1:point and NS2:point.

5 Declaring Namespaces We need to declare a namespace before we can use a its name in FQN s of elements. A namespace is declared as an attribute using the keyword xmlns. For instance: xmlns:myspace=" This declares a namespace: Namespace name is and Namespace prefix is myspace Example declaring a namespace in an element called address: <address xmlns:data=" /> prefix is data and name is

6 Default Namespace As we have seen, namespaces are declared as attributes. The declaration specifies the prefix and the name of the namespace. A default namespace is decalred without a prefix: xmlns=" This declares a default namespace (has no prefix). An xml document may or may not contain namespace declarations. Consider the following example where multiple namespaces are declared: <address xmlns:data=" xmlns:values=" xmlns=" </address>

7 Fully Qualified Names of Elements and Attributes To declare that an element or an attribute belongs to a particular namespace, we write the name of the namespace (or its prefix) followed by :, followed by the name of this element or attribute. Example: <data:address xmlns:data=" /> The name address now belongs to the namespace whose prefix is data. The prefix data is just a placeholder for the namespace name. Prefixes are used just as shorthand to keep text shorter. The actual fully qualified name of the element is: Fully qualified names of elements are unique. Two elements belonging to two different namespaces may have the same element name.

8 Scope of a Namespace The scope of a namespace is the element in which it was declared, and any subelements of it. The namespace name, or prefix, can be used anywhere inside its scope. scope of s1 <s1:address xmlns:s1=" <s1:street xmlns:s2=" <s2:name> scope of s2 </s2:name> </s1:address> </s1:street>

9 Using Namespaces A fully qualified name may appear: In element names: <s1:name xmlns:s1=" </s1:name> In attribute name: <s1:name xmlns:s1=" s1:type="string"> </s1:name> In attribute values: <s1:name xmlns:s1=" s1:type="xsd:string"> </s1:name>

10 Unprefixed Names in XML Data Unprefixed names of elements have the name of a default namespace if they appear in its scope. If they do not appear in the scope of a default namespace, their namespace has no value (they have no namespace). Unprefixed names of attributes have no namespace. <street xmlns:s1=" s1:type="xsd:string"> <name xmlns=" MyStreet </name> <s1:number xmlns=" value="int"> 15 </s1:number> </street> street has no namespace since it does not appear in the scope of a namespace. name has the namespace since it appears in its scope. value has no namespace although it appears in the scope of a default namespace (

11 Overriding Within the scope of a namespace, we can bind its prefix to another namespace. <s1:address xmlns:s1=" scope of s1 <s1:street xmlns=" a new s1 <name>xmlns:s1=" xmlns:=" </name> </s1:street> </s1:address> Within the element name, the prefix s1 is bound to the namespace name instead of and the default namespace becomes instead of

12 Well-formed XML Data An xml file is called well-formed if it obeys a particular set of rules. These rules apply to any piece of xml data. Examples: For each container element the name of the end-tag must match that in the start-tag. Both start-tag and end-tag of any container element must appear within the content of a single container element. Names of elements and attributes must follow naming rules. Any xml data that do not follow well-formedness rules are called ill-formed. Well-formedness rules apply to any xml file, however files may have different structures (elements, attributes, etc.). For instance, one file may represent students data, while another represents shipping orders. How do we specify the elements (and their attributes, if any) that an xml file should contain? This is the role of a schema.

13 Schema and Valid XML Data A schema specifies the elements of an xml file and their content/attributes. For instance, a file that represents a student s record may contain a root element called student that contains elements called name, age, and address. Each of these three elements may contain particular attributes and subelements that should also be specified. A schema definition specifies the names of elements (and attributes) of an xml file and their relationships to each other (which data goes where). An xml file contains these elements and attributes with particular content, e.g., the record of the student Ahmed. An xml file that follows the rules specified by a schema is called valid accroding to this schema.

14 How to specify a Schema? There are several methods used to specify schemas: Document type Defintion (DTD): Defines elements and their content/attributes. Does not support namespaces and typing. As an example, the following DTD declaration specifies an element called student-record that contains three sub-elements. <!ELEMENT sudent-record (name, age, address)> W3C XML Schema: Supports namespaces and typing and is usually written in files having a.xsd extension. Schemas (DTD or W3C XML Schema) define the syntax of an xml-based language. However, having a schema is not mandatory.

15 Example of a W3C XML Shema Note: language keywords are in black, user-specific input is in blue. <xs:schema xmlns:xs=" <xs:element name="student-record"> <xs:complextype> <xs:all> <xs:element ref="name"/> <xs:element ref="age"/> <xs:element ref="address"/> </xs:all> </xs:complextype> </xs:element> <xs:element name="name" type="xs:string"/> <xs:element name="age" type="xs:integer"/> <xs:element name="address" type="xs:string"/> </xs:schema>

16 SOAP Protocol SOAP stands for Simple Object Access Protocol. However the protocol has nothing to do with objects (in the sense of object-oriented programming). SOAP may also stand for Service Oriented Architecture protocol, or it may stand for nothing! SOAP is a stateless protocol designed to carry xml messages from a node to another. As we have seen, there are some things missing from XML RPC: How to convey XML RPC messages using standard protocols. How to handle XML RPC messages by nodes on the way to the final destination of the message. Standardization of fault messages. SOAP can be used for RPC.

17 SOAP Protocol Specification The specification of the SOAP protocol contains the following: Different protocol messages and their formats. How to process messages by intermediary nodes (nodes that are not the intended destination of the message). How to turn an RPC into a SOAP message. How to bind a SOAP message to a transport protocol. We mean by transport protocol the protocol used to convey SOAP messages, which is usually an application layer protocol.

18 SOAP Messages Structure of a SOAP message: Envelope (required) Header (optional) Body (required) Fault (optional)

19 SOAP Message Path and Message Header A SOAP message path, starts at an initial sender, goes through several SOAP intermediaries and ends at an ultimate receiver. A SOAP message header provides a way to include application specific data, e.g., encryption keys. Details of the header are left for implementers according to the particular application, i.e., SOAP does not define xml elements for header. A header may contain sub-elements (header xml elements), called header entries or header blocks.

20 SOAP Message Header Attributes The SOAP specification defines attributes for header elements: env:role, env:mustunderstand and env:relay env:role defines the target of the element, it can be set to: none ( Element not targeted at a specific node, e.g., just an information message. next ( Element targeted at the next node on message path. ultimatereceiver ( Element targeted at the final receiver of message. env:mustunderstand can be set to true or false: true: Node must process the element or produce a fault. false: Node may ignore element, if it cannot process it. env:relay determines whether an intermediary node should relay (forward) a header element.

21 Relaying Message Header Blocks The role and relay attributes determine whether an intermediary node will forward a header block (element that is a direct child of the Header element): If env:role attribute is next and node is an intermediary node: If node understood and processed the header block, it will not relay it unless it decides to reinsert the block. If node did not process the header block, it will not relay it unless the env:relay attribute is true. These rules are part of SOAP s message processing rules defined in SOAP V1.2 specifications.

22 SOAP Message Processing The table below summarizes message processing for header blocks. Role Header block Attribute value Role Assumed by Understood & Forwarded current node? Processed next Yes Yes No, unless reinserted next Yes No No, unless relay = true ultimatereceiver Yes Yes n/a ultimatereceiver No n/a yes none n/a Yes Please note that if env:mustunderstand = "true" in a header block, the node must produce a fault message if it did not understand this block.

23 SOAP Message Header An Example <env:envelope xmlns:env=" <env:header xmlns:n=" <n:temperature env:role=" env:mustunderstand="false"> <n:dateandtime> t13:35: :00</n:dateandtime> 25 </n:temperature> <n:humidity env:role=" env:mustunderstand="true"> 0.8 </n:humidity> </env:header> <env:body>... </env:body> </env:envelope>

24 SOAP Message Body A SOAP message body is intended to convey application-specific data. It is targeted at the ultimate receiver of the SOAP message. SOAP messages may carry any xml data. However, they may also be used for RPC requests and responses. The body of a SOAP RPC request should contain: The name of the procedure (function or method) to be called. A value for each parameter of this procedure. A SOAP RPC response contains one of the following: The return value of the function invoked by the request. A fault element.

25 SOAP Message Body RPC Request Elements in SOAP RPC request Envelope (required) Header (optional) Body (required) Procedure (method) name Parameter 1 Parameter n

26 SOAP Message Body RPC Response Elements in SOAP RPC response Envelope (required) Header (optional) Envelope (required) Header (optional) Body (required) Response name Output 1 OR Body (required) Fault Output m

27 SOAP Message for an RPC Request Note: language keywords are in black, user-specific input is in blue. <?xml version= 1.0 encoding= UTF-8?> <SOAP-ENV:Envelope xmlns:soap-env=" xmlns:xsi=" xmlns:xsd=" <SOAP-ENV:Body> <ns1:gettemp xmlns:ns1="urn:xmethods-temperature" SOAP-ENV:encodingStyle= " <zipcode xsi:type="xsd:string">10016</zipcode> </ns1:gettemp> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

28 SOAP Message for an RPC Response Note: language keywords are in black, user-specific input is in blue. <?xml version= 1.0 encoding= UTF-8?> <SOAP-ENV:Envelope xmlns:soap-env=" xmlns:xsi=" xmlns:xsd=" <SOAP-ENV:Body> <ns1:gettempresponse xmlns:ns1="urn:xmethods-temperature" SOAP-ENV:encodingStyle= " <return xsi:type="xsd:float">71.0</return> </ns1:gettempresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

29 SOAP Message for an RPC Response with Fault Note: language keywords are in black, user-specific input is in blue. <?xml version= 1.0 encoding= UTF-8?> <SOAP-ENV:Envelope xmlns:soap-env=" xmlns:xsi=" xmlns:xsd=" <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode xsi:type="xsd:string">soap-env:client </faultcode> <faultstring xsi:type="xsd:string">method failed </faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

30 SOAP Fault Element A fault element contains the following sub-elements: faultcode: May be one of: SOAP-ENV:VersionMismatch SOAP-ENV:MustUnderstand: Could not process header element. SOAP-ENV:Client: Client request conatins an error. SOAP-ENV:Server: Server has an internal error. faultstring: Human-readable description. faultactor: Who caused the fault. detail: Implementation specific, may contain sub-elements.

31 SOAP Body Element In a SOAP request, the Body element contains a single subelement which has the name of the method to be called. The method element contains subelements, each of which represents a parameter of the method. In a SOAP response, the Body element contains a single element called return. The return element contains the output of the called method. Any subelement (descendent) of the Body element may have an encodingstyle attribute that determines the interpretation of this element.

32 xml Serialization/Encoding xml serialization means how to represent data objects (such as arrays, integers, etc.) into an xml stream. For instance consider the following example: public class student{ public string name; } Depending on serialization rules (which are specified by the xml-based language we use), we may have the following serializations of an object of this class: Serialization 1: Serialization 2 <student> <name> Ibrahim </name> </student> <student name="ibrahim" />

33 The encodingstyle Attribute The SOAP protocol supports multiple encodings (serializations as xml streams) for message data. The encoding is determined by the value of the encodingstyle attribute, which may be: (SOAP encoding) The SOAP message uses SOAP data types when serializing/encoding data into an xml stream. No particular encoding is used and the xml stream of the message is parsed as plain xml text. Any URL that determines an implementation dependent encoding.

34 SOAP Data Types (Encoding) Scalars and Arrays SOAP defines the following data types: Scalar types: All built-in simple types defined by xml such as xsd:double, xsd:string, xsd:date, xsd:time. Compound types: Arrays and structs: Arrays: Arrays are ordered lists of elemets. In SOAP an array is a container element, whose sub-elements are identified by their order of appearance and may have same name. In the example, an array of two doubles. <return xmlns:ns2=" xsi:type="ns2:array" ns2:arraytype="xsd:double[2]"> <item xsi:type="xsd:double">54.99</item> <item xsi:type="xsd:double">19.99</item> </return>

35 SOAP Data Types Structs Structs: A struct is an unordered list of elements. In SOAP a struct is a container elements, that contains sub-elements identified by different names, i.e., different tags. In the example, a struct called product that contains a name and a price. <return xmlns:ns2=" xsi:type="ns2:product"> <name xsi:type="xsd:string">red Hat Linux</name> <price xsi:type="xsd:double">54.99</price> </return>

36 encodingstyle: Literal Encoding Literal encoding enables the transmission of xml data or any literal string. <ns1:getproductresponse xmlns:ns1="urn:examples:xmlproductservice" SOAP-ENV:encodingStyle= " <return> <product sku="a358185"> <name>red Hat Linux</name> <description>operating System</description> <price>54.99</price> </product> </return>

37 From RPC to a SOAP Message A SOAP message used in RPC should contain: The address of the target SOAP node. The procedure or method name. The identities and values of any arguments to be passed to the procedure or method together with any output parameters and return value. A clear separation of the arguments used to identify the Web resource which is the actual target for the RPC, as contrasted with those that convey data or control information used for processing the call by the target resource. The message exchange pattern which will be employed to convey the RPC, together with an identification of the so-called Web Method, e.g., POST, GET, etc., to be used. Optionally, data which may be carried as a part of SOAP header blocks.

38 Bindings to Transport Protocol A transport protocol here means any protocol that is used to convey SOAP messages (SMTP, FTP, HTTP, etc.). The SOAP specification shows how to use HTTP. SOAP requests are sent via HTTP requests, and responses sent within an HTTP response. Both HTTP requests and responses are required to set their content type to text/xml. Messages from SOAP clients must include a SOAPAction HTTP header, that is understandble by the server. This way the server may know the purpose of the message without examining its content.

39 Example HTTP Request POST /perl/soaplite.cgi HTTP/1.0 Host: services.xmethods.com Content-Type: application/soap+xml; charset=utf-8 Content-Length: 538 SOAPAction: "urn:xmethodsbabelfish#babelfish" <?xml version= 1.0 encoding= UTF-8?> <SOAP-ENV:Envelope xmlns:soap-env=" xmlns:xsi=" xmlns:xsd=" <SOAP-ENV:Body> <ns1:convert xmlns:ns1="urn:converttemperature" SOAP-ENV:encodingStyle=" <conversion xsi:type="xsd:string">fahr-celsius</conversion> <Temperature xsi:type="xsd:double">64.89</temperature> </ns1:convert> </SOAP-ENV:Body> </SOAP-ENV:Envelope>