Este blog describe los pasos SOA que una organización debe seguir antes de que pueda tener éxito en la realización de los beneficios de costo y agilidad que ofrece la arquitectura orientada a servicios empresariales. Analiza lo que representa SOA y las diversas etapas de adopción de SOA al describir las tecnologías, los procesos y las mejores prácticas disponibles para ayudar a las empresas a tener éxito en sus iniciativas de arquitectura orientada a servicios.
¿Qué es SOA?
La arquitectura orientada a servicios (SOA) es un tipo de arquitectura utilizada en el diseño de software que admite la orientación a servicios, mediante la cual los servicios se proporcionan a otros componentes a través de un protocolo de comunicación a través de una red.
¿Qué Significa SOA?
La definición de SOA, según lo proporcionado por Wikipedia:
Arquitectura orientada a servicios (SOA) es un estilo de diseño de software donde los servicios se proporcionan a los otros componentes por componentes de aplicaciones, a través de un protocolo de comunicación a través de una red. Los principios básicos de la arquitectura orientada a servicios son independientes de los proveedores, los productos y las tecnologías. Un servicio es una unidad de funcionalidad discreta a la que se puede acceder de forma remota, actuar y actualizar de forma independiente, como recuperar un extracto de tarjeta de crédito en línea.
Un servicio tiene cuatro propiedades de acuerdo con una de las muchas definiciones de SOA:
- Representa lógicamente una actividad empresarial con un resultado específico.
- Es autónomo.
- es una caja negra para sus consumidores.
- Puede consistir en otros servicios subyacentes.
Se pueden usar diferentes servicios en conjunto para proporcionar la funcionalidad de una gran aplicación de software, un principio que SOA comparte con la programación modular. La arquitectura orientada a servicios integra componentes de software distribuidos, mantenidos e implementados por separado. Está habilitado por tecnologías y estándares que facilitan la comunicación y cooperación de los componentes a través de una red, especialmente a través de una red IP.
Esto proporciona una respuesta concisa a lo que significa SOA, pero no describe las razones por las que una organización querría avanzar hacia una arquitectura orientada a servicios, o los beneficios de SOA.
También de Wikipedia sobre lo que significa SOA:
Algunos arquitectos empresariales creen que SOA puede ayudar a las empresas a responder de manera más rápida y rentable a las cambiantes condiciones del mercado.Este estilo de arquitectura promueve la reutilización a nivel macro (servicio) en lugar de a nivel micro (clases). También puede simplificar la interconexión y el uso de los activos de TI (heredados) existentes.
En algunos aspectos, SOA podría considerarse como una evolución arquitectónica más que como una revolución. Captura muchas de las mejores prácticas de arquitecturas de software anteriores. En los sistemas de comunicaciones, por ejemplo, se ha desarrollado poco de soluciones que utilicen enlaces verdaderamente estáticos para comunicarse con otros equipos de la red. Al adoptar un enfoque SOA, tales sistemas pueden posicionarse para enfatizar la importancia de interfaces bien definidas y altamente interoperables.
Analizando estos conceptos, podemos ver que hay un conjunto de capacidades básicas que se requieren para lograr los beneficios potenciales de SOA. Wikipedia discute una serie de estos principios rectores, entre los que se encuentran:
- Reutilización: la capacidad de encapsular y exponer funciones comerciales de grano grueso como servicios
- Acoplamiento suelto: garantizar que los consumidores de servicios estén suficientemente abstraídos de la implementación física de un servicio
- Identificación y categorización (detectabilidad): asegurarse de que los consumidores potenciales puedan encontrar los servicios que necesitan
Sin importar la definición SOA que use, estos principios fundamentales llevar a un orden natural de actividades que una organización debe completar para obtener gradualmente los beneficios de la orientación a los servicios arquitectura.
Vea por qué Akana tiene un gran desempeño en el informe Forrester Wave™: Soluciones de administración de API, tercer trimestre de 2020.
Descargar Informe
¿Cuáles Son los Siete Pasos de SOA?
Hay siete pasos SOA:
- Crear/Exponer Servicios
- Registrar Servicios
- Servicios seguros
- Gestionar (supervisar) Servicios
- Mediar y Virtualizar Servicios
- Gobernar el SOA
- Integración SOA Con ESB
Los pasos 2 a 6 de SOA describen las preocupaciones entre empresas que deben abordarse con una plataforma de infraestructura SOA centralizada. Los pasos 1 y 7 abordan necesidades específicas y, a menudo, se entregan como parte de una pila de aplicaciones empresariales existente. Seguir estos pasos conducirá a una organización por el camino correcto para realizar los beneficios de SOA. Sigue leyendo para profundizar en cada paso de SOA.
Crear / Exponer servicios
El primer paso para mover una organización hacia SOA es obvio. No puede haber aplicaciones SOA sin servicios, por lo que el primer paso debe ser exponer o crear servicios que puedan ser consumidos fácilmente por aplicaciones habilitadas para servicios web.
Hay una serie de decisiones interesantes a las que se enfrentan las empresas al comenzar este proceso, una de las cuales es la decisión de reconstruir las aplicaciones existentes utilizando un paradigma orientado a servicios o exponer la lógica de las aplicaciones existentes como un conjunto de servicios. Por supuesto, esta no es una decisión binaria, y la mayoría de las organizaciones crearán nuevos servicios desde cero, a menudo utilizando J2EE y/o.NET, y también expondrán servicios de mainframe existentes y otras aplicaciones empresariales.
Hay una amplia gama de soluciones diferentes para las empresas que buscan exponer las aplicaciones existentes como servicios, incluida SOLA, líder del mercado de Akana, que permite que las aplicaciones CICS de mainframe expongan y consuman servicios confiables, seguros y de alto rendimiento.
Cualquier empresa con una inversión significativa (más de 1000 MIPS según Gartner) en mainframe debería estar investigando formas de aprovechar mejor las ventajas de esta plataforma y debería utilizar servicios Web para integrar fácilmente sus aplicaciones de mainframe con sistemas modernos. SOLA de Akana está probada en producción en clientes como Merrill Lynch, donde procesa más de 2 millones de transacciones por día de más de 600 servicios web. SOLA es el único producto que ofrece a los programadores de mainframe una interfaz web fácil de usar para exponer y consumir servicios de aplicaciones CICS. Incluye soporte integrado para funciones avanzadas de servicios Web como Seguridad WS, Cifrado XML y firma XML.
La mayoría de las empresas tradicionales de integración de aplicaciones empresariales (EAI) también ofrecen versiones de sus adaptadores que exponen servicios web en lugar de sus protocolos propietarios tradicionales. De hecho, muchas de estas plataformas EAI están resurgiendo como productos de Bus de servicio Empresarial. El ESB aborda múltiples cuestiones diferentes, una de las cuales es la funcionalidad de tipo de servicios de datos básicos utilizada para exponer las interfaces de servicios web de los adaptadores tradicionales.
¿Qué es un Servicio Web?
De Wikipedia:
En relación con los Servicios Web del W3C, el W3C definió un servicio web como: «Un servicio web es un sistema de software diseñado para soportar la interacción interoperable de máquina a máquina a través de una red. Tiene una interfaz descrita en un formato procesable por máquina (específicamente WSDL). Otros sistemas interactúan con el servicio web de la manera prescrita por su descripción mediante mensajes SOAP, que normalmente se transmiten mediante HTTP con una serialización XML junto con otros estándares relacionados con la web.»
Esta definición es interesante desde una perspectiva técnica, pero realmente no llega al corazón del valor que se puede derivar de SOA y servicios web. Un aspecto fundamental de los servicios web es que deben exponer la lógica empresarial a través de una interfaz basada en estándares. Un aspecto importante de exponer o crear un servicio es su granularidad. Hay muchas escuelas de pensamiento diferentes sobre lo que constituye un servicio (véase más arriba), pero la mayoría de los arquitectos empresariales estarían de acuerdo en que para ser útil en una SOA, un servicio debe ser lo suficientemente grueso como para ser útil para múltiples aplicaciones diferentes.
Esto, por supuesto, se ajusta a uno de los principios fundamentales de los servicios en SOA: para que un servicio se reutilice, debe ser generalmente útil y utilizable. Un ejemplo de un servicio generalmente útil podría ser un servicio» getCustomerInfo » que devolverá detalles sobre un cliente desde un identificador de cliente. Un servicio de grano más fino que puede no ser útil en general podría ser algo específico para una aplicación en particular, «setApplicationState», por ejemplo.
Es importante tener en cuenta la granularidad de los servicios tanto al crear nuevos servicios como al exponer la lógica empresarial existente como servicio. Por ejemplo, sería fácil tomar una transacción CICS y exponer múltiples servicios diferentes para establecer y obtener varios parámetros, mientras que la realidad es que un servicio de grano más grueso que exponga toda la transacción como un solo servicio podría ser mucho más útil en general y, por lo tanto, valioso.
Lectura relacionada: Descubra cómo la API de Mainframe SOLA de Akana proporciona a los clientes un proceso rápido y sencillo para exponer las aplicaciones de mainframe como servicios web seguros y permite que las aplicaciones de mainframe consuman servicios web.
Regístrese
Ok, para que tenga uno o más servicios disponibles en su empresa. ¿Y ahora qué?
Para que un servicio sea utilizado, y mucho menos reutilizado, los arquitectos y desarrolladores de aplicaciones que podrían beneficiarse de este servicio necesitan saber que existe. Aquí es donde entra en juego un registro. En su nivel más simple, un registro no es más que un índice de biblioteca que ayuda a los usuarios potenciales de servicios a encontrar servicios en los que podrían estar interesados. El registro debería ofrecer interfaces de búsqueda y navegación, y organizarse de manera lógica para facilitar la detección rápida y precisa de los servicios.
En la SOA actual, el estándar aceptado para los servicios de registro básicos es UDDI (Descubrimiento, Descripción e Integración universales). La especificación UDDI proporciona un modelo de datos y un conjunto de interfaces (todos los servicios Web en sí) para publicar y descubrir servicios, así como un conjunto adicional de interfaces para administrar el propio servidor de registro.
Muchos proveedores de registros han llevado el concepto original de registro un poco más lejos y están utilizando tecnologías de registro como base para un repositorio más completo. Los proveedores de registro también están agregando filtros basados en» políticas «a sus herramientas de publicación y ofreciendo»soluciones de gobernanza en tiempo de diseño».
Akana considera que el registro es un componente fundamental de SOA. Todos nuestros productos aprovechan UDDI como una única tienda central para obtener información fidedigna sobre los servicios de una SOA. Los productos pueden funcionar con cualquier registro compatible con UDDI, y Akana incluye su propio servidor de registro UDDIv3 con su producto de Administrador de servicios para empresas que aún no tienen un registro. En este sentido, registry está cumpliendo el rol de SOA que LDAP cumplió para las soluciones de Administración de Identidades y Acceso.
Los productos de Akana se centran en la gobernanza en tiempo de ejecución y aprovechan el registro como un lugar central para encontrar políticas en tiempo de ejecución para implementar y hacer cumplir. Por supuesto, el registro integrado es un servidor UDDIv3 completamente funcional y, por lo tanto, también es un repositorio de servicios ideal en tiempo de diseño.
Beyond registry es todo el concepto de servicios de políticas y metadatos que proporcionan repositorios completos para todos los artefactos en tiempo de diseño y tiempo de ejecución para los servicios en SOA. Este concepto se trata con más detalle en el documento técnico de Akana, El Modelo de Referencia de Infraestructura SOA.
Seguro
El mundo de SOA y servicios web no es todo vino y rosas. Suponiendo que ya ha completado los pasos uno y paso, dé un paso atrás y considere lo que ha hecho. Suponiendo que busca el máximo valor comercial, es probable que haya tomado aplicaciones de misión crítica, las haya dividido en piezas de funcionalidad de grano grueso, haya expuesto esta funcionalidad como servicios y luego haya publicado estos servicios en un registro de acceso universal.
Todo esto puede parecer una buena cosa, y en la mayoría de los casos es una gran cosa, pero es posible que haya creado inadvertidamente algunos agujeros de seguridad enormes en su organización y haya expuesto información confidencial o transacciones de alto valor a cualquier persona con habilidades rudimentarias de servicios web. Garantizar la seguridad de los servicios significa crear un nivel de aplicación de seguridad en los proveedores de servicios y un nivel de implementación de seguridad en los consumidores de servicios.
Una buena manera de comprender los riesgos de seguridad de los servicios web es pensar en las aplicaciones tradicionales de mainframe con pantalla verde. La única seguridad requerida por estas aplicaciones era la seguridad de inicio de sesión, si podía acceder a la aplicación, estaba en. Estas aplicaciones contenían las mismas piezas básicas que una aplicación moderna (interfaz, lógica de negocios, servicios de datos), pero solo la interfaz era accesible fuera de la aplicación. En el mundo de los servicios web, es probable que algunos de los servicios de datos principales se expongan como servicios, parte de la lógica de negocio ciertamente debería exponerse, y la aplicación no se escribió teniendo en cuenta ninguno de estos puntos de acceso. Esto significa que es fundamental proteger los servicios que expone individualmente, no puede confiar en el funcionamiento interno de la aplicación para garantizar su propia seguridad.
Entonces, ¿qué significa proteger un servicio web? Los mismos 5 principios de seguridad que se aplican a otras aplicaciones también se aplican a los servicios Web:
- Autenticación: asegúrese de conocer la identidad del solicitante del servicio (y también asegúrese de que el solicitante conozca la identidad del servicio con el que se está comunicando). Existen múltiples estándares de servicios Web diferentes para autenticar solicitudes, que van desde enfoques simples como la autenticación básica http hasta mecanismos más complejos como la firma SAML o X. 509. Una buena herramienta de seguridad de servicios web debería admitir todas estas opciones.Autorización
- : asegúrese de que el solicitante esté autorizado para acceder al servicio u operación que solicita. La autorización es un asunto complejo y hay varios productos de decisión de políticas disponibles. La mayoría de las grandes empresas tendrán una solución de autorización existente (CA SiteMinder, IBM TAM, etc.), y una buena solución de seguridad de servicios Web debería poder integrarse con estas y proporcionar sus propias capacidades de autorización.
- Privacidad: asegúrese de que los mensajes de solicitud y respuesta no puedan ser leídos por terceros no autorizados. Aquí es donde los estándares como el cifrado XML entran en juego, pero para usar con éxito el cifrado XML, la solución de seguridad de servicios Web debe proporcionar capacidades efectivas de administración y distribución de claves y certificados, e idealmente algunas herramientas del lado del cliente para ayudar a los desarrolladores de consumidores.
- No repudio: asegúrese de que el solicitante no pueda denegar el envío de una solicitud y asegúrese de que el servicio no pueda denegar el envío de su respuesta. Este es el papel de la firma XML, con la misma provisión de administración y distribución de claves que para la privacidad.Auditoría
- : asegúrese de que el sistema pueda mantener un registro preciso y oportuno de solicitudes y respuestas según sea necesario.
Una pregunta interesante, y punto de debate, que surge en torno a la seguridad de los servicios web es dónde se debe aplicar esta seguridad. Algunos proveedores argumentarán que la seguridad debe ser una función central aplicada a través de un grupo de proxies implementados centralmente, mientras que otros argumentarán que debe ser exclusivamente el dominio del proveedor de servicios o contenedor. La realidad, por supuesto, está en algún lugar entre estas dos posiciones. Sin duda, un proxy (o clúster de proxies) tiene un papel importante a la hora de proporcionar servicios de autenticación y detección de amenazas en el perímetro de la red para protegerse contra amenazas externas. También hay un papel igualmente importante para la seguridad basada en proveedores o contenedores para garantizar la seguridad del servicio hasta la última milla.
Muchas empresas tienden a pasar por alto la investigación que muestra que la mayoría de las amenazas de seguridad son internas de la empresa, no externas, y por lo tanto delegan la seguridad en un tipo de solución de firewall. Akana ofrece un proxy de alto rendimiento que realiza funciones de seguridad centralizadas o en el perímetro de la red, y una amplia gama de agentes en contenedores para garantizar la seguridad de última milla de los servicios implementados.
Asegurar los servicios web requiere:
- Implemente agentes en contenedor completamente funcionales para garantizar la seguridad de la última milla y distribuir la carga de operaciones criptográficas
- Implemente intermediarios de red de alto rendimiento para el enrutamiento y la aplicación de seguridad en el perímetro de la red
- Proporcione una administración y distribución integral de claves y certificados para garantizar que los proveedores de servicios y los desarrolladores de consumidores puedan implementar con éxito las políticas de seguridad requeridas
- Proporcione kits de herramientas para desarrolladores de consumidores para abstraer a los desarrolladores de consumidores de la complejidad de descubrir e implementar la seguridad empresarial directivas
Lectura relacionada: Obtenga más información sobre las prácticas recomendadas de seguridad de API.
Administre
Tres pasos en el enfoque de 7 pasos para SOA y estamos comenzando a avanzar hacia el logro de valor real de SOA empresarial. Tenemos algunos servicios, se publican en un registro y pueden ser descubiertos por usuarios potenciales, y nos hemos asegurado de que sean seguros. ¿Qué más podríamos necesitar?
Para responder a esta pregunta, primero debemos mirar un escenario de desastre potencial. ¿Qué sucede cuando mis servicios se convierten en víctimas de su propio éxito? I. e. un servicio se ha vuelto tan popular que hay varias (decenas, o cientos, o miles) aplicaciones diferentes que lo consumen y comienza a plegarse bajo la carga. De repente tenemos decenas, o cientos, o miles de aplicaciones que están fallando o realizar mal y no sabemos por qué, o cómo pararlo.
Necesitamos monitorear nuestros servicios para saber si están funcionando dentro de los parámetros operativos normales, y para ver posibles problemas antes de que ocurran mediante la implementación de modelos de planificación de capacidad.
La solución de monitoreo que implementamos debe ser capaz de monitorear los servicios para la disponibilidad básica, el rendimiento (tiempo de respuesta), el rendimiento e incluso extenderse al contenido y la supervisión basada en el usuario. Debe ser capaz de supervisar y alertar sobre umbrales de ANS específicos, y debe ser capaz de aplicar diferentes ANS a diferentes usuarios del mismo servicio u operación.
Muchos proveedores definen esta categoría de producto como una solución de administración de Servicios Web, aunque muchos analistas coinciden en que la administración es mucho más amplia que una simple solución de monitoreo y debe incluir gran parte de la funcionalidad descrita en el siguiente paso.
Idealmente, por supuesto, no deberíamos tener que implementar soluciones separadas para seguridad y monitoreo porque cada vez que interceptamos mensajes a través de un agente o intermediario, agregamos otro cuello de botella de rendimiento. Esta es la razón por la que el Administrador de servicios de Akana se combina con el Director de red para proporcionar una plataforma integral de seguridad, monitoreo y administración de SOA en una única solución de alto rendimiento y fácil de implementar.
Algunos proveedores de gestión de servicios Web (monitoreo) posicionan sus soluciones como plataformas de Monitoreo de Actividad Empresarial (BAM), aunque BAM es una solución compleja que requiere integración con muchos sistemas y bases de datos de back – office y front-office. La supervisión de las interacciones de los servicios web para el contenido no debe considerarse una alternativa a una solución BAM empresarial.
Lectura relacionada: Obtenga más información sobre la Solución de Gestión de API de Extremo a Extremo de Akana.
5. Mediar y Virtualizar
En este punto, parecería que nuestra SOA está lista para el horario estelar. Y así es, al menos por un tiempo…
El siguiente conjunto de desafíos se produce a medida que su SOA madura. Debe introducir nuevas versiones de servicios o aumentar la capacidad de un servicio ejecutando varias instancias de ti, debe aprovisionar aplicaciones para usar instancias específicas de servicios y ofrecer servicios que expongan una gama más amplia de tipos de interfaz diferentes.
Aquí es donde entra en juego la virtualización de servicios. La virtualización parece compleja, pero la realidad es bastante simple. Un servicio virtual es un servicio completamente nuevo, definido por su propio WSDL, con su propia dirección de red y parámetros de transporte. No implementa ninguna lógica de negocio; simplemente actúa como un proxy para uno o más servicios físicos, enrutamiento, equilibrio de carga, transformación y mediación entre diferentes tipos de mensajes de solicitud y estándares.
Aunque simple en la superficie, el concepto de virtualización es extremadamente potente. Proporciona la capacidad de abstraer completamente a los consumidores de servicios de cualquier conocimiento directo del servicio físico. Por ejemplo, a través de un servicio virtual, un cliente.NET que utiliza una implementación de Microsoft de un protocolo de mensajería confiable con SOAP sobre http podría consumir un servicio XML antiguo expuesto a través de IBM WebSphere MQ series desde una aplicación de mainframe. El cliente. NET creería que se trataba de una comunicación con un servicio http que soportaba su protocolo de mensajería confiable, mientras que la aplicación de mainframe creería que estaba siendo consultada por otra aplicación nativa de la serie MQ.
Los servicios virtuales ofrecen una amplia gama de funcionalidades:
- Pueden utilizar tecnologías de transformación XML para permitir a los consumidores seguir utilizando una versión antigua de un servicio que ya no existe mediante la transformación de los mensajes de solicitud y respuesta entre la versión antigua y la nueva versión que se ha implementado.
- Pueden seleccionar operaciones específicas de múltiples servicios diferentes y combinarlas en un único WSDL funcional para una clase específica de aplicación consumidora.
- Pueden proporcionar diferentes requisitos de política para diferentes clases de usuarios (p. ej. usuarios internos con un conjunto de políticas y otra implementación del servicio que impone un conjunto de políticas diferente para los consumidores externos).
- Pueden proporcionar puentes de transporte para servicios y consumidores en transportes incompatibles (por ejemplo, http y JMS). * Pueden mediar entre diferentes implementaciones de estándares o incluso versiones de estándares.
- Pueden mediar entre diferentes estilos de mensajería: RSS, SOAP, REST, POX (XML antiguo simple).
- Pueden proporcionar un enrutamiento potente basado en contenido o contexto para ofrecer capacidades avanzadas de equilibrio de carga y alta disponibilidad.
El resultado final de los servicios virtuales es que son necesarios para cualquier enrutamiento u otros servicios web avanzados, y se convertirán rápidamente en una parte esencial de cualquier SOA empresarial.
Govern
Con 5 de los 7 pasos completados, el enterprise SOA está prácticamente listo para funcionar. Ahora dispone de servicios gestionados y seguros que están disponibles para un público amplio de forma fiable y equilibrada de carga, y que se pueden detectar fácilmente.
El siguiente paso es unir todas las capacidades entregadas a través de los primeros 5 pasos con un marco de gobierno. La gobernanza es un trabajo sobreutilizado y muy mal utilizado, así que veamos brevemente una definición de gobernanza. De nuevo de Wikipedia:
El término gobernanza se refiere a los procesos y sistemas por los que opera una organización o sociedad. Con frecuencia se establece un gobierno para administrar estos procesos y sistemas.
El punto clave a tomar de esta definición es que la gobernanza se trata de procesos y sistemas. En el caso de la gobernanza SOA, estamos discutiendo procesos organizacionales como una junta de revisión de arquitectura y sistemas como el registro, la seguridad y las tecnologías de gestión discutidas en este blog.
El gobierno de SOA a menudo se divide en dos partes separadas, gobierno en tiempo de diseño y gobierno en tiempo de ejecución. En el momento del diseño, las organizaciones quieren controlar (gobernar) los tipos de servicios que se pueden publicar, quién puede publicarlos, qué tipos de esquemas y mensajes pueden aceptar estos servicios y una gran cantidad de otras reglas sobre los servicios. En tiempo de ejecución, las organizaciones deben garantizar la seguridad, la fiabilidad y el rendimiento de sus servicios, y deben asegurarse de que los servicios cumplan con las políticas empresariales definidas. El gobierno en tiempo de diseño es interesante y ayuda a garantizar un SOA organizado y bien diseñado, pero palidece en insignificancia en comparación con el control activo del SOA en tiempo de ejecución.
El Administrador de servicios de Akana es la plataforma de gobierno en tiempo de ejecución líder del sector, que ofrece una solución integral para seguridad, supervisión, gestión, mediación y registro. La gobernanza en tiempo de ejecución proporciona esencialmente un marco único para controlar y supervisar la aplicación de los diversos pasos de SOA descritos en este documento. Proporciona una solución global única que proporciona supervisión del registro de servicios, la seguridad, la gestión y la mediación. Una buena solución de gobernanza en tiempo de ejecución se manifestará como una forma de banco de trabajo que proporcionará herramientas para todos los participantes activos en una SOA.
- Desarrollador de servicios: herramientas para publicar, categorizar, definir metadatos, descargar «agente», virtualizar, versión, elegir política, elegir derechos de visibilidad/acceso, participar en la planificación de la capacidad y acceder al flujo de trabajo
- Consumidor de servicios: Herramientas para facilitar la detección, selección y acceso al flujo de trabajo de servicios
- Personal de operaciones: Herramientas para supervisar el rendimiento del servicio, solucionar problemas, supervisar dependencias, servicios de versiones, virtualización, administración de proxy
- Personal de seguridad: Herramientas para la administración de políticas, 6827 >
- Arquitecto empresarial: Herramientas para monitoreo de aplicaciones, administración de relaciones, validación y definición de políticas de diseño, administración de versiones de servicios, asignación de servicios a proxy, virtualización de servicios
- Administración de TI empresarial: Administración de métricas de reutilización, métricas de reutilización de servicios, estadísticas SOA
Integración SOA Con ESB
Mirando hacia atrás los resultados de los últimos 6 pasos hacia un SOA, nos quedamos preguntándonos qué más puede haber. Por ahora, tenemos un conjunto de servicios que se publican en un registro, seguros, administrados, confiables y acoplados libremente, todos envueltos en un diseño sólido y una solución de gobierno en tiempo de ejecución.
El paso final para algunas empresas es implementar una o más implementaciones de Bus de servicios empresariales (ESB) para integrar servicios en servicios compuestos u orquestados de nivel superior. Estos ESB a menudo se entregarán como parte de un conjunto de aplicaciones más amplio, como Oracle eBusiness applications o SAP. Algunos ESB especializados se pueden utilizar para crear servicios compuestos complejos, y se extenderán al ámbito de la Gestión de Procesos de Negocio (BPM).
Lectura relacionada: Obtenga más información sobre las soluciones de integración de Akana.
El bus de servicio empresarial (ESB) es un concepto cada vez más popular. Originalmente concebido como la evolución de las soluciones de middleware orientadas a mensajes y EAI (integración de aplicaciones empresariales), ESB significa cosas muy diferentes para diferentes organizaciones. A medida que los analistas, proveedores y clientes aceptan la idea de un ESB, parece que un ESB encapsula 3 conceptos funcionales: adaptadores tomados de una herramienta EAI para garantizar la conectividad con aplicaciones heredadas, servicios de mensajería tomados de una plataforma de middleware orientada a mensajes para garantizar una entrega confiable y orquestación de procesos para crear aplicaciones ágiles.
El consenso entre los analistas es que la mayoría de las organizaciones terminarán con múltiples plataformas ESB de múltiples proveedores, que proporcionarán servicios en su propio contexto. En este entorno, es fundamental que los ESBS utilicen una infraestructura SOA central para garantizar el cumplimiento coherente de las políticas de seguridad y mensajería para los servicios que exponen y consumen.
Los productos de Administrador de servicios y Director de red de Akana se combinan para proporcionar una solución completa para el gobierno y la mediación entre múltiples instancias de ESB en una empresa.
Ahora que sabes más sobre lo que significa SOA y los pasos clave de SOA, ¡echa un vistazo a Akana en acción!
Iniciar la prueba