17. Arquitectura de sistemas orientada a serveis_ API Manager.pdf

Tema 17 Arquitectura de sistemes orientada a serveis: API Manager (application programming interface). 1 El títol del Tema 17 és “Arquitectura de sistemes orientada a serveis: API Manager (application programming interface)”. Tot i que interpreto que el co...

Tema 17 Arquitectura de sistemes orientada a serveis: API Manager (application programming interface). 1 El títol del Tema 17 és “Arquitectura de sistemes orientada a serveis: API Manager (application programming interface)”. Tot i que interpreto que el concepte principal a tractar és la gestió d’APIs amb l’API Manager, crec que és convenient fer una breu descripció del concepte més general d’arquitectura orientada a serveis i d’on surt la conveniència i necessitat de la gestió de serveis. Arquitectura orientada a serveis Es pot definir el concepte d’arquitectura orientada a serveis (Service Oriented Architectura - SOA) com un paradigma de disseny d’alt nivell basat en l’organització i ús de funcions o funcionalitats distribuïdes que poden ser propietat de diferents actors. [Ref. 1]. En aquest context, un servei es pot definir com un mecanisme d’accés a una o més funcions que representen la lògica d’una activitat de negoci, a través de la utilització d’una interfície pre-definida i segons les regles especificades a la descripció del servei. El proveïdor ofereix el servei per l’ús dels possibles consumidors, que poden de forma genèrica no ser coneguts pel proveïdor. Aquest paradigma d’arquitectura té les següents característiques [Ref. 2]:  Es basa en el disseny de serveis que reflecteixen activitats de negoci.  Els serveis es representen mitjançant descripcions de negoci.  Imposa requeriments d’infraestructura específics.  Requereix un govern (control) sobre la descripció i implementació dels serveis.  Requereix un conjunt de proves que determinin la correcta implementació del servei. El consumidor només coneix la interfície del servei, que descriu les dades i les funcions que exposa i les dades necessàries per a que els consumidors determinin si el servei és adequat per cobrir les seves necessitats. Els detalls de la implementació del servei resten ocults al proveïdor. La descripció del servei en aquest patró d’arquitectura s’anomena contracte. Cridar un servei pot tenir com a conseqüència l’obtenció d’algunes dades, el canvi d’estat en algunes entitats, o la combinació de totes dues coses. Aquest concepte de servei posa de relleu la distinció entre una funcionalitat o conjunt de funcionalitats creades per cobrir una necessitat i el punt d’accés a aquesta funcionalitat en el context d’una arquitectura orientada a serveis. Anem a veure ara les característiques dels serveis definits en aquest context [Ref. 3]:  Els serveis disposen d’un contracte de servei estandarditzat. Aquest contracte conté la descripció de les dades i funcions que exposa els servei que són necessàries per a que els consumidors determinin si el servei és adequat per cobrir les seves necessitats.  Baix acoblament o dependència entre el contracte del servei, la seva implementació i els consumidors. Aquest principi té com objectiu separar el disseny de la lògica i implementació dels serveis i la seva evolució, a la vegada que es manté la interoperabilitat amb els consumidors.  Els serveis amaguen (abstreuen) la lògica de la implementació als consumidors, que només coneixen el contracte del servei.  Els serveis són reutilitzables per diferents consumidors. La seva lògica de negoci és independent del consumidor.  Els serveis necessiten disposar d’un grau de control significatiu del seus recursos i entorn d’execució. D’aquesta característica se’n diu principi d’autonomia.  Els serveis redueixen al màxim la gestió d’estats (sessions). Manegar excessiva informació d’estat pot comprometre la disponibilitat del servei i restar-li capacitat d’escalabilitat.  Els serveis inclouen metadades a la seva descripció per tal de poder ser descoberts i interpretats en termes de negoci.  Els serveis són preparats per ser utilitzats en composicions, independentment de la complexitat i mida de la composició. 2 Els principals avantatges d’aquest model d’arquitectura de serveis són [Ref. 4]:  Independència d’infraestructures i plataformes tecnològiques, el que permet a les organitzacions treballar amb les tecnologies que ja tenen implantades i/o seleccionar-ne la que consideren més convenient segons la seva infraestructura tecnològica.  Facilitar la interoperabilitat entre sistemes d’informació implementats amb diferents tecnologies. NOTA: el paradigma d’arquitectura orientada a serveis no determina la utilització d’estàndards per a la implementació dels serveis ni d’una arquitectura tecnològica o empresarial concreta. Tot i així és recomanable l’adopció d’estàndards i és per això que s’associa el concepte a tecnologies o estàndards concrets. A l’Annex 1 es descriuen molt breument alguns dels estàndards, tecnologies conceptes que es mencionen en aquest document. La tecnologia de serveis web (web services) és la que tradicionalment més s’ha associat al concepte d’arquitectura orientada a serveis. Aquesta tecnologia és d’àmplia adopció, però pot presentar problemes per organitzacions amb gran número de serveis, en funció de les característiques concretes de cada organització i de la seva implementació de l’arquitectura. Per exemple, l’impacte d’un petit canvi en una de les funcions de negoci d’un servei implicarà actualitzar el contracte del servei. Aquesta modificació del contracte impactarà en tots els consumidors del servei, siguin o no consumidors de la funció concreta que ha originat el canvi, i obligarà a executar cicle complet de proves i desplegament de tot el servei i molt possiblement de les aplicacions que el consumeixen. Així, les arquitectures orientades a servei amb implementació de serveis web poden presentar els següents problemes, que impacten en el cost de manteniment dels sistemes:  Dificultats per a escalar, si els serveis no s’han dissenyat acuradament en aquest sentit.  Eventual necessitat d’implantar mecanismes de middleware amb capacitats de transformació i enrutament de missatges per a la interoperabilitat entre serveis. Els productes tipus ESB (Enterprise Service Bus) faciliten la centralització de la gestió dels serveis (transformació de missatges, enrutament, control d’accés i securització, etc.)  Complexitat i/o pèrdua de flexibilitat en el cicle de vida de les aplicacions pel que fa a proves i desplegaments si s’opta per agrupar els desplegaments dels canvis en els serveis. Arquitectura de microserveis (tema 1) El següent conjunt de factors ha conduit a l’adopció de l’anomenada arquitectura de microserveis (Micro Services Architectura – MSA):  La necessitat de superar les limitacions abans exposades de l’arquitectura orientada a serveis.  L’augment en la flexibilitat i la necessitat d’evolucionar les aplicacions més ràpidament i de consumir els serveis per un número creixent de canals i dispositius.  L’adopció de noves metodologies de treball per donar resposta a aquests nous reptes (AGILE, DEVOPS).  L’aparició de tecnologies que ho fan possible (REST per al desenvolupament de serveis, Dockers pel que fa a la infrastructura). Nota: aquests factors apareixen sovint a la literatura com motors, desencadenants o palanques de la Transformació Digital. L’arquitectura de microserveis constitueix un nou paradigma, que consisteix en la construcció de les aplicacions com conjunts de serveis molt petits i especialitzats que es comuniquen mitjançant protocols lleugers. Cadascun d’aquests petits serveis s’encarrega d’implementar una funcionalitat completa del negoci, es desplega de forma independent i pot estar implementat en diferents tecnologies [Ref. 4]. 3 Es pot considerar que l’arquitectura de microserveis és una particularització de l’arquitectura orientada a serveis, amb les següents característiques [Ref. 5]:  És basada en components que són unitats de software independents, reemplaçables i actualitzables.  És organitzada en torn a les funcionalitats del negoci, definint molt clarament les responsabilitats de cada servei, que ha d’implementar tota la funcionalitat, incloses les col·laboracions amb sistemes externs si escau.  Alineament amb la idea de treballar per productes i no per projectes, entenent el software com una funció contínua de millora del negoci.  Disseny tolerant a fallides, assumint que qualsevol crida a un servei pot fallar el consumidor ha de respondre a aquesta circumstància amb flexibilitat i eficàcia evitant errors encadenats. A tal fet s’utilitzen patrons com la utilització de temps màxim d’espera, reintents, cues de peticions, etc. En una arquitectura de microserveis aquests es comuniquen entre ells mitjançant interfícies senzilles anomenades en aquest context APIs. Una API (Application Programing Interface) és una interfície de programació, és a decir, una forma d'exposar la funcionalitat d'un component software a un altre component (que desenvolupa el rol de client). Una API típicament es defineix como un set d'especificacions, como el set de missatges http (GET, POST, PUT, DELETE), així com la definició de les estructures retornades com resposta a aquests missatges. Normalment les estructures retornades com resposta venen formatejades en Extensible Markup Language (XML) o JavaScript Object Notation (JSON). Les API proporcionen flexibilitat en l’accés als serveis i les dades i poden proveir una certa estandardització per a l’accés a través de diferents canals i per diferents audiències o consumidors. Els principals beneficis de l’arquitectura de microserveis es considera que son els que es relacionen a continuació [Ref. 8]. Cal considerar però que aquests beneficis depenen en certa mesura de la granularitat amb què es defineixen els microserveis en una implementació concreta.  Agilitat i productivitat. Es suposa que l’equip pot construir, testejar i desplegar un servei de forma independent d’altres components, amb cicles de construcció molt més ràpids gràcies a la simplicitat del microservei.  Escalabilitat. Es suposa que l’equip de desenvolupament pot escalar el microservei en temps d’execució de forma independent d’altres, habilitant la reutilització eficient de recursos i la reacció ràpida.  Tolerància a falles (resiliència). Els entorns d’execució separats contribueixen a proporcionar la capacitat de les aplicacions de ser tolerants a falles, sempre que el disseny de les aplicacions sigui acurat en el desacoblament de components, evitant dependències síncrones i utilitzant els patrons de disseny adients. Aquest paradigma d’arquitectura també pot presentar alguns problemes [Ref. 6 i 7]:  El disseny i les proves poden esdevenir molt complexes en funció del nombre de microserveis que s’utilitzen i de la tolerància a errades aconseguida.  La gestió de versions i el desplegament poden resultar també molt complexes atenent a les característiques de la implementació i les eventuals dependències entre serveis.  Complexitat del disseny elevada en funció de la granularitat dels serveis. Arquitectura basada en serveis a l’IMI Per donar resposta a la necessitat de flexibilitzar i donar agilitat a la construcció d’aplicacions, l’IMI ha adoptat un model de construcció de sistemes d’informació basat en serveis. A continuació es relacionen els requeriments que es posen a la construcció de sistemes.  El desenvolupament del sistema ha d’estar orientat a serveis. Tot el negoci de l’aplicació ha de exposar-se mitjançant una o més API(s) de serveis.  En el disseny de l’arquitectura general de qualsevol sistema es consideraran els següents components: L'Aplicació(Negoci), l’API Getway i el client(Presentació), com es mostra a la figura següent. 4   Totes les API(s) per motius de Seguretat i gestió s'han de publicar en el API Manager estàndard del IMI i s'han de consumir única i exclusivament per aquest API Manager.  Qualsevol intercanvi de dades entre serveis o aplicacions es realitzarà mitjançant API(s) de serveis fen servir el protocol encriptat HTTPS.  L’IMI disposa d'un únic API Manager que centralitza la publicació i consum de serveis en entorns de desenvolupament i pre-producció. Per entorns productius es disposa de 2 instàncies d’API Manager separades per a donar serveis a l’entorn corporatiu intern i a l'entorn d'internet.  Actualment, el bus (Message Broker - WMB) s'ha d'usar només per a les integracions que no poden ser incorporades com API(s) en el API Manager, o integracions que requereixin un alt grau de transformació en les crides, inicialment s'ha d'utilitzar només per a les integracions amb HOST i amb SAP.  Qualsevol integració entre plataformes que es pugui realitzar mitjançant API(s) RESTful, sempre s'ha de realitzar a través de API Manager (Ex. J2EE, Phyton, Node, etc.)  Qualsevol nova integració es farà a través del API Manager.  Les possibles integracions de serveis ja existents a través del WMB es transformaran en serveis RestFul i es publicaran pel API Manager. Aquest model de construcció de sistemes fa necessària la figura de l’API Manager per a proporcionar la governabilitat sobre les API que publiquen els negocis dels sistemes d'informació. API Management – conceptes generals Podem definir la gestió d’APIs (API Management) com el procés de creació i publicació d’APIs, aplicant les polítiques de seguretat i control d’accés adients, recollint i analitzant estadístiques d’ús, i reportant sobre el seu rendiment [Ref. 9]. L'API Manager serveix perquè els usuaris puguin consumir serveis, interconnectar mòduls i aplicacions i facilitar l’accés al backend, permetent re-utilització de serveis.Un sistema de gestió d’APIs (API Manager) genèric proporciona eines de suport als desenvolupadors i als consumidors o subscriptors de les APIs. Existeixen molts productes de mercat per a la gestió d’APIS, a continuació una imatge de Forrester Report Q4 2018 [Ref. 8]. A l’IMI s’utilitzen 3 productes diferents per a la gestió d’APIs:  WSO2: es tracta d’un producte Open Source de gestió d’APIs que es troba integrat a la plataforma City OS.  API Umbrella: un altre producte Open Source de gestió d’APIs que s’utilitza per a la gestió de les API que s’ofereixen per oferir dades de l’Ajuntament per al consum per altres organitzacions o pels ciutadans.  IBM API Connect: producte d’IBM per a la gestió d’APIs. S’ha seleccionat com a producte corporatiu per a la gestió d’APIs. Amb aquest producte es gestionaran les API de serveis de les aplicacions corporatives, i en un futur es preveu pugui absorbir la publicació de les API que es fa a través de l’API Umbrella. 5 De forma genèrica podem considerar que un sistema API Manager disposa dels següents components:  Gateway (Bescanviador d'APIs): un servidor que actua com front-end per les API. Habilita la interconnexió entre els serveis i els consumidores, mitjançant les APIs publicades en ell. Rep les peticions, aplica les polítiques de control i seguretat, les passa als serveis de back-end i torna la resposta al peticionari. El Gateway sovint inclou capacitats de transformació i modificació de peticions i respostes al vol, així com d’analítica de dades i d’emmagatzematge temporal (caché), autenticació, autorització, seguretat i auditoria [Ref. 10].  Eines de publicació (Gestor d'APIs): un conjunt d’eines que els proveïdors d’APIs utilitzen per definir les API (configuració i publicació de les APIs al Gateway), utilitzant estàndards com OpenAPI o RAML, generar documentació de les API, gestionar-hi l’accés i les polítiques d’utilització i coordinar-ne el cicle de vida.  Portal del desenvolupador (Portal d'API): portal web a través del qual els proveïdors de las API pot encapsular-les en una sola font d’informació i funcionalitat, incloent la documentació d’ús, tutorials, codi d’exemple i eines de test. Recopila tota la informació necessària pels consumidors sobre les APIs publicades en l'API Gateway. A través d’aquest portal es proporciona la capacitat als consumidors de subscriure’s a les API que volen consumir, normalment utilitzant claus de subscripció com els Client ID i Client Secret del protocol OAuth2.  Reporting i analítica: funcionalitat per al monitoratge d’utilització i càrrega de les API (nombre de peticions, transaccions completades, dades de rendiment, etc.). Poden trobar-se funcionalitat de monitorització en temps real i generació d’alertes directament o via altres eines de gestió de sistemes.  Monetització: funcionalitats de suport que fan possible el cobrament per a la utilització d’APIs d’ús comercial aplicant diferents criteris (ús, funcionalitat, etc.). 6 Un dels plans de l'Ajuntament per accelerar l'evolució tecnològica, passa per la integració de la arquitectura basada en serveis en els procesos de desenvolupament. A nivell tecnològic, per cumplir amb aquests objetius, l'IMI compte amb el desplegament d'un API Manager corporativo (l'IBM API Connect) així com l'orquestrador de contenidors (IBM Cloud Private-ICP, tot i que estem canviant a OpenShift-OCP). La pregunta del test sobre Api Manager és molt genèrica, no crec que calgui saber com funciona l'API de l'IMI, per això he deixat aquest apartat a l'annex. El cicle de vida d'un producte a l'API Manager també és molt complex. El que sí recomano és llegur les definicions dels "estàndars, tecnologies i acrònims" de l'annex. BIBLIOGRAFIA 19. Per a què serveix un API Manager? A. Per gestionar el catàleg d’aplicacions d’una organització. B. Per gestionar les integracions dels sistemes. C. Per a què els usuaris puguin demanar aplicacions, peticions i integracions. D. Per a què els usuaris puguin consumir serveis, interconnectar mòduls i aplicacions i facilitar l’accés al backend, permetent re-utilització de serveis. BIBLIOGRAFIA Ref. 1: Reference Model for Service Oriented Architecture 1.0 Ref. 2: The SOA Source Book Ref. 3: “Service-Oriented Architecture. Concepts, Technology, and Design”. Thomas Erl. Ref. 4: Microservices - Martin Fowler Ref. 5: Building microservices - Sam Newman Ref. 6: Developing Microservices for PaaS - Matt Stine Ref. 7: How small should your microservice be? - Stefan Tilkov Ref. 8: Getting Started with IBM API Connect - Concepts and Architecture Ref. 9: Oracle White Paper - A comprehensive solution for API Management Ref. 10: The API gateway pattern versus the Direct client-to-microservice communication Ref. 11: The Forrester Wave™: API Management Solutions, Q4 2018 Ref. 12: WIKI Arquitectura Desenvolupament IMI Ref. 13: Web Services Architecture - W3C Ref. 14: SOAP - W3C Ref. 15: Enterprise Service Bus - Wikipedia Ref. 16: Architectural Styles and the Design of Network-based Software Architectures - Roy Thomas Fielding Ref. 17: REST - Wikipedia ANNEX Estàndards, tecnologies i acrònims  Web Service (servei web): es un sistema software dissenyat per a suportar la interacció entre màquines de forma interoperable. Compta amb una interfície descrita en un format processable per un equip informàtic (específicament en WSDL), a través de la que és possible interactuar amb el mateix mitjançant el bescanvi de missatges SOAP, típicament transmesos utilitzant serialització XML sobre HTTP [Ref. 13]. S’associa molt freqüentment el concepte de serveis web amb el d’arquitectura orientada a serveis, però hi ha implementacions del paradigma d’arquitectura orientada a serveis no basats en serveis web, com CORBA, EDI o DCOM.  SOAP (Simple Object Access Protocol): es un protocol estàndard que defineix com dos processos poden comunicar-se mitjançant un bescanvi de dades XML. Aquest protocol deriva del protocol XML-RPC i es 7  troba sota els auspicis de W3C. Es tracta d’un paradigma de missatgeria d’una direcció sense estat, que pot ser utilitzat per conformar protocols més complexes [Ref. 14].  ESB (Enterprise Service Bus): més enllà dels productes de mercat, un ESB és una infrastructura de programari que permet la comunicació entre aplicacions actuant com intermediari, facilitant l’encaminament i la transformació (si escau) dels missatges entre diferents serveis [Ref. 15]. Freqüentment es considera l’ESB com component essencial d’una arquitectura orientada a serveis, tot i que no és mandatori d’acord a la definició del paradigma. L’ESB pot minimitzar l’efecte dels canvis en l’estructura de dades dels missatges que entre els serveis si incorporen capacitats de transformació de missatges.  REST (Representational State Transfer): aquest terme es refereix originàriament a un conjunt de principis d’arquitectura de software [Ref. 16], però actualment s’utilitza en sentit més ampli per descriure qualsevol interfície entre sistemes que utilitzi directament HTTP per obtenir dades o sol·licitar l’execució d’operacions sobre les dades en qualsevol format sense les abstraccions addicionals dels protocols basats en patrons de bescanvi de missatges, com SOAP [Ref. 17].  API (Application Programming Interface): es pot definir de forma genèrica una API com una interfície que específica la forma en què diferents components de software poden interaccionar. Tot i que el tradicionalment el concepte és d’aplicació a l’encapsulament de funcionalitats ofertes a llibreries de software, és pot aplicar també a la interfície que ofereixen els serveis. El terme API es va aplicar de forma més àmplia a les interfícies dels microserveis per ser més lleugeres, en contraposició al terme contracte dels serveis, tot i que conceptualment també s’hi podria aplicar.  Open API: l’Open API Specification és una especificació per a les interfícies de descripció, producció, consum i visualització de serveis RESTful. És gestionada pel consorci Open API Initative, que és un projecte col·laboratiu de la Linux Foundation. Smart Bear va donar l’especificació Swagger que va ser adoptada com l’estàndard Open API Specification al 2016.  Swagger: és un framework open-source que disposa d’un gran nombre d’eines per dissenyar, construir, documentar i consumir serveis web RESTFul.  YAML: es defineix un llenguatge de serialització de dades dissenyat al voltant de les estructures de dades pròpies de llenguatges de programació àgils, d’àmplia utilització en el tractament de dades (fitxers de configuració, etc.) Cicle de vida d’un producte Fase 1: L'empresa desenvolupadora ha de proveir els fitxers de definició de l'API seguint l'estàndard OpenApi 2.0 (swagger), en un fitxer amb format YAML. Aquests fitxers de definició de l'API han d'estar convenientment validats. Fase 2: Un cop l'empresa ha alliberat els fitxers que defineixen l'API (swagger), aquests han de ser enriquits amb les extensions pròpies del producte. API Connect ofereix 'out-of-box' un toolkit d'eines d'ajuda al desenvolupador amb aquesta finalitat. És important entendre el mapa de conceptes d'API Connect. Mai es podran publicar definicions d'APIs per si soles, sinó que s'han de publicar Productes. Un producte és una unitat lògica que agrupa un conjunt d'APIs. Fase 3: De cara a fer proves del nostre nou producte, hem d'utilitzar el catàleg Sandbox o 'Recinte de Proves'. Aquest catàleg, no està subjecte a regles d'aprovació, ni de subscripció. Per poder provar, en un catàleg de Sandbox, el sistema s'autogenera 1 ClientId i un ClientSecret de prova, condicions necessàries per al consum de qualsevol API. Fase 4: Si el desenvolupador només vol provar l'API, i no publicar-la en un catàleg de Preproducció o Producció, llavors el flux de treball finalitza en aquest punt. Fase 5: 8 Quan el desenvolupador ha realitzat totes les proves necessàries, ha de publicar els seus productes en un catàleg de Preproducció o Producció. Aquests catàlegs sí que estan subjectes a regles d'aprovació i de subscripció. Així doncs, perquè el desenvolupador pugui publicar Productes en aquest tipus de catàleg, aquest ha de pertànyer a l'organització propietària del catàleg i ha de tenir els permisos adients per poder publicar. Aquest punt està especialment afectat pels processos d'automatització de desplegament. Idealment, la publicació d'un producte en un determinat catàleg serà una tasca automatitzada, i per tant transparent per al desenvolupador. Com a alternativa a aquest fet, es pot fer un desplegament manual des de les eines de desenvolupament, però sempre sota la supervisió de l'Oficina Tècnica API Connect. Un cop el producte està publicat en un catàleg productiu o preproductiu, l'administrador del catàleg (Oficina Tècnica), enviarà una invitació a una o diverses organitzacions consumidores. Una organització consumidora, és una unitat lògica que conté; una o més aplicacions consumidores i una persona propietària de la mateixa. Fase 6: La persona declarada per l'administrador com a persona propietària de l'organització consumidora, serà la responsable de registrar l'aplicació consumidora fent login al portal del desenvolupador. Al portal del desenvolupador s'exposen tots els productes i les seves APIs associades, de cada a ser consumides per aplicacions consumidores. En el moment de crear una organització consumidora, el portal del desenvolupament de proveir d'un ClientId i ClientSecret que identificarà l'aplicació consumidora de forma unívoca en el sistema. Tant el ClientId, com el ClientSecret identificaran al consumidor de les APIS, així que és important no compartir ni perdre aquestes dades. En cas de pèrdua, des del portal del desenvolupador hi ha mecanismes per resetejar els valors dels mateixos. Fase 7: Un cop el consumidor ha registrat una aplicació consumidora, i el sistema li ha proporcionat un ClientId i ClientSecret, el propietari de l'organització consumidora podrà subscriure al o els productes disponibles per a aquell catàleg. Aquestes subscripcions han de ser aprovades per l'administrador (Oficina Tècnica API Connect). Diferents versions del producte poden estar disponibles al portal del desenvolupament. És responsabilitat del desenvolupador, el definir un mecanisme de compatibilitat cap enrere, per mantenir durant un cert període de temps (definit per negoci) la disponibilitat de cadascuna de les versions de l'API i / o del producte. Fase 8: L'organització consumidora, construeix un client que consumeixi les APIs embevent en la seva solució al ClientId i / o ClientSecret obtingut en la fase 6. Fase 9: Un cop ha finalitzat el procés d'implementació de l'aplicació consumidora, aquesta aplicació pot consumir els serveis exposats en el catàleg i als quals s'ha subscrit. Fase 10: Finalment la persona administradora del catàleg en conjunció amb el referent de servei, tindrà capacitats de monitorització de certes mètriques (nombre de trucades a l'API, temps de resposta mitjans, etc...), que li permetran avaluar com funciona el negoci. Per a això, API Connect proveeix d'analítiques, que ens permeten veure a través de widgets Kibana dins d'un Dashboard, com estan funcionant les nostres APIs. API Manager a l’IMI En aquest apartat es descriu com s’ha implantat el producte IBM API Connect a l’IMI per a realitzar la funció d’API Manager. En aquest context, el concepte API Manager fa referència a com s’ha implantat i particularitzat el producte IBM API Connect a l’IMI. Components de la solució L’API Manager disposa de 3 components fonamentals, que es descriuen a continuació [Ref. 10]. 9 Bescanviador d’APIs (Gateway): És el component principal. Té com a funció habilitar la interconnexió entre els serveis i els consumidors a través de les API publicades al Gateway. A tal efecte disposa de les següents capacitats.  Routing: Enrutament de missatges a diferents destinacions depenent del context o del contingut del missatge.  Suport muti-protocol: Suporta múltiples protocols tant per a la publicació de APIs en el component Gateway com pel enrutament als serveis interns.  Suport multi-format: Disposa de components destinats a transformar les dades d'un format a un altre, o del seu emmascarament.  Monitoring: Monitoratge del tràfic d'entrada i sortida.  Polítiques de seguretat: Otorga a les API característiques d'autenticació, autorització i xifrat utilitzant estàndards o tecnologies conegudes com el xifrat de transport mitjançant HTTPS, la suite de seguretat W-Security per SOAP o l'estàndard d'autorització OAuth per a interfícies REST. Compatibilitat amb sistemes de gestió d'identitats: Active Directory, LDAP, JDBC, etc.  Polítiques d'ús: Capacita a les APIs per gestionar polítiques de consum, rendiment, fallades, etc. per assegurar SLAs i sistemes de pagament per ús. Gestor d’APIs: Aquest component ofereix als proveïdors d’APIs capacitats de configuració i publicació de les API al Gateway. A tal efecte disposa de les següents capacitats.  Publicació: Publica efectivament les APIs al component API Gateway definint el seu endpoint.  Edició: Eina per al disseny de la interfície de la API.  Gestor del cicle de vida: Permet gestionar els diferents estats pel que passa una API, així com la seva versió o deprecació.  Gestor de polítiques d'ús: Eina per a la configuració de regles d'ús tals com pagament per us, SLAs, QA, etc.  Consum: Monitoratge de l'ús de les APIs i sistema de configuració d'alertes segons els paràmetres de consum.  Gestor de polítiques de seguretat: Gestiona totes la configuració de seguretat d'una API. Portal d’APIs: Component dedicat a recopilar tota la informació necessària per als consumidors sobre les APIs publicades en el API Gateway. Disposa de les següents capacitats.  Comunitat de desenvolupament: Publicacions de notícies i comentaris referents a l'ús, configuració, errors i solucions de les APIs publicades.  Navegador intern: Cercador de API registrades en el sistema, amb diversos filtres de consulta com a estat, versió, millor valoració, etc.  APIs Store on es localitzen les API publicades, accessos directes a les comunitats de consumidors, eines de testing, monitoratge, recomanacions d'usuaris, etc.  Testing: Sistema integrat de testeo de cada API.  Documentació: Repositori de documentació referent a les APIs publicades.  Estadístiques d'ús: Sistemes de monitoratge i anàlisi des de la perspectiva del consumidor: timing, status, etc. La figura següent mostra la interacció entre els tres components de l’API Manager, els sistemes consumidors i proveïdors d’APIs i els desenvolupadors i gestors de la publicació de les APIs: 10 Implantació a l’IMI - Conceptes A la figura següent es mostren els principals conceptes a tenir en compte per entendre el model de gestió de les API a l’IMI. Cloud Manager: Aquest és un concepte que fa referència a una instal·lació de IBM API Connect. El producte disposa de capacitat de gestió d’APIS en infrastructura cloud, i d’aquí el terme. Una instal·lació d’API Connect necessàriament ha de disposar d’un Gestor d’APIs (Management Service) i un bescanviador d’APIS (DataPower Gateway a la figura). Management Server: Component de runtime que realitza les següents funcions:  Exposa l’API Manager User Interface, Cloud Management console i Portal del desenvolupador.  Emmagatzema les analítiques amb informació específica de les peticions fetes a les APIs (transaccions). Gateway Server (DataPower): Aquest terme es refereix com API Gateway també. Bàsicament és la peça receptora de la transacció des d'un agent d'usuari. Addicionalment pot forçar i securitzar les transaccions a través de polítiques. Organització (no apareix a la figura anterior): 11 Les organitzacions estan posicionades en el més alt a la jerarquia d'elements de API Connect. L'eina permet la gestió i creació de diverses organitzacions, entenent aquestes com a espais aïllats entre si, on poder gestionar la resta d’entitats de la jerarquia que es descriuen a continuació. Cadascuna de les organitzacions que es defineixen ha de tenir un set de rols ben definits i diferenciats que han de permetre la gestió dels actius (productes) i del seu cicle de vida. Inicialment s'ha de considerar el nom de l'organització, ja que aquesta apareixerà en la URI d'accés als diferents recursos (API endpoints). Per exemple, es recomana l'ús de noms curts, sense presència d'espais ni caràcters especials. Com a millor pràctica, s’aconsella d'evitar l'ús de versionat com a part del nom de l'organització. A la implantació a l’IMI es proposa inicialment treballar amb una sola organització per evitar la fragmentació, tant dels productes com de catàlegs, considerant que no s’han detectat requeriments que facin necessària la configuració de diferents organitzacions. Catàleg: Dins de cada organització es podran definir tants catàlegs com siguin necessaris. Els catàlegs són agrupacions lògiques de productes que permeten una visió agrupada de les APIs publicades per al seu consum. El catàleg actua com a partició lògica del Gateway i del portal del desenvolupador. Per cada catàleg tindrem un portal de desenvolupador. Un catàleg compleix amb dues funcions bàsiques:  Sobre ell s'executen els estats del producte, propis del control del flux de vida dels productes. Per tant, és on finalment es publiquen els productes per fer-los visibles per al seu consum.  Alhora, s'exposen els productes sobre un portal del desenvolupador, des d'on les empreses desenvolupadores podran crear aplicacions consumidores que se subscriguin als plans específics del producte. El nom del catàleg apareix a l’URI d’accés als recursos, per tant caldrà posar noms curts, sense caràcters especials i espais, i sense incloure-hi nombres de versió. Espai: Partició lògica d'un catàleg. En el cas del IMI no s'utilitzen. El nom de l'espai, no formarà part de la URL final de la API. Producte: Agrupació auto-continguda de APIs. En el producte es descriuran les següents peces fonamentals:  Les APIs que el conformen.  La definició dels mecanismes de control d’accés que escaiguin. El Departament de Seguretat defineix els criteris per a la definició d’aspectes de seguretat dels productes. L’API Manager delega a l’OAM (Oracle Access Manager) l’autenticació i autorització dels catàlegs de tipus corporatiu.  Els plans de consum que s'habiliten. Un pla definirà el tipus de subscripció que una empresa desenvolupadora pot utilitzar des del portal del desenvolupament, així com les regles necessàries per assegurar el SLA del producte. Els plans estan diferenciats en el cas de consum intern o consum extern. El significat del pla per a consum intern canvia pel que fa al consum extern. Així com, quan considerem un producte per a consum extern (Internet) els plans especificaran els SLAs de consum d'aquests productes sobre la base de criteris d'ús. En canvi, quan considerem la definició de plans per a consum corporatiu (intern i extern) només existirà un únic pla amb accessos il·limitats. En qualsevol cas davant qualsevol dubte referent a que plans assignar haurem de posar-nos en contacte amb l'Oficina Tècnica. Es diu que el producte és una agrupació auto-continguda perquè ha d’incloure totes les APIs necessàries per al consum vertical d'una aplicació, para d'aquesta forma facilitar la tasques de gestió d’accés. Els productes els han de definir el desenvolupador en format Swagger (Open Api 2.0) sobre un fitxer de tipus YAML. API: Agrupació d'operacions de negoci. Aquestes operacions quedaran exposades en forma de paths. Com en el cas dels productes, la definició de l’API és responsabilitat del desenvolupador que l’ha de lliurar en format Swagger (Open Api 2.0) sobre un fitxer de tipus YAML. Es consideren dos tipus d’API:  APIs orientades al consum per aplicacions corporatives, tant en àmbit corporatiu (Aplicacions d'ús intern a l'ajuntament) com en Internet quan sigui necessari, amb control d’accés basat en rols. 12   APIs orientades al consum genèric (organitzacions externes a l’Ajuntament, aplicacions de tercers orientades al ciutadà), que són publicades a Internet amb seguretat basada en estàndards WWW (OAuth2). El producte validarà els artefactes produïts (fitxers YAML) abans de la publicació dels mateixos sobre un catàleg. La responsabilitat d'assegurar la validesa dels citats arxius de tipus YAML serà responsabilitat de l'equip de desenvolupament. L'obtenció de les credencials de consum d’una API es farà a través del portal del desenvolupador. Com s’ha dit, cada catàleg té associat un portal del desenvolupador diferent entre si, així doncs serà necessari repetir els passos descrits a continuació en funció del producte / api que es vulgui consumir. La següent taula mostra els catàlegs disponibles existents. Catàleg Entorn Descripció dsv-corp DSV Corporatiu - Serveis APIs autenticats basats en Rols dsv-icorp DSV Internet Corporatiu - Serveis APIs autenticats basats en Rols dsv-inet DSV Internet Ciutadà - Serveis APIs autenticats mitjançant ClientId i/o ClientSecret dsv-dti DSV Internet DTI - Serveis APIs autenticats mitjançant ClientId i ClientSecret per a ús intern pre-corp PRE Corporatiu - Serveis APIs autenticats basats en Rols pre-icorp PRE Internet Corporatiu - Serveis APIs autenticats basats en Rols pre-inet PRE Internet Ciutadà - Serveis APIs autenticats mitjançant ClientId i/o ClientSecret pre-dti PRE Internet DTI - Serveis APIs autenticats mitjançant ClientId i ClientSecret per a ús intern corp PRO Corporatiu - Serveis APIs autenticats basats en Rols icorp PRO Internet Corporatiu - Serveis APIs autenticats basats en Rols inet PRO Internet Ciutadà - Serveis APIs autenticats mitjançant ClientId i/o ClientSecret dti PRO Internet DTI - Serveis APIs autenticats mitjançant ClientId i ClientSecret per a ús intern Cicle de vida del producte A la figura següent es mostren els diferents estats que es poden produir en el cicle de vida dels productes. A continuació es descriuen els diferents estats. Draft: La definició del producte encara no està associada a cap catàleg. En aquest estat es poden implementar canvis sobre qualsevol de les definicions, bé sigui de producte o d’API. Staged: Quan un producte es passa a estat ‘Staged’, una còpia de la versió del mateix és desplegada sobre un catàleg. És l'estat inicial de qualsevol producte. Un producte en aquest estat no és visible encara per a cap desenvolupador. Published: Un producte que es publica, es fa visible al portal del desenvolupador. Per tant, des d'aquest mateix moment qualsevol aplicació consumidora pot subscriure's al consum del mateix. La configuració referent a la visibilitat del producte dins del catàleg i sobre la subscripció des del portal del desenvolupador, 13 poden ser canviats al moment de la publicació. És important remarcar que NO pot haver-hi una mateixa versió d'un mateix producte dins d'un catàleg, a excepció del catàleg conegut com Sandbox (sb o Recinte de Proves). Deprecated: Quan un producte es ‘depreca’, la definició del producte és tan sols consumible per aquelles aplicacions consumidors ja subscrites. No s'accepten noves subscripcions a la versió del producte. Retired: Quan un producte es retira, no s'admeten noves subscripcions, ni tampoc es permet el consum de les APIs associades, passant aquestes a estat ‘Offline’. Archived: Quan un producte s'arxiva, deixa de ser visible al catàleg. Deleted: La definició del producte, no existeix mai més dins del sistema. Estat irreversible. Les transicions d'un estat a un altre pot estar subjecte a aprovacions. Necessiten aprovació les accions Stage, Publish, Replace, Supersede, Deprecate i Retire. No necessiten aprovació les accions Delete from catalog, Re-Stage y Publish (de ‘Deprecated’ a ‘Published’) A continuació es descriuen les accions Replace i Supercede que poden resultar menys òbvies. Replace: Quan es substitueix un producte amb una altra versió del mateix producte, s'executen les següents accions:  Es publica la nova versió del producte.  S’hi apliquen la mateixa visibilitat, subscriptors i polítiques de ‘enforcement’ que tenia el producte substituït.  Els subscriptors del producte original són migrats a la nova versió del producte.  El producte original es mou a estat retirat. En aquest estat els productes JA NO SÓN VISIBLES al portal del desenvolupador i totes les subscripcions al producte antic són cancel·lades. Supercede: Quan s'executa l'acció de ‘supercede’ d'un producte, les següents accions són executades automàticament:  Es publica la nova definició del producte.  S’hi apliquen la mateixa visibilitat, subscriptors i polítiques de ‘enforcement’ que tenia el producte substituït.  El producte original és mogut a estat deprecated. En aquest estat les aplicacions consumidores que ja estaven subscrites encara poden continuar amb el consum del producte, però no s'accepten noves subscripcions. A l’Annex 2 es proporciona una visió general del cicle de desenvolupament, publicació, consum i monitorització d’un producte. 14