SOAP with Attachments

Team-Fly    

 
XML, Web Services, and the Data Revolution
By Frank  P.  Coyle
Table of Contents
Chapter 4.   SOAP


SOAP provides a protocol to deliver XML across the Internet. However, requirements often dictate that not just XML needs to be transported but also other related documents such as DTDs, schema, Unified Modeling Language diagrams, faxes, public and private keys, and digests that may be related to the XML. In keeping with the spirit of the Web not to introduce new technologies when existing ones are available, SOAP relies on the existing rules for HTTP attachments to deliver auxiliary data with a primary SOAP message, allowing a SOAP message to reference the attachments.

The SOAP with Attachments (see Figure 4.15) document defines a binding for a SOAP message to be carried within a Multi-Purpose Internet Mail Extensions (MIME) multipart/related message in such a way that the processing rules for the SOAP message are preserved. The MIME multipart mechanism for encapsulation of compound documents can be used to bundle entities related to the SOAP message, such as attachments.

Figure 4.15. SOAP with Attachments lets additional documents travel with SOAP-based XML content using HTTP as the transport protocol.

graphics/04fig15.jpg

SOAP and Firewalls

SOAP's global reach is made possible by its alliance with HTTP, the Internet protocol that is the basis for moving data back and forth from Web servers to browsers. HTTP works by accessing Web servers on port 80, which is kept open for Web traffic. Most servers shut down other ports for security purposes.

SOAP's use of port 80 is a double-edged sword. While an open port 80 makes SOAP messaging possible, it also makes system managers nervous about incoming SOAP traffic, since SOAP messages traveling on port 80 bypass the protection afforded by firewalls. SOAP messages can contain XML-RPC commands to execute code on the server, which requires caution to protect the server from unwanted attacks, the form of which is difficult to anticipate.

It should be noted that while XML-RPC calls can easily pass through firewalls, XML-RPC distinguishes itself from other server traffic by including a header element that specifies content-type as text/xml . This at least alerts the server and associated firewall software that XML is being POSTed to the server.

The W3C and SOAP

The XML Protocol Working Group is the W3C group formed in response to the submission of the SOAP 1.1 specification as the basis for a universal XML-based protocol. The formation of the Working Group signals the W3C's willingness to consider extending the Web from a network that delivers documents and links to human users, to a network that supports communication between applications.

The goal of the XML Protocol Working Group is the creation of simple protocols that can be deployed across the Web and easily programmed through scripting languages, XML, and Web tools. It is important to note that the goal of the Working Group is not to provide a complete infrastructure for Web communication, but to build a foundational layer that can be incrementally extended to support the security, scalability, and robustness required for more complex applications.

A key aspect of the XML Protocol Working Group is that, like all other W3C initiatives, the group effort must fit within the broader W3C goals of modularity and simplicity. In defining a protocol for the Web, it is important that the final version of the envelope and any serialization mechanisms developed by the Working Group should not preclude any programming model nor assume any particular mode of communication between peers. In addition, it should also support distributed extensibility where the communicating parties do not have a priori knowledge of each other.

By limiting the scope of its effort to include neither transport nor application-specific features, the Working Group is better positioned to achieve its goal of producing a simple mechanism for encapsulating and representing data that is transferred between communicating peers. In keeping with the foundational W3C design principle of avoiding constraints if at all possible, the XML Protocol Working Group carries on the W3C philosophy of fostering interoperability.

Much of the work on SOAP has been influenced by the experience of developing HTTP, which has demonstrated how difficult it is to retrofit support for evolution and how important extensibility is as a feature of an infrastructure.

Taking SOAP to the Next Level

Going beyond the simple use of SOAP to exchange data, several options are emerging that use SOAP as their base protocol. As can be seen in Figure 4.16, other options include Electronic Business XML (ebXML) and Web services. Although we examine ebXML and Web services in more detail in Chapter 5, it's important to realize that both these technologies impose some structure on the freewheeling world of SOAP-based communication. As we'll see, ebXML is useful in defining messages and processes for common B2B transactions, and Web services is an infrastructure for discovering and connecting to services anywhere on the Web. Thus rather than spending time and money defining a schema for purchase orders, a company can turn to ebXML or a Web services framework to provide a structure for communication. However, using SOAP alone is a completely satisfactory approach with minimal risk that gets the job done.

Figure 4.16. SOAP offers an envelope for sending XML data across the Web. Technologies such as Web services and ebXML add structure and process to the B2B dialog.

graphics/04fig16.jpg


Team-Fly    
Top


XML, Web Services, and the Data Revolution
XML, Web Services, and the Data Revolution
ISBN: 0201776413
EAN: 2147483647
Year: 2002
Pages: 106
Authors: Frank Coyle

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net