Home

In IBM's tutorial on Web service design patterns, they use several concrete examples of XML messaging. The result is interesting.

Consider one of the XML messages used in the example:

     <SOAP-ENV:Envelope
          xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
          xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:xsd="http://www.w3.org/2001/XMLSchema"><SOAP-ENV:Body>
            <m:submitRequest
                  xmlns:m="http://one.wspattern.developerworks.ibm.com">
                     <request>
                         <a>String</a>
                         <b>String</b>
                         <c>String</c>
                     </request>
             </m:submitRequest>
     </SOAP-ENV:Body></SOAP-ENV:Envelope>

After one removes the formatting and XML meta-data about the three values of "String", we are really talking about is the values ( in comma-delimited form ):

    String,String,String 

That's 526 bytes of XML to represent 20 bytes of data in comma delimited form, an increase of about 2500%. One must grant that this may be an extreme case, but it is in no way unrepresentative of the XML inflation experienced in real SOA applications. A 1000% ( 10X ) rate of inflation for short messages is fairly typical, perhaps as little as several 100% for large blocks of data.

XML inflation is a very real problem for SOA technology. The price of operational meta-data can be very high in terms of server resource consumption for communications bandwidth and CPU/Memory capacity. It might even become expensive in terms of disk storage capacity - in what is becoming a terabyte world, that's no mean accomplishment.

It is true that more powerful compression/decompression services for XML messaging can mitigate some of the problems encountered in implementing real-world SOA solutions, but much of the purity of the architectural vision presented by SOA proponents seems to get lost in the process. In fact, this loss of purity may be a precondition for SOA's acceptance into the mainstream of business applications.

Perhaps the first question should not be how to implement SOA and its associated mechanisms for XML meta-data, but why do it ? IT managers should ask, how much is it worth to the value of a business function to warrant the increased operational cost and overhead ?