¿Qué es SOA (Arquitectura Orientada a Servicios)?
SOA, arquitectura orientada a servicios (arquitectura orientada a servicios) es un modelo de componentes que conecta diferentes unidades funcionales de una aplicación (llamadas servicios) a través de interfaces bien definidas y se mantienen contratos entre estos servicios. La interfaz se define de forma neutral y debe ser independiente de la plataforma de hardware, sistema operativo y lenguaje de programación en el que se implementa el servicio. Esto permite que los servicios integrados en una variedad de dichos sistemas interactúen de una manera unificada y común.
Esta característica de tener definiciones de interfaz neutrales (sin estar obligado a vincularse a una implementación específica) se denomina acoplamiento flexible entre servicios. Los beneficios de un sistema débilmente acoplado son su flexibilidad y su capacidad para sobrevivir cuando la estructura interna y la implementación de cada servicio que compone toda la aplicación cambian gradualmente. El acoplamiento estrecho, por otro lado, significa que las interfaces entre los diferentes componentes de la aplicación están estrechamente vinculadas a su funcionalidad y estructura, lo que las hace vulnerables cuando es necesario realizar algún tipo de cambio en partes o en toda la aplicación.
La necesidad de sistemas débilmente acoplados surge de la necesidad de que las aplicaciones comerciales se vuelvan más flexibles de acuerdo con las necesidades comerciales para adaptarse a entornos cambiantes, como políticas, niveles comerciales, prioridades comerciales, relaciones de socios e industrias que cambian con frecuencia. estado y otros factores relacionados con el negocio que pueden incluso afectar la naturaleza del negocio. Llamamos negocio bajo demanda a un negocio que puede adaptarse de manera flexible a los cambios en el entorno. En un negocio bajo demanda, se pueden realizar los cambios necesarios en la forma en que se completa o realiza una tarea una vez que se necesita.
Aunque la arquitectura orientada a servicios no es algo nuevo, es un modelo alternativo al modelo más tradicional orientado a objetos, que está estrechamente acoplado y existe desde hace más de dos décadas. Aunque los sistemas basados en SOA no excluyen el uso de un diseño orientado a objetos para crear servicios individuales, su diseño general está orientado a servicios. Aunque SOA está basada en objetos porque tiene en cuenta los objetos dentro del sistema, no está orientada a objetos en su conjunto. La diferencia está en la propia interfaz. Un ejemplo típico de prototipo de sistema SOA es la Common Object Request Broker Architecture (CORBA), que existe desde hace mucho tiempo y define conceptos similares a SOA.
Sin embargo, la SOA actual es diferente porque se basa en avances más recientes basados en el lenguaje de marcado extensible (XML). Al utilizar un lenguaje basado en XML llamado Lenguaje de definición de servicios web (WSDL) para describir interfaces, los servicios se han trasladado a un sistema de interfaz más dinámico y flexible que el lenguaje de descripción de interfaz (Interfaz) anterior en CORBA.
Los servicios web no son la única forma de implementar SOA. El CORBA que acabamos de mencionar es otra forma, por lo que existe un sistema de middleware orientado a mensajes (Message-Oriented Middleware), como la serie MQ de IBM. Pero para modelar una arquitectura, se necesita más que descripciones de servicios. Debe definir cómo toda la aplicación realiza su flujo de trabajo entre servicios. En particular, es necesario encontrar puntos de transición entre las operaciones del negocio y las operaciones del software utilizado en el negocio. Por lo tanto, SOA debería poder conectar los procesos comerciales de la empresa con sus procesos técnicos y mapear la relación entre los dos. Por ejemplo, pagarle a un proveedor es un proceso comercial, mientras que actualizar su base de datos de repuestos para incluir nuevos suministros es un proceso técnico.
Por tanto, el flujo de trabajo también puede desempeñar un papel importante en el diseño de SOA.
En definitiva, todo ello debe ser dentro de un ambiente de confianza y confiabilidad, para que el proceso se lleve a cabo según lo esperado y según los términos acordados. Por lo tanto, la seguridad, la confianza y la mensajería fiable deberían desempeñar un papel importante en cualquier SOA.
La necesidad de SOA surge de la necesidad de flexibilizar los sistemas TI empresariales para adaptarse a los cambios del negocio. Al permitir relaciones fuertemente definidas e implementaciones específicas que siguen siendo flexibles, los sistemas de TI pueden aprovechar las capacidades de los sistemas existentes y estar preparados para realizar cambios más adelante para satisfacer las necesidades de sus interacciones.
Aquí tienes un ejemplo concreto. Una organización minorista de ropa con 500 cadenas de tiendas internacionales a menudo necesita cambiar de diseño para mantenerse al día con las tendencias de la moda. Esto puede significar no sólo cambiar estilos y colores, sino incluso cambiar telas, fabricantes y productos. Si los sistemas entre el minorista y el fabricante son incompatibles, cambiar de un proveedor a otro puede ser un proceso de software muy complejo. Al aprovechar la flexibilidad operativa de la interfaz WSDL, cada empresa puede mantener sus sistemas existentes tal como están y simplemente combinar la interfaz WSDL y desarrollar nuevos acuerdos de nivel de servicio sin tener que refactorizar completamente sus sistemas de software. Este es un cambio a nivel empresarial, lo que significa que cambian de socios mientras que todas las operaciones comerciales siguen siendo esencialmente las mismas. Aquí, la interfaz empresarial se puede cambiar ligeramente, pero no es necesario cambiar las operaciones internas, sólo para poder trabajar con socios externos.
Otra forma es el cambio interno, en el que la organización minorista ahora ha decidido que también alquilará algunos lugares dentro de las cadenas de tiendas minoristas a pequeñas tiendas especializadas en ropa de moda. Esto puede verse como Adoptar una tienda. Modelo de negocio en tienda. Aquí, si bien la mayoría de las operaciones comerciales de la empresa siguen siendo las mismas, ahora requieren un nuevo software interno para manejar dichos acuerdos de alquiler. Si bien los sistemas de software internos pueden soportar una revisión completa, deben hacerlo sin tener un impacto importante en las interacciones con los sistemas de proveedores existentes. En este caso, el modelo SOA permanece intacto mientras cambia la implementación interna. Si bien se pueden agregar nuevos aspectos al modelo SOA para incorporar responsabilidades para nuevos acuerdos de alquiler, los sistemas normales de gestión minorista continúan como de costumbre.
Para continuar con la idea de cambio interno, los administradores de TI pueden encontrar que la nueva configuración del software se puede utilizar de otra manera, como alquilar espacio para carteles con fines publicitarios. En este caso, se derivan nuevas propuestas comerciales mediante la reutilización de modelos SOA flexibles en nuevos diseños. Este es un nuevo resultado del modelo SOA y una nueva oportunidad que tal vez no haya existido antes.
También son posibles cambios verticales, en los que los minoristas pasan completamente de vender su propia ropa a alquilar espacio exclusivamente a través de un modelo de tienda dentro de tienda. Si los cambios verticales comienzan completamente desde abajo, provocarán cambios significativos en la estructura del modelo SOA y, junto con los cambios, también puede haber nuevos sistemas, software, procesos y relaciones. En este caso, el beneficio del modelo SOA es que considera los problemas desde la perspectiva de las operaciones y procesos comerciales en lugar de desde la perspectiva de aplicaciones y programas, lo que permite a la gestión empresarial determinar claramente lo que se debe agregar, modificar en función de la operaciones del negocio o eliminarlas. Luego, el sistema de software se puede estructurar de una manera que se adapte al proceso de negocio en lugar de otras formas que suelen verse en muchas plataformas de software existentes.
Como puedes ver, el cambio y la capacidad del sistema SOA para adaptarse al cambio son las partes más importantes aquí. Para los desarrolladores, tales cambios son posibles tanto dentro como fuera del alcance de su trabajo, dependiendo de si hay un cambio que requiere conocimiento de cómo se definen las interfaces y cómo se relacionan entre sí para interactuar.
A diferencia de los desarrolladores, el papel del arquitecto es provocar grandes cambios en el modelo SOA. Esta división del trabajo, que permite a los desarrolladores centrarse en la creación de unidades funcionales definidas como servicios, mientras que los arquitectos y modeladores se centran en cómo organizar adecuadamente estas unidades, existe desde hace más de una década. Por lo general, el Lenguaje de modelado unificado (UML). utilizado y descrito como una arquitectura basada en modelos (MDA).