Una arquitectura orientada a servicios (SOA) es un patrón arquitectónico en el diseño de software de computadora en el que los componentes de la aplicación brindan servicios a otros componentes a través de un protocolo de comunicaciones, generalmente a través de una red. Los principios de la orientación al servicio son independientes de cualquier producto, proveedor o tecnología.
SOA simplemente facilita que los componentes de software de varias redes funcionen entre sí.
Los servicios web que se construyen según la arquitectura SOA tienden a hacer que el servicio web sea más independiente. Los propios servicios web pueden intercambiar datos entre sí y, debido a los principios subyacentes sobre los que se crean, no necesitan ningún tipo de interacción humana y tampoco necesitan modificaciones de código. Garantiza que los servicios web de una red puedan interactuar entre sí sin problemas.
SOA se basa en algunos principios clave que se mencionan a continuación
- Contrato de servicio estandarizado : los servicios se adhieren a una descripción de servicio. Un servicio debe tener algún tipo de descripción que describa de qué trata el servicio. Esto facilita que las aplicaciones cliente comprendan lo que hace el servicio.
- Acoplamiento suelto : menos dependencia entre sí. Esta es una de las principales características de los servicios web que simplemente establece que debe haber la menor dependencia posible entre los servicios web y el cliente que invoca el servicio web. Por lo tanto, si la funcionalidad del servicio cambia en cualquier momento, no debería interrumpir la aplicación cliente ni impedir que funcione.
- Abstracción de servicios : los servicios ocultan la lógica que encapsulan del mundo exterior. El servicio no debe exponer cómo ejecuta su funcionalidad; solo debería decirle a la aplicación cliente lo que hace y no cómo lo hace.
- Reutilización del servicio : la lógica se divide en servicios con la intención de maximizar la reutilización. En cualquier empresa de desarrollo, la reutilización es un tema importante porque, obviamente, uno no querría gastar tiempo y esfuerzo en construir el mismo código una y otra vez en múltiples aplicaciones que lo requieran. Por lo tanto, una vez que se escribe el código para un servicio web, debería tener la capacidad de trabajar con varios tipos de aplicaciones.
- Autonomía del servicio : los servicios deben tener control sobre la lógica que encapsulan. El servicio sabe todo sobre las funciones que ofrece y, por lo tanto, también debe tener un control completo sobre el código que contiene.
- Apatridia del servicio : idealmente, los servicios deberían ser apátridas. Esto significa que los servicios no deben retener información de un estado a otro. Esto debería hacerse desde la aplicación cliente. Un ejemplo puede ser un pedido realizado en un sitio de compras. Ahora puedes tener un servicio web que te da el precio de un artículo en particular. Pero si los artículos se agregan a un carrito de compras y la página web navega a la página donde realiza el pago, la responsabilidad del precio del artículo a transferir a la página de pago no debe ser realizada por el servicio web. En su lugar, debe hacerlo la aplicación web.
- Detección de servicios : los servicios se pueden descubrir (generalmente en un registro de servicios). Ya lo hemos visto en el concepto de UDDI, que realiza un registro que puede contener información sobre el servicio web.
- Capacidad de composición del servicio : los servicios dividen los grandes problemas en pequeños problemas. Nunca se debe incrustar toda la funcionalidad de una aplicación en un solo servicio, sino dividir el servicio en módulos, cada uno con una funcionalidad comercial separada.
- Interoperabilidad del servicio : los servicios deben utilizar estándares que permitan a diversos suscriptores utilizar el servicio. En los servicios web, se utilizan estándares como XML y comunicación a través de HTTP para asegurar que se ajusta a este principio.