Présentation de l'architecture

L'architecture d'IBM® UrbanCode Deploy se compose d'un niveau services et d'un niveau données.

Le niveau services dispose d'un serveur central qui fournit les services frontaux et de base d'un serveur Web, tels que flux de travaux, gestion d'agents, déploiement, inventaire, sécurité et autres. Un service peut être considéré comme un mécanisme indépendant pour héberger une partie de la logique métier. Les services peuvent être utilisés par des clients, des agents, ou d'autres services. Les déploiements sont orchestrés par le serveur et exécutés par des agents répartis sur le réseau. La plupart des agents utilisent des navigateurs pour communiquer avec le serveur Web via HTTP(S). La majorité de la communication serveur-agent est effectuée via JMS (voir discussion ci-dessous) mais HTTP(S) est également utilisé lorsqu'il est requis.

La base de données relationnelle du niveau données stocke les données de configuration et d'exécution. La librairie de fichiers du niveau données, CodeStation, contient les fichiers journaux, les artefacts et d'autres objets de données non structurés. Les outils de génération de rapports peuvent se connecter directement à la base de données relationnelle.

Diagramme d'un système usuel, affichant le niveau données, le niveau services et les clients Cliquez sur cette zone pour plus d'informations sur les clients. Cliquez sur cette zone pour plus d'informations sur le niveau services. Cliquez sur cette zone pour plus d'informations sur les agents. Cliquez sur cette zone pour plus d'informations sur le niveau données.

IBM UrbanCode Deploy utilise des communications sans état pour les communications de service serveur-agent (basées JMS) et client-Web. Sans état, dans ce contexte, signifie que le serveur ne conserve que peu d'informations de session entre les demandes et que chaque demande contient toutes les informations nécessaires pour la traiter. Le serveur configure des sockets en mode écoute et reste à l'écoute des agents, des relais et des utilisateurs (clients). Pour plus de sécurité, les agents ne sont pas à l'écoute sur les ports. Les agents envoient des demandes lorsqu'ils sont prêts pour la transition vers un nouvel état.

La communication serveur-agent est construite autour du transfert, ou déploiement, de composants. Les composants peuvent contenir n'importe quel contenu pertinent à l'activité, tel que des informations sur l'environnement, les données de configuration, la source, les fichiers statiques, ou tout autre élément associé à un projet logiciel. Etant donné que les connexions JMS sont persistantes et ne reposent pas sur un protocole de demande-réponse, IBM UrbanCode Deploy n'a pas à ouvrir et à fermer continuellement des ports. Ces connexions persistantes permettent au serveur de communiquer en tout temps avec les agents tout en ménageant la sécurité et l'évolutivité de ces agents.

De nombreux services IBM UrbanCode Deploy sont de type REST (Representational State Transfer). Les services REST sont des services Web qui se consacrent au transfert de ressources via HTTP. Une ressource peut être n'importe quel élément de données pertinent à l'activité. Les ressources sont transférées par un format auto-descriptif, tel que XML ou JSON (JavaScript Object Notation). Les représentations XML et JSON modélisent généralement les états des ressources au moment des demandes agent-client. Les services REST peuvent opérer sans état en assurant que les demandes incluent toutes les données requises par le serveur pour produire une réponse cohérente.


Vos commentaires