glossaire

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Cette technique est une combinaison de :

• XHTML (ou HTML) et CSS pour le style et la présentaion.
• un modèle objet de document (DOM) accédé par un langage de script comme les mises en oeuvre de ECMAScript telles JavaScript ou JScript pour afficher et interagir avec l’information consultée.
• Un objet XMLHttpRequest pour échanger des données de manière asynchrone avec le serveur web. Dans certains frameworks Ajax dans certaines situations, un objet IFrame est utilisé à la place d’un objet XMLHttpRequest.

Et optionellement AJAX peut utiliser :

• Le format XML pour transférer les données
  entre le client et le serveur, mais d’autres formats sont possibles tels le HTML préformatté, le format texte, le format JSON et même le EBML.
• Le format SOAP.

Les applications Ajax/HTML :

1. gèrent l’état de session principalement sur le serveur.
2. génèrent la plus grande partie de l’interface utilisateur sur le serveur.
3. Rafraîchissent fréquemment les pages d’interface utilisateur pour maintenir l’état de la session ou pour générer des parties d’interface utilisateur
4. Communique principalement au moyen de d’invocations de CGI ou de Servlet.
5. Peut être dégradé pour des navigateurs qui ne supportent pas ou qui n’ont pas activé le javascript.

Une application est un programme ou un ensemble de programmes permettant la saisie, la mise à jour, la recherche et la consolidation des données entrant dans la réalisation d’une ou plusieurs activités d’un métier de l’entreprise ou d’un utilisateur.Cela comprend les logiciels de productivité personnelles tableurs, traitement de texte, gestionnaire de base de données,…), les programmes spécifiques de paie, de facturation, de gestion des stocks ou comptabilité.

Une application est composée d’un ou plusieurs modules fonctionnels, chacun prenant en charge un ensemble de services.Les applications échangent des flux de données afin de diffuser ou de recevoir les événements et les changement d’états leur permettant de tenir à jour leurs données.

Une application est également constituée de composants techniques fournissant les fonctions techniques nécessaires à la réalisation des services.Ces composants fournissent les fonctions techniques de présentations, les fonctions techniques exécutant la logique métier, les fonctions techniques de communication pour réaliser les interfaces avec les autres applications.

Entrées liées : Architecture applicative, architecture 3-tiers, composant applicatif

Client/SOA est une variation composée de Client/Server et SOA qui désigne une architecture au sein de laquelle le composant client est un navigateur web et le serveur un fournisseur de web-services dans un style SOA. L’architecture Client/SOA est une réelle architecture client/server centrée sur la mise en oeuvre de web-services.A côté de la notion de client lourd ou de client léger, Client/SOA définit un client athlétique.

Dans ce style d’architecture, le navigateur est un composant autonome qui peut accéder et composer les données d’un ou plusieurs web services. Client/SOA promeut la mise en oeuvre d’un portail prenant en charge les fonctionnalités nécessaires au client pour accéder et composer les services.Une application Client/SOA ne doit pas requérir une gestion de session sur le serveur, elle supporte les caches de données locaux et les opérations offline.

Un Client/SOA a les caractéristiques suivantes :

1. Gére l’état de la session principalement (pas entièrement) au sein du client.
2. Génère la plus grande partie (pas entièrement) de l’interface utilisateur au sein du client.
3. Rafraîchit rarement les pages pour maintenir l’état de la session ou pour générer des parties d’interface.
4. Communiquer principalement en utilisant XML ou des web services API basés sur JSON.
5. Requiert une machine virtuelle Javascript.Dans le cadre de Client/SOA, les appels aux web services peuvent être comparés à des appels de « procédures stockées » invoquées par le client, d’où le paralléle avec l’architecture client/serveur classique.

L’architecture Client/SOA a été définie initiallement par Scott Shattuck, architecte logiciel de Technical Pursuit Inc., créateur de TIBET, framework Client/SOA, comme un moyen de décrire la différence entre des sites internet ou intranet Ajax et des applications d’entreprise dont la plate-forme de déploiement est un navigateur web.

Liens : Projet archimate,SOA , AJAX

5 Caractéristiques essentielles : self-service à la demande, large accès réseau, regroupement des ressources, elasticité rapide de l’offre, services supervisés.

3 modèles de service : Software as a Service, Platform as a Service, Infrastructure as a Service

4 modèle de déploiement : Privé, Communautaire, Public, Hybrid

Liens : Nist

L’event driven architecture (EDA) est une architecture logicielle qui définit comment des systèmes peuvent être conçus pour détecter les événements et y répondre. Un événement peut être défini comme « changement significatif d’état ». Les changements d’état d’objets lorsqu’ils sont significatifs génèrent des événements.Dans certains cas, on appelle cela un signal.

Le style d’architecture EDA définit une méthodologie pour concevoir et mettre en application des applications et les systèmes dans lesquels les événements sont transmis entre les composants logiciels. Un système EDA est typiquement composé de consommateurs et de producteurs d’événements. Les consommateurs d’événement souscrivent à un gestionnaire intermédiaire d’événements, et les producteurs publient vers ce gestionnaire.Quand le gestionnaire d’événement reçoit un événement d’un producteur, le gestionnaire le fait suivre vers le consommateur.

Si le consommateur est indisponible, le gestionnaire peut stocker l’événement pour l’expédier plus tard. Cette méthode de transmission est appelée « store and forward ».L’architecture EDA permet de construire des systèmes plus souples, plus réactifs. Elle complète l’architecture SOA puisque les services peuvent être déclenchés par les événements.

On distingue 3 type d’événements :

• les événements simples consécutifs à des franchissement de seuils (montants, température,…)
• les événements de flux consécutifs au pilotage du filtrage et du routage de flux d’information au sein et autour de l’entreprise
• les événements complexes combinaisons des 2 types précédents, basé sur la reconnaissance de patterns

Liens : Projet archimate, SOA

Les flux de données sont des représentations techniques de l’information. Dans certains cas ce sont des messages, dans d’autres ce sont simplement des données représentant une information qui alimentent un ou plusieurs processus.

Le concept de message recouvre pleinement la notion de flux de données, car un message est un événement notifié à un processus avec des données représentant une information.

Dans le cas d’un flux simple de données, l’événement est implicite, quand il s’agit de flux de type message, l’événement est toujours spécifié.Ainsi les flux de données ne servent pas seulement à alimenter les processus, mais également à les synchroniser.

La question de la gouvernance se pose dès lors qu’un tiers administre une organisation pour le compte du détenteur légitime de l’autorité.La démarche de Gouvernance s’appuie sur les deux piliers que sont le pilotage et le contrôle.

En effet, le pilotage répond à la question de la mesure de performance, il donne un retour sur l’efficience de l’organisation.Le contrôle assure que les activités sont exécutées conformément aux intérêts et à la stratégie de l’autotrité légitime, et notamment que l’organisation ne lui fait courir de risques autres que ceux qu’elle a librement accepté de porter.

Pour les économistes, l’information est une vision plus ou moins fine des différents états que peut prendre la nature dans le futur. Plus linformation est fine, plus elle permet, dès aujourdhui, de prendre des décisions adaptées aux situations futures.Pour les statisticiens, linformation dérive des séries de données qui, lorsquelles montrent une proximité régulière de la moyenne (variance), sont réputées contenir davantage dinformation.

Pour les cogniticiens, l’information surgit du simple fait de la communication entre deux êtres. Basée sur des signes physiques, l’information est un objet qui transforme une connaissance représentée (la sémantique), qui constitue le modèle mental du receveur.

Pour les hommes de communication, l’information provient d’une organisation des signaux échangés entre un émetteur et un récepteur (negentropie) à travers un canal de communication. Cette théorie développée par C.SHANNON a permis en outre de mettre en valeur le rôle du canal qui, affectant la forme physique du message, a un impact sur sa signification et son interprétation.

Un message est un ensemble de signaux captés ou exposé au système d’information qui lui permet de détecter un changement d’état de son environnement ou de l’organisation, et de modifier ses représentations. (voir Signal)

Representational State Transfer (REST) est un style d’architecture logiciel destiné aux systèmes hypermédia distribués comme le Web. L’origine de REST provient de la thèse de doctorat (2000) de Roy Fielding, un des principaux contributeurs à la spécification du protocole HTTP.

REST repose sur les principes suivants :

• Les états des applications et les fonctions sont divisé en ressources
• Chaque ressource est adressable au moyen d’une syntaxe universelle. Pour le protocole HTTP, c’est la syntaxe URI.

Chaque ressource possède une interface uniforme pour publier son état vers les clients. Cette interface consiste :

• Un ensemble d’opérations définies. HTTP definit un ensemble de méthodes dont les plus importantes sont POST, GET, PUT et DELETE. (autre exemple CRUD pour la persistance de données, ou plus simplement Cut and Paste)
• Un ensemble de type de contenus définis. Pour HTTP, C’est le standard MIME. Chaque ressource peut publier son état ou accepter une demande de changement d’état dans une des représenttaions définies.
• Un protocole sans mémoire entre client et serveur : pour exemple, chaque message HTTP contient toute les informations de contexte nécessaire au traitement de la requête.

Ainsi ni le client, ni le serveur n’ont la nécessité de maintenir la persistance des états précédents. Cependant, pour des raisons fonctionnelles, beaucoup d’applications utilisent les cookies pour obtenir une persistance de session. Elles ne sont alors pas considérées comme de type REST. Le protocole doit supporter le caching, pouvoir s’insérer dans une architecture en couche, supporter les mécanismes de code-on-demand (ex: java package).

Liens : Projet archimate, SOA

La fiche thématique du Club Urba EA distingue 2 types de référentiels : les référentiels contenant les données de production (Client, Contrat, Produits,…) et ceux contenant les nommenclatures.A cela, il faut rajouter les référentiels de gammes ou d’opérations qui contiennent les règles ou les process qui s’appliquent aux objets des catégories précitées.

Finalement, les référentiels contiennent les objets qui représentent les organes de l’entreprise et de son environnement ainsi que leurs caractéristiques. Les gisements de données opérationnelles enregistrent les changements d’états de ces objets au cours de chaque opération effectuée par l’entreprise.

Un service est constitué d’un ensemble d’opérations cohérentes et liées exécutées par une ressource organisationnelle (acteurs) ou technique dans le cadre d’un rôle au sein d’un ou plusieurs processus métiers ou techniques.La notion de service est un concept de base de l’Architecture d’Entreprise.

Un « service » doit être défini au sein d’un catalogue, le catalogue de services.

Cette définition se compose :

1. Une définition explicite et détaillée illustrée par un modèle de processus et l’articulation du service au sein des processus.
2. Un ensemble d’indicateurs d’exécution qui définissent des paramètres de mesures/exécution tels que la disponibilité, le temps de réponse, la charge d’exécution, etc…
3. Un lien avec le modèle d’information de l’entreprise, mettant en évidence quelle information le « service » possède (création, mise à jour, effacements) et quelle information le service utilise comme référence.
4. Une liste des consommateurs connus et habilités ainsi que les conditions d’utilisation.

Liens : Projet archimate, SOA

L’architecture dite Service Oriented Architecture est un style d’architecture plus qu’une démarche. D’ailleurs, l’identification des services est une des composantes du problème à résoudre par l’architecte, lors d’une conception d’un Système SOA.

Le modèle de référence standard de SOA a été spécifié par l’OASIS..

SOA est un style d’architecture logiciel proposé par initialement en 1996 par Roy W. Schulte et Yefim V. Natis qui étaient analystes au Gartner. Il est basé sur le principe selon lequel un système est défini à partir de la structure des interfaces de ses composants, ainsi que de la réalisation des fonctions et des appels d’interface. SOA aurait pu être appelé « architecture orientée interfaces ».

Cependant SOA va bien au-delà en spécifiant des rôles de modules producteurs de services et les modules consommateurs de services d’interfaces. Le consortium OASIS en donne la définition suivante : « un ensemble de concepts pour organiser et utiliser des capacités distribuées qui peuvent être sous le contrôle de domaines appartenant à différents propriétaires. » Une capacité d’entreprise est un ensemble de compétences, de processus et de systèmes constituant un savoir-faire d’une entreprise donnée.

Par exemple, SOA  est particulièrement adapté pour répondre aux besoins d’interaction dans un cadre multicanal et multiterminal, comme la CRM et la mobilité.

SOA 2.0 est une extension de SOA qui ajoute le concept d’EDA (Event Driven Architecture). Alors que SOA offre un support aux transactions requêtes réponse, EDA apporte le support de transactions métier longues et asynchrones.

SOA repose sur les principes suivants :

• ?Réutilisation, granularité, modularité, capacité à être composé, capacité à être mis sous forme de composants, et interoperabilité
• ?Conformité aux standards
• ?Identification des services : identification, categorisation, fourniture et délivrance, supervision et traçabilité

Au sein de SOA, les services ont les propriétés suivantes :

• ?Encapsulation : la logique est accédée et vue à travers les interfaces
• ?Couplage lâche : les interfaces sont conçues pour minimiser la dépendance entre les composants du système
• ?Contrat de service : les opérations du services et leur caractéristiques (temps de réponse, charge, sécurité) sont publiées et respectées
• ?Réutilisabilité : Les services sont conçus dans le but de promouvoire la réutilisabilité
• Capacité à être composé : Les ensembles de services peuvent être coordonnées et assemblés pour former des services composites
• ?Autonomie : Les services sont autonome quant au contrôle et à la supervision de leurs opérations
• ?Sans mémoire : Les services minimise la maintenance d’information à propos de leurs états passés
• ?Découvrables : les services sont conçus pour publier leur description, leur localisation et leurs conditions de déclenchement
• En outre la définition des services doivent inclure :

• ?la gestion de leur cycle de vie
• ?l’usage efficient des ressources
• ?Maturité et performance

Souvent, les Webservices sont cités comme étant une mise en œuvre de SOA. S’ils peuvent constituer une technologie fournissant une brique de base, ils sont incapables de fournir la sémantique métier nécessaire pour mettre en œuvre le couplage lâche et la cohésion fonctionnelle de SOA.

Cette sémantique métier peut être définit en mettant en œuvre des méthodes de conception comme la Méthode Praxème,la méthode Archimate.

Pour définir la hiérarchie des services d’un système d’information SOA, l’architecte doit s’inspirer du modèle IIIRM du TOGAF.

Liens : Projet archimate,EDA