Algunos problemas con los sistemas SOA
La demanda de SOA surge de la necesidad de hacer que los sistemas TI empresariales sean más flexibles para adaptarse a los cambios del negocio. Al permitir relaciones fuertemente definidas e implementaciones concretas que aún son flexibles, los sistemas de TI no sólo pueden aprovechar las capacidades de los sistemas existentes sino también estar preparados para realizar cambios en el futuro para satisfacer las necesidades de sus interacciones. He aquí un ejemplo concreto. Una organización minorista de ropa tiene 500 cadenas de tiendas internacionales y, a menudo, necesitan cambiar de diseño para mantenerse al día con las tendencias de la moda. Esto puede significar cambiar no sólo estilos y colores, sino también telas, fabricantes y métodos de entrega.
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 sin cambios, simplemente adaptar la interfaz WSDL y desarrollar nuevos acuerdos de nivel de servicio, sin tener que reconstruir completamente su sistema de software.
Se trata de un cambio a nivel empresarial, es decir, han cambiado de socios, pero todas las operaciones comerciales se mantienen básicamente sin cambios. La interfaz comercial aquí se puede cambiar ligeramente, pero no es necesario cambiar las operaciones internas, solo para poder cooperar con socios externos.
Otra forma es el cambio interno. En este cambio, la organización minorista decidió que también alquilaría algunos lugares en las tiendas minoristas de la cadena a pequeñas tiendas especializadas en ropa de moda, lo que puede considerarse como la adopción de un modelo de negocio tienda en tienda.
Aquí, si bien la mayoría de las operaciones comerciales de la empresa seguían siendo las mismas, necesitaban un nuevo software interno para manejar dichos acuerdos de arrendamiento. Si bien los sistemas de software internos pueden resistir una revisión exhaustiva, deben hacerlo sin interrumpir las interacciones con los sistemas de proveedores existentes.
En este caso, el modelo SOA sigue siendo el mismo, pero la implementación interna cambia. Aunque se pueden agregar nuevos aspectos al modelo SOA para agregar responsabilidades para nuevos acuerdos de arrendamiento, el sistema normal de gestión minorista sigue funcionando como de costumbre.
Para continuar con la idea de cambio interno, los administradores de TI pueden descubrir que la nueva configuración del software se puede utilizar de otra manera, como alquilar espacio para carteles publicitarios. Aquí se desarrollan nuevas propuestas de negocio reutilizando modelos SOA flexibles en nuevos diseños. Este es un nuevo logro del modelo SOA y una nueva oportunidad que tal vez no haya existido antes.
También son posibles cambios verticales, ya que los minoristas pasarán por completo de vender su propia ropa a alquilar espacio exclusivamente a través de un modelo de tienda dentro de otra tienda. Si los cambios verticales comienzan completamente desde abajo, traerán cambios importantes en la estructura del modelo SOA, así como nuevos sistemas, software, procesos y relaciones.
En este caso, la ventaja del modelo SOA es que considera el problema desde la perspectiva de las operaciones y procesos de negocio en lugar de desde la perspectiva de aplicaciones y programas, lo que permite a la gestión empresarial determinar claramente la necesidad. Agregar en función de las operaciones comerciales, modificar o eliminar algo. Luego, el sistema de software se puede construir de una manera que sea adecuada para el procesamiento empresarial, en lugar de otras formas que a menudo se ven en muchas plataformas de software existentes.
Como puedes ver, el cambio y la capacidad del sistema SOA para adaptarse al cambio es la parte más importante aquí. Para los desarrolladores, este cambio puede ocurrir dentro o fuera del alcance de su trabajo, dependiendo de si hay cambios que requieran comprender cómo se definen las interfaces y cómo interactúan entre sí.
A diferencia de los desarrolladores, el papel del arquitecto es provocar cambios dramáticos en el modelo SOA. Esta división del trabajo permite a los desarrolladores centrarse en crear unidades funcionales como definiciones de servicios y permite a los arquitectos y modeladores centrarse en cómo organizar estas unidades de forma adecuada. Tiene más de una década, a menudo se describe en Universal Modeling Language (UML) y se describe como Arquitectura basada en modelos (MDA).
SOA es una revolución en la computación distribuida basada en el modelo de solicitud/respuesta para aplicaciones síncronas y asíncronas. La lógica empresarial de la aplicación o alguna funcionalidad individual se modulariza y se proporciona como un servicio a los consumidores o clientes. La clave de estos servicios es su naturaleza débilmente acoplada.
Por ejemplo, la interfaz y la implementación de un servicio son independientes.
Los desarrolladores de aplicaciones o integradores de sistemas pueden crear aplicaciones combinando uno o más servicios sin conocer la implementación subyacente de los servicios. Por ejemplo, puede utilizar servicios. NET o J2EE, las aplicaciones que utilizan este servicio pueden utilizar diferentes lenguajes en diferentes plataformas. Los servicios SOA tienen documentos XML autodescriptivos independientes de la plataforma. WSDL (lenguaje de descripción de servicios web) es un lenguaje estándar para describir servicios.
Los servicios SOA se comunican con mensajes, que normalmente están definidos mediante esquemas XML (también conocidos como XSD, XML Schema Definición). La comunicación entre consumidores y proveedores o entre consumidores y servicios es más común en entornos donde se desconoce al proveedor. La comunicación entre servicios también puede considerarse documentos críticos para el negocio procesados dentro de la empresa.
Dentro de la empresa, los servicios SOA se mantienen a través de un centro de registro, que desempeña la función de listado de directorio. La aplicación busca y llama al servicio en el registro.
UDDI (Descripción, Definición e Integración Universal) es un estándar para el registro de servicios. Cada servicio SOA tiene asociada una Calidad de Servicio (QoS). Algunos elementos clave de la QoS son los requisitos de seguridad (como la autenticación y la autorización) y una comunicación confiable significa garantizar que los mensajes se envíen solo una vez para filtrar los mensajes duplicados. ) y la política de quién puede llamar al servicio. Diferentes tipos de sistemas operativos, software de aplicaciones, software de sistemas e infraestructura de aplicaciones están entrelazados. Ésta es la situación actual de las empresas de TI. Algunas aplicaciones existentes se utilizan para manejar procesos comerciales actuales, por lo que es imposible construir un nuevo entorno de infraestructura desde cero.
Las empresas deben poder responder rápidamente a los cambios comerciales, aprovechar las inversiones en aplicaciones e infraestructura de aplicaciones existentes para abordar nuevas necesidades comerciales y proporcionar nuevos canales de interacción para clientes, socios comerciales y proveedores, y proporcionar un marco capaz de apoyar el negocio orgánico.
Con su naturaleza débilmente acoplada, SOA permite a las empresas agregar nuevos servicios o actualizar los servicios existentes de manera modular para satisfacer nuevas necesidades comerciales, brindar la opción de brindar servicios a través de diferentes canales y aplicaciones empresariales existentes o existentes. como servicio, protegiendo así las inversiones existentes en infraestructura de TI.
Las empresas que utilizan SOA pueden crear aplicaciones compuestas de la cadena de suministro utilizando un conjunto de aplicaciones existentes que proporcionan funcionalidad a través de interfaces estándar.
Arquitectura de servicios
Para implementar SOA, las empresas necesitan una arquitectura de servicios. Por ejemplo, un consumidor de servicios puede invocar un servicio enviando un mensaje. Estos mensajes son transformados por Service Bus y enviados a la implementación de servicio adecuada.
Esta arquitectura de servicio puede proporcionar un motor de reglas de negocio que permite incorporar reglas de negocio en uno o más servicios. La arquitectura también proporciona una infraestructura de gestión de servicios para gestionar servicios como auditoría, facturación, registro y otras funciones.
Además, la arquitectura proporciona a las empresas procesos comerciales flexibles que pueden manejar mejor los requisitos regulatorios como la Ley Sarbanes-Oxley (SOX) y se pueden implementar sin afectar otros servicios de cambio.
Infraestructura SOA
Para ejecutar y gestionar aplicaciones SOA, las empresas necesitan una base SOA, que forma parte de la plataforma SOA. La base SOA debe soportar todos los estándares relevantes y los contenedores de tiempo de ejecución requeridos. La Figura 3 muestra una infraestructura SOA típica.
SOAP, WSDL, UDDI, WSDL, UDDI y SOAP son los componentes básicos de la base SOA. WSDL se utiliza para describir servicios; UDDI se utiliza para registrar y buscar servicios; SOAP se utiliza como capa de transporte para transmitir mensajes entre consumidores y proveedores de servicios.
SOAP es el mecanismo predeterminado para los servicios web y otras tecnologías pueden implementar otros tipos de enlaces para servicios. Los consumidores pueden buscar servicios en el registro UDDI, obtener la descripción WSDL del servicio y luego llamar al servicio a través de SOAP.
Perfil básico WS-I
El perfil básico WS-I proporcionado por la Organización de interoperabilidad de servicios web es el componente central necesario para las pruebas y la interoperabilidad del servicio SOA. Los proveedores de servicios pueden utilizar Basic Profile Tester para probar la interoperabilidad de los servicios en diferentes plataformas y tecnologías.
J2EE y. Net
Aunque J2EE y . NET es una plataforma común para desarrollar aplicaciones SOA, pero SOA no se limita a esto. Plataformas como J2EE no sólo proporcionan a los desarrolladores una plataforma natural para participar en SOA, sino que también introducen escalabilidad, confiabilidad, disponibilidad y rendimiento en el mundo de SOA a través de sus características inherentes.
Las nuevas especificaciones, como JAXB (Java API para enlace XML), se utilizan para ubicar documentos XML en clases Java; JAXR (Java API para registro XML) se utiliza para estandarizar el funcionamiento del registro UDDI; J2EE1.4 utiliza XML-RPC (Java API para llamadas a procedimientos remotos basados en XML) para llamar a servicios remotos, lo que facilita el desarrollo y la implementación de servicios web que pueden migrarse a contenedores J2EE estándar. Al mismo tiempo, se logra la interoperabilidad de servicios multiplataforma (como .NET). En la empresa, sistema de misión crítica significa que si la confiabilidad del sistema es crítica para una organización, entonces el sistema es de misión crítica para la empresa.
Por ejemplo, el sistema telefónico es un sistema de misión crítica para una empresa de telemercadeo, pero el sistema de procesamiento de textos no lo es tanto. ) aborda necesidades de alto nivel como seguridad, confiabilidad, etc. Cuando las empresas comenzaron a utilizar la arquitectura de servicios como herramienta para desarrollar e implementar aplicaciones, las especificaciones de servicios web básicos como WSDL, SOAP y UDDI no pudieron satisfacer estas necesidades avanzadas.
Como se mencionó anteriormente, estos requisitos también se conocen como Calidad de Servicio (QoS). Algunos grupos de estándares han propuesto muchas especificaciones relacionadas con la QoS, como el W3C (World Wide Web Consortium) y Oasis (Organización para el Avance de los Estándares de Información Estructurada). Las siguientes secciones analizan algunos servicios de QoS y estándares relacionados.
Seguro
Las especificaciones de seguridad de los servicios web se utilizan para garantizar la seguridad de los mensajes. La especificación cubre principalmente el intercambio de autenticación, la integridad de los mensajes y la confidencialidad de los mensajes. El atractivo de la especificación es que se basa en estándares de seguridad existentes, como SAML (como lenguaje de marcado de afirmación de seguridad), para implementar la seguridad de los mensajes de servicios web. OASIS está comprometido con el desarrollo de especificaciones de seguridad de servicios Web.
Confiable
En un entorno SOA típico, se intercambian varios documentos diferentes entre los consumidores y los proveedores de servicios. Existen características como "entrega una sola vez", "entrega como máximo una vez", "eliminación de mensajes duplicados", etc. El envío y el acuse de recibo de mensajes característicos como la "entrega de mensajes garantizada" se vuelven muy importantes en tareas de misión crítica. sistemas. WS-Reliability y WS-ReliableMessaging son dos estándares que se utilizan para resolver este tipo de problemas. OASIS es responsable de estos estándares.
Políticas
Los proveedores de servicios a veces requieren que los consumidores de servicios se comuniquen con ciertas políticas. Por ejemplo, un proveedor de servicios puede exigir a los consumidores que proporcionen un token de seguridad Kerberos para poder obtener servicios. Estos requisitos se definen como afirmaciones de política. Una política puede contener múltiples afirmaciones. WS-Policy se utiliza para estandarizar la comunicación de políticas entre consumidores de servicios y proveedores de servicios.
Control
Cuando una empresa se embarca en una arquitectura de servicios, los servicios se pueden utilizar para integrar silos de datos, aplicaciones y componentes. La integración de aplicaciones significa que las solicitudes de procesos como la comunicación asincrónica, el procesamiento paralelo, la transformación y corrección de datos deben estandarizarse. En SOA, los procesos se crean utilizando un conjunto discreto de servicios.
BPEL4WS o wsbpel (Web Services Business Process Execution Language) es un lenguaje utilizado para controlar estos servicios. WSBPEL también está a cargo de OASIS.
Operación
A medida que crecen los servicios empresariales, también aumenta el número de servicios y procesos de negocio utilizados. Para los administradores de sistemas, la gestión de las tareas que se ejecutan en un entorno de varias etapas es el sistema de gestión de todos. servicios es particularmente importante. WSDM (servicios web para gestión distribuida) estipula que cualquier servicio implementado según WSDM se puede gestionar a través de un esquema de gestión compatible con WSDM.
Otras características de qos, como la comunicación entre socios y el procesamiento de transacciones entre múltiples servicios, se describen en los estándares WS-Coordination y WS-Transaction, que son obra de OASIS. El concepto de SOA no es nuevo. SOA se diferencia de las tecnologías distribuidas existentes porque la mayoría de los proveedores de software la aceptan y tienen plataformas o aplicaciones que pueden implementar SOA. Con estándares ubicuos, SOA aporta una mayor reutilización de los activos o inversiones existentes de una empresa.
SOA puede crear aplicaciones sobre las aplicaciones más recientes y existentes; SOA puede proteger a los clientes o consumidores de servicios de cambios en la implementación del servicio; SOA puede actualizar servicios individuales o consumidores de servicios, sin tener que reescribir toda la aplicación o conservarla. sistemas existentes que ya no son adecuados para las nuevas necesidades. En resumen, SOA proporciona a las empresas una mayor flexibilidad para crear aplicaciones y procesos de negocio de forma ágil combinando aplicaciones existentes para generar nuevos servicios.
La implementación de SOA puede traer cinco ventajas principales:
1: SOA se puede lanzar a través del servidor de Internet, superando así las limitaciones de la intranet empresarial y logrando la cooperación empresarial con las áreas ascendentes y descendentes. Socios en la cadena de suministro. Estrechamente combinados. A través de la arquitectura SOA, las empresas pueden establecer directamente nuevos canales con socios comerciales y se puede reducir el costo de establecer nuevos socios.
En segundo lugar, SOA no tiene nada que ver con la plataforma, lo que reduce las restricciones en la implementación de aplicaciones empresariales. No existen restricciones sobre las tecnologías específicas que los socios comerciales de una empresa pueden emplear para integrarlos en los "grandes" sistemas comerciales de la empresa.
En tercer lugar, SOA tiene las características de un bajo acoplamiento y agregar o reducir socios comerciales tiene un impacto muy bajo en todo el sistema comercial. A medida que las relaciones de la empresa con varios socios comerciales sigan cambiando, los ahorros de costos aumentarán.
Cuarto: La ventaja de SOA es que se puede implementar en etapas según módulos. Puede dar el siguiente paso con éxito, paso a paso, con un impacto de implementación mínimo en su negocio.
Quinto: El coste de implementación de SOA puede no ser significativo. Esto debe discutirse en tres situaciones:
Cuando una empresa construye un sistema empresarial desde cero, el costo de adoptar la arquitectura SOA y no adoptarla puede considerarse el mismo. Cuando el desarrollo comercial o la reorganización de una empresa cambia y el sistema original no puede satisfacer las necesidades y es necesario reconstruir el sistema comercial, el costo de adoptar la arquitectura SOA puede considerarse el mismo que el costo de no adoptar la arquitectura SOA.
Cuando el negocio de una empresa cambia lentamente y es previsible que el sistema empresarial necesitará ser reconstruido en el futuro, SOA se puede implementar paso a paso según módulos para satisfacer las necesidades cambiantes, de modo que la empresa no es necesario invertir una gran cantidad de dinero a la vez. En lugar de transformar el sistema, invertiremos gradualmente de acuerdo con el desarrollo comercial y la situación de capital de la empresa, aliviando así la presión sobre la inversión en información. a. Equilibrar el apalancamiento inicial de la inversión inicial:
Si los sistemas, software y hardware invertidos por la organización en el pasado se pueden reutilizar, se le dará nuevo valor, lo que también reducirá costos y aumentará la competitividad de la misma. la organización.
B. Comoditización de la infraestructura:
Permitir que todas las aplicaciones se comuniquen entre sí (interoperabilidad)
C. Rápido tiempo de comercialización:
La reutilización de servicios puede acortar procesos organizativos pasados y proporcionar servicios más rápidamente para acercarse al mercado.
D. Reducir costos:
La reutilización de servicios puede reducir los costos de desarrollo. Porque el costo de desarrollar un sistema nuevo es mayor que el costo de actualizar un sistema antiguo.
E. Mitigación de riesgos:
Los riesgos de desarrollar nuevos sistemas son mucho mayores que los riesgos de actualizar sistemas antiguos.
F. Ciclo de mejora continua de los procesos de negocio.
G. Procesamiento centrado en procesos