5.5 QA: A time to recap and reflect

5.5 Q&A: A time to recap and reflect

	Q: What does SOAP stand for?
	Q: What is SOAP?
	Q: Is SOAP a standard?
	Q: What is SOAP s role in relation to Web services?
	Q: Is SOAP just an RPC mechanism?
	Q: Will SOAP work only over HTTP?
	Q: With what network configurations can SOAP be used?
	Q: What is the composition of a SOAP message?
	Q: Why does SOAP appear to be so dependent on XML namespaces?
	Q: Are there any known security issues related to SOAP?

Answers

	A: SOAP, up until mid-2003, was an acronym that stood for Simple Object Access Protocol. However, with the SOAP 1.2 specification, the term SOAP ceased to be an acronym. The introductory section 1.0 of the SOAP Version 1.2 Part 1: Messaging Framework includes this terse, one-line note at its very end: In previous versions of this specification the SOAP name was an acronym. This is no longer the case. There are two overriding rationales for this change in name . SOAP never was an object access mechanism, like Internet Inter-Object Request Broker Protocol (IIOP), in the conventional sense. It was always a messaging scheme. Moreover, whether it was simple or not was subjective and open to debate. Consequently, it was best to do away with the acronym and just think of it as SOAP.
	A: SOAP is a totally XML-centric messaging scheme that can be formally characterized as a lightweight communications protocol for exchanging XML-based information between applications in a decentralized, distributed environment. If you need a thumbnail sketch, you can think of it as XML datagrams, albeit with a powerful capability that enables RPCs, irrespective of programming language, to be encapsulated within the SOAP messages.
	A: Yes. SOAP 1.2 was accepted by the W3C as a recommendation as of June 24, 2003. That makes it a bona fide industry standard for the Web community. The SOAP 1.1 specification had also been submitted to the W3C in May 2000. It was, however, never formally ratified. Thus SOAP 1.1 at best was but a de facto standard.
	A: SOAP is the underlying XML-based communications mechanism for conventional XML Web services. It is what is used to send input to and receive output from Web services ”given that XML Web services operate via exchanging XML documents. Since a Web service requires input parameters in order to be activated, SOAP is also considered to be what invokes a Web service ”given that it is what delivers the input parameters. While it is theoretically possible to have Web services that do not use SOAP, today s conventional wisdom is that SOAP is a mandatory prerequisite for XML Web services at least for the next 4 to 5 years .
	A: No. SOAP is much more than just an RPC mechanism, though it is seen as a nifty, platform-independent, and programming language “independent RPC invocation scheme. In addition to invoking RPCs via an RPC encapsulation methodology, SOAP can also be used to send request-response -type messages in client/server, multicast, or workflow-type scenarios.
	A: SOAP, by and large, is transport agnostic . HTTP is just one of the transport protocols on top of which it can be layered. SOAP also can be used on top of TCP, SMTP, FTP, message queuing, BEEP, or even other programming language “specific RPC mechanisms. HTTP, however, is the preferred and most widely used transport scheme for SOAP ”in the context of Web services as well as other scenarios. The SOAP specifications (i.e., 1.1 and 1.2) categorically state that SOAP is not tied to any one particular transport protocol, though the only SOAP binding examples shown in these specifications are those for HTTP.
	A: SOAP can be used in any distributed networking environment consisting of two or more logical SOAP nodes. Since SOAP nodes are implemented in software, it would be possible to have a multinode SOAP network implemented on a single physical machine ” especially if it is a machine such as a mainframe or UNIX server that can be readily partitioned into multiple virtual machines. SOAP messages flow from an original sender to an ultimate recipient. It is possible to have configurations that do not have any intermediaries between the sender and the receiver, as well as those that have one or more intermediaries. Within this overall, unconstrained framework it is possible to have any conceivable network configurations, including point-to-point, multipoint, meshes, and loops .
	A: A SOAP message is made up entirely of a SOAP envelope. Thus in the case of SOAP, the envelope is the message. A SOAP envelope may contain two subelements ”namely, an optional header and a mandatory body. A SOAP header, in turn , can consist of individual header blocks. A header block is a logical and discrete set of application-defined data ”with it being possible for each header block to be associated with a different namespace. Each such header block can be explicitly targeted at specific nodes, whether they are intermediaries or the ultimate receiver, via the role= attribute.
	A: XML namespaces are the standard XML mechanism to ensure that there will be no ambiguity when it comes to the meaning or intent of elements used in an XML document ”especially with documents exchanged between different organizations or individuals. Namespaces guarantee the uniqueness and integrity of XML elements across documents, organizations, businesses, and industries. Since SOAP is a messaging scheme for XML-based documents, it is taken as a given that XML documents used with SOAP will in general be read and processed at a site different from that in which the document was originally created. Use of namespaces ensures that there is no ambiguity between the sender and receiver. Moreover, using a namespace to describe the elements that make up a SOAP message (e.g., the envelope) ensures that no restrictions have to be placed as to the contents of a SOAP message to preclude conflicts with the SOAP message structure. Thus namespaces in relation to SOAP provide overall flexibility and extensibility and guarantee that the contents of XML documents delivered via SOAP can always be clearly and consistently interpreted.
	A: SOAP messages when used with HTTP can typically go through firewalls, since they are treated as HTTP transmittals. This by itself is not a major security threat ”though it is fair to point out that, as with anything that can get through a firewall, this capability could potentially be exploited to cause a denial-of-service-type attack. However, SOAP messages can be processed only by actual implementations of SOAP nodes ”which furthermore have to be explicitly programmed to accept designated SOAP messages and process them (per different roles). If a SOAP node does not process a given message, the contents of that message cannot generate any harmful behavior at the receiving system ”bar clogging it up with spurious messages. When it comes to SOAP, the key thing to ensure when it comes to security is that SOAP messages are accepted and processed behind the firewall only by trusted, proven, and reliable software. This is because whatever SOAP-related security exposures that can happen behind the firewall have to be done via collusion with the SOAP message processing software. A SOAP message by itself is on the whole harmless ”in much the same way that today s e- mails , other than clogging up mailboxes and servers, cannot typically cause damage until someone executes a malicious piece of code attached to an e-mail. However, given that it is possible to have rogue SOAP messages sent by somebody other than who is claimed on the message that may ask the recipient to perform certain tasks , it is important to validate and authenticate SOAP messages. The privacy of SOAP messages, especially when they flow across the Internet, is another matter. The content of SOAP messages could be intercepted by SOAP and non-SOAP intermediary nodes. Thus, any sensitive information conveyed with SOAP should always be adequately encrypted on an end-to-end basis.