لطفا منتظر باشید ...
SOAP
SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP was designed to reduce the engineering cost of integrating applications built on different platforms as much as possible with the assumption that the lowest-cost technology has the best chance of gaining universal acceptance. Given its central role in the Web services architecture, we describe SOAP and its processing model in some detail.A SOAP message is an XML document information item that contains three elements: <Envelope>, <Header>, and <Body>. The Envelope is the root element of the SOAP message and contains an optional Header element and a mandatory Body element. The Header element is a generic mechanism for adding features to a SOAP message in a decentralized manner. Each child element of Header is called a header block, and SOAP defines several well-known attributes that can be used to indicate who should deal with a header block (role) and whether processing it is optional or mandatory (mustUnderstand), both described below. When present, the Header element is always the first child element of the Envelope. The Body element is always the last child element of the Envelope and is a container for the "payload" intended for the ultimate recipient of the message. SOAP itself defines no built-in header blocks and only one payload, which is the Fault element used for reporting errors.All Web services messages are SOAP messages that take full advantage of the XML Infoset. The fact that both the message payload and the protocol headers employ the same model can be used to ensure the integrity of infrastructure headers as well as application bodies. Messaging infrastructure and applications can route messages based on the content of both the headers and the data inside the message. Tools that have been developed for the XML data model can be used for inspecting and constructing complete messages. These benefits were not available in architectures such as DCOM, CORBA, and RMI, where protocol headers were infrastructural details opaque to the application.SOAP messages are transmitted one-way from sender to receiverthey are datagram messages of XML documents. Multiple one-way messages can be combined into more sophisticated patterns. For instance, a popular pattern is a synchronous request/response pair of messages. The rest of this chapter describes key elements of the SOAP processing model.Any software agent that sends or receives SOAP messages is called a SOAP node. The node that performs the initial transmission of a message is called the original sender. The final node that consumes and processes the message is called the ultimate receiver. Any node that processes the message between the original sender and ultimate receiver is called an intermediary. Intermediaries are used to model the distributed processing of an individual message. The collection of intermediary nodes traversed by the message and the ultimate receiver are collectively referred to as the message path.To allow parts of the message path to be identified, each node participates in one or more roles. SOAP roles are a categorization scheme that associates a URI-based [URI] name with abstract functionality (e.g., caching, validation, authorization). The base SOAP specification defines two built-in roles: Next and UltimateReceiver. Next is a universal role in that every SOAP node other than the sender belongs to the Next role. UltimateReceiver is the role that the terminal node in a message path plays. This is typically the application or, in some cases, infrastructure that is performing work on behalf of the application.The body of a SOAP envelope is always targeted at the ultimate receiver. In contrast, SOAP headers may be targeted at intermediaries or the ultimate receiver. To provide a safe and versionable model for processing messages, SOAP defines three attributes that control how intermediaries and the ultimate receiver process a given header block: role, relay, and mustUnderstand. The role attribute is used to identify which node the header block is targeted at. The relay attribute indicates whether that node should forward unrecognized optional headers or discard them. The mustUnderstand attribute indicates whether that node can ignore the header block if it is not recognized. Header blocks marked mustUnderstand="true" are called mandatory header blocks. Header blocks marked mustUnderstand="false" or that have no mustUnderstand attribute are called optional header blocks.Every SOAP node must use these three attributes to implement the SOAP processing model. That model is defined by the following steps:
| 1. | Identify all header blocks of the SOAP message intended for the current SOAP node using the role attribute. (The absence of this attribute implies the header block is for the ultimate receiver.) |
| 2. | Verify that all mandatory header blocks identified in Step 1 can be processed by the current SOAP node using the SOAP mustUnderstand attribute. If a mandatory header block cannot be processed by the current SOAP node, the message must be discarded and a distinguished fault message generated. |
| 3. | Process the message. Optional message elements can be ignored. |
| 4. | If the SOAP node is not the ultimate receiver of the message, all header blocks identified in Step 1 that are not relayable are removed and the message is then relayed to the next SOAP node in the message path. The SOAP node is free to insert new header blocks into the relayed message. Some of these header blocks may be copies of header blocks identified in Step 1. |
The SOAP processing model is designed to allow extensibility and versioning. The must-Understand attribute controls whether the introduction of new header block is a breaking or nonbreaking change. Adding optional headers blocks (e.g., headers marked mustUnderstand="false") is a nonbreaking change, as any SOAP node is free to ignore it. Adding mandatory headers blocks (e.g., headers marked mustUnderstand="true") is a breaking change, in that only SOAP nodes that are aware of the header block's syntax and semantics are able to process the message. The role and relay attributes compose with mustUnderstand to distribute this processing model along a message path.The Action element, optional in the header elements defined in the SOAP specification, is a mandatory element in the Web services architecture. It is used to specify the URI that identifies the intent, or processing semantics, of the message. In particular, the ultimate destination uses the value of the Action element to associate messages with the code that will process them.
