por Chris Haddad
A pesar de que todo el mundo reconoce que la adopción de una Arquitectura Orientada a Servicios (SOA) y las API son los enfoques más apropiados para un gran número de desarrollos y soluciones en sistemas empresariales, las curvas de aprendizaje y adopción pueden ser muy pronunciadas. Para obtener beneficios a nivel corporativo, los equipos TI deben entender los objetivos de negocio, definir la visión adecuada tanto SOA como API, describir cómo se implementarán los objetivos de negocio y las API públicas además de definir las prácticas de gobierno de los servicios.
SOA es una disciplina de diseño que se centra en la implementación de funcionalidades compartidas como servicios reutilizables. La principal premisa SOA es mantener una separación clara entre lo concerniente a la implementación de funcionalidades compartidas en forma de servicios y las aplicaciones que los consumen.
Este enfoque de diseño permite a cualquier tipo de aplicación consumir los servicios. Se ocultan los detalles de implementación de la capa de servicios a las aplicaciones que los consumen y permite una mayor flexibilidad y una mayor capacidad de adaptación de los sistemas. La unidad básica del diseño en arquitecturas SOA es un servicio reusable que implementa una pieza de funcionalidad separada.
Los servicios exponen sus funcionalidades mediante una interfaz bien definida. Cualquier aplicación que requiera esa funcionalidad puede consumir el servicio usando implementaciones estándares por lo que un único servicio puede ser utilizado en múltiples aplicaciones sin necesidad de que éste sufra ninguna modificación. En la actualidad las APIs son un componente estratégico para dar sentido a una iniciativa SOA completa.
Cuando los equipos de desarrollo publican las APIs separan el interfaz de la implementación del servicio. La administración de los endpoints de cada API son proxis ligeros que permiten reforzar la seguridad, monitorizar el uso y limitar o modular el tráfico. El proxy API permite una clara separación entre el contrato del interfaz del consumidor y la implementación del back-end del servicio.
¿Qué proporciona una API correctamente administrada?
En el pasado cuando nació la SOA-manía, los defensores de esa nueva corriente de diseño y desarrollo de sistemas distribuidos atribuían multitud de beneficios en aspectos de negocio y perspectivas técnicas. Los beneficios son reales, pero sin embargo, en la mayoría de ocasiones difíciles de obtener, ya que requieren un gran cambio de mentalidad en los departamentos TIC y en la mayoría de aspectos corporativos. En la actualidad sorprendentemente los defensores de las API, en sus argumentaciones expresan beneficios similares a aquellos que se otorgaban a SOA, pero más enfocados a la ejecución.
El paradigma SOA puede ser usado como estrategia para alinear los activos de TIC con las capacidades, los recursos y los procesos de negocio. El enfoque principal de la filosofía SOA es el intercambio y la reutilización para optimizar el uso de los activos disponibles TIC en la empresa. En origen algunas de las promesas de SOA eran desconcertantes, ya que prometía la reinvención de las interacciones business-to-business, permitir mejores relaciones entre partners y dar soporte a las redes de procesos. Los servicios externos fueron vistos como un mecanismo para mejorar aspectos económicos empresariales mediante la reducción de costes de integración e interacción, facilitando la incorporación de capacidades de negocio externas, permitiendo la especialización en las aplicaciones empresariales y creando soluciones de alto valor añadido para extender los procesos propios de la empresa a través de una red de socios1.
El actual negocio de la Economía API2 recoge las propuestas de valor de negocio que ofrece SOA a lo que se le añade lecciones ya aprendidas anteriormente sobre SOA, y usa tendencias tecnológicas populares en la industria cómo REST, Internet of Everything, móvil y Servicios en la nube.
Desde una perspectiva técnica, una arquitectura SOA debe presentar tres principios clave en su diseño; orientación al servicio, separación clara de conceptos y bajo acoplamiento. La orientación al servicio se mide por la reutilización de servicios, la granularidad y la simplicidad arquitectónica.
La separación de conceptos la podemos evaluar mediante pruebas de separación entre la lógica de negocio y la infraestructura, entre la interfaz y la aplicación y entre la interfaz y las competencias. Por último un débil acoplamiento se evalúa por la interoperabilidad, el control de las transacciones, y la mediación de las interacciones.
Superficialmente las API REST son simplemente una versión especializada de servicios web y proporcionan beneficios técnicos similares. Tanto el diseño de la API REST como de los servicios SOA tienen la intención de exponer funcionalidades individuales a través de una interfaz bien definida. El endpoint de una API y el de un servicio sirven ambos como una pieza core de diseño, y los equipos de desarrollo ofrecen soluciones técnicas mediante el acceso, la agregación, la composición y la orquestación de las interacciones entre ellos.
Una solución exitosa y escalable ya esté cimentada en API o en servicios SOA requiere una óptima infraestructura mensajería, gestión de niveles de servicio y seguridad.
A pesar de que ambas propuestas API y SOA tienen objetivos de negocio y técnicos similares, se está produciendo una ruptura cada vez más evidente entre las dos tecnologías. El cisma desde el punto de vista pragmático API REST y SOA está causado por las diferencias en el enfoque estratégico.
Los equipos de desarrollo ‘que hacen REST’ y ‘construyen APIs’ habitualmente se enfocan en superar las barreras de adopción tecnológicas y de negocio mediante build-outs incrementales y demos concretas de casos de uso del core de negocio sin la introducción de complejidades (y complicaciones) tecnológicas. En cambio los equipos SOA comúnmente se centran en: la obtención de eficiencias a escala para lograr la estandarización de los sistemas empresariales, la centralización de las decisiones, y en satisfacer complejos requisitos no funcionales.
REST es un estilo de arquitectura de desarrollo de sistemas que impone una serie de restricciones entre las interacciones de servicios. Todas juntas, estas restricciones permiten que emerjan propiedades como la simplicidad, la escalabilidad, la capacidad de modificación, la fiabilidad, la visibilidad, el rendimiento y la portabilidad. Los Sistemas que satisfacen estas restricciones son RESTful. Un diseño RESTful puede fomentar muchos beneficios:
Mientras que los beneficios del diseño RESTful soportan los objetivos SOA, el foco de la estrategia pragmática REST difiere de muchas iniciativas SOA. Los equipos de diseño de REST API se centran en adopción de escenarios bottoms-up , formatos y protocolos accesibles (p.ej. HTTP, JSON, DNS), definición de interfaces permisivas y modelos de interacción simples.
El enfoque pragmático SOA se centra en los patrones de la orientación a servicios para aumentar el valor de los recursos del software.
Los fundamentos de los patrones de la orientación a servicios son:
La aplicación estos tres patrones reducirá la complejidad dentro de un entorno TI y proporcionará mayor agilidad de desarrollo, es decir, la habilidad de construir aplicaciones en el menor tiempo posible y modificarlas rápidamente para redirigir los cambios requisitos que se produzcan. El patrón de orientación a servicios fuerza a los equipos de desarrollo a evaluar como las capacidades de los recursos de software satisfacen las necesidades de los intereses de negocio. Los equipos con enfoques SOA Pragmáticos ofrecen capacidades de negocio útiles, reducen las fricciones en la adopción del sistema y proporcionan valores de servicio excepcionales.
Estos equipos no predican difíciles buenas prácticas. Simplifican su adopción haciendo mentoring y entregando el gobierno del servicio de manera automatizada que hace fácil de hacer al equipo, lo que hay que hacer. Los equipos de SOA “pragmático” son conscientes de las carencias en las capacidades que pueden sufrir sus integrantes y los obstáculos y dificultados en la adopción de las tecnologías, y es por este motivo que habitualmente ofrecen packs de “aceleración” (infraestructuras, herramientas, frameworks, bloques de construcción de API/service) que reducen la formación, aumentan la “auto-adopción” y, por lo tanto, aceleran la entrega del proyecto.
Para conseguir esos resultados se debe de equilibrar la balanza entre el gobierno “de negocio” y la autonomía del proyecto. En lugar de erigir barreras de registro y desarrollo, estos equipos tienen éxito cuando promueve el desarrollo, intercambio y adopción del servicio mediante la introducción de mecanismos que promuevan su uso, que medien las interacciones, que endurezcan los niveles de servicio y que faciliten la adopción vía el autoservicio. Estos mecanismos se reconocen como el núcleo de la gestión de la API.
REST es diferente a, aunque no incompatible con, SOA. Los servicios pueden ser RESTful, y los recursos RESTful pueden ser servicios. Como SOA, REST es una disciplina arquitectónica definida por un conjunto de principios de diseño, y también impone un conjunto de restricciones. REST usa un modelo centrado en los recursos el cual es lo contrario a un modelo centrado en los objetos, es decir, comportamientos encapsulados por recursos. En REST cada “cosa” de interés es un recurso. Cuando se modela un servicio RESTful (aka API), las capacidades del servicio están encapsuladas y expuestas como un conjunto de recursos.
Debido a que SOA presenta una arquitectura cuyo objetivo es contrario a un portfolio de sistemas legacy TI de largo recorrido, se convierte en un viaje arquitectónico a largo plazo, y no una iniciativa puesta en práctica para obtener un resultado a corto. A causa de las capacidades de interconexión interna y externa de las APIs, éstas pueden proveer una plataforma para las empresas sponsors TI interesadas en renovarse y una ejecución empresarial pragmática.
SOA representa un cambio de paradigma significativo en las técnicas de desarrollo de aplicaciones. SOA es una disciplina de diseño de software en la cual aplicación y la funcionalidad de la infraestructura están implementadas como como servicios compartidos y reusables. Cada servicio implementa una tarea concreta, y cada aplicación que necesita realizar la tarea usa el servicio compartido para hacerlo. Los equipos de desarrollo crean aplicaciones ensamblando los servicios apropiados, posteriormente se implementan las funcionalidades de negocio como servicios, para que una organización, sus partners, y sus clientes puedan ser capaces de mezclar y encontrar esos servicios y rápidamente crear una aplicación que soporte requisitos de negocio cambiantes. La economía API y los mensajes API negocio/desarrollador refuerzan la propuesta tradicional de valor de SOA. Los beneficios de usar la plataforma WSO2 para implementar estos servicios incluyen:
Debido a que SOA presenta una arquitectura cuyo objetivo es contrario a un portfolio de sistemas legacy TI de largo recorrido, se convierte en un viaje arquitectónico a largo
plazo, y no una iniciativa puesta en práctica para obtener un resultado a corto. A causa de las capacidades de interconexión interna y externa de las APIs, éstas pueden proveer
una plataforma para las empresas sponsors TI interesadas en renovarse, una ejecución empresarial pragmática y beneficios económicos rápidos.
Los últimos diez años de promoción, implementación y evaluación SOA han cultivado
dos caminos diferentes de aproximación a esta arquitectura; La mentalidad “Big SOA” y la mentalidad “Small SOA”. En relación a las estrategias API actuales existen dos aproximaciones la mentalidad API-Access y la mentalidad Empresarial API-Centric.
Las organizaciones que quieren adoptar “Big SOA” requieren escalar el proceso de adopción a través de múltiples consumidores estableciendo un conocimiento compartido para dominar la lógica de negocio y la tecnología. Cada servicio es una parte de la gran fotografía, y un servicio bien diseñado conecta con procesos de negocio existentes y da solución a requisitos de negocio definidos.
Una adopción de servicios efectiva en na empresa requiere un esfuerzo significativo en la planificación, la coordinación y el gobernó de la solución.
Las iniciativas “Big SOA” se enfocan en el gobierno de los procesos empresariales, en la reutilización global empresarial y la consolidación del portfolio de servicios. La consecución de estos grandes objetivos requiere cambios estructurales en tiempo de diseño de los procesos y la superación de significativas diferencias culturales que conducen a la inhibición de diseño, contabilidad, control y ramificaciones operacionales. Las iniciativas “Big SOA” tradicionales pueden tener éxito, pero solo si tienen apoyo de la organización al más alto nivel que permita superar la inercia organizacional y los silos de los equipos de proyecto para crear puentes entre ellos y operar como un solo equipo
Cuando un equipo de desarrollo se plantea el uso de Big SOA, es necesario encontrar un punto de entrada efectivo. Algunos equipos comienzan con una iniciativa impulsada desde el propio departamento TI o siguiendo la estela de alguna importante iniciativa de transformación impulsado por la misma lógica de negocio. El acercamiento a Big SOA a través de iniciativas salidas de TI puede ser muy efectivo cuando se centra en construir infraestructuras de servicios compartidas, tales como seguridad, identidad, autoría, monitorización o gestión de la nube. Estos esfuerzos pueden proporcionar rápidas recuperaciones de la inversión (ROI), y no requieren una extensa colaboración con las unidades de negocio para el éxito. Por otro lado, este acercamiento retrasa la participación de los departamentos de negocio y puede que se reconozca una rentabilidad de la inversión mínima, a no ser que se incorpore en iniciativas empresariales más visibles como la gestión de riesgos, ciber-seguridad o la experiencia de usuario.
El acercamiento a Big SOA cuando se impulsa desde negocio es muy a menudo se desencadena por imperativo de la cúpula para rediseñar los procesos de negocio y/o la
experiencia de usuario. Por diseño, estos esfuerzos de transformación de negocio deben ser fuertemente coordinados a través del departamento TI y de las distintas unidades de
negocio implicadas. Big SOA, en este caso sigue la estela de una inversión en la cartera de servicios que ofrece la empresa.
Una iniciativa Big SOA es debe ser tomada como un proyecto corto de tres o cuatro meses,
sino un que debe seguir un programa de varios años, que contará con muchos pasos en su roadmap. Para maximizar y acelerar el éxito, el equipo que se embarque camino a Big SOA debe incorporar un programa de transformación estructurada:
Muchos equipos que se aventuran hacia el establecimiento de una arquitectura SOA no tienen la autoridad, el control del ámbito dónde se quiere instaurar, o la influencia para implementar las actividades necesarias Big SOA. Sin posibilidad de obtener éxito en la instauración de Big SOA que muchas organizaciones padecen, los miembros de los equipos que quieren “hacer SOA” y demostrar el valor que ello aporta al negocio focalizan sus esfuerzos en el Small SOA.
Una aproximación a Small SOA implementa los principios SOA basado en Proyecto-porproyecto. Esta aproximación incurre en menos riesgos, pero produce un retorno más pequeño. Típicamente hay coordinación limitada entre proyectos y además no requiere “forcejeos” entre departamentos o cambios en la política global de la empresa. El uso de un proceso Small SOA permite a la organización crear la cartera de servicios más despacio, pero con una coordinación limitada, los procesos son menos propensos a ser reusados o compartidos entre múltiples consumidores.
Las iniciativas Small SOA a menudo se focalizan en aspectos “run-time” en lugar de en aspectos “design-time”, es decir se busca más el resultado en ejecución y no se realiza un diseño profundo de la solución.
Las inquietudes más frecuentes en entornos “run-time” es habilitar un estilo de comunicación flexible, patrones de interacción y mecanismos de mediación que faciliten la integración y promuevan una articulación flexible. Los ejemplos de estilos de comunicación incluyen sincronía, a sincronía y peticiones de mensajes de respuesta.
Los patrones de interacción soportados más comunes incluyen peer-to-peer, entrega negociada (broker delivery), hub-and-spoke, publicación/subscripción (publish/subscribe) y orquestación de procesos, los cuales son usados como puente para cerrar el espacio entre la disponibilidad, la confiabilidad y la topología consumidor-proveedor
Los mecanismos de mediación reducen la necesidad de proveer plataformas de mensajería simétrica dónde ambos, consumidor y proveedor se comunican usando el mismo protocolo, formato de mensaje y estilo de comunicación. Los mecanismos de mediación también encapsulan los detalles de la implementación relacionados con la localización, el versionado y el dominio de identidades (identity domain).
Con la adopción de Small SOA conducido desde el punto de vista TI requiere una aproximación cautelosa para no dejar que el esfuerzo se focalice exclusivamente en la tecnología en lugar de en diseño, cultura y objetivos TI.
Los equipos que quieran adoptar Small SOA desde una aproximación TI tendrán éxito cuando fomenten seguimientos de adopción de consumo de los servicios y de subscriptores, as fomentar historias de adopción de consumo, los suscriptores del servicio de pista, y dar a conocer el crecimiento del uso de los servicios en la organización.
Con la adopción de Small SOA conducido desde el punto de vista TI requiere una aproximación cautelosa para no dejar que el esfuerzo se focalice exclusivamente en la tecnología en lugar de en diseño, cultura y objetivos TI.
Los equipos que quieran adoptar Small SOA desde una aproximación TI tendrán éxito cuando fomenten seguimientos de adopción de consumo de los servicios y de subscriptores, as fomentar historias de adopción de consumo, los suscriptores del servicio de pista, y dar a conocer el crecimiento del uso de los servicios en la organización.
Un enfoque Small SOA impulsada desde negocio, puede dar lugar a casos de éxito atractivos, los cuales ayudarán y propiciarán la adopción de SOA. Sin embargo los activos de negocio son de dudosa reutilización sin la colaboración entre equipos y la promoción. Los esfuerzos descoordinados y sin gobierno de proyecto-a-proyecto pueden generar una situación caótica que resulta en un poco e incluso nula, reutilización de lo implementado, ¿Cuántos de los servicios desarrollados son compartidos?, y ¿Cuántos servicios son simplemente una forma de facilitar integraciones punto a punto?
Similar al Small SOA conducido desde negocio, la aproximación API-Access es el resultado de casos de éxito convincentes, lo que favorece aún más la adopción. Proporcionando una plataforma tecnológica API-Restful accesible para que los equipos que integren TI y conocimientos de negocio con apps móviles, aplicaciones Javascript basadas en el navegador o Shell scripts máquina-máquina (M2M).
Mientras que la tecnología API puede ser un adelanto de una estrategia SOA, las APIs no necesitan seguir los principios SOA (por ejemplo, débil acoplamiento, separación de intereses, orientación a servicio), y los equipos API se pueden fija de manera predominante en preocupaciones derivadas de las integraciones que refuerzan los silos de capacidades. Los equipos de proyectos API abarcan el control de dominios e integran APIs externas para dar soluciones al proyecto.
En lugar de centrarse en el intercambio de información y en las inquietudes por la reusabilidad (un enfoque más SOA), los defensores de la tecnología API evangelizan cómo los equipos pueden rediseñar su negocio, aumentar el crecimiento de los ingresos y retener a los clientes mediante de una Empresa API-Centric. (Empresa con la tecnología API como centro de sus esfuerzos TI y de negocio)
Las empresas API-Centric se mueven más allá de un destino ecommerce para abrazar descentralización, personalización, contextualización, gamification, y los canales de distribución dinámicos. Las tendencias tecnológicas engloban estos conceptos incluyendo los canales móviles, M2M (machine-to-machine), P2P (person-to-person), B2D (businessto-developer). En cada caso, las APIs son el pegamento que conecta los distintos actores y componente distribuidos de la solución. Los equipos tecnológicos en las empresas API-Centric usan las API para montar rápidamente soluciones utilizando bloques de construcción internos y externos. Debido a que las API extienden la accesibilidad, facilitan el consumo y reducen las barreras técnicas, los usuarios avanzados de negocio y los desarrolladores pueden ajustar rápidamente soluciones conjuntas. Estos bloques preconstruidos API incluyen, por ejemplo, módulos de clientes, pedidos, productos, logística, mapas, email, SMS, clima o tráfico.
En adición a los beneficios de ganancia interna en la productividad, las empresas APICentric consiguen más clientes y generan una actividad de negocio mayor. Las APIs facilitan la interconexión de procesos de negocio a través de una cadena de valor extendido. Socios, proveedores, distribuidores y clientes pueden aprovechar rápidamente una capacidad de negocio ofrecida como una API, y aumentar la interacción de negocio sobre el canal API.
Los equipos de desarrollo, en lugar de crear una arquitectura consistente de servicios y demostrar la capacidad de re-utilización de los servicios, a menudo producen de manera inadvertida solo un conjunto de Web Services (Just a Bunch of Web Services, JBOWS) o un conjunto de Servicios REST (Just a Bunch of REST Services, JBORS).
Una aplicación frecuentemente consume un servicio y una web de conexiones “spaghetti” uno-a-uno entre los endpoints del proveedor del servicio y los consumidores. Muchos equipos encuentran que un desarrollo enfocado en SOA o REST puede no mejorar la agilidad TI, pero esto resulta en un simple intercambio de herramientas TI, formatos de mensajes y protocolos.
La infraestructura TI, el diseño de procesos, el gobiernos, la cultura y los incentivos deberían ayudar a conseguir los objetivos de negocia SOA y API incentivando la compartición de recursos y la reutilización, consolidando la funcionalidad y la conducción de la adopción tecnológica por parte del equipo de desarrollo.
Para crear un mejor entorno para la arquitectura y ganar agilidad API-Centric, los equipos deben entender:
Se debe crear un servicio cuando se quieren compartir capacidades o información de negocio entre aplicaciones de red o limitar las aplicaciones en tiempo de ejecución. Un servicio debe implementar una tarea de negocio autónoma de manera razonable y no estar diseñado de manera excesivamente granular como un componente con interdependencias con otros componentes. Desarrolladores y analistas de negocio son más cercanos a entender el propósito del servicio cuando éste expone una tarea ligada con un proceso de negocio. Diseñando servicios para tareas de negocio la granularidad reduce la complejidad de las interacciones del servicio y simplifica el mantenimiento de la aplicación.
Ejemplos de tareas de negocio que son compatibles con una aproximación orientada a servicio incluye “tramitar un pedido”, “recuperar un registro de cliente” y “pagar una factura”. El servicio debe exponer sus competencias a través de múltiples estilos de interfaces (HTTP/JSON, XML/JMS, SOAP/SML, asíncrono, síncrono), y las APIs RESTful son solo un estilo de interfaz. Idealmente, el estilo del interfaz es solo un tipo de implementación con características de gestión importantes (seguridad, cumplimento del nivel del servicio, seguimiento de uso) estarán disponibles entre todos los canales de los interfaces (por ejemplo, orientación a recurso, publish/subscribe, método de invocación). La Ilustración 1 Ilustra el patrón de implementación de fachada (facade)
Ilustración 1: Patrón API façade
La separación del contrato y los protocolos externos de la representación interna impacta positivamente en la habilidad de evolución de la implementación del servicio en el tiempo. Cuando existe una clara separación de la interfaz con respecto a la implementación, un desarrollador puede modificar la implementación sin impactar las aplicaciones que llaman y usan el servicio.
Sin embargo, desacoplar el consumidor y el proveedor desde una plataforma de aplicación compartida, y desacoplar interfaz de implementación hace que surjan aspectos adicionales a tener en cuenta. Por ejemplo, las dificultados aparecen cuando se intentan flujos continuos en operaciones semánticas (seamlessly flowing), es decir, identidad, niveles de servicio, autorización entre plataformas diferentes y entornos distribuidos. Los equipos confían en infraestructuras middleware para enlazar las semánticas entre todas las partes participantes y los componentes.
Porque separar interfaz de implementación introduce complejidad y esfuerzos de desarrollo extra, muchos equipos deciden vincular estrechamente la interfaz a la implementación. Siguiendo buenas prácticas arquitectónicas e introduciendo fachadas API o Proxy endpoints (con desarrollo automatizado), los equipos aumentan la capacidad de mantenimiento y adaptación de la solución.
En general se crea una API Restful cuando compartimos un servicio fuera de un dominio controlado, es decir, unidades de negocio, organización, etc…, considerando que va dirigido y orientado a conseguir al mayor alcance y consumos posibles, ofreciendo el servicio a través de una infraestructura web nativa o con el interés de maximizar la evolución asimétrica entre los clientes de servicios, interfaces e implementación.
Cuando los equipos de desarrollo publican fachadas API delante de los servicios existentes, explícitamente separan el interfaz del servicio de la implementación del servicio. Los endpoints API son proxies ligeros que refuerzan la seguridad, monitorizan el uso y distribuyen el tráfico. El proxy permite una clara separación de conceptos entre el contrato del interfaz de consumo y la implementación del “back-end” del servicio.
Mientras los servidores de aplicación, los nodos del bus de servicios empresarial o los hosts de servicios de datos pueden publicar API endpoints, las API gateways son el mecanismo preferido para la entrega. Una API gestionada está:
Las APIs RESTful exponen un interfaz orientado a recurso. El interfaz es un conjunto de recursos, cada uno exponiendo una API uniforme. Para crear una API RESTful:
El éxito de una iniciativa SOA requiere la creación de conexiones consumidor-proveedor poco acopladas, rebajando la separación de aspectos en los que estén involucrados ambos, exponiendo un conjunto de servicios reusables y compartibles y consiguiendo la adopción tecnológica por parte del consumidor del servicio.
Muchos equipos de desarrollo publican servicios, mientras en paralelo siguen peleando por crear una arquitectura de servicios que pueda cumplir los requisitos SOA, compartida, reusable y adoptable entre los distintos equipos de desarrollo internos. En su lugar, sin proponérselo, en lugar de crear esa arquitectura de servicios consistente de la que hablábamos producen sólo un grupo de servicios web o de servicios REST (JBOWS o JBORS).
Una aplicación frecuentemente consume un servicio y una web de conexiones “spaghetti” uno-a-uno entre los endpoints del proveedor del servicio y los consumidores. Muchos equipos encuentran que un desarrollo enfocado en SOA o REST no mejoraría la agilidad TI, y el resultado es en un simple intercambio de herramientas TI, formatos de mensajes y protocolos. El Gobierno SOA, el Gobierno API y el Gobierno de la Aplicación pueden cerrar la brecha y mejorar la coherencia en la arquitectura del sistema.
En muchas organizaciones, las iniciativas SOA acaban siendo soluciones en integraciones punto-a-punto en lugar de arquitecturas, generalmente porque no existen programas de gobierno que mitiguen los factores de riesgo y soporten los principios SOA. Retrasar la creación del gobierno en los proyectos a menudo resulta en la creación de servicios que no pueden ser re-utilizados posteriormente, la proliferación de múltiples definiciones de dominios de negocio y el aumento del mantenimiento del coste del catálogo de servicios de la empresa.
Un Gobierno SOA efectivo controla el desarrollo y el operativo de los sistemas orientados a servicios, y está implementado usando políticas, procesos, métricas y organización:
Un programa de Gobierno SOA debería proporcionar la guía para el ciclo de vida integral del servicio, incluyendo la creación, las pruebas, el aprovisionamiento, el uso, la gestión y el versionado. Los componentes de una infraestructura de Gobierno SOA proporcionan herramientas y servicios que dan soporte a un programa de Gobierno, ofrecen mecanismos para: gestionar y mantener las políticas y para imponer unos checkpoints durante varias fases del ciclo de vida de desarrollo de software (SDLC) verificando que los servicios, las APIs y/o los proyectos cumplen con esas políticas. También proporciona mecanismos que permiten la aprobación manual y automática y la gestión de excepciones de los procesos. Todo esto permite al Gobierno SOA la integración con las herramientas del ciclo de vida de desarrollo tradicional (SDLC) y de los sistemas de gestión y gobierno habituales de las tecnologías de la información (TI).
Algunos componentes de la infraestructura de Gobierno SOA están dirigidos al gobierno del tiempo de desarrollo, y otros componentes al gobierno están destinados al gobierno a nivel de ejecución (runtime). Por ejemplo el componente “Service registry” permite un puente entre los componentes desarrollo y los de ejecución.
Un objetivo clave para las iniciativas SOA es conseguir un portfolio de servicios que exhiba una arquitectura clara. Los modelos de negocio técnicos e industriales verticales son puntos de inicio útiles para el desarrollo de un catálogo de servicios único para una organización. El diseño de servicios e interfaces son pequeñas piezas de un conjunto de programas más grandes que deben ser gestionados para establecer una altamente efectiva manera de entrega, colaboración y confiabilidad de los servicios TI.
Iniciando proyectos complementarios como la gestión de los procesos de negocio (BPM), aplicaciones de racionalización o arquitecturas empresariales son excelentes mecanismos para entender las dinámicas TI, descomponer los dominios de negocio, y determinar que activos de software (¡y servicios!) pueden soportar los procesos de negocio.
El Gobierno API está fuertemente influenciado por los objetivos de negocio IT. Las plataformas líderes en Gobierno API proporcionan analítica que permiten la evaluación de los valor de negocio IT. La plataforma debe capturar información sobre las suscripciones en la capa de servicio, recolectar estadísticas de uso, presentar métricas de productividad e integrarse con sistemas de facturación y pago.
El Gobierno API engloba las suscripciones y la promoción de meta-data API. Las actividades de gobierno en lo que se refieren a la promoción de los metadatos API incluyen la racionalización de las etiquetas y keywords usadas para categorizar las APIs, y la gestión de los contenidos de la documentación de desarrollo. Por otra banda los procesos de gobiernos deben mejorar la revisión en tiempo de diseño antes de la publicación definitiva de la API.
Las métricas de economía API incluyen la adopción de la tecnología y su uso, y es el gobierno API el que establece cómo se realizan las políticas, las métricas y los procesos de adopción (por versión, o por API) y el uso (por versión o por API). Entendiendo la adopción y el uso de una API, los propietarios de negocio y los arquitectos pueden invertir de manera más inteligente en futuros recursos de desarrollo, planificar convenientemente una infraestructura API escalable y racionalizar el catálogo de las APIs.
Para la entrega eficiente y efectiva de soluciones IT, los equipos deben sincronizar las actividades del Gobiernos API y del Gobierno SOA. La gestión de las API proporciona un sencillo conjunto de estados en el ciclo de vida (por ejemplo, creado, publicado, obsoleto, retirado, bloqueado) que pueden ser adaptados por el equipo de desarrollo.
Los registros facilitan la gestión de los metadatos del servicio y el gobierno en el diseño, la implementación, el testeo y las operaciones en tiempo de ejecución.
Ilustración 2: Intersección de las dos vistas del Gobierno.
Cuando desarrolladores consumen, incorporan, orquestan o componen APIs o servicios entre organizaciones, las limitaciones, la documentación y los contratos que describen cómo interactuar con la API o el servicio, lo que llamamos la adopción toma especial relevancia. Los defensores de la tecnología API proponen evitar los contratos de interfaz de servicios pesados y cambiarlos por documentación ligera y fácilmente inteligible por las personas. Los paradigmas “RESTafari” en contra de los lenguajes descriptivos, los esquemas y las políticas machine-readable clásicos comienzan a disminuir.
Las buenas prácticas REST, se están comenzado a ver influenciadas por el diseño y la descripción, por lo que se construyan servicios SOA o RESTful APIs, los equipos deben de considerar los siguientes puntos:
Los Metadatos permiten una descripción formal de los endpoints y alientan el descubrimiento y la reutilización por parte de otros equipos.
La mayoría de las organizaciones no comienzan con un esfuerzo completo de inventariar los servicios o APIs, en su lugar simplifican el ámbito del proyecto. Las empresas trabajan en describir cada candidato a servicio/API que es core de negocio para la empresa, redefiniendo los metadatos de taxonomía, ganando de esta manera la aceptación por parte de los equipos que ofrecen soluciones para la posible reutilización.
Conseguir un equilibrio productivo entre orientación útil y control asfixiante requiere entender los impedimentos y la cultura propia del equipo involucrado. Las iniciativas SOA/ API se estancan principalmente por:
Es necesaria una orientación, pero si los procesos de gobierno son molestos y caros, hará que el resentimiento y la resistencia.
Cuando sea posible, los procesos deben ser transparentes y automáticos. Por ejemplo las comprobaciones de conformidad pueden ser realizadas durante el alta o el registro al servicio. Muchos sistemas de gestión de políticas proporcionan herramientas para verificar el cumplimiento de las políticas de manera automática. Se deben buscar productos que se integren perfectamente con las herramientas de desarrollo para que, de esta forma, sea lo más sencillo posible para los desarrolladores la detección, la identificación y la solución de incidencias relacionadas al cumplimiento de las políticas.
Los sistemas de gestión de contrato pueden ser muy valiosas como apoyo para la gobernabilidad del proceso de aprovisionamiento de los consumidores, de la misma manera que para la gestión del ciclo de vida del proceso, las peticiones de evolutivos y el control de versiones de servicio.
Las iniciativas ya sean de mentalidad Big SOA, Small SOA, API-access o API-Centric tienen éxito cuando se produce una adopción generalizada por todos los participantes, se comparte, y se reúsa entre los distintos silos de proyecto, los dominios organizacionales y las comunidades de desarrollo.
Las iniciativas de gobierno tienen éxito cuando implementan las siguientes iniciativas:
SOA puede ser una estrategia que alinee los recursos TI con las capacidades, los recursos y los procesos de negocio. SOA se focaliza en compartir y en la reutilización que puede optimizar el uso de los activos TI. Las iniciativas SOA se comprometen a reinventar las interacciones B2B y permitir así, mejores relaciones con los partners y apoyo a redes de proceso, lo que lo convierte inicialmente en desconcertante. Los servicios externos son vistos como un mecanismo para extender el alcance económico de la empresa mediante la reducción de costes de interacción, incorporando capacidades de trabajo externos, permitiendo así especialización empresarial y la creación de soluciones de mayor valor que extienden los procesos de negocio entre la red de socios empresariales.
El actual negocio de la API economy vincula la propuesta de valor de SOA, añade lecciones aprendidas e incorpora tendencias populares en la industria, como son, REST, Internet of everything, servicios en la nube y tecnología móvil.
Las APIs son un componente estratégico para ayudar en tu iniciativa SOA. Superficialmente, las APIs RESTful son simplemente una versión especializada de Web Services, y proporcionan unos beneficios técnicos similares. Ambos diseños REST API y SOA pretenden exponer una funcionalidad clara mediante un interfaz bien definido. Ambos modelos API y Servicios para que sean exitosos y escalables requieren endpoints gestionados.
REST es un estilo de arquitectura de desarrollo de sistemas que imponen una serie de restricciones en la interacción con los servicios. Todo junto, las restricciones permiten propiedades beneficiosas para emerger, simplificar la nomenclatura, escalar, modificar, afianzar, visibilizar, aumentar el rendimiento y la portabilidad. Los sistemas que satisfacen estas restricciones son RESTful.
Mientras los beneficios de diseño RESTful ayudan a los objetivos SOA, el foco estratégico del pragmatismo REST difiere en muchas de las iniciativas SOA. Los equipos que usan diseños REST API Pragmáticos se centran en escenarios de adopción bottom-up(ver def. 3), protocolos y formatos accesibles (p.ej. HTTP, JSON, DNS), definiciones de interfaz permisivas y simplificación de modelos de interacción (es decir, garantía de entrega y reentrega).
Los equipos que “hacen REST” y “construyen APIs” normalmente se enfocan en superar las barreras técnicas y en la adopción por parte de negocio mediante la creación de muchas versiones que demuestren soluciones concretas a casos de uso del core de negocio sin introducir complejidad tecnológica. Los equipos SOA comúnmente se centran en obtener eficiencia en escalado, conseguir estandarizar la compañía, centralizar las decisiones y satisfacer complejos requisitos no funcionales.
Las aproximaciones al enfoque pragmático SOA y al enfoque pragmático API se superponen y un significado parecido. Los equipos que traten de seguir cualquiera de los dos enfoques no fuerzan el uso de los estándares más comunes (y complicados), no predican buenas prácticas difíciles, equilibran el gobierno de negocio con la autonomía del proyecto y son conscientes de las deficiencias en habilidades y los obstáculos de adopción. Una estrategia de adopción SOA efectiva require cambios fundamentales en el diseño de la aplicación y en las técnicas de desarrollo y reducir los problemas de adopción de las tecnologías (API o Service). El Gobierno SOA, el Gobierno API y el Gobierno de la Aplicación pueden cruzarse y coexistir en una organización para avanzar en el objetivo de conseguir una arquitectura racional.
Debido a que SOA representa la consecución de una arquitectura a largo plazo en la mayoría de ocasiones entra en conflicto con tener una cartera de recursos TI de larga vida, en resumidas cuentas SOA no ofrece soluciones rápidas, ni puede estar fundamentada como iniciativa a corto plazo, sino que es un viaje arquitectónico con resultados futuros. Debido a las APIs interconectan distintas capacidades empresariales hacia dentro y hacia fuera de la organización, las API pueden proporcionar una plataforma para que los que las estructuras comerciales patrocinen una renovación empresarial TI, así como una ejecución desde el punto de vista de negocios pragmática.
Similar a las iniciativas Small SOA conducidas desde negocio, una aproximación a la tecnología API con mentalidad API-access resulta en la compilación de casos de éxito, los cuales animen futuras adopciones. Las APIs RESTful proporcionan una plataforma tecnológica accesible para los equipos de integración TI y de negocios con el fin de acercase a las aplicaciones móviles, aplicaciones Javascript basadas en navegadores o scripts máquina-a-máquina (M2M).
Las organizaciones con mentalidad empresarial API-Centric llegan a más clientes y generan mayor actividad de negocio.
Las APIs facilitan la interconexión con procesos de negocio entre una cadena de valor extendida. Parnerts, proveedores, distribuidores, y clientes pueden acceder de manera sencilla a una capacidad de negocio ofrecida por una API, y aumentar la interacción de negocios a través del canal API. Las empresas con mentalidad API-Centric van más allá de una solución de comercio electrónico como finalidad, sino que abrazan la descentralización, la personalización, la contextualización y la gamification, así como los canales de distribución dinámicos. Entre las tendencias tecnológicas actuales que abarcan estos conceptos se incluyen los canales: móvil, machine-to-machine (M2M), person-to-person (P2P), business-to-developer (B2D). En cada uno de estos casos las APIs son el pegamento a través de los actores y los componentes de una solución distribuida.
Para mais detalhes de nossas soluções ou discutir algum requisito especifico, entre em contato conosco.
