Web Services

1. Web Services Chapter 28

2. Web Basics

3. Internet • Collection of physically interconnected computers. • Messages decomposed into packets. • Packets transmitted from source to destination using a store-and-forward technique. • Routing algorithm directs packets to destination

4. Connection-Oriented Protocol • Prior to transmission:connection is established between source and destination. Each maintains state information: • Sequence numbers, acknowledgements provide reliability • guarantee that packet loss or duplication will be detected • packets arrive in the order they were sent • Buffers, flow control algorithm guarantee transmission rate appropriate to both sender and receiver • Destination address • Characteristics of connection (e.g., out-of-band messages) • Transmission Control Protocol (TCP) is connection-oriented. • Problem:Overhead of setting up & taking down connection.

5. Hypertext Transfer Protocol (HTTP) • A high level protocol built on top of a TCP connection for exchanging messages (with arbitrary content) • Each (request) message from client to server is followedby a (response) message from server to client. • Facilitates remote invocation of methods on the server. • Web: A set of client and server processes on the Internet that communicate via HTTP.

6. Protocol Stack HTTP TCP Added features to support client interactions (reliability flow control, ..) Network Level Protocol End-to-end protocol Link Level Protocol Protocol for tranmitting packets between neighboring nodes

7. Clients and Servers • Client: browser capable of displaying HTML pages. • Web Server:stores pages for distribution to clients. • Pages identified by Uniform Resource Locator (URL). • <protocol>: protocol to be used to communicate with host. • Example - http, ftp • <host_name>: Directory server translates this into the host’s internet address • Example – www.cs.sunysb.edu becomes 155.233.123.532 • <file_name>: name of file on host. <protocol>://<host_name>/<file_name>

8. HTTP Request Format Start line: <method> <URL> <protocol_version> CrLf Followed by:<header>* Followed by: CrLf Followed by: <data> <method> = GET | HEAD | POST | PUT | …. <protocol_version> = HTTP/1.1 | …. there can be several header lines

9. Request Methods • GET:response body contains data identified by argument URL • HEAD:response header describes data identified by argument URL (no response body) • Use: has page changed since last fetched? • PUT:request body contains page to be stored at argument URL

10. Request Methods • DELETE:delete data at argument URL • POST:request body contains a new object to be placed subordinate to object at argument URL • Use: adding file to directory named by URL • Use: information entered by user on displayed form • Others ….

11. HTTP Request Format <header> = <field_name> : <value> CrLf <field_name> = From | -- sender’s e-mail address Accept | -- acceptable response formats User-Agent | -- identifies requestor’s program SOAPAction -- identifies SOAP processor to receive message (if data is a SOAP message) If-Modified-Since | --send document only if modified since <value> (used with GET) Content-Type | -- type of data (application/soap+xml for SOAP) Host | -- destination host … <data> = ASCII text (default)

12. Simple Client / Server Interaction I 1. User supplies URL (clicks on link) http://yourbusiness.com/~items/printers.html 2. Browser translates<host_name> (yourbusiness.com) to host_internet_address (using name server) 3. Browser assumes a port number of 80 for http (if no port is explicitly provided as part of <host_name> ) Program at port 80 interprets http headers

13. Simple Client / Server Interaction I 4. Browser sets up TCP connection to yourbusiness.com at (host internet address, 80) 5. Browser sends http message GET ~items/printers.html HTTP/1.0 over connection

14. HTTP Response Status line:<HTTP_version> <status_code> <reason_line> CrLf Followed by: < header >* Followed by: <data>

15. HTTP Response <status_code> = 3 digits Ex: 2xx -- success 4xx -- bad request from client 5xx -- server failed to fulfill valid request <reason_line> = explanation for human reader <header> = <field_name> : <value> CrLf <field_name> = Allowed | -- methods supported by URL Date | -- creation date for response Expires | -- expiration date for data Last-Modified | -- creation date for object Content-Length | Content-Type | ….

16. Simple Client/Server Interaction I 6. Server sends response message with requested html page to browser 7. Server releases TCP connection (stateless) 8. Browser receives page and displays it HTTP/1.0 200 Document follows Date: <date> Content-Type: text/html Content-Length: integer Expires: date html document ~items/printers.html goes here

17. Simple Client/Server Interaction II 1. Page displayed by browser is a form with tag <FORM ACTION=“http://yourbusiness.com/servlets/placeorder” METHOD=…> 2. Client fills input boxes 3. If METHOD=GET, client sets up connection to yourbusiness.com and sends http request: Values in input boxes encoded as suffix. Since ACTION designates a servlet, server invokes placeorder GET /servlets/placeorder?name1=value1&name2=value2 HTTP/1.0

18. Simple Client / Server Interaction II 4.If METHOD=POST, client sends http request invoking POST to yourbusiness.com; data contains values in input boxes. POST /servlets/placeorder HTTP/1.0 Content-Type: text/………………. Content-Length: 54321 Printer=HP660&Name=Art+Bernstein

19. HyperText Transfer Protocol (HTTP 1.1) 1. Client sets up TCP connection to server named in URL 2. Client sends a request 3. Client receives a response 4. If (server has not disconnected) goto 2 else goto 1 - Only actively used connections are maintained

20. SOAP Version 1.2

21. What is SOAP? • The de facto standard for Web Service communication that provides support for: • Remote procedure call (RPC) to invoke methods on servers • Messaging to exchange documents • Extensibility • Error handling • Flexible data encoding • Binding to a variety of transports (e.g., SOAP, SMTP) • We will discuss Version 1.2

22. HTTP Binding • A SOAP message must be carried by some transport protocol • HTTP is frequently used for this purpose • Message is the data part of arequest invoking POST POST /fareService/getFareOp HTTP/1.1 Host: www.SlowHawk.com Content-Type: application/soap+xml Content-Length: xxx SOAPAction: yyy <!– the SOAP message goes here 

23. SOAP and XML • Since XML is language and platform independent, it is the lingua franca for the exchange of information in a heterogeneous distributed system. • SOAP supports the transmission of arbitrary XML documents • For RPC, SOAP provides a message format for invoking a procedure and returning results in XML

24. SOAP Message SOAP Envelope SOAP Header Header Block optional Header Block SOAP Body Message Body required

25. SOAP Envelope <s:Envelope xmlns:s=“http://www.w3.org/2003/05/soap-envelope”> <s:Header> <!-- header blocks go here --> </s:Header> <s:Body> <!-- anXML document goes here--> </s:Body> </s:Envelope> http://www.w3.org/2003/05/soap-envelope identifies a name space that defines the structure of a SOAP message

26. Using SOAP • For document exchange, the XML document being exchanged is nested directly in SOAP envelope. • Referred to as document-style SOAP • Conversational mode of message exchange • For RPC, SOAP defines the format of the body of messages to be used for invocation and response. • Referred to as RPC-style SOAP • Uses a request-response pattern • Parameters are passed by value/result

27. RPC Request Message Client invocation of procedure: public Float getQuoteOp(String symbol); generates SOAP request message: <s:Envelope xmlns:s=“http://www.w3.org/2003/05/soap-envelope” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”> <s:Body> <n:getQuoteOp xmlns:n=“http://www.shearson.com/quoteService”> <n:symbol xsi:type=“xsd:string”> IBM </n:symbol> </n:getQuoteOp> </s:Body> </s:Envelope>

28. RPC Response Message <s:Envelope xmlns:s=“http://www.w3.org/2003/05/soap-envelope” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”> <s:Body> <n:getQuoteOpResponse xmlns:n=“http://www.shearson.com/quoteService”> <n:value xsi:type=“xsd:float”> 30.45 </n:value> </n:getQuoteOpResponse> </s:Body> </s:Envelope>

29. RPC Request/Response Messages • Conventions: • Name of the request structure is same as method name. • Name of response structure is same as method name concatenated with “Response” • Name and order of in and in/out parameters in request structure same as name and order in signature • Value of method (if returned) is first child element of response structure; out and in/out parameters follow, their name and order same as name and order in signature

30. Data Encoding • Problem: SOAP provides a language/platform independent mechanism for invoking remote procedures • Argument values are carried in an XML document • Caller and callee may use different representations of the same types (e.g., Java, C) • A mechanism is needed for mapping from caller’s format to XML syntax and from XML syntax to callee’s format (referred to as serialization/deserialization) • Example: mapping a Java array to XML syntax

31. Serialization • Serialization is simple for simple types (integer, string, float,…) since they correspond to XML Schema types. • Translate from binary to ASCII using XML schema specified format • Serialization not so simple for complex types • Ex: What tags will be used for an array? Will it be stored by rows or by columns? How will a sparse array be sent?

32. Encoding Style • encodingStyle attribute used to identify the serialization rules to encode the data contents of an element • An arbitrary set of rules can be used • SOAP defines its own set of rules • Message is referred to as RPC/encoded • RPC refers to the format of the message as a whole • Encoded refers to the fact that argument values have been represented using the rule set specified in the encoding style attribute

33. SOAP Encoding Style • SOAP defines its own graphical data model for describing complex types and rules for transforming instances of the model into serialized ASCII strings • Vendors provide serializers (and deserializers) which maps each local type to an instance of the model and then transforms the local representation to the encoded data using the SOAP rules

34. Data Encoding <s:Envelope xmlns:s=“http://www.w3.org/2003/05/soap-envelope” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”> <s:Body> <n:getQuoteOp xmlns:n=“http://www.shearson.com/quoteService” s:encodingStyle=“http://www.w3.org/2003/05/soap-encoding”> <n:symbol xsi:type=“xsd:string”> IBM </n:symbol> </n:getQuoteOp> </s:Body> </s:Envelope>

35. SOAP Extensibility • A SOAP message goes from client to server to advance some application related cause. • It is often the case that some orthogonal issues related to the message must be handled: • Security: encryption, authentication, authorization • Transaction management • Tracing • Logging

36. Intermediaries client intermediary intermediary server • To support scalability and decentralization, these issues need not be handled by the server. • Intermediaries between client and server are used • Intermediaries perform orthogonal services as the message passes along a route

37. Example purchasing server Proxy/ gateway client accounting server inventory server Message addressed to Proxy. Contains target dept (purchasing), client name, password, and request body. Proxy performs authentication. Message addressed to target dept. Contains authenticated Id and request body. Target department services the request.

38. Requirements • Information directed to each intermediary and to final destination kept separate • Intermediaries can be easily added/deleted, route changed • SOAP does not specify how routing is to be done • It is up to each node along the chain to know where to send the message next • Information carried in the message may direct routing

39. Header • SOAP envelope defines an optional header containing an arbitrary number of header blocks. Each block: • Has an optional role and should be processed by an intermediary that can perform that role • Can have its own namespace declaration • Eliminates the possibility of interference between groups that independently design headers.

40. Example – Message Sent by Client POST /purchasing/retailSale HTTP/1.1 -- method invoked at final destination Host: proxy.yourcompany.com -- initial destination intermediary ……. <s:Envelope xmlns:s=….> <s:Header> <td:targetdept xmlns:td=“….” s:role=“company-proxy.com” -- identifies intermediary s:mustUnderstand=“true”> -- this header better be processed purchasing -- identifies next node </td:targetdept> <auth:authinfo=“….” s:role=“company-proxy.com” -- identifies intermediary s:mustUnderstand=“true” > -- this header better be processed <auth:name> madonna </auth:name> <auth:passwd> xxxxxx </auth:passwd> </auth:authinfo> </Header> <s:Body> …… </s:Body> </s:Envelope>

41. Processing Model • An intermediary has an assigned set of roles • On receiving a message, it identifies the blocks whose role attribute matches an element of its set (or has value next) • A block without a role attribute is targeted for final destination • The intermediary • can modify/delete its block • can insert new blocks • should retarget the message to the next destination • can do anything (frowned upon)

42. Must Understand • An intermediary can choose to ignore a block directed to it • If mustUnderstandattribute has value “true” intermediary must process the block or else abort the message and return a fault message

43. Example – Message Sent by Proxy POST /purchasing/retailSale HTTP/1.1 -- method invoked at destination Host: purchasing.yourcompany.com -- initial intermediary ……. <s:Envelope xmlns:s=….> <s:Header> <cc:ClientCredentials xmlns:cc=“….” s:mustUnderstand=“true” > -- this block better be processed by -- destination (no role specified) <cc:clientId> 122334 </cc:clientId> </ cc:ClientCredentials > </Header> <s:Body> …… </s:Body> -- same body </s:Envelope>

44. Example – Message Sent by Proxy • Proxy has deleted the two headers • Verified that user is valid using <name> and <passwd> and determined Id • Retargeted message to final destination using <targetdept> • Proxy has inserted a new header containing Id • Final destination uses Id to determine authorization

45. WS-Addressing • Problem: As described up to this point destination address (including target SOAP processor) is not included in SOAP message • This information is contained in transport header (e.g., SOAPAction header in HTTP) • Information has to be supplied separately to the transport and the mechanism for doing this is different for different transports • SOAP is not transport-neutral

46. WS-Addressing • Solution: Include the information in SOAP header blocks. • WS-Addressing is defined for this purpose: • <wsa:To> - destination URL • <wsa:Action> - message intent (analogous to SOAPAction) • <wsa:MessageID> - unique Id • <wsa:ReplyTo> - address for reply • <wsa:RelatesTo> - Id of another message • ….

47. WS-Addressing • The type EndpointReferenceType is defined to carry references to endpoints (e.g., value of ReplyTo) • Contains destination address as well as additional information that might be needed to send a message to that address: • Identity of WSDL elements describing destination (port type, service,..) • Policy information (e.g., should message be encrypted)

48. SOAP Faults • SOAP provides a message format for communicating information about errors containing the following information: • Fault category identifies error (not meant for human consumption) – • VersionMismatch • MustUnderstand – related to headers • Sender – problem with message content • Receiver – error had nothing to do with the message • human readable explanation • node at which error occurred (related to intermediaries) • application specific information about Client error

49. Embedding SOAP in HTTP: POST • For document-style SOAP, the envelope is the body of an HTTP POST. • The HTTP response message simply acknowledges receipt of HTTP request messsage • For RPC-style SOAP, the envelope containing the SOAP request is the body of an HTTP POST; the envelope containing the SOAP response (or fault) is the body of the corresponding HTTP response.

50. Embedding RPC-style SOAP in HTTP POST /StockQuote HTTP/1.1 Content-Type: text/xml Content-Length: ….. <s:Envelope xmlns:s=“http://www.w3.org/2003/05/soap-envelope” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”> <s:Body> <n:getQuoteOp xmlns:n=“http://www.shearson.com/quoteService” s:encodingStyle=“http://www.w3.org/2001/06/soap-encoding”> <n:stockSymbol xsi:type=“xsd:string”> IBM </n:stockSymbol> </n:getQuoteOp> </s:Body> </s:Envelope>