estrategia de convergencia soa y api
TRANSCRIPT
w w w . c h a k r a y . c o m
Convergencia SOA – API .
Estrategia y Tácticas. Chakray Team Este documento pretende llevar a la comunidad hispano-hablante el
“whitepaper” original en inglés de WSO2 (“SOA and API Convergence.
Strategy and Tactics
2
3
Índice Introducción ................................................................................................................... 4
Objetivos de negocio SOA y API. ................................................................................ 5
Perspectivas de negocio SOA y “ecos” de la Economía API. ................................ 6
Perspectivas técnicas SOA y especialización API. .................................................... 6
Cisma entre API y SOA y la Reconciliación pragmática ......................................... 7
Enfoque Pragmático REST API ...................................................................................... 8
Enfoque Pragmático SOA ............................................................................................. 9
La reconciliación pragmática ................................................................................... 10
Definiendo una mentalidad apropiada SOA y API ................................................ 11
Mentalidad “Big SOA” ................................................................................................. 12
Mentalidad “Small SOA” ............................................................................................. 14
Mentalidad API-Access ............................................................................................... 16
Mentalidad Empresarial API-Centric ......................................................................... 16
Construir Servicios y APIs .............................................................................................. 17
¿Cuándo Crear un Servicio? ..................................................................................... 18
Cuándo crear APIs RESTful .......................................................................................... 20
Cómo acercar Servicio, API y Gobierno de la aplicación .................................... 21
Gobierno SOA .............................................................................................................. 21
Catálogo de Servicios objetivo SOA ......................................................................... 24
Gobierno API ................................................................................................................ 24
Convergencia entre el Gobierno API y el Gobierno SOA ..................................... 25
Descripción de las necesidades habituales ............................................................ 26
Gobierno equilibrado .................................................................................................. 28
Conclusión .................................................................................................................... 29
4
Introducción
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.
5
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?
Está activamente anunciada y preparada para que las aplicaciones se
subscriban
Está disponible con un acuerdo asociado y publicado a nivel de servicio
(SLA)
Es Segura, incorpora Autenticación y Autorización.
Se puede monitorizar y monetizar gracias a herramientas de análisis.
Objetivos de negocio SOA y API.
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.
6
Perspectivas de negocio SOA y “ecos” de la Economía API.
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.
Perspectivas técnicas SOA y especialización API.
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
1 The Only Sustainable Edge, John Hagel III & John Seely Brown, 2005
http://www.johnseelybrown.com/readingTOSE.pdf 2 La economía API (The API Economy) Se puede definir como el intercambio comercial
de recursos de información facilitado por: La exposición de la información de entidades
“core” a un ecosistema de desarrolladores a través de una API basada en internet y por
la combinación de recursos de información expuestos por otras entidades API para
construir nuevos recursos de información.
.
7
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.
Cisma entre API y SOA y la Reconciliación pragmática
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
8
empresariales, la centralización de las decisiones, y en satisfacer complejos
requisitos no funcionales.
Enfoque Pragmático REST API
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:
Hacer que los datos y los servicios sean accesibles al máximo.
Entrada en el entorno, sencilla y con pocas barreras.
Ampliación del alcance dirigido a la mayor audiencia posible.
Hacer que los servicios/API sean consumidos por el mayor número de
agentes posibles.
Hacer que datos y los servicios evolutivos.
Extender el sistema en tiempo de ejecución.
Alterar los recursos sin impactar a los clientes.
Dirigir el comportamiento del cliente dinámicamente.
Hacer los sistemas escalables, fiables y de alto rendimiento.
Simplificación
Cacheable
Atomización
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-up3,
3 Top-down (‘de arriba abajo’) y bottom-up (‘de abajo arriba’) son estrategias de
procesamiento de información características de las ciencias de la información,
especialmente en lo relativo al software.
9
formatos y protocolos accesibles (p.ej. HTTP, JSON, DNS), definición de interfaces
permisivas y modelos de interacción simples.
Enfoque Pragmático SOA
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:
Compartir y reutilizar recursos.
Consolidar las funcionalidades redundantes para conseguir un menor
número de partes “transportables”.
Conformar los proyectos pensando en estándares comunes y buenas
prácticas.
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.
10
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
La reconciliación pragmática
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
11
empresas sponsors TI interesadas en renovarse y una ejecución empresarial
pragmática.
Definiendo una mentalidad apropiada SOA y API
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.
12
Mentalidad “Big SOA”
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
13
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:
Elaborar un grupo multifuncional de trabajo.
Desarrollar un plan de adopción SOA.
Definir la cartera de servicios objetivo.
Desarrolla un Caso de Negocio.
Planificar y recaudar fondos para una infraestructura SOA.
Establecer los nuevos roles.
Planificar la formación y el plan de “mentoring” para el personal
Desarrollar políticas corporativas, guías y Buenas prácticas.
Instituir los procesos de Gobierno SOA.
Establecer nuevas iniciativas buscando un buen comportamiento.
Identificar proyectos Candidatos.
Establecer prioridades.
14
Re-evaluar el Ciclo de Vida de Desarrollo de Software (SDLC)
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.
Mentalidad “Small SOA”
Una aproximación a Small SOA implementa los principios SOA basado en
Proyecto-por-proyecto. 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.
15
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.
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?
16
Mentalidad API-Access
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.
Mentalidad Empresarial API-Centric
En lugar de centrarse en el intercambio de información y en las inquietudes por
la re-usabilidad (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 (business-to-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
17
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 pre-construidos 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 API-Centric 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.
Construir Servicios y APIs
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.
18
Para crear un mejor entorno para la arquitectura y ganar agilidad API-Centric,
los equipos deben entender:
Cuándo crear servicios
Cuándo crear APIs
Cómo acercar gobierno de servicio y de API.
Cómo los servicios y las APIs impactan en el gobierno de la aplicación.
¿Cuándo Crear un Servicio?
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)
19
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.
20
Cuándo crear APIs RESTful
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á:
Publicitado activamente y es suscribible
Disponible con un SLA asociado y publicado.
Asegurado, Autenticado, Autorizado y protegido.
Monitorizado y monetizado con analíticas.
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:
1. Dar a todo un “ID”
2. Enlazar todas las cosas entre ellas.
3. Usar métodos HTTP estándar.
21
4. Permitir la representación en múltiples formatos de mensaje.
5. Reducir el estado compartido.
Cómo acercar Servicio, API y Gobierno de la aplicación
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.
Gobierno SOA
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
22
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:
Las políticas especifican la forma “correcta” de hacer las cosas, éstas
codifican leyes, regulaciones, guías corporativas y buenas prácticas.
Los procesos son actividades que proporcionan una oportunidad de
probar un proyecto o artefacto conforme a las políticas y permiten tomar
la decisión de avanzar o no. Algunos procesos son automáticos y son
dirigidos por el sistema y otros requiere esfuerzo humano.
Las métricas proporcionan visibilidad en el programa de Gobierno y son
requeridas para medir y verificar cómo se cumple la aplicación de las
políticas.
La organización debe alentar una cultura empresarial que de soporte y
aliente unas buenas prácticas en el Gobierno.
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
23
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.
24
Catálogo de Servicios objetivo SOA
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.
Gobierno API
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.
25
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.
Convergencia entre el Gobierno API y el Gobierno SOA
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.
Intersección de las dos vistas del Gobierno.
26
Descripción de las necesidades habituales
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:
No publicar endpoints que expongan modelos de dato rígidos y que
requieran complicados patrones de interacción.
Documentar cómo la sesión de contexto y el estado de la sesión
influencia las interacciones.
Documentar el modelo de mensaje.
Describir las limitaciones de uso y las inquietudes de seguridad, es decir
credenciales de autenticación aceptables, protocolos de autorización,
etc...
Las tácticas de ocultación los detalles internos de la interfaz exterior SOA
y API deberían incluir frameworks de metadatos y de políticas que
provean los cimientos requeridos para identificar, clasificar y describir los
candidatos a consumir nuestros servicios o APIs. Las políticas se utilizan
para asignar metadatos a cada caso y a los endpoints de los servicios
desplegados. Los metadatos pueden abarcar los siguientes aspectos:
o Visión general (nombre, descripción, …)
o Atributos del ciclo de vida (versión, relaciones entre las versiones,
estado en relación al ciclo de vida)
27
o Clasificación (básico, compuesto, de infraestructura, de negocio,
…)
o Atributos del endpoint desplegado(protocolos, localización,
especificaciones WS-*)
o Modelo de datos (esquema JSON, RAML, esquema XML, WSDL,
versión propiedades semánticas, validaciones)
o Políticas y requisitos a nivel de Servicio (disponibilidad, capacidad,
respuesta, seguridad, tasa de transacción)
o Mediación (routing, queuing, caching, transformación, etc…)
o Atributos de dependencia (para APIs, servicios, bases de datos,
directorios, frameworks)
o Instancias de dependencias físicas (por ejemplo, plataforma de la
aplicación, seguridad, gestión)
o Modelo de Proceso de Negocio o BPEL (Diagrama UML,
clasificación de negocio, etc…)
o Información del contrato (por ejemplo, consumidores,
proveedores, usos)
o Guías de uso (momento del día, disponibilidad, número de
usuarios, rendimiento)
o Opciones contables y de remuneración (pago por uso,
suscripción, devoluciones, etc…)
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.
28
Gobierno equilibrado
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:
Insuficiente educación, formación o mentoring
Falta de confianza o de colaboración entre departamentos u
organizaciones.
Incentivos o iniciativas contradictorias
Un pobre diseño del servicio o API
Falta de métricas
Falta de Gobierno.
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.
29
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:
Establecer una tabla de revisión del diseño.
Se controlen los modelos de información, y clases.
Se adopte un modelo de financiación compartida.
Se implemente la monitorización del cumplimiento de las políticas
(compliance).
Crear definiciones comunes en el acuerdo de nivel de servicio.
Crear un inventario de activos de aplicaciones y conexiones de
integración.
Implementar procesos de revisión del gobierno para gestionar cambios
en el inventario.
Extender el gobierno del ciclo de vida del desarrollo del software para
que permita la orientación al servicio.
Conclusión
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
30
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
31
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,
32
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
33
Autor:
WSO2. (Traducido por : Chakray Team)
www.chakray.com
@chakray_com
Página LinkedIn de Chakray