Normalmente se conoce como SON (Service Oriented Network) a la arquitectura de hardware y red que soportará nuestra arquitectura SOA.
SON nos proporciona dispositivos "más inteligentes" que los tradicionales; dispositivos que son capaces de tratar el tráfico de una arquitectura SOA de una manera más eficaz que dispositivos más tradicionales que no son capaces de ver la diferencia.
Por ello, SON debe ser capaz de interpretar el lenguaje de los Servicios Web y entender su débil acoplamiento en la arquitectura con dispositivos que faciliten la virtualización de dicho desacoplamiento.
Dispositivos como balanceadores de carga, aceleradores SSL, de compresión, de cacheo o capaces de optimizar la persistencia de aplicaciones son los más orientados a conformar nuestra arquitectura hardware y de red (SON).

Esto ciertamente es un problema, ya que suelen ser dispositivos caros y en muchas ocasiones la tendencia es a reutilizar dispositivos ya existentes en la empresa que caracen de dichas características.

Por ejemplo, el uso de SOAP/HTTP en Servicios Web y XML es de lo más común en Arquitecturas Orientadas a Servicios. Existen dispositivos capaces de acelerar y parsear de manera más eficiente mensajes XML (que suelen ser bastante costosos a nivel de red por el tamaño que pueden llegar a tener). Además, si utilizamos securización SSL en nuestras comunicaciones podemos plantearnos utilizar aceleradores SSL para optimizar dicho proceso (que suele ser bastante costoso en tiempo / rendimiento cuando se realiza únicamente vía software).

Imaginemos otro ejemplo: hemos desarrollado un servicio web crítico para nuestra empresa y para nuestros partners, que hacen uso del mismo. Con dispositivos tradicionales; en ocasiones, es imposible discernir entre peticiones de algo tan simple como una página web (alojada en los mismos servidores) o una transacción en ese servicio web tan importante que hemos desarrollado. Incluso balanceadores de carga normales podrían llegar a saturar servidores de respaldo en situaciones críticas por no darse cuenta de la diferencia de importancia entre una y otra petición.
Hoy en día, existen dispositivos inteligentes; que a modo de proxy’s, son capaces de identificar dichas peticiones SOAP/HTTP para el Servicio Web y darle prioridad sobre otro tipo de peticiones. Además, pueden incluso interpretar de manera correcta el uso de Excepciones SOAP y (a partir de códigos de error de nuestra aplicación crítica) redirigir las peticiones a modo de reintentos en otros servidores de respaldo.

Pongamos ahora el siguiente problema: disponemos de un centro de datos con 10 servidores y un único Servicio Web replicado en cada servidor. Un dispositivo de red virtualiza una IP soportada por el pool de servidores. Las peticiones hechas al Servicio Web (virtualizado en una única IP) serán redirigidas al servidor que óptimamente se encuentra en mejores condiciones de resolverlo. A medida que las peticiones aumenten, el dispositivo podría monitorizar dichas peticiones, ver errores y realizar cambios en la configuración del propio dispositivo a fin de añadir instancias adicionales a nuestro pool de servidores. Incluso podría redirigir cierto tráfico a otro centro de datos con servidores latentes a modo de respaldo y asi evitar el colapso para servicios y procesos críticos.

Son solo unos pequeños ejemplos en los que evidentemente podemos sacar provecho de dispositivos construidos a fin de optimizar dichas operaciones. Para comprender la importancia de SON, uno debe de ver las redes y los servidores de la misma manera que SOA ve las aplicaciones; es decir, como la base de su desarrollo y funcionamiento.

Links interesantes:

SONA by Cisco Systems
Introducing the Service Oriented Network Architecture (SONA)
Building a Service Oriented Network