¿Por qué SOA?

Tomado de: Url Original
Por qué SOA?
Juan José Vázquez

En un post anterior hemos discutido sobre las ventajas que aporta un Enterprise Service Bus como implementación de SOA (Arquitectura Orientada a Servicios) en la organización. Sin embargo, previo a la decisión de desplegar un ESB en la compañía cabe plantearse por qué necesitamos SOA en nuestra implementación de los procesos de negocio.

Para entender qué ventajas aporta la arquitectura SOA tenemos que hablar del concepto de Coste de Propiedad o TCO (Total Cost of Ownership). El TCO es una estimación financiera que ayuda a los consumidores y gestores a determinar cuáles son los costes directos e indirectos de un producto o servicio. Es decir, independientemente del precio de un producto o servicio, debemos plantearnos cuáles son los costes de renovación, mantenimiento o incluso ecológicos y sociales ligados a la adquisición de dicho producto o servicio. En la industria del hardware y del software es particularmente importante considerar cuáles van a ser los costes implicados en la integración del nuevo desarrollo o producto adquirido con nuestros sistemas previos. Es decir, cómo de fácil o difícil será el encaje del nuevo sistema y de los futuros en la nueva configuración del mapa de sistemas.
Los enemigos de la integración

Más concretamente, en la industria del software, los dos grandes enemigos de la integración son el acoplamiento y la no adecuación a estándares. Se dice que un sistema está fuertemente acoplado cuando resulta muy complicado o incluso imposible modificar alguna de sus partes sin que no resulten afectadas las demás. Es decir, cada módulo o subsistema conoce y necesita demasiada información del entorno en el que opera, resultando por tanto poco autónomo y muy dependiente. En términos de integración, cuanto más acopladas estén las distintas partes de un sistema más difícil resulta integrarse con alguna de ellas sin tener que hacerlo con las demás o con el sistema al completo.

Pensemos por ejemplo en un escenario de fusión de empresas. Si los sistemas de las empresas que se fusionan presentan un acoplamiento bajo resultará más sencillo proceder a un intercambio de datos, por ejemplo de clientes o ventas, de forma gradual y sin traumas. Los dos sistemas podrían estar conviviendo durante mucho tiempo participando de forma transparente en los procesos de negocio. Por el contrario, si los sistemas están fuertemente acoplados la convivencia será prácticamente imposible implicando la toma de partido por uno de los sistemas. Esto último sin embargo suele plantear un importante reto en términos de adecuación de los datos y procesos embebidos en el sistema que desaparece en el sistema definitivo. Estos proyectos de fusión suelen resultar muy complejos, traumáticos y costosos, hasta el punto de generar caídas en el servicio con la consiguiente insatisfacción de empleados y clientes.

Como comentamos antes, otro de los grandes enemigos de la integración es la no adecuación a estándares. Los sistemas bien planificados y diseñados presentan interfaces de integración que permiten el diálogo con el resto de sistemas de la compañía y con sistemas de terceros, partners, proveedores y organismos reguladores por ejemplo. El uso de estándares facilita enormemente este diálogo dado que minimiza la necesidad de desarrollar software específico para llevar a cabo esta integración. Si cada módulo del sistema se desarrolla teniendo en mente los estándares se está preparando para una larga vida interviniendo en los procesos de negocio de la organización.
¿Qué es SOA?

Dicho esto, debemos hacer notar que SOA (Service Oriented Architecture) no es una tecnología ni un producto que podamos comprar e instalar. SOA es un conjunto de patrones, principios y prácticas para construir piezas de software que puedan interoperar independientemente de la tecnología empleada en su implementación. En este sentido, SOA implica la superación de tecnologías como Java RMI o .NET Remoting que no permiten la interoperabilidad entre distintas tecnologías de desarrollo de software.

La clave de la arquitectura SOA está en la exposición de interfaces abstractas que aíslen de la implementación particular de cada pieza de software. Para conseguir este objetivo resulta especialmente útil el uso de servicios web basados en los estándares SOAP, XML y WSDL. Sin embargo, hay que tener en cuenta que es posible tener web services y no por ello tener SOA dado que como hemos comentado, SOA es un problema de diseño y no de aplicación de una determinada tecnología.

Como características típicas de una arquitectura SOA podemos comentar:

* SOA está basado en estándares, por ejemplo las especificaciones WS-*.
* Los servicios deben ser autónomos y granulares.
* Los proveedores y consumidores deben estar débilmente acoplados.

Por último, comentar que la aplicación de una arquitectura SOA en el contexto de un problema de integración se conoce como SOI o Integración Orientada a Servicios.
Conclusión

Hoy en día las organizaciones tienen la necesidad de adaptarse a constantes cambios en el mercado, y por tanto, deben ser capaces de adaptar sus procesos a unas condiciones dinámicas como única forma de mantener y mejorar su competitividad.

A su vez, los sistemas que dan soporte a esos procesos deben poderse adaptar fácilmente para responder de forma ágil a las necesidades del negocio. El estado del arte actual de la tecnología da respuesta a este reto con SOA.