ContacteCanigó. Capa de presentació desacoblada amb serveis REST i Javascript
REST (REpresentational State Transfer) és un estil d’arquitectura que s’ha convertit en l’estàndard de facto en el desenvolupament d’arquitectures orientades a serveis i web APIs. Està basat en l’estàndard HTTP i presenta una sèrie d’avantatges respecte a arquitectures basades en SOAP Webservices, com que poden ser consumits per qualsevol dispositiu que suporti el protocol HTTP.
Relacionat amb REST ha emergit un format de representació de dades diferent de l’XML tradicional. Aquest format és JSON (JavaScript Object Notation) les característiques principals del qual són la lleugeresa i la fàcil d’interpretació tant a client com a servidor.
L’ús d’aquestes dues tecnologies (REST + JSON) permet construir serveis als quals es poden connectar multitud de clients: des d’aplicacions lleugeres basades en HTML+Javascript a sistemes d’informació que en facin ús d’aquestes dades a la banda de servidor.
Aquest escenari és perfectament compatible amb Canigó 3: els mètodes dels objectes de negoci (BO - Business Objects) poden ser exposats via serveis REST amb Spring MVC (això vol dir, que podem fer accessible mitjançant http directament un mètode de negoci), i ser consumits des de Javascript, per exemple amb JQuery, ja sigui dins d’una interfície construït amb Canigó – JSF o bé una web (fins i tot estàtica) totalment separada. Com afegit, l’ús d’HTML5 i CSS3 pot proporcionar una interfície rica (RIA - Rich Interface Application) més potent i atractiva visualment.
Tant a la secció de Howto’s d’aquest comunicat com al portal de Canigó, podeu accedir al Howto que hem redactat per la implementació d’un manteniment CRUD amb serveis REST i JQuery a Canigó 3.
SIC. Validació d’integritat dels artefactes desplegats
Una de les funcionalitats que proporciona la plataforma SIC és la realització de desplegaments en els diferents entorns ja sigui de forma automàtica com en el cas d’integració o bé via ticket a SAU prèvia còpia d’artefactes en els entorns de preproducció i producció.
En un futur el SIC serà la única via a través de la qual es puguin realitzar desplegaments. Els anàlisis de seguretat i qualitat del codi hauran de garantir la validesa dels artefactes a desplegar. És per aquest motiu que és desitjable proporcionar a l’usuari un mecanisme per poder validar que els artefactes desplegats en un determinat entorn han estat generats al SIC.
El servei Jenkins proporciona el que s’anomena “file fingerprinting”. Consisteix en el registre d’una emprenta (checksum) associada a cada artefacte generat que permet identificar-lo de forma unívoca dins el sistema. Per defecte, aquesta opció no està habilitada i requereix d’una petició a la bústia sic.ctti@gencat.cat per la seva activació en un determinat projecte.
L’usuari del SIC, un cop ha accedit al servei Jenkins (http://hudson.intranet.gencat.cat), mitjançant l’opció de menú “Check File Fingerprint” pot validar si un determinat fitxer correspon a un artefacte generat al SIC. Aquesta comprovació es realitza comparant el checksum del fitxer amb els checksum’s de les empremtes dels artefactes generats al SIC. En cas que coincideixi amb alguna de les empremtes d’aquests artefactes es mostrarà a l’usuari la informació del job que l’ha generat:
Evolució
Uns dels evolutius previstos per la plataforma SIC pretén automatitzar la detecció d’artefactes no generats al SIC i que han estat desplegats a Serveis Centrals. El checksum serà configurable per adaptar-lo a les necessitats de profunditat criptogràfica que necessiti l’aplicació.