1 / 59

CSPP51038

CSPP51038. SOAP (formerly Simple Object Access Protocol). What is the point of SOAP?. Create a standard for how XML can be used as a messaging format for distributed programs.

awen
Télécharger la présentation

CSPP51038

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSPP51038 SOAP (formerly Simple Object Access Protocol)

  2. What is the point of SOAP? • Create a standard for how XML can be used as a messaging format for distributed programs. • Tricky part is that the history of the evolution of SOAP has made certain aspects of it very hard to understand motivation-wise.

  3. Some facts about SOAP • SOAP no longer stands for Simple Object Access Protocol • This was dropped in 2003 with publication of v1.2 • Considered to be a misleading name • Originally was XML-RPC • Created in 1998 as a very lightweight protocol for remote procedure calls • Was basis for development of SOAP several years later • SOAP currently maintained by W3C XML working group • SOAP and XML-RPC are both based entirely on XML

  4. SOAP as a messaging protocol • SOAP is fundamentally a stateless, one-way message exchange paradigm • However, applications can create more complex interaction patterns (e.g., request/response, request/multiple responses, etc.) by combining such one-way exchanges with features provided by an underlying protocol and/or application-specific information. • SOAP is silent on the semantics of any application-specific data it conveys, as it is on issues such as the routing of SOAP messages, reliable data transfer, firewall traversal, etc. • However, SOAP provides the framework by which application-specific information may be conveyed in an extensible manner. Also, SOAP provides a full description of the required actions taken by a SOAP node on receiving a SOAP message.

  5. SOAP • SOAP is made up of three major parts • A generic XML messaging framework • An optional data encoding standard • An optional RPC (remote procedure call) framework • It is possible to use just the messaging framework or messaging framework/encoding standard without using the RPC mechanism (though latter is arguably where much of power/usefulness lies). • The fact that these are separate leads to great confusion about what SOAP is.

  6. Web Services • Note that classic Web Services are made up of three parts • SOAP • WSDL (Web Services Descriptor Language) • UDDI (Universal Description, Discovery, and Integration) • All three are based on XML • SOAP simply defines the structure of the XML document used to transfer the message + possibly conventions for serializing data into XML + convention for representing method call • WSDL and UDDI are covered next class

  7. SOAP: Messaging framework • Just defines a generic message XML schema • Virtually any type of message you can think of can be packaged as a SOAP message. • However, doing so without RPC mechanisms takes only very small advantage of the features defined in the SOAP standard • We now have learned everything necessary to understand SOAP schema: http://www.w3.org/2001/06/soap-envelope

  8. General (Basic) Structure SOAP Message • Envelope • Defines the content of the message • Header (optional) • Contains destination information, versioning, extensions • Good place for security • Body • Contains payload SOAP Envelope SOAP Header SOAP Body Payload Document(s) SOAP Fault

  9. General (Basic) Structure SOAP Message <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/encoding/" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <soap:Header> ... ... </soap:Header> <soap:Body> <!-- User request code here --> <soap:Fault> ... ... </soap:Fault> </soap:Body> </soap:Envelope>

  10. What is encodingStyle? • Note that this general message framework can be used to attach any valid XML-based message in the <body> element. • In the original design of SOAP this message was intended to be serialized data organized as input/output parameter lists wrapped in method calls. • If the intent is to use SOAP message bodies this way, a standard must be developed for representing generic simple and compound types in programming languages in XML. • Note that schema have much of this already but are lacking some specifics.

  11. SOAP encoding • In order to build SOAP messages from our language of choice, we need to know how to serialize data -- ie the rules for representing an integer, string, or floating point number. The serialization of data inside a SOAP message is referred to as encoding • SOAP does this in a language agnostic way, much like CORBA (but not in binary form) • If the encodingStyle attribute does not appear in the message, the receiver cannot make any assumptions about how data will be represented within the message

  12. SOAP Encoding • You may be wondering about the relationship between encoding and XML Schemas • Encoding can make use of XML Schemas. • The SOAP Specification defines a single set of (recommended) encoding rules call SOAP encoding. SOAP encoding is based on XML Schemas and as such it closely models many of the standard types and constructs. The value is http://schemas.xmlsoap.org/soap/encoding/, which points to the XML Schema that defines the encoding rules. • SOAP encoding rules use XML Schemas heavily, relying on the XML Schema datatypes namespace and the type attribute. • The key difference is that encoding does not mandate XML Schemas. • Encoding rules are simply identified by a URI. The rules implied by that URI could be backed up by nothing more than a verbal agreement, or possibly some written documentation. • This allows developers who do not necessarily need the capabilities of XML Schemas to forego their use and start sending messages with encoding rules based on an accepted URI.

  13. SOAP Encoding • For example, SOAP stipulates that an array of three integers be represented as: <SOAP-ENC:Array SOAP-ENC:arrayType="xsd:int[3]"><SOAP-ENC:int>8</SOAP-ENC:int><SOAP-ENC:int>5</SOAP-ENC:int><SOAP-ENC:int>9</SOAP-ENC:int> </SOAP-ENC:Array> • SOAP also provides a type for representing binary data One approach for working with binary data is to use the base64 type. We can represent binary data, such as an image file, as an array of bytes in the message. The base64 type converts binary data to text using the base64-encoding algorithm of XML Schemas. There is no relationship between SOAP and base64-encoding; If we use it, our application (or implementation of SOAP for your platform) must be able to understand and work with base64-encoding.

  14. SOAP RPC • The third part of SOAP is an RPC mechanism that turns messages into method calls • We have a generic message structure + data. It requires just a little more work to turn the message into a function call. • Must be a standard way to represent parameters and return values, exceptions, etc. • Note that the encoding and rpc mechanisms are only important if SOAP is being automatically generated/read from the application level (see next slide) in a general way

  15. Sample RPC interface package com.jwsbook.soap; import java.rmi.RemoteException; public interface BookQuote extends java.rmi.Remote { // Get the wholesale price of a book public float getBookPrice(String ISBN) throws RemoteException, InvalidISBNException; }

  16. Sample rpc SOAP message <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookQuote"> <soap:Body> <mh:getBookPrice> <isbn>0321146182</isbn> </mh:getBookPrice> </soap:Body> </soap:Envelope>

  17. Sample rpc SOAP reply <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookQuote" > <soap:Body> <mh:getBookPriceResponse> <result>24.99</result> </mh:getBookPriceResponse> </soap:Body> </soap:Envelope>

  18. SOAP RPC cartoon VB application Java application InvoiceVB-Structure InvoiceJava-Structure SOAP client SOAP Server SOAP Message The client application thinks its making a procedure call to a remote module

  19. SOAP transport • Recall that SOAP is just a generic message envelope • Augmented by encodingstyle and simple rpc rules, it becomes a powerful middleware layer for remote procedure calls, if one chooses to use it that way • Now we must consider how to transport SOAP messages -- this is the final ingredient in making it something useful

  20. SOAP protocol bindings • Question:how are SOAP messages transmitted? • Answer: using existing protocols (http, SMTP, etc.) • This has some obvious advantages vs. defining its own protocol • Piggybacks on security model, general robustness • This has some disadvantages also • What are these? • SOAP defines bindings to different protocols that specify how SOAP is used with that protocol to send messages. • http is most popular

  21. Inside http • http is a simple, flexible protocol • Some examples GET http://people.cs.uchicago.edu/~asiegel/lottery/lotto.html POST /path/script.cgi HTTP/1.0 From: frog@jmarshall.com User-Agent: HTTPTool/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 32 home=Cosby&favorite+flavor=flies POST /path/script.cgi HTTP/1.0 From: frog@jmarshall.com User-Agent: HTTPTool/1.0 Content-Type: text/xml Content-Length: 32 <greeting>hello world</greeting>

  22. Testing http • Good idea to play around with http by connecting to server and issuing http commands • There are a two typical ways to do this: • Using telnet, which allows arbitrary commands to be passed to a server • telnet people.cs.uchicago.edu 80 • Note that expect can be useful in automating this • Using a socket library in a programming language (see sock.py on website) • Question: how does the server obtain the uploaded data in each case?

  23. Role of SOAP • Note that the http + XML is the important thing here • SOAP only helps standardize the meaning of the messages that are sent • In terms of datatypes for rpc • In terms of headers, faults, etc. • Note that it is still possible to bypass SOAP and define your own xml-based protocol, retaining many of the advantages of SOAP.

  24. Sorting out the API’s • In Java the following directly related API’s are available: • SAAJ • SOAP with Attachments API for Java • Provides a relatively low-level interface that allows one to programmatically construct/decompose SOAP messages and send to web server • Intended more tool writers. Good for learning. • JAX-RPC • Java API form XML-based RPC • Java’s rmi framework over SOAP • Compare RMI, CORBA, etc. • Makes developer unaware of SOAP internals • Apache XML-RPC for Java • A framework for remote procedure calls using XML-RPC • Recall that XML-RPC is an alternative protocol to SOAP

  25. Looking deeper into SOAP

  26. Envelope • MUST be the root element of the SOAP message • MUST be associated with SOAP envelope namespace • http://schemas.xmlsoap.org/soap/envelope • http://www.w3.org/2001/06/soap-envelope in SOAP 1.2 (Oct 15, 2002) • SOAP serialization namespace • Encoding Style attributes can contain a URI describing how the data should be serialized. • Two usual styles (more on this later) • "SOAP Section 5" encoding: http://www.w3.org/2001/06/soap-encoding • Literal encoding: (no namespace used – or set to empty string) • SOAP message MUST NOT contain • DTD • Processing Instructions.

  27. Envelope versioning • Version determined by the namespace associated with the Envelope element • SOAP 1.1 Envelope version: http://schemas.xmlsoap.org/soap/envelope • If any other namespace used, assume it's a version problem • Versioning problems must generate a SOAP Fault • Example SOAP fault: HTTP/1.0 500 Internal Server Error Content-Type: text/html; charset="utf-8" Content-length: 311 <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <env:Fault> <faultcode>env:VersionMismatch</faultcode> <faultstring>SOAP Envelope Version Mismatch</faultstring> </env:Fault> </env:Body> </env:Envelope>

  28. Envelope Versioning Fault in SOAP 1.2 Note that 1.2 Envelope Version Fault Response is versioned 1.1 (or whatever incoming request is) • SOAP 1.2 (Oct 15, 2002) has defined an Upgrade element in the header for the versioning fault: <?xml version="1.0" ?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header> <upg:Upgrade xmlns:upg="http://www.w3.org/2002/06/soap-upgrade" > <envelope qname="ns1:Envelope" xmlns:ns1="http://www.w3.org/2002/06/soap-envelope" /> </upg:Upgrade> </env:Header> <env:Body> <env:Fault> <faultcode>env:VersionMismatch</faultcode> <faultstring>Version Mismatch</faultstring> </env:Fault> </env:Body> </env:Envelope>

  29. Header • Optional • If present, must immediately follow the SOAP Envelope XML element followed by any header entries • Uses same namespace as Envelope • Often contains meta-information regarding the method call. • Examples: • Security • No security mechanisms yet, but soon • Transaction IDs

  30. Header • actor attribute  defines the URI for which the header elements are intended (i.e. who should process a Header element) • mustUnderstand attribute  how to process (default is “0” if not present) • encodingStyle attribute  used to describe how data (such as binary integers) are marshaled into characters in the XML document <env:Header> <t:TransactionID xmlns:t="http://www.cs.uchicago.edu/dangulo/transact" env:mustUnderstand="1" env:actor="http://www.cs.uchicago.edu/dangulo/transact" > 42 </t:TransactionID> <m:localizations xmlns:m="http://www.cs.uchicago.edu/dangulo/localize/" env:actor="http://www.cs.uchicago.edu/dangulo/currency" > <m:language>en</m:language> <m:currency>USD</m:currency> </m:localizations> </env:Header>

  31. actor Attribute • The SOAP message often gets passed through several intermediaries before being processed • For example, a SOAP proxy service might get the message before the target SOAP service • Header may contain information for both • intermediary service • target service • actor attribute specifies which service should process a specific Header element • actor attribute is replaced by role attribute in SOAP 1.2

  32. Intermediary Services • SOAP requires that an intermediary strip off Header elements specified for that intermediary before passing the message to the next service in the chain. • If information in a Header element targeted for an intermediary is also needed by another service in the chain • The intermediary service may insert additional Header elements with an actor attribute that specifies the downstream service • In fact, any service may insert any Header elements that it deems necessary • If a Header element has no actor attribute • It is assumed to be destined for the final recipient • This is equivalent to adding an actor attribute with the URL of the final recipient

  33. mustUnderstand Attribute • Also put on a Header element • If its value is "1" • recipient is required to understand and make proper use of the information supplied by that element • intended for situations where recipient can't do its job unless it knows what to do with the specific information supplied by this particular element • Examples of use • Client is upgraded to a new version which includes extra information • username • security

  34. mustUnderstand Attribute • If the recipient does not understand this element • Must respond with a SOAP Fault HTTP/1.0 500 Internal Server Error Content-Type: text/xml; charst="utf-8" Content-length: 287 <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <env:Fault> <faultcode>env:MustUnderstand</faultcode> <faultstring>SOAP Must Understand Error</faultcode> <faultactor>http://www.cs.uchicago.edu/dangulo/transact</faultactor> </env:Fault> </env:Body> </env:Envelope> • faultactor indicates where fault took place • We'll look at Faults in more detail later • Attribute values change to "true" / "false" in SOAP 1.2

  35. Some examples Taken from W3C primer

  36. Sample SOAP message for travel reservation <?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>Andrew Siegel</n:name> </n:passenger> </env:Header> Next slide ..

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

  38. Sample SOAP reply <?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:35: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>Andrew Siegel</n:name> </n:passenger> </env:Header> Next slide …

  39. <env:Body> <p:itineraryClarification xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing> <p:airportChoices> JFK LGA EWR </p:airportChoices> </p:departing> </p:departure> <p:return> <p:arriving> <p:airportChoices> JFK LGA EWR </p:airportChoices> </p:arriving> </p:return> </p:itineraryClarification> </env:Body> </env:Envelope>

  40. Reply continuing conversational exchange <?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:36:50.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>Andrew Siegel</n:name> </n:passenger> </env:Header> <env:Body> <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>LGA</p:departing> </p:departure> <p:return> <p:arriving>EWR</p:arriving> </p:return> </p:itinerary> </env:Body> </env:Envelope>

  41. SOAP RPC request with a mandatory header and two input (or "in") parameters <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <t:transaction xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding" env:mustUnderstand="true" >5</t:transaction> </env:Header> <env:Body> <m:chargeReservation env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:m="http://travelcompany.example.org/"> <m:reservation xmlns:m="http://travelcompany.example.org/reservation"> <m:code>FT35ZBQ</m:code> </m:reservation> <o:creditCard xmlns:o="http://mycompany.example.com/financial"> <n:name xmlns:n="http://mycompany.example.com/employees">Andrew Siegel</n:name> <o:number>123456789099999</o:number> <o:expiration>2005-02</o:expiration> </o:creditCard> </m:chargeReservation> </env:Body> </env:Envelope>

  42. RPC response with two output (or "out") parameters ?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <t:transaction xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding" env:mustUnderstand="true">5</t:transaction> </env:Header> <env:Body> <m:chargeReservationResponse env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:m="http://travelcompany.example.org/"> <m:code>FT35ZBQ</m:code> <m:viewAt> http://travelcompany.example.org/reservations?code=FT35ZBQ </m:viewAt> </m:chargeReservationResponse> </env:Body> </env:Envelope>

  43. RPC response with a "return" value and two "out" parameters <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <t:transaction xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding" env:mustUnderstand="true">5</t:transaction> </env:Header> <env:Body> <m:chargeReservationResponse env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:rpc="http://www.w3.org/2003/05/soap-rpc" xmlns:m="http://travelcompany.example.org/"> <rpc:result>m:status</rpc:result> <m:status>confirmed</m:status> <m:code>FT35ZBQ</m:code> <m:viewAt> http://travelcompany.example.org/reservations?code=FT35ZBQ </m:viewAt> </m:chargeReservationResponse> </env:Body> </env:Envelope>

  44. Encoding • The encodingStyle attribute can be placed on any element – allowing mixed encoding styles • Two values most often used (anything possible): • "SOAP Section 5" encoding: http://www.w3.org/2001/06/soap-encoding • Literal encoding: (no namespace used – or set to empty string) • Also can do base64 encoding • Can turn it off currently scoped style using an empty string as URL ("") • parent scoped style becomes default again

  45. Document vs. RPC style • Document: <soap:Body> contains one or more child elements called parts. There are no SOAP formatting rules for what the <soap:Body> contains; it contains whatever the sender and the receiver agree upon.･ • RPC: RPC implies that <soap:Body> contains an element with the name of the method or remote procedure being invoked. This element in turn contains an element for each parameter of that procedure. • See section 5 in http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapforrpc

  46. Encoded vs. literal • SOAP Encoding: SOAP encoding is a set of serialization rules defined in section 5 of SOAP 1.1 and is sometimes referred to as "section 5 encoding." The rules specify how objects, structures, arrays, and object graphs should be serialized. Generally speaking, an application using SOAP encoding is focused on remote procedure calls and will likely use RPC message style. The rest of this article ignores SOAP encoding and focuses on literal format. • Literal: Data is serialized according to a schema. In practice, this schema is usually expressed using W3C XML Schema. Although there are no prescribed rules for serializing objects, structures, and graphs, etc., the service's schema describes the application-level Infoset of each of the service's messages.

  47. Example document/literal soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <!-- the following is an XML document described in the service's contract using XML Schema. In this case Example may or may not be the name of a remote procedure being invoked by this message. Also, cust may or may not be the name of a parameter. We know the structure of the XML document but we don't know how the service processes it --> <Example xmlns="http://example.org/soapformat"> <cust> <Customer> <Name>John Doe</Name> <Id>ABC-1234</Id> </Customer> <Customer> <Name>Jane Doe</Name> <Id>XYZ-1234</Id> </Customer> </cust> </Example> </soap:Body> </soap:Envelope>

  48. Example rcp/literal <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <!-- Example is the name of the procedure being invoked cust is a parameter of that procedure. Note that cust is not namespace-qualified. The two Customer elements are contents of the cust parameter. In this case cust can be thought of as an array of Customer items. Note that Customer is namespace qualified but it's in a different namespace than Example. These namespace rules are unique to RPC-style messages and will be explained in the next section --> <x:Example xmlns:x="http://example.org/soapformat/Example"> <cust> <t:Customer xmlns:t="http://example.org/soapformat"> <t:Name>John Doe</t:Name> <t:Id>ABC-1234</t:Id> </t:Customer> <t:Customer> <t:Name>Jane Doe</t:Name> <t:Id>XYZ-1234</t:Id> </t:Customer> </cust> </x:Example> </soap:Body> </soap:Envelope>

  49. Response • No Special HTTP Response headers (doesn't use SOAPAction: header) • Only special SOAP element is the Fault element and its children • Otherwise, looks like a normal SOAP message <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <soap:Body><m:FavoriteColorResponseMsg xmlns:m="http://www.cs.uchicago.edu/dangulo/soap-methods"> <answer xsi:type="xsd:string">Red...No, Blue...Aarrgh!</answer> </m:FavoriteColorResponseMsg> </soap:Body> </soap:Envelope>

  50. Fault • The <fault> element is in the body of the SOAP message • 0 or 1 <fault> elements may be in the message • The following subelements may be in the <fault> element

More Related