ContacteCanigó. Arquitectura d’aplicacions web modernes
En passats comunicats s’ha introduït l’arquitectura que des del CS Canigó s’està proposant com a estratègia a futur. Aquesta arquitectura es basa en el desacoblament de client i servidor mitjançant la publicació de serveis REST, per part de servidor, i el seu consum amb Javascript, per part del client. En aquest comunicat es pretén anar una mica més enllà proporcionant un exemple pràctic d’aquesta arquitectura
Exemple d’arquitectura amb desacoblament client/servidor
És possible tenir múltiples clients consumint els serveis que publica el servidor. Aquest és un exemple real desenvolupat al CS Canigó consistent en la publicació d’un backend Canigó 3 a OpenShift i dos frontends, un CanigóMòbil i un altre Bootstrap+AngularJS, publicats a Dropbox. Podeu descarregar el codi font d’aquesta aplicació.
Backend
REST permet exposar mètodes dels objectes de negoci (BO - Business Objects) per ser consumits mitjançant diferents mètodes HTTP (GET, POST, PUT, DELETE). La publicació de serveis REST a Canigó 3 es realitza amb Spring MVC donat que Spring forma part del core de Canigó. A continuació especifiquem el contracte de l’exemple que tractem en aquest comunicat, consistent en les operacions necessàries per poder realitzar el CRUD (Create-Read-Update-Delete) d’una entitat Equipament:
| Resource | POST (Create) | GET (Read) | PUT (Update) | DELETE (Delete) |
|---|---|---|---|---|
| /equipaments | Crea nou equipament | Llista equipaments | ||
| /equipaments/32769 | Error | Mostra equipament amb id ‘32769’ | Si existeix actualitza equipament amb id ‘‘32769. |
En cas contrari error Elimina equipament amb id ‘32769’
L’accés a aquests recursos pot protegir-se, per exemple en el cas de les operacions (Create, Update i Delete) que impliquen modificació de dades, amb autenticació bàsica (BASIC Authentication). El client haurà de proporcionar les credencials per poder accedir-hi. També és possible implementar altres mecanismes d’autenticació com per exemple GICAR.
El format de les dades que intercanvien client i servidor és JSON (JavaScript Object Notation). Aquest és un format de dades molt lleuger i ràpid de processar per els navegadors. En cas que el client que consumeix aquestes dades estigui en un domini diferent al de servidor, caldrà utilitzar alguna tècnica que ho permeti degut a que els navegadors tenen restriccions de seguretat per evitar aquests accessos entre dominis.
Cross-domain
Els diferents tipus de peticions que es poden realitzar mitjançant HTTP tenen restriccions de seguretat implementades pels navegadors:
- GET: es poden fer des d’un domini A a un domini B sense restriccions de seguretat (utilitzant el mètode GET en formularis HTML o JSONP des de javascript)
- POST: les peticions POST també es poden fer entre dominis
- PUT/DELETE: requereixen que les capçaleres que permeten fer peticions entre dominis estiguin habilitades al servidors web (CORS)
És possible salvar les restriccions de seguretat que incorporen els navegadors actuals mitjançant CORS (Cross-origin resource sharing). Aquesta tècnica consisteix en l’intercanvi d’una sèrie de capçaleres HTTP (Access-Control-*) entre client i servidor negociant aquest accés. En cas necessari, el client també és capaç d’enviar credencials per l’autenticació si el servidor ho requereix. En l’exemple que es tracta en aquest comunicat s’ha configurat CORS en el servidor i autenticació bàsica per els mètodes POST, PUT i DELETE. El fet que el backend estigui a OpenShift i els clients a Dropbox demostra que es poden tenir aplicacions en diferents dominis, tot i que el més habitual és que es trobin en el mateix domini sense necessitat de realitzar cross-domain.
Frontend
En aquest exemple d’arquitectura moderna es proporcionen dues variants d’aplicació client basades en HTML i JS, una Canigó Mòbil amb JQuery Mobile i estils corporatius com a principals característiques, i una altre Bootstrap+AngularJS. Es pot accedir a aquestes aplicacions de demo a través dels següents enllaços:
- Aplicació client Canigó Mobile: exemple de llistat d’equipaments. Únicament utilitza el mètode GET per obtenir les dades (no requereix CORS).
- Aplicació client Bootstrap+AngularJS: exemple de CRUD d’equipaments. Utilitza els mètodes POST, GET, PUT i DELETE per interactuar amb servidor (requereix CORS).
S’envien credencials per els mètodes POST, PUT i DELETE donat que estan protegits amb autenticació bàsica. Mitjançant Bootstrap és possible fer un disseny responsiu (Responsive Web Design), fet que permet adaptar el lloc web a l’entorn de l’usuari. Per aconseguir-ho es basa en l’ús d’estructures, imatges fluides, i media-queries en la fulla d’estil CSS. Per altra banda, AngularJS és un framework Javascript que facilita el desenvolupament d’aplicacions web. Aquest segon client, Bootstrap+AngularJS, és un exemple que segueix les tecnologies HTML5 i CSS3, present i futur de les aplicacions web.
Destacar que el desacoblament entre client i servidor permet que dos equips de desenvolupament puguin treballar de forma independent. Únicament cal definir el contracte del servei REST. En una arquitectura on no existeix aquest grau de desacoblament cal incorporar el prototip que dissenya l’equip de frontal a les plantilles de servidor (Ex. Facelets a Canigó 3 o Apache Tiles a Canigó 2).
Per aquest comunicat hem redactat un HowTo on expliquem amb més detall com s’ha desenvolupat aquest exemple d’arquitectura moderna.
Notícies
- Desplegaments automatitzats a Tomcat 7 i Weblogic 12c
Seguint amb la certificació dels serveis que s’ofereixen des del CS Canigó als nous servidors del Full de ruta de CTTI, s’ha realitzat la tasca de certificació de desplegaments automatitzats des del SIC als servidors Tomcat 7 i Weblogic 12c.
Al Manual d’Integració es pot trobar la informació per sol·licitar dins l’alta d’una aplicació al SIC desplegaments automatitzats en entorns d’Integració sobre aquests servidors.