SOAP

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

RPC Protocols (1980s)

• Dominant RPC protocols were– Sun RPC: NFS (UNIX Systems)– DCE RPC: Windows NT (System Services)

• Both were quite functional and adaptable

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

• 1990s: ORPC Protocols– CORBA’s IIOP– DCOM

• They differed in– Interface ID– Format of parameter values (NDR in DCOM,

CDR in IIOP)

• Were incompatible

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

• 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

Server to Server Communication

• Smaller number of machines-reduced cost of management

• Common administration-consistent configuration

• Direct Connectivity-no firewall problems

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

• 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

• Example of HTTP Response200 OK

Content-Type: text/plain

Content-Length: 12

dlrow ,olleH

400 Bad Request

Content-Length: 0

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.

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).

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

• 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.

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.

• Element declaration– Every element in a valid XML document must

correspond to an element type declared in DTD

– Examples:

• 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

• XML Examples

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

• 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

• 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

• 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

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

• 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

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

• 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)

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

Example

Header Block-1

Header Block-2

BODY subelement-1

BODY subelement-2

SOAP Envelop

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

Example

<env:Body> <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>New York</p:departing> <p:arriving>Los Angeles</p:arriving> <p:departureDate>2001-12-14</p:departureDate> <p:departureTime>late afternoon</p:departureTime> <p:seatPreference>aisle</p:seatPreference> </p:departure> <p:return> <p:departing>Los Angeles</p:departing> <p:arriving>New York</p:arriving> <p:departureDate>2001-12-20</p:departureDate> <p:departureTime>mid-morning</p:departureTime> <p:seatPreference/> </p:return> </p:itinerary> <q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels"> <q:preference>none</q:preference> </q:lodging> </env:Body></env:Envelope>

Message Format

• The messages are serialized in a well known format– Every SOAP payload in an XML document which is

distinguished root element called <Envelop>– All SOAP specific elements are scoped by the SOAP

URI– Envelop contains an optional <Header> followed by

mandatory <Body>– <Body> had one distinguished root which is either a

request or response

• 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

– 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

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

• 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

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

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

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

• “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

– 3 standard roles have been identified• none• next• ultimateReceiver

– Example 7a– <p:oneBlock xmlns:p=“http://example.com”

env:role=“http://example.com/Log”> ….

</p:oneBlock>– Here the header block is targeted at any SOAP node

that plays the application defined role by the URI http://example.com/Log

– 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

• “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

– 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

• “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

– 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

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??)

• Infoset

• Namespace

• Schema

Rules for encoding types in XML

• XML allows flexible encoding, SOAP defines narrower set of rules

• Serialization rules

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

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

• 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

• 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

– 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

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.

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