Results 1 to 1 of 1
  1. #1
    Java Exam is offline Member
    Join Date
    Dec 2011
    Posts
    64
    Rep Power
    0

    Default Tutorial:Review of SOAP Web Services for the Web Service Developer Exam

    In this article, we will look at SOAP web services so that a developer can succeed on the web service developer exam. We will provide an overview of SOAP and how it serves as one of the fundamental pillars for web services. This article is part of a series of articles to help you prepare for the web service developer exam. You can review the first article of this series, "Tutorial:Review of Building Web Services for the Web Service Developer Exam" if so desired.

    What is SOAP and SOAP Web Services?

    SOAP stands for Simple Object Access Protocol. It is the standard messaging protocol used by Web Services. SOAP Web Services are used primarily for Application-to-Application (A2A) communication such as Business-to-Business (B2B) and Enterprise Application Integration (EAI). The focus of both is on integrating software applications and sharing data. As the protocol is platform-independent, flexible, and based on standard, ubiquitous technologies it is a good fit for these type of systems.

    SOAP is basically a XML markup language used for doing one-way transmissions over networks from a SOAP sender to a SOAP receiver. It is focused on encapsulating and encoding XML data and defining the rules for transmitting and receiving that data. So basically SOAP is a network application protocol.

    A SOAP XML document instance, known as a SOAP message carries it’s payload of some other network protocol between a SOAP sender to a SOAP receiver. SOAP messages are exchanged between applications on a network and are not available for human consumption. The most elegant feature of SOAP is that the platforms and programming languages on either side of a SOAP conversation are independent of one another but are able to communicate as long as each side of the conversation does the following:
    • Send and receive data transmissions across a network using either HTTP or SMTP
    • Understand MIME encoding rules and base the means of constructing and deconstructing binary attachments on these rules
    • Construct and deconstruct XML documents that conform to the enveloping and encoding rules established by SOAP
    • Perform the required action, if an action is indicated in the SOAP document

    An figure of a SOAP communication is shown below:

    Tutorial:Review of SOAP Web Services for the Web Service Developer Exam-b2-onewaycommunication.jpg
    Figure: One-Way SOAP Communication

    You can use Web services for either One-Way messaging or Request/Response messaging. As shown above, in One-Way messaging, SOAP messages only from the sender to the receiver. In Request/Response messaging, a SOAP message travels from the sender to the receiver, which is expected to send a reply back to the sender. The figure below shows Request/Response messaging:

    Tutorial:Review of SOAP Web Services for the Web Service Developer Exam-b2-twowaycommunication.jpg
    Figure: Request/Response Messaging

    SOAP defines how messages can be structured and processed by software in a way that is independent of any programming language or platform, and thus facilitates interoperability between applications written in different programming languages and running on different operating systems.

    A key reason for the use of SOAP is that it is based in XML. The message format for SOAP is defined by an XML schema. It is also extensible by it’s use of XML namespaces. An additional advantage of SOAP is its explicit definition of an HTTP binding, a standard method for HTTP tunneling. The use of HTTP tunneling for SOAP messages allow them to pass through a firewall unimpeded. This is because most firewalls are configured to allow HTTP traffic through port 80, but will restrict or prohibit the use of other protocols and ports. These features have led to widespread adoption of SOAP by many organizations. This doesn’t mean that SOAP has not had issues. Fortunately, the recent update of SOAP 1.1 by W3C to SOAP 1.2 improves upon the SOAP processing rules and implements a number of changes that will improve interoperability. SOAP 1.2 is has recently been included as part of the WS-I Basic Profile 1.1..

    The Basic Structure of SOAP

    As mentioned previously, a SOAP message is a type of XML document. SOAP has its own XML schema, namespaces, and processing rules. Let’s now look at the structure of SOAP messages as well as the rules for creating and processing them. SOAP messages are similar to envelopes from a traditional postal service. This is shown in the table below:
    Tutorial:Review of SOAP Web Services for the Web Service Developer Exam-b2-soap-envelope-compare.jpg
    Table: Comparison of Traditional Envelope and SOAP Message

    An example of this is shown in the listing below of a SOAP message used to enclose a purchaseOrder element. The first thing to notice is how the XML namespaces are used to keep SOAP-specific elements separate from purchaseOrder elements. Next thing of note is that similar to a letter, the SOAP message that contains an arbitrary XML element in the form of a purchaseOrder element. Here we are doing One-Way communication of this SOAP message. There is no expectation of a reply from the receiver. The SOAP message will be used by Acme Books' retail customers to submit a purchase order, a request for a shipment of books. In this example, MyBooks.com is ordering 300 copies of ‘The Road to Serfdom’ for sale on its Web site

    XML Code: SOAP Message Containing an Instance of Purchase Order Markup
    <?xml version="1.0" encoding="UTF-8"?>
    <soap:Envelope
     xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >
      <soap:Body>
        <po:purchaseOrder orderDate="2003-09-22"
         xmlns:po="http://www.acmebooks.com/b2bbooks/PO">
          <po:accountName>mybooks.com</po:accountName>
          <po:accountNumber>18323</po:accountNumber>
          <po:address>
            <po:name>MYBOOKS.COM</po:name>
            <po:street>1850 Main Street</po:street>
            <po:city>New York</po:city>
            <po:state>NY</po:state>
            <po:zip>10041</po:zip>
          </po:address>
          <po:book>
            <po:title>The Road to Serfdom</po:title>
            <po:quantity>300</po:quantity>
            <po:wholesale-price>12.99</po:wholesale-price>
          </po:book>
         </po:purchaseOrder>
       </soap:Body>
    </soap:Envelope>
    The SOAP message can have an XML declaration stating the version of XML used as well as the encoding format. This is shown in the listing below:

    XML Code: XML Declaration
    <?xml version="1.0" encoding="UTF-8"?>
    If an xml declaration is used, the version of XML must be 1.0 and the encoding can be either UTF-8 or UTF-16. If encoding is absent, the assumption is that the SOAP message is based on XML 1.0 and UTF-8. This declaration isn't mandatory since web services are required to accept messages with or without them.

    Every XML document must have a root element, and in SOAP this corresponds to the Envelope element. The Envelope element may have an optional Header element, and must contain a Body element. The Header element must be the immediate child of the Envelope element and precede the Body element. It is the Body element that contains the actual application data in XML format that is being exchanged between applications. Note how similar to a traditional envelope this would correspond to actual letter. The Body element delimits the application-specific data. The figure below shows the structure of a SOAP message:

    Tutorial:Review of SOAP Web Services for the Web Service Developer Exam-b2-soapstructure.jpg
    Figure: SOAP Envelope Structure

    In SOAP web services, a SOAP message structure contains two primary components: a header and a body. Each may contain multiple blocks of information. In order to adheres to the SOAP 1.2 XML schema all the elements and attributes be fully qualified with prefixes or default namespaces. A SOAP message can have a single Body element preceded, optionally, by one Header element. The Header element generally contains information about the message, in the form of one or more distinct XML elements, each of which describes some aspect or quality of service associated with the message. This can contain XML elements that describe security credentials, transaction IDs, routing instructions, debugging information, payment tokens, or any other information about the message that is important in processing the data in the Body element. The Envelope element cannot contain any other children. This is due to the flexibility available to the SOAP message for the type of XML data carried in the SOAP Body. You can exchange a wide spectrum of data. This can be anything from an arbitrary XML element like a purchaseOrder to an element mapping the arguments of a procedure call. Below is a listing showing the outlines of the structure of a basic SOAP

    XML Code: The Structure of a SOAP Message
    <?xml version="1.0" encoding="UTF-8"?>
    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
      <soap:Header>
        <!-- Header blocks go here -->
      </soap:Header>
      <soap:Body>
        <!-- Application data goes here -->
      </soap:Body>
    </soap:Envelope>
    An example of a SOAP message with a unique identifier attached in order to facilitate debugging and logging is shown below. This is to demonstrate the flexibility of what can be inserted in the header element. In this case, we know that unique identifiers are not an integral part of the SOAP protocol itself. This is shown in the listing below:

    XML Code: SOAP Message with a Unique Identifier
    <?xml version="1.0" encoding="UTF-8"?>
    <soap:Envelope
     xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
     xmlns:mi="http://www.acmebooks.com/b2bbook/message-id" >
      <soap:Header>
        <mi:message-id>29r1d9f471wae:c4bc5fv:j3mfnc3acvc9:-9221</mi:message-id>
      </soap:Header>
      <soap:Body>
        <!-- Application-specific data goes here -->
      </soap:Body>
    </soap:Envelope>
    SOAP Namespaces

    XML namespaces are important for SOAP messages since they may include several different XML elements in the Header and Body elements, and are used to avoid name collisions for each of these elements that need to be identified by a unique namespace. They are what makes SOAP a flexible and extensible protocol. The use of XML namespaces allows for you to fully qualify an element or attribute name from another which might have similar partially qualified names. In our purchaseOrder example, the SOAP message contains a purchaseOrder element as well as the message-id and XML digital-signature header blocks requires at least six different namespaces. This is shown is the listing below:

    XML Code: Using XML Namespaces in a SOAP Message
    <?xml version="1.0" encoding="UTF-8"?>
    <soap:Envelope
     xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
     xmlns:sec="http://schemas.xmlsoap.org/soap/security/2000-12"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
     xmlns:mi="http://www.acmebooks.com/b2bbook/message-id" >
      <soap:Header>
        <mi:message-id>29r1d9f471wae:c4bc5fv:j3mfnc3acvc9:-9221</mi:message-id>
        <sec:Signature>
          ...
        </sec:Signature>
      </soap:Header>
      <soap:Body sec:id="Body">
        <po:purchaseOrder orderDate="2012-01-20"
         xmlns:po="http://www.acmebooks.com/b2bbooks/PO"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
         ...
        </po:purchaseOrder>
      </soap:Body>
    </soap:Envelope>
    There are six namespaces declared above listing. First, there is the declared namespace for all standard SOAP elements (i.e Envelope, Header and Body). Here it has a required namespace declaration for the Envelope element to be a standard SOAP 1.2 envelope namespace, "http://schemas.xmlsoap.org/soap/envelope/" . This namespace determines the version of SOAP used. If the SOAP application receives a message based on some other namespace, it will generate a fault. This rule ensures that all conforming messages are using exactly the same namespace and XML schema, and therefore the same processing rules.

    The second, third, and fourth namespaces declared in the Envelope element are associated with XML elements in the header blocks. Best practice is for each header block in the Header element to have its own namespace. This is important as namespaces aid SOAP web services to identify header blocks and process them separately. There is a variety of "standard" header blocks used to address such topics as security, transactions, and other qualities of service that have been developed by various organizations such as W3C, OASIS, IETF, Microsoft, BEA, and IBM. Each of the proposed standards define their own namespaces and XML schemas, as well as processing requirements.

    The next two namespaces are declared in the immediate child of the Body element, as shown in the previous listing. The first namespace declaration belongs to the Purchase Order Markup Language defined by Acme Books and the next one is linked to all the local elements of a SOAP message. This is becuase these elements must be namespace-qualified since the elementFormDefault attribute for the XML Schema for SOAP 1.2 is set to “qualified”. Also WS-I Basic Profile 1.1 requires that all application-specific elements containing the Body element must be qualified in order to avoid ambiguity of meaning and a proper structure to the elements.

    Finally the xsi:schemaLocation attribute which provides the URL of the schema may be declared for validation. In most cases, the SOAP stack handles this matter at design time, so that you don’t need to make an explicit declaration of the xsi :schemaLocation in a SOAP message.

    Namespaces enable a SOAP receiver to handle different versions of a SOAP message, without impairing backward compatibility or requiring different Web service endpoints for each version of a particular SOAP message. This is because a SOAP message may contain many different namespaces as well as versions of the namespaces, which makes SOAP web services very modular. This modularity facilitates different parts of a SOAP message being processed independently of other parts and also allows for each part to evolve separately. The version of the SOAP Envelope or header blocks may change over time, while the structure of the application-specific contents in the Body element remains the same. Similarly, the application-specific contents may change while the version of the SOAP message and the header blocks do not.

    The way to declare namespaces is really a matter of style. As long as you adhere to the conventions and limitations of namespace declarations spelled out by W3C Namespaces in XML recommendation, you are free to use any style you wish. The table below shows the namespace prefixes from WS-I Basic Profile 1.1 as well as the ones that we are using:

    Tutorial:Review of SOAP Web Services for the Web Service Developer Exam-b2-namespaceprefixes.jpg
    Table: Namespace Prefixes

    SOAP Headers

    The SOAP header and body are the same syntactically. There are no conventions for what is supposed to be in the header; it is used to put directives to the SOAP processor that receives the message. There must be agreement between the sending and receiving parties on the elements which are placed in the header. Higher-level protocols built on top of SOAP web services, such as ebXML Message Service (MS), have formalized the elements to use in a SOAP header by defining specific elements such as a <MessageHeader>, which contains such specific things as <From>, <To>, and <MessageId>. The leaves the SOAP body to use for actual data, or message payload, to be consumed and processed by the ultimate receiver.

    This distinction between the header and body is similar when using SOAP for RPC. The <Body> is reserved for the method call and its parameters, while the <Header> is used for things targeted at the underlying infrastructure, such as a transaction ID. A transaction ID is intended for the SOAP processor that receives the message such as a J2EE server with a transaction manager. That’s why it should not belong to the method signature. Below is the syntactic form for a SOAP header:

    XML Code: Syntactic Form of a SOAP header
    <SOAP-ENV:Envelope 
         xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
         xmlns:sec="http://schemas.xmlsoap.org/soap/security/2000-12"
         xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
         xmlns:mi="http://www.acmebooks.com/b2bbook/message-id" >
    <SOAP-ENV:Header>
        <mi:message-id>29r1d9f471wae:c4bc5fv:j3mfnc3acvc9:-9221</mi:message-id>
        <proc:processed-by>
          <node>
            <time-in-millis>102345947100</time-in-millis>
            <identity>http://www.acmebooks.com/sales</identity>
          </node>
             ...
        </proc:processed-by>
    
    </SOAP-ENV:Header> 
    <SOAP-ENV:Body> 
            ... 
    </SOAP-ENV:Body> 
    </SOAP-ENV:Envelope>
    In the listing above, each SOAP intermediary has added a node element to the processed-by header block, identifying itself and the time it processed the message. We have only shown the message from the first application to have added a node element to the processed-by header block but there could be many.

    The SOAP Body

    All SOAP messages must have exactly one Body element. The Body element contains either the application-specific data or a fault message. We include application-specific data when we want to exchange information such as arbitrary XML data or parameters to a parameters to a procedure call with a Web service. In both cases, the Body element contains the application data being exchanged. You use a fault message only when an error occurs. If the receiving node has discovered a problem, such as a processing error or a message that's improperly structured and sends it back to the sender just before it in the message path. You cannot use a SOAP message to carry both application-specific data and a fault. It is an either or proposition.

    Whether the Body element contains application-specific data or a fault, only the ultimate receiver of the SOAP message should process the contents of the Body. As we did in the previous listing intermediary nodes in the message path can view the Body element, but should never alter its contents. Instead it is free to add information to the header blocks, which may be processed by any number of intermediaries along the message path. SOAP 1.2 explicitly prohibits certain intermediaries, called forwarding intermediaries, from changing the contents of the Body element and recommends that all other intermediaries, called active intermediaries, use a header block to document any changes to the Body element.

    SOAP Messaging Modes

    SOAP generally doesn’t specify the contents of the Body element but it does specify the general structure of RPC-type messages. The only exception is in the case of fault messages. For non fault messages, SOAP expects the Body to contain well-formed XML holding application-specific data. The Body element can contain any XML element or it can be empty.

    SOAP web services supports four modes of messaging (i.e. RPC/Literal, Document/ Literal, RPC/Encoded, and Document/Encoded) the Basic Profile only permits the use of RPC/ Literal or Document/Literal. The RPC/Encoded and Document/Encoded modes are explicitly prohibited. This is because XML schema makes them obsolete, and they introduce a number of difficult interoperability problems.

    A messaging mode is defined by its messaging style; either RPC or Document as well as its encoding style. There are two common types of encoding used in SOAP messaging: SOAP encoding and Literal encoding. SOAP encoding is not supported by WS-I-conformant Web services because it causes significant interoperability problems. Literal enconding means that the XML document fragment can be validated against its XML schema.

    Document/Literal

    In the Document/Literal mode of messaging, a SOAP Body element contains an XML document fragment, a well-formed XML element that contains arbitrary application data (text and other elements) that belongs to an XML schema and namespace separate from the SOAP message's.

    Continuing with our purchase order example, a set of XML elements describing a purchase order, embedded within a SOAP message, is considered an XML document fragment. This purchase-order SOAP message is considered a Document/Literal message. The listing below shows the complete purchase-order SOAP message, which contains the purchaseOrder XML document fragment.

    XML Code: Document-Style SOAP Message
    <?xml version="1.0" encoding="UTF-8"?>
    <soap:Envelope
     xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
     xmlns:mi="http://www.acmebooks.com/b2bbooks/message-id"
     xmlns:proc="http://www.acmebooks.com/b2bbooks/processed-by">
      <soap:Header>
        <!-- Header blocks go here -->
      </soap:Header>
      <soap:Body>
        <po:purchaseOrder orderDate="2012-01-20"
         xmlns:po="http://www.acmebooks.com/b2bbooks/PO">
          <po:accountName>mybooks.com</po:accountName>
          <po:accountNumber>18323</po:accountNumber>
          ...
          <po:book>
            <po:title>The Road to Serfdom</po:title>
            <po:quantity>300</po:quantity>
            <po:wholesale-price>12.99</po:wholesale-price>
          </po:book>
        </po:purchaseOrder>
      </soap:Body>
    </soap:Envelope>
    RPC/Literal

    The RPC/Literal mode of messaging is used to enable SOAP messages to model calls to procedures or method calls with parameters and return values. In RPC/Literal messaging, the Body contents are always formatted as a struct. An RPC request message holds the method name and the input parameters of the call. An RPC response message holds the return value and any output parameters (or a fault). Generally RPC/Literal messaging is used when traditional components that have been encapsulated in Web services to open them up to a wider audience. A traditional component can come from any number of legacy systems and technologies such as CORBA, Java or DCOM. None of these components we made originally to exchange XML data. Instead they all have methods with parameters and return values. Let’s say for example, Acme Books has a legacy system that now has a JAX-RPC service endpoint called BookQuote that Acme's sales force uses. The remote interface to the BookQuote looks like this:

    Java Code: Remote Interface for BookQuote Method
    package com.b2bbooks.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;
    }
    The declaration for the getBookPrice() method requires a String parameter called ISBN. The International Standard Book Number (ISBN) is a unique string of characters assigned to every retail book. When this method is invoked with the correct ISBN, the Web service will return the wholesale price of the book identified.

    The JAX-RPC service endpoint uses RPC/Literal mode of messaging. The Web service has two SOAP messages: one message for the request and another for the reply. The request message is sent from an initial sender to the Web service and contains the method name, getBookPrice, and the ISBN string parameter. The reply message is sent back to the initial sender and contains the price of the book as a float value. The listing below shows the SOAP request message for the BookQuote Web service:

    XML Code: RPC/Literal SOAP Request Message
    <?xml version="1.0" encoding="UTF-8"?>
    <soap:Envelope
     xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
     xmlns:mh="http://www.acmebooks.com/b2bbooks/BookQuote">
       <soap:Body>
          <mh:getBookPrice>
              <isbn>1721216194</isbn>
          </mh:getBookPrice>
       </soap:Body>
    </soap:Envelope>
    The next listing shows the corresponding SOAP response message.
    XML Code: RPC/Literal SOAP Response Message
    <?xml version="1.0" encoding="UTF-8"?>
    <soap:Envelope
     xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
     xmlns:mh="http://www.acmebooks.com/b2bbooks/BookQuote" >
       <soap:Body>
          <mh:getBookPriceResponse>
              <result>12.99</result>
          </mh:getBookPriceResponse>
       </soap:Body>
    </soap:Envelope>
    As you can note from the listings, RPC/Literal messages has a simple set of arguments. RPC-style messaging is a common idiom in distributed technologies, including EJB, CORBA, DCOM, and others. This is why SOAP web services has defined a standard XML format for RPC-style messaging, called RPC/Literal. The RPC/Literal mode of messaging specifies how methods and their arguments and return values are represented within the Body element of a SOAP message.

    You should note that RPC/Literal and Document/Literal can be indistinguishable from the perspective of a developer using tools like JAX-RPC since JAX-RPC can present procedure-call semantics for both RPC/Literal and Document/Literal.

    Messaging Modes versus Messaging Exchange Patterns

    One can get confused with Document/Literal and RPC/Literal modes of messaging with the One-Way and Request/Response message exchange patterns (MEPs), but they are conceptually different. Document/Literal or RPC/Listeral messaging mode describes the payload of the SOAP message: an XML document fragment or an XML representation of the parameters and return values associated with a remote procedure call. One-Way and Request/Response MEPs relates to the flow of messages, not their contents. Whereas One-Way messaging is unidirectional and Request/Response is bi-directional, it is possible to use the Document/Literal mode of messaging with either One-Way or Request/Response messaging. Similarly RPC/Literal mode of messaging can also be used with

    SOAP Faults

    SOAP fault messages are the mechanism by which SOAP web services report errors "upstream," to nodes earlier in the message path. SOAP faults are generated by receivers of a message. This can be either an intermediary or the ultimate receiver of a message. The receiver is required to send a SOAP fault back to the sender only if the Request/Response messaging mode is used. If it is operating in One-Way mode, the receiver should generate a fault and store it for later perusal but must not attempt to transmit it to the sender.

    SOAP faults are returned to the receiver's immediate sender. If for example, the fourth node in a message path generates a fault, that fault message should be sent to the third node in the message path. In other words, you only send the fault to the original sender. When that sender receives the fault message, it may do some action, such as undoing operations, and then send another fault further upstream to the previous sender if there is one.

    A SOAP message that has a Body with a Fault elementis called a fault message. It is analogous to a Java exception. It's generated when an error occurs. Fault messages are generally used in Request/Response messaging. Nodes in the message path generate them when processing a request message. When a fault occurs, the receiving node sends a fault message back to the previous sender. Faults are caused by any number of problems such as improper message formatting, version mismatches, trouble processing a header, and application-specific errors.

    When a fault message is generated, the SOAP message Body holds a single Fault element and nothing else. The Fault element itself must contain a faultcode element and a faultstring element, and an optional faultactor and detail elements. The listing below provides an example of a SOAP fault message.

    XML Code: SOAP Fault Message
    <?xml version="1.0" encoding="UTF-8"?>
    <soap:Envelope
     xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
     xmlns:mh="http://www.acmebooks.com/b2bbooks/BookQuote" >
      <soap:Body>
        <soap:Fault>
          <faultcode>soap:Client</faultcode>
          <faultstring>
            The ISBN value contains invalid characters
          </faultstring>
          <faultactor>http://www.mybooks.com</faultactor>
          <detail>
            <mh:InvalidIsbnFaultDetail>
              <offending-value>242118584-J</offending-value>
              <conformance-rules>
                The first nine characters must be digits. The last
                character may be a digit or the letter 'X'. Case is
                not important.
              </conformance-rules>
            </mh:InvalidIsbnFaultDetail>
          </detail>
        </soap:Fault>
      </soap:Body>
    </soap:Envelope>
    Note that the Fault element and its children are part of the SOAP namespace similar to the SOAP Envelope and Body elements. It is important to note that the children of the Fault element don’t need to be qualified with the soap prefix. As well it's forbidden for the Fault element to contain any immediate child elements other than faultcode, faultstring, faultactor, and detail.

    The SOAP Protocol Binding

    As the vast majority of all Internet traffic is data transferred using HTTP (HyperText Transfer Protocol), SOAP has been designed SOAP so that every message can be carried as the payload of an HTTP message. This "tunneling" has been fundamental to SOAP's rapid adoption and unprecedented success.

    You can also deliver SOAP messages using other protocols, such as SMTP and FTP as well, but details of these non-HTTP bindings are not specified by SOAP and are not supported by the Basic Profile, so we will only look at SOAP over HTTP. The following listing shows the HTTP header information that is prepended to the message when it is bound to the HTTP protocol:

    XML Code: SOAP Request over HTTP
    POST /jwsbook/BookQuote HTTP/1.1
    Host: [url]www.acmebooks.com[/url]
    Content-Type: text/xml; charset="utf-8"
    Content-Length: 298
    SOAPAction=""
    
    <?xml version="1.0" encoding="UTF-8"?>
    <soap:Envelope
     xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
     xmlns:mh="http://www.acmebooks.com/b2bbooks/BookQuote">
       <soap:Body>
          <mh:getBookPrice>
              <isbn>1721216194</isbn>
          </mh:getBookPrice>
       </soap:Body>
    </soap:Envelope>
    Note that the Content-Type is text/xml, indicating that the payload is an XML document. The WS-I Basic Profile 1.0 prefered that the text/xml Content-Type be used with SOAP over HTTP. It's possible to use others such as multipart/related for SOAP with Attachments but it's not recommended.

    As HTTP is ubiquitous, well understood, and widely supported it provides a good base for SOAP. The fact that modern firewalls do not restrict HTTP traffic on port 80 makes HTTP convenient for accessing servers and clients behind firewalls—which are a major impediment to distributed computing. This introduces security issues because it allows the circumventing the firewalls that help keep organizations safe from malicious hackers.

    But as SOAP is a transparent protocol with simple text rather than opaque data, a firewall can easily inspect the contents and route the message to a SOAP-specific security processor. Although HTTP is not the only protocol over which you can send SOAP messages, for now HTTP is the only protocol endorsed by the WS-I.

    Finally the SOAPAction header was a required part of the HTTP protocol binding in SOAP 1.1. Its purpose was to allow something that does routing or dispatching to make decisions without any knowledge of SOAP or the means to parse the SOAP envelope. This would allow a dumb CGI script or servlet whose only purpose is to route requests to other processes would not need to process the SOAP envelope to get routing information. The only problem with this concept is that it is tied to the HTTP protocol. In SOAP 1.2 (and Basic Profile 1.1) the HTTP protocol binding has become optional. This has been replaced by a generic mechanism for specifying extra data independent of the protocol.

    Wrapping Up

    The Basic Profile has done a lot of work to clear up ambiguities in SOAP 1.1, and SOAP 1.2. SOAP 1.2 has now supplanted SOAP 1.1 and it has been integrated into the WS-I Basic Profile. J2EE 1.5 Web Services support SOAP 1.2 so there is little to prevent you from taking advantage of SOAP web services out of the box. Next we are on to WSDL.
    Last edited by Java Exam; 02-15-2012 at 02:17 PM.

Similar Threads

  1. Replies: 0
    Last Post: 02-14-2012, 07:21 PM
  2. Replies: 0
    Last Post: 02-06-2012, 06:46 PM
  3. Replies: 0
    Last Post: 02-03-2012, 05:23 AM
  4. Replies: 0
    Last Post: 01-17-2012, 04:53 PM
  5. Replies: 0
    Last Post: 01-06-2012, 11:51 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •