La arquitectura orientada a servicios (SOA) surgió a principios de este siglo como una evolución de la computación distribuida. Antes de SOA, los servicios se entendían como el resultado final del proceso de desarrollo de aplicaciones. En SOA, la aplicación en sí está compuesta por servicios. Los servicios se pueden entregar individualmente o combinados como componentes en un servicio compuesto más grande.
Los servicios interactúan a través del cable usando un protocolo como REST o SOAP (Protocolo simple de acceso a objetos). Los servicios están débilmente acoplados, lo que significa que la interfaz del servicio es independiente de la implementación subyacente. Los desarrolladores o integradores de sistemas pueden componer uno o más servicios en una aplicación sin saber necesariamente cómo se implementa cada servicio.
Este artículo es una descripción general de Java SOA y las características clave de un Arquitectura orientada a servicios implementada utilizando servicios web basados en SOAP. También compararé brevemente SOA y microservicios y analizaré la diferencia entre los servicios web basados en RESTful y SOAP en Java.
¿Por qué la arquitectura orientada a servicios?
SOA aborda tres desafíos empresariales comunes :
- Responda rápidamente a los cambios comerciales.
- Aproveche las inversiones en infraestructura existentes.
- Apoye nuevos canales de interacción con clientes, socios y proveedores.
La infraestructura empresarial es heterogénea entre los sistemas operativos, las aplicaciones, el software del sistema y la infraestructura de aplicaciones. Como resultado, muchos sistemas empresariales están compuestos por aplicaciones complejas e inconsistentes que ofrecen gama de servicios interdependientes. Las aplicaciones existentes que ejecutan los procesos comerciales actuales son críticas, por lo que comenzar desde cero o modificarlas es una propuesta delicada. Pero las empresas deben poder modificar y expandir la infraestructura técnica para satisfacer las demandas comerciales.
Como en comparación con un archi monolítico En la tecnología, la naturaleza poco acoplada de SOA hace que sea relativamente sencillo conectar nuevos servicios o actualizar los servicios existentes para los nuevos requisitos comerciales. También brinda la opción de hacer que los servicios sean consumibles a través de diferentes canales y exponer aplicaciones heredadas como servicios, salvaguardando así las inversiones en infraestructura.
Debido a que están débilmente acoplados, los componentes SOA se pueden cambiar con un impacto mínimo en otros componentes. . Los componentes también se pueden agregar a la arquitectura de manera estandarizada, y se pueden escalar para abordar la carga.
Como ejemplo, considere cómo una empresa podría usar un conjunto de aplicaciones existentes para crear una nueva, Aplicación de cadena de suministro compuesta. Si bien las aplicaciones existentes son heterogéneas y están distribuidas en varios sistemas, su funcionalidad se expone y se accede a ellas mediante interfaces estándar.
Figura 1. Aplicación de la cadena de suministro en una arquitectura orientada a servicios
Características clave de SOA
SOA puede ser tan simple como un solo componente que consume servicios proporcionados por otro componente o tan sofisticado como una gama de componentes que interactúan a través de un bus de servicio empresarial como el ESB de MuleSoft. No importa cuál sea la escala, la clave para una implementación SOA exitosa es utilizar la menor complejidad posible para lograr sus objetivos. Su primera y última pregunta siempre debe ser: ¿Este diseño satisface nuestros requisitos comerciales?
Independientemente de la escala o complejidad, el patrón de una arquitectura orientada a servicios es más o menos lo mismo:
- Los proveedores de servicios exponen los puntos finales y describen acciones disponibles en cada punto final.
- Los consumidores de servicios emiten solicitudes y consumen respuestas.
- Los proveedores de servicios generan mensajes para manejar solicitudes.
Implementación de servicios arquitectura orientada
Para implementar SOA, se comienza con la arquitectura de servicio básica, luego se proporciona la infraestructura, es decir, los protocolos y otras herramientas que permiten la comunicación y la interoperabilidad. La Figura 2 muestra un diagrama de una arquitectura de servicio típica.
Figura 2. Una arquitectura de servicio de muestra
En este diagrama, tres consumidores invocan servicios enviando mensajes a un bus de servicio empresarial, que transforma y enruta los mensajes a una implementación de servicio adecuada . Un motor de reglas comerciales incorpora reglas comerciales en un servicio o entre servicios. Una capa de administración de servicios administra actividades como auditoría, facturación y registro.
Los componentes de esta arquitectura están débilmente acoplados, por lo que se pueden cambiar o actualizar con un impacto relativamente mínimo en la aplicación en su conjunto. Esto le da a la empresa flexibilidad para agregar o actualizar procesos comerciales según sea necesario. En su mayor parte, los cambios en los servicios individuales no deberían afectar mucho a otros servicios.
Servicios web basados en SOAP
Los servicios web implementados mediante SOAP son aún más rígidos que los servicios web RESTful o la implementación de microservicios, pero mucho más flexibles que los primeros días de SOA. Aquí solo veremos los protocolos de alto nivel requeridos para los servicios web basados en SOAP.
SOAP, WSDL y XSD
SOAP, WSDL y XSD son la infraestructura fundamental de una implementación de servicio web basada en SOAP. WSDL se utiliza para describir el servicio, y SOAP es la capa de transporte para enviar mensajes entre consumidores y proveedores de servicios. Los servicios se comunican con mensajes definidos formalmente mediante XML Schema (XSD). Puede pensar en WSDL como interfaz del servicio (ligeramente análoga a una interfaz Java). La implementación se realiza en clases de Java y la comunicación a través de la red se realiza a través de SOAP. Funcionalmente, un consumidor buscaría un servicio, obtendría el WSDL para ese servicio y luego invocaría el servicio usando SOAP.
Seguridad del servicio web
El WS -I La especificación Basic Profile 2.0 aborda la seguridad de los mensajes. Esta especificación se centra en el intercambio de credenciales, la integridad de los mensajes y la confidencialidad de los mensajes.
Descubrimiento de servicios web
Una vez que la piedra angular del descubrimiento de servicios web, UDDI (Descripción, definición e integración universales) se ha desvanecido en la historia. Hoy en día es común exponer un servicio web basado en SOAP de la misma manera que lo haría con cualquier otro servicio, a través de una URL de punto final. Como ejemplo, puede usar la interfaz de punto final de servicio JAX-WS y su @WebService y @WebMethod anotaciones.
Creación e implementación de servicios web
Los desarrolladores de Java tienen varias opciones para construir e implementar SOAP servicios web, incluidos Apache Axis2 y Spring-WS; sin embargo, el estándar Java es JAX-WS, la API de Java para servicios web XML. La idea central detrás de JAX-WS es crear clases Java y anotarlas para crear los artefactos necesarios. Bajo el capó, JAX-WS utiliza varios paquetes de Java, incluido JAXB, una biblioteca de propósito general para vincular clases de Java a XML.
JAX-WS oculta la complejidad subyacente y los protocolos del desarrollador, lo que agiliza el proceso de definir e implementar servicios SOAP basados en Java. Los IDE de Java modernos como Eclipse incluyen soporte completo para el desarrollo de servicios web JAX-WS. La especificación WS también ha sido seleccionada para su desarrollo continuo en Jakarta EE.
Conclusión
La arquitectura orientada a servicios implementada con servicios web basados en SOAP requiere más rigidez y definiciones de servicios formales que los servicios web RESTful o microservicios. Sin embargo, algunas organizaciones más grandes continúan favoreciendo el estilo más formal impuesto por SOAP. Muchos sistemas heredados a gran escala también se basan en SOAP, y algunos sistemas internos y B2B eligen servicios web basados en SOAP para sus contratos API definidos de manera más formal. Ya sea que esté desarrollando o manteniendo un sistema empresarial a gran escala, comprender el patrón SOA y poder evaluar sus opciones para implementarlo le será de gran utilidad en su carrera de programación.