One of the primary benefits of using Web Services to achieve a SOA is technology independence. An often used argument against Web Services in the DoD is its unsuitability for bandwidth challenged environments. Indeed, the SOAP and XML protocols are relatively “heavy” protocols and are not the best implementation choice for bandwidth limited environments. However, utilizing a common language (i.e., WSDL and XML) to universally facilitate understanding of the services and data available on the Net is of tremendous value. Use of WSDL and XML to describe the services available does not preclude implementation using more bandwidth friendly message formats. Conversely, using Web Services as a standard facilitates the automated transformation of XML/SOAP messages into the most efficient transport protocol as the packet traverses a network that is characterized by high and low bandwidth segments.
Remember that if there are no comms then there is no integration, period. If comms are limited or intermittent, then SOA/Net-Centricity still applies with the possible requirement for translation of messages into bandwidth optimized protocols. Some change averse will argue that SOA/Net-Centricity is a flawed approach because of the limitations of Web-services protocols over a low bandwidth environment. This is like calling the Internet flawed because it doesn't reach every household.
I am not saying that existing systems that work well in a bandwidth challenged environment should be de-fielded in the name of SOA/Net-Centricity any more than I am calling for the shutdown of the US Postal Service because we now have e-mail. Good Net-Centric systems design will integrate those systems that work well in a bandwidth challenged environment with the larger community thereby increasing their value to the "net." Net-Centricity and SOA are more about leveraging the capabilities that already exist rather than replacing them.
