¿Qué es SOA, la arquitectura orientada a servicios?

La urgencia de datos, la exactitud y la seguridad a partir de un final de un proceso de negocio al otro son ahora un mandato de negocio. Las organizaciones que pueden hacer esto tienen una distintiva ventaja competitiva.

Pero la integración por la integración no es el objetivo exclusivo. El objetivo final de contar con un sistema unificado, significa para las compañí­as estar preparadas para cambiar sus focos y recursos desde el mantenimiento de las aplicaciones separadas al desarrollo de procesos de negocios de punta a punta basados en el servicio al cliente.

Asimismo, la flexibilidad de un sistema unificado hace esto posible para cambiar aquellos procesos en una respuesta rápida a los cambios en las necesidades de los negocios.

La arquitectura orientada a servicios (SOA) no se trata de software o de un lenguaje de programación, SOA es un marco de trabajo conceptual que permite a las organizaciones unir los objetivos de negocio con la infraestructura de TI integrando los datos y la lógica de negocio de sus sistemas separados.

Desarrollada a finales de los ´90, SOA establece un marco de trabajo para servicios de red – o tareas comunes de negocios – para identificar el uno al otro y comunicarlo.

La necesidad de tal marco se deriva de la evolución del software de negocio. En los comienzos, los desarrollos de aplicaciones de negocio se concentraban en necesidades especí­ficas: contabilidad, compras, nómina de sueldos, transporte. Cada aplicación fue desarrollada sin consideración de otros sistemas en la empresa y como comunicarse con ellos. Porque las aplicaciones eran auto suficientes, la información común a toda la empresa (como por ejemplo: la dirección del cliente) y funciones especí­ficas de negocios (como por ejemplo: buscar un nombre) aparecí­an en todas partes y requerí­an un código complejo para, todos o muchos de los sistemas independientes.

Por consiguiente, los diversos sistemas de TI de la mayorí­a de las empresas hoy no pueden acceder o procesar los datos desde el uno al otro. Un simple proceso de negocio (como una venta para un pedido a un depósito enviado a una cuenta por cobrar) que tomarí­a segundos si los sistemas se podrí­an comunicar, ahora puede tomar semanas.

¿Qué puede hacer una empresa? Deberí­a tener inversiones masivas en hardware, software y perfiles de individuos involucrados en la ejecución de cada una de las aplicaciones separadas? Con SOA, una empresa puede mantener sus inversiones en los sistemas legacy y la gente necesaria para mantenerlos. Esto evita continuos y costosos proyectos "de integración", como las mejoras a cualquier aplicación son transparentes a todas las otras. La información de negocio es siempre "hasta el último minuto", permitiendo mejores decisiones de negocio y mejorar las relaciones entre clientes y partners.

A menudo, SOA es una solución prometedora para los problemas de integración. El desafí­o es cómo llegar ahí­.

Cómo crear un ambiente SOA

El desarrollo de un ambiente SOA involucra un número de pasos. El primer paso es asegurar que todo el software nuevo que se instale sea compatible con SOA. El segundo paso es identificar las funciones dentro de los sistemas legacy que desean integrar y publicarlas como servicios. Por supuesto, esto no es tan fácil como suena. El desarrollo de estos servicios puede requerir de perfiles que no existen en la empresa. Y las herramientas necesarias para examinar los desarrollos y las etapas de despliegue pueden venir de diferentes proveedores, cada uno con su propia instalación, entrenamiento y temas de comunicación. El Desarrollo de Aplicaciones Orientadas a Servicios (SODA) está diseñado para vencer muchos de los problemas de lenguajes de software inherentes en los sistemas legacy. SODA permite reutilizar aplicaciones existentes y proveer un camino para construir nuevas, basadas en estándares, con interfases flexibles.

Esta adopción habilita un alto nivel de abstracción tecnológica. Es decir, SODA encapsula y abstrae tecnologí­as tales como bases de datos, J2EE, .NET y CORBA de modo que los desarrolladores no afronten la complejidad técnica de la interacción con aplicaciones heterogéneas y sistemas de infraestructura. SODA así­ reduce significativamente el esfuerzo requerido para traducir nuevos desafí­os de negocios dentro de aplicaciones funcionales.

Diego Marsili es Technical Pre-Sales Manager de Sybase

(C) Infobaeprofesional.com