WebReference.com - Part 2 of Chapter 3: Professional XML Web Services, from Wrox Press Ltd (5/5)

[previous]

Professional XML Web Services

Custom Encoding

SOAP encoding is just one example of a set of encoding rules. This is a topic that deserves a level of detail beyond the slope of this chapter. Suffice it to say that we can define our own encoding, and there are many reasons that we might want to. SOAP encoding will probably handle most needs because the rules for data representation match up well with the customary programming types.

Multi-reference Values

Whether a value is represented as a simple or compound type, it is not uncommon for the same value to appear multiple times in a single payload. Because XML is a verbose representation of data, there is an opportunity to write more efficient XML documents by eliminating redundant data. SOAP follows the lead of XML Schemas by allowing values to be referenced multiple times inside a document. SOAP uses the id and href attributes to allow values to be referenced inside of a message. This allows for redundant data to be eliminated, and for the payload to more accurately reflect the language models it represents (if we are serializing a reference, why not serialize it as a reference?).

Let's look at an example of multi-reference values in use. In this example, we have a struct that represents an employee. The employee struct contains the employee's name, identification number, and address. The address is also represented as a struct.

<m:Employee>
   <idno>12345</idno>
   <fname>Billy</fname>
   <lname>Batson</lname>
   <address>
      <street>1000 Sharon Drive</street>
      <city>Charlotte</city>
      <state>North Carolina</state>
      <zip>28211</zip>
   </address>
</m:Employee>

When we introduce a second employee record, it turns out that these two employees live at the same address. There is redundant data in the address member if both these employees appear in the message payload.

<m:Employee>
   <idno>12345</idno>
   <fname>Billy</fname>
   <lname>Batson</lname>
   <address>
      <street>1000 Sharon Drive</street>
      <city>Charlotte</city>
      <state>North Carolina</state>
      <zip>28211</zip>
   </address>
</m:Employee>
<m:Employee>
   <idno>23456</idno>
   <fname>Wally</fname>
   <lname>West</lname>
   <address>
      <street>1000 Sharon Drive</street>
      <city>Charlotte</city>
      <state>North Carolina</state>
      <zip>28211</zip>
   </address>
</m:Employee>

By using the id and href attributes, we can make the address field of these two structs a multi-reference value. The example below shows what the resulting payload would look like:

<m:Employee>
   <idno>12345</idno>
   <fname>Billy</fname>
   <lname>Batson</lname>
   <address href="#address1"/>
</m:Employee>
<m:Employee>
   <idno>23456</idno>
   <fname>Wally</fname>
   <lname>West</lname>
   <address href="#address1"/>
</m:Employee>
<m:address id="address1">
   <street>1000 Sharon Drive</street>
   <city>Charlotte</city>
   <state>North Carolina</state>
   <zip>28211</zip>
</m:address>

If we are working with a SOAP message with only two structs in the payload, multi-reference values might seem like overkill. The real advantage to using multi-reference values becomes obvious when we are working with large amounts of data, such as an array of structs. Let's assume our redundant address in this example is a high-rise apartment building one block away from our company. If we were passing an array of 100 structs in a payload, perhaps 50 or more employees might all have the same address. The reduction in message size by using multi-reference values would be significant.

For many SOAP implementations, supporting multi-reference values has come late, and some still do not support this capability. On the other hand, implementations like Microsoft's .NET Framework took the approach of using multi-reference values to represent every element of an array, whether the values appear more than once or not. Interoperability tests between SOAP implementations have made great progress in identifying these types of issues.

What's Simple About It?

At this point, many developers ask, "Whatever happened to 'Simple'?" It's fair to say that with advanced topics like multiref accessors and sparse arrays, the "Simple" part of SOAP seems like a distant memory, and it is tempting to use XML-RPC or even a home-grown solution. For SOAP to be able to function as a generic messaging protocol, it must be extensible, and this extensibility does not come without a price. This is an advantage of SOAP, not a handicap. SOAP is simple when the needs of the application allow it to be, and yet its open nature allows it to handle the complexities of more sophisticated systems. As yet, not all SOAP implementations handle the more advanced aspects of the specification. As SOAP implementations mature, complex topics like multirefs will be handled transparently for most users. Until then, be extra nice to those developers working on SOAP implementations.

For any developers out there who are working on an implementation of SOAP for their platform, we highly recommend checking out both the SOAPBuilders group at Yahoo (https://groups.yahoo.com/group/soapbuilders) and the DevelopMentor SOAP discussion list (https://discuss.develop.com). They are both great sources of information on interoperability, advanced topics, and what the specification really means, as the best of the SOAP community and many of the authors of SOAP frequent them.

Now that we have covered the details of what goes into a SOAP message, let's turn our attention to how we move a message from point A to point B. This mechanism for moving messages is called the transport. [To be continued in part 3 - Ed.]

[previous]

Created: November 19, 2001
Revised: November 19, 2001

URL: https://webreference.com/authoring/languages/xml/webservices/chap3/2/5.html