- SOAP
- Doing Business with SkatesTown
- Inventory Check Web Service
- A Closer Look at SOAP
- The SOAP Messaging Framework
- SOAP Intermediaries
- The SOAP Body
- The SOAP Processing Model
- Versioning in SOAP
- Processing Headers and Bodies
- Faults: Error Handling in SOAP
- Objects in XML: The SOAP Data Model
- The SOAP RPC Conventions
- XML, Straight Up: Document-Style SOAP
- When to Use Which Style
- The Transport Binding Framework
- Using SOAP to Send Binary Data
- Small-Scale SOAP, Big-Time SOAP
- Summary
- Resources
Processing Headers and Bodies
The SOAP spec has a specific meaning for the word process. Essentially, it means to fulfill the contract indicated by a particular piece of a SOAP message (a header or body). Processing a header means following the rules of that extension, and processing the body means performing whatever operation is defined by the service.
SOAP says you don't have to process an element in order to look at it as a part of other processing. So even though an intermediary might, for instance, encrypt the body as a message passes through it, we don't consider this processing in the SOAP sense, because encrypting the body isn't the same as doing what the body requests.
This gets back to the question of why you might use the none role. Imagine that SkatesTown wants to extend its purchase order schema by adding additional customer information. The company didn't design the schema for explicit extensibility, so adding elements in the middle will cause any older systems receiving the new XML to fail validation. SkatesTown can continue to use the old schema in the body but add arbitrary additional information in a SOAP header. That way, newer systems will notice the extensions and use them, but older ones won't be confused. This header would be purely data, without an associated SOAP module specification and processing rules, so it would make sense for SkatesTown to target the header at the none role to make sure no one tries to process it.