Team-Fly |
XML, Web Services, and the Data Revolution By Frank P. Coyle | |
Table of Contents | |
Chapter 4. SOAP |
SOAP carries on the XML-RPC tradition by defining an XML language for packaging arbitrary XML inside an XML envelope. Although SOAP does not depend on HTTP, the momentum behind SOAP is attributable to the fact that HTTP will usually be used as the transport protocol for SOAP messages. Understanding SOAP is important for seeing how XML can be used to move information across the Web and how it fits in the grand vision of making XML-based distributed computing a reality. Dave Winer, whom some consider the godfather of XML-RPC, and who publishes a widely read forum called "DaveNet," [2] wrote about his work with RPC and caught the attention of some folks at Microsoft who asked Winer if he'd be interested in working with them on XML-over-HTTP. As Winer recounts it:
SOAP BackgroundThe SOAP 1.0 specification was developed by Microsoft, DevelopMentor, and Dave Winer of UserLand Software and released in the spring of 1998. Figure 4.8 illustrates the influences on SOAP. Prior to the release of SOAP 1.0, Winer released his work on RPC as the XML-RPC specification (http://www.xmlrpc.com), which is very close to SOAP 1.0. Following the release of SOAP 1.0, IBM and Lotus joined the original developers, along with a group of partners including Ariba, Commerce One, Compaq, IONA, Intel Corp., ObjectSpace, Rogue Wave, and others. SOAP 1.1 was published by the W3C as a Note in May 2000. In July 2001, the W3C released the first public Working Draft for SOAP Version 1.2 based on the work of the W3C's XML Protocol Working Group. Figure 4.8. The SOAP specification and its influences.
The SOAP ProtocolAs Figure 4.9 illustrates, SOAP is a transport protocol similar to IIOP for CORBA, ORPC for DCOM, or JRMP for RMI. SOAP differs from CORBA, RMI, or DCOM in several ways:
Figure 4.9. The SOAP protocol opens up new options for data exchange across the Web.
The net effect is that SOAP can be picked up by different transport protocols and delivered in different ways. For example, when used with HTTP it can be delivered to a Web server; when used over FTP it can deposited directly into a file system; and when used with SMTP it can delivered to a user 's mailbox. Figure 4.10 illustrates that SOAP can be used for direct connection between sender and receiver, or, with the use of messaging middleware, SOAP messages can be stored for subsequent delivery and/or broadcast to multiple receivers. Figure 4.10. SOAP extends the Web from server-to-browser to server-to-server interaction.
It should be noted that for many companies, using SOAP as protocol for exchanging data between established partners is proving a totally satisfactory way to leverage the benefits of XML and the Web. In this scenario all that is required is an agreed-upon schema, either a DTD or an XML Schema, for the XML data being exchanged and a SOAP server capable of handling the incoming XML as it arrives over the Web. Details about what kind of schemas to expect and who will check that the XML conforms to the schemas are decided offline by individuals participating in the process. On the software side, senders need to be involved in packaging their data in an XML document. For those companies already storing data in XML, this should require only minimal effort. If the stored XML data is not in the form required by the agreement, an XSL Transformations (XSLT) style sheet can be programmed to automate the transformation. SOAP OverviewSOAP consists of three parts :
SOAP messages define one-way data transmission from a sender to a receiver. However, SOAP messages are often combined to implement patterns such as request-response . When using HTTP bindings with SOAP, SOAP response messages can use the same connection as the inbound request. SOAP Message StructureFigure 4.11 illustrates the structure of a SOAP message, consisting of three parts:
Figure 4.11. SOAP messages have a common format that includes a SOAP Envelope, an optional Header, and a Body section that contains the message content. SOAP also defines a message path and set of roles that SOAP nodes can adopt along a path .
SOAP Messaging ExampleIn the previous section we looked at sending XML-RPC over HTTP to execute specific procedures on our ZwiftBooks server. With SOAP we may still use XML-RPC to trigger specific methods on the server, or we may simply define XML elements that get processed by our SOAP server. To understand how SOAP works, let's continue our ZwiftBooks example and look at how SOAP may be used to expand business functionality by opening our server up to collectors who wish to notify ZwiftBooks about books they have for sale. ZwiftBooks will then add the providers and their books to the ZwiftBooks database. To make this happen, several things must be done by ZwiftBooks:
Figure 4.12 illustrates a SOAP request for the ZwiftBooks guaranteed delivery time for a specific book, specified by ISBN number. Note that the SOAP Envelope element is the top-level element in the body of the SOAP message and within the SOAP body element is found the request for GetGuaranteedDeliveryTime , packaged as an element including the ISBN number. Figure 4.12. A SOAP request sent to the ZwiftBooks server.
A SOAP response takes the form illustrated in Figure 4.13. Here the XML response indicating the best delivery time is packaged in a SOAP message that is delivered using the standard HTTP response protocol. As far as HTTP is concerned , it's just data being returned to the client that initiated the request. However, for a client that understands SOAP, the data becomes useful information. Figure 4.13. A SOAP response to a request to the ZwiftBooks server.
Message PathsAn important aspect of SOAP is the provision for message paths. Independent of the transport protocol used to send SOAP messages, messages may be routed from server to server along a so-called message path. As we saw in Figure 4.11, message paths support message processing at one or more intermediate nodes in addition to the ultimate destination. SOAP IntermediariesSOAP intermediaries are an essential aspect of building scalable Web-based distributed systems. Intermediaries can act in different roles, including proxies, caches, store-and-forward hops, and gateways. Again, experience with HTTP has shown that intermediaries cannot be implicitly defined but must be provided as an explicit part of the messaging path model. Thus, one of the key motivations of the Working Group is to ensure that an XML protocol supports composability between peers. A SOAP-compliant server must be able to act as a SOAP intermediary capable of processing and forwarding a SOAP message on a path from its origin to a final destination. SOAP intermediaries may be explicitly specified by providing their URIs as the value of the SOAP actor attribute within a SOAP header , for example: <SOAP-ENV:Header SOAP-ENV:actor=http://yourServer.com . . .> Alternatively, a SOAP message can specify that the header should be processed by the first SOAP application that processes the message, as in this example: <SOAP-ENV:Header SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next" . . .> SOAP and ActorsIf the SOAP actor attribute is not present in a header, then the recipient of the message is considered the final destination. The following list covers the rules a well-behaved SOAP server must follow when receiving a SOAP message:
If the application is not the ultimate destination of the message, then it must remove all header elements intended for it before forwarding the message. SOAP Design PatternsArchitectural design patterns capture the proven experience of software architects in the form of architectural patterns, each with distinct properties that address different architectural design problems. To a business strategist, software architecture patterns provide a high-level conceptual view of a software system independent of the specific implementation's details. To a software engineer, patterns provide a structure within which components can be designed and integrated. To those tasked with moving from requirements to design, patterns provide a starting point for developing implementation strategies. Figure 4.14 illustrates two of the architectural patterns in wide use today: the Layers Pattern, and the Pipe and Filter Pattern. The Layers Pattern is one of the earliest successful architectural patterns and is the basis for the design of telecommunications infrastructures such as TCP/IP. Layers describe a solution to a problem by partitioning the problem into subtasks that are assigned to individual layers. Each layer draws on services from the layer below and provides services to the layer above. Figure 4.14. Architectural design patterns: The Layers Pattern and the Pipe and Filter Pattern.
A variant of the Layers pattern, the Multitier Pattern, is used to build tiered systems. For example, two-tier client-server systems partition display functionality to the client tier and business logic to the server tier. Three-tier systems add another tier for managing data. The Pipe and Filter Pattern is another architectural approach to systems construction that assumes a stream of data moving through a series of pipes and filters and being transformed as it travels from origin to destination. In addition to serving as transforming agents , stages in the Filter Pattern can be used to buffer data and help deal with issues that arise in working with interruptible network connections. The SOAP specification provides support for the filters through its ability to specify intermediary processing agents along a path from an XML document's origin to a final destination. Filters are also supported by the Simple API for XML (SAX), a Java application program interface for processing XML. SAX makes use of a filter class that can act as an intermediary in a complex chain of processing. The filter class is passed as the event handler to another class that generates SAX events, forwarding all or some of those events to the next handler or filter in the processing chain. Filters may be used to prune the document tree by not forwarding events for elements with a given name (or that satisfy some other condition), or a filter can generate new events to add parent or child elements to an existing document stream. Filters can also be used to add or remove element attributes or modify the character data. The Filter is related to UNIX's capability to take simple processing functions and pipe them together to perform complex tasks . The power of SOAP and SAX filters derives from the fact that simpler, easy-to-maintain filters may be chained together to produce complex XML data transformations. SOAP FaultsSOAP faults occur when an application cannot understand a SOAP message or when an error occurs during the processing of a message. SOAP defines an XML fault element that carries error and/or status information back to the message sender. Faults are intended to provide detail to the sender as to why the fault occurred. The information that can be returned as part of a fault includes the following:
|
Team-Fly |
Top |