1. SOAP

2. History of RPCs There are 2 dominant communication models: –Message Passing: allows system to send and receive messages any time –Request Response: restrict systems to request-response pairs, hence natural fit for RPC

3. RPC Protocols (1980s) Dominant RPC protocols were –Sun RPC: NFS (UNIX Systems) –DCE RPC: Windows NT (System Services) Both were quite functional and adaptable

4. ORPC Protocols (1990s) Codified mapping of communication endpoint to language level object. –Used object ID, interface ID, method ID and in-out parameters to locate and call methods –Endpoints were named using portable Object References How was earlier communication endpoint

5. 1990s: ORPC Protocols –CORBA’s IIOP –DCOM They differed in –Interface ID –Format of parameter values (NDR in DCOM, CDR in IIOP) Were incompatible

6. What’s wrong? good for server to server communication but severe weakness for client to server communication Both rely on single vendor solution –DCOM, every machine runs NT –CORBA, every machine runs same ORB product Rely on closely administered network Rely on fairly hi-tech runtime environment

7. Inability to work with Internet scenarios –In case of DCOM, unable to perform domain based authentication with servers –Firewall reduce likelihood of getting through of IIOP or DCOM packets, due to HTTP bias –Vendors have built-in tunneling technologies, but are very sensitive to configuration mistakes and are not interoperable

8. Server to Server Communication Smaller number of machines-reduced cost of management Common administration-consistent configuration Direct Connectivity-no firewall problems

9. HTTP as a better RPC CORBA and DCOM for server to server and HTTP for Client to Server RPC Style Protocol: simple, widely deployed and likely to function in face of firewalls Handled by Web server software

10. Request Response over TCP/IP Example of HTTP Request Message POST /foobar HTTP/1.1 Host: 209.110.197.12 Content-Type: text/plain Content-Length: 12 Hello World

11. Example of HTTP Response 200 OK Content-Type: text/plain Content-Length: 12 dlrow,olleH 400 Bad Request Content-Length: 0

12. Wide deployment of HTTP CGI to write HTTP server code for lowest common denominator Every HTTP server provides a much more efficient mechanism to get your code to process HTTP request IS provides ASP and ISAPI Apache allows C or PERL modules to run Most application server modules allow you to write Servlets, COM components, EJB Session Beans, CORBA servants etc.

13. XML XML is not a markup language. It’s a set of rules for creating a new markup language such as HTML etc. Subset of SGML SGML: formalized method for capturing the metadata for a document by using markup on the content. SGML defines rules for creating markups in terms of tags and tree structure which is called Data Type Definition (DTD).

14. XML & HTML HTML is an application of SGML. Extensions to HTML with growth of web were counter productive and ill suited to general use To provide interoperability and scalability, a simplified version of SGML was developed by W3C which is XML XML is not intended to replace HTML, both are complimentary XML is more general and better for data sharing on web than extending HTML

15. Extending a single language to every possible case is impossible. Such domains of data can be structured and captured by XML compliant markup language XML specifies specific syntax and semantic rules and constraints for creating new markup language You create HTML, MATHXML, CML documents, which you design using rules laid out in XML specification.

16. Components of XML Elements: Lexical construct of a document –Contains content, either character data or other elements Attributes: characteristics of an element –name/value pairs Comments: free text description Document Type Definition: –Declares all legal elements –Legal attributes elements can have –Hierarchy, nesting and occurrence indicators of all elements –In order for a document to be valid, it must satisfy what DTD it adheres to. A document declares its DTD in a document type declaration.

17. Element declaration –Every element in a valid XML document must correspond to an element type declared in DTD –Examples:

18. Attribute List Declaration –Example Syntactic Rules –An XML document is valid if it declares a document type definition and conforms to element and attribute declaration in DTD It follows all syntax rules specified in XML specification

19. XML Examples

20. HTTP+XML=SOAP SOAP –Light weight protocol for exchange of information in a decentralized, distributed environment –Consists of 3 parts Envelop: defines framework for describing what is in a message and how to process it Encoding Rules: for expressing instances of application defines data types Convention for representing remote procedure calls and responses

21. Uses XML as encoding scheme Request-Response structure of HTTP SOAP Method: –HTTP Request and Response that complies with SOAP encoding rules SOAP EndPoint –HTTP based URI that identifies target for method invocation

22. SOAP Request: –HTTP POST request, use text/xml content-type –Must contain request URI –Server interpretation is application specific: it may map request URI to classname, objects, may use cookies to recover state –Request must include method name to be invoked, using SOAPMethodName HTTP header –HTTP payload is simply an XML document that contains values for in and in,out parameters

23. SOAP Response –Similar to request –Response payload will contain out and in, out parameters of the method called XML aspects of SOAP are simply an encoding scheme for serializing instances of data types in XML The request-response object are serialized in a well known format. XML schema is used to define the object characteristics : Structure and Attributes

24. SOAP Provides definition of XML based information which can be used for indexing structured and types information between peers in a decentralized, distributed environment. Formally specified as an XML Infoset which provides abstract description of its contents Fundamentally 1 way message exchange paradigm, but applications can create more complex interaction patterns by underlying protocol and/or application specific information

25. Silent on semantics of application-specific data, however – it provides framework by which application specific information may be conveyed in an extensible manner. –It provides full description of the required actions to be taken by a SOAP node on receiving SOAP message

26. SOAP Message Exchange Model SOAP implementation can be optimized to exploit the unique characteristics of particular network systems. e.g. –SOAP response messages can be delivered as HTTP responses to inbound request Regardless of protocol used, the messages are routed along a message path which allows for processing at one or more intermediate nodes in addition to the ultimate destination

27. A SOAP application on receiving a SOAP message must process that message by performing following actions: –Identify all parts of SOAP message intended for that application –Verify that all mandatory parts are supported by application and process them accordingly. If not, discard the message –Optional parts may be ignored –Remove all identified parts before forwarding the message Processing an application requires that SOAP processor understands message exchange pattern being used, role of recipient, employment of RPC (if any)

28. SOAP Messages Relation to XML –Messages are encoded using XML –Message should include proper SOAP namespace on all elements and attribtes defined by SOAP –Application must be able to process namespaces in messages that it receives –Applications must discard messages with incorrect namespace

29. Example Header Block-1 Header Block-2 BODY subelement-1 BODY subelement-2 SOAP Envelop

30. <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d 2001-11-29T13:20:00.000-05:00 <n:passenger xmlns:n="http://mycompany.example.com/employees" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> Åke Jógvan Øyvind Example

31. <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"> New York Los Angeles 2001-12-14 late afternoon aisle Los Angeles New York 2001-12-20 mid-morning <q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels"> none

32. Message Format The messages are serialized in a well known format –Every SOAP payload in an XML document which is distinguished root element called –All SOAP specific elements are scoped by the SOAP URI –Envelop contains an optional followed by mandatory – had one distinguished root which is either a request or response

33. SOAP Header: Its an extension mechanism that provides a way to pass information in SOAP messages that is not application payload. –(e.g. passing directives, authentication transaction management, payment information, contextual information) –Header entry is identified by its fully qualified name (namespace URI + local name) –SOAP ‘mustunderstand’ and ‘actor’ attribute may be used to indicate how to process the entry and by whom

34. –SOAP headers have been designed in anticipation of various uses for SOAP, many of which involve Participation of other SOAP nodes called intermediaries This allows intermediaries to provide value added services

35. Header Attributes Define how a recipient of a SOAP message should process the message SOAP ‘actor’ attribute –Some parts of some messages may be intended for intermediaries and not the ultimate destination –Actor attribute is used to indicate the recipient of a header element. The value of actor attribute is a URI –A recipient must not forward the header element to next application in SOAP message path. It may insert a similar or modified header but in that case the contract is between that node and the recipient of the header element

36. SOAP ‘mustunderstand’ attribute –To indicate the entry is mandatory or optional for recipient –If = 1, recipient must obey semantics and process correctly or must fail –Allows robust evolution

37. SOAP Body Provides simple mechanism for exchanging mandatory information intended for the ultimate recipient of the message Must be present Each body entry is identified by namespace URI and a local name

38. SOAP Fault Used to carry error and/or status information with in SOAP message If present, must appear as Body entry and must not appear more than once Defines 4 sub-elements –Fault code –Fault string –Actor –Detail

39. SOAP Processing Model Describes the actions taken by a SOAP node on receiving a SOAP message The first step is overall check that the SOAP message is syntactically correct, i.e. conforms to processing instructions and DTD

40. “role” attribute –Further processing of header and body elements depend on the role assumed by a SOAP node for processing a given message –SOAP defines the (optional) role attribute that may be present in a header block –It identifies the role played by the intended target of the header block. –SOAP node is required to process a header block if it assumes the role identified by the value of the URI

41. –3 standard roles have been identified none next ultimateReceiver –Example 7a –<p:oneBlock xmlns:p=“http://example.com”http://example.com env:role=“http://example.com/Log”> …. http://example.com/Log –Here the header block is targeted at any SOAP node that plays the application defined role by the URI http://example.com/Log http://example.com/Log

42. –Node receiving message with header block with role=next must be capable of processing the contents of the element. –Message having header block with role=none implies no SOAP node should process its content –If there is no role attribute, its implied to be intended for the ultimate receiver –Body has no role attribute but it is always targeted for the ultimate receiver

43. “mustunderstand” attribute –To ensure that SOAP nodes do not ignore header blocks which are important to overall purpose of the application –If “true”, the node must process the block –Processing of a message must not start until the node identifies all mandatory parts of the header blocks targeted to itself and understood them –Node must be capable to process whatever is described in that block’s specification or else discard it generating SOAP fault

44. –Processing may include removing header or reinserting header with same or altered value or inserting a new header –Inability to process a header may require all further processing of the message cease and a fault be generated. This message is not forwarded further –Body has no mustunderstand attribute but it must be processed by the ultimate recepient

45. “relay” attribute –Indicates whether a header block targeted at SOAP intermediary must be relayed if not processed –If a header block is processed, the rules require that it be removed from outbound message, however it maybe inserted changed or unaltered by the node). –The default behavior for an unprocessed header block targeted at a a role played by SOAP intermediary is to remove it before relaying the message. –This is to ensure that intermediary makes no assumptions about survivability past itself of a header block targeted at a role it assumes, particularly if it chooses not to process it

46. –Can be used to introduce a header block targeted at any capable intermediary which might be encountered on SOAP path. –So the incapable intermediaries should ignore and relay it (opposite to default rule), so that it could be available for those who are capable –This can be done by mustUnderstand=false, relay=true

47. SOAP Encoding Generalization of common features found in type systems in programming languages, databases etc. Defines rules so that an XML schema can be defined for representing the structure and constraints on datatypes Instances of the schema can be developed given certain values of the datatypes (in what detail??)

48. Infoset Namespace Schema

49. Rules for encoding types in XML XML allows flexible encoding, SOAP defines narrower set of rules Serialization rules

50. Using various protocol bindings SOAP messages can be passed using a variety of underlying protocols, including other application layer protocols Specification of how SOAP messages may be passed from one SOAP node to another using an underlying protocol is called SOAP Binding SOAP Message is described in terms of elements and attributes in an abstract document. This abstract document is made concrete by protocol bindings whose task is to provide a serialized representation of the infoset that can be conveyed to the next node, in such a way that message can be represented without loss of information

51. There can be different types of bindings –Pure XML –Compressed structure –Encrypted structure

52. In addition to providing a concrete realization, SOAP message provides a mechanism to support features by SOAP application –A request-response feature –An encrypted feature –A reliable delivery feature

53. If a feature is not available through binding, it may be implemented with in the SOAP envelop using header blocks (identified by some URI). This specification of features implemented is called SOAP module –Is using UDP, SOAP module itself has to provide message correlation or directly the application should take care of it –If using HTTP as a protocol providing the service, the application could inherit this feature provided by binding and no further support is needed

54. –A SOAP message travels along several hops, where each hop may have a different protocol binding. So any feature that is required by an application and may not be available can be carried as a SOAP module

55. Using SOAP with HTTP HTTP implicitly correlates request with response SOAP follows the HTTP request/response message model providing SOAP request parameters in HTTP request and response in HTTP response HTTP allows multiple intermediaries between client and server. However SOAP intermediaries are different from HTTP intermediaries.

56. What’s the difference and how the new one is better RPC –??? ORPC Single vendor solution Close administration Hi-tech runtime environment Inability to work with internet scenario Good for server to server communication but bad for client to server HTTP Simple, widely deployed, likely to function in firewalls, webserver support –HTML Difficult to extend to different cases… –XML hence allow user defined language by providing rules to create language SOAP –Protocol using HTTP and XML