Editions ENI Livres | Vidéos | e-Formations
Architectures d’intégration
Paysage IT
Après avoir parcouru les chemins du développement purement applicatif, nous voilà confrontés à un nouveau changement d’échelle. Les systèmes d’information modernes sont protéiformes, de nouvelles briques technologiques viennent s’ajouter aux anciennes à un rythme effréné. Il devient nécessaire d’observer, de cartographier, d’urbaniser nos SI afin de rester compétitifs et surtout d’intégrer l’existant logiciel en y extrayant sa sève fonctionnelle.
On parlera donc ici d’architecture d’intégration. Un tel sujet demanderait plusieurs ouvrages pour être traité en profondeur tant il est vaste et ses ramifications nombreuses, c’est pourquoi nous nous contenterons de résumer les grandes lignes de force de ce type d’architecture et de renvoyer le lecteur avide d’approfondissement vers les ouvrages de référence.
1. Évolution des SI
Les DSI doivent aujourd’hui surmonter de nombreux challenges dans la gestion des infrastructures IT. Les entreprises doivent impérativement rationaliser leurs dépenses dans ce secteur et rester compétitives dans un milieu globalisé, donc soumis à une pression d’évolution extrême (au sens darwinien du terme). Il y a deux aspects sous-jacents à ces impératifs...
Architecture orientée services (SOA)
Nous allons maintenant définir les concepts basiques des architectures orientées services (SOA). Ce paragraphe se concentre donc sur les architectures d’entreprise (ou d’intégration) et leurs caractéristiques spécifiques.
1. Le concept de service
Le concept tout entier d’une SOA se focalise sur la définition d’une infrastructure métier. Quand nous utilisons le terme « service », nous avons à l’esprit un service métier tel que la réservation d’un billet de train ou l’accès à la base de données des clients d’une entreprise. Ces services proposent des opérations métier telles que prendre une réservation, récupérer un profil client, annuler une commande. Contrairement aux services métier et bien que très utiles, les services d’infrastructure technique tels que la gestion de la persistance, des transactions ou de la sécurité n’ont que peu d’intérêt stratégique au regard d’une SOA. D’une manière générale, la technologie ne devrait pas impacter outre mesure la structure de haut niveau d’une application et encore moins induire de dépendance entre les composants.
En réalité, une SOA doit découpler les applications métier des services d’infrastructure pour rendre l’entreprise indépendante d’une implémentation spécifique.
2. Vue d’ensemble
Une SOA est fondée sur quatre abstractions, comme le montre la figure suivante : l’application front-end, le service, le dépôt (repository) de service et le bus de service.
Figure 8.2 : Vue d’ensemble d’une SOA
Bien que le front-end applicatif soit propriétaire du processus métier, les services fournissent des fonctionnalités métier que les applications front-end ainsi que d’autres services peuvent utiliser. Un service consiste en une implémentation qui fournit logique métier et données, un contrat qui spécifie la fonctionnalité, l’usage et les contraintes pour les clients du service et une interface qui expose physiquement la fonctionnalité. Le dépôt stocke les contrats...
Technologies
Une SOA s’impose pour précepte l’ignorance des détails techniques, c’est-à-dire qu’elle se veut le plus universel et portable possible. Mais paradoxalement, pour parvenir à un tel degré d’indépendance, elle aura besoin de s’approprier un certain nombre d’outils et de standards technologiques de très haut niveau, le plus souvent auto-descriptifs. Ici, le XML, de par sa neutralité extensible, règne en maître. Il est à la base de toute une série de technologies utilisées dans une architecture de services (comme SOAP, WSDL ou BPEL).
De plus, la partie bus de services est souvent la plus délicate en termes de choix d’infrastructure car aucun standard n’est encore sorti vainqueur.
1. Systèmes distribués
La notion de système distribué n’est pas nouvelle. Elle n’est pas non plus l’apanage des architectures orientées services. Nous présentons ici trois grandes catégories de systèmes distribués : les architectures CORBA, les middlewares orientés messages et les serveurs d’application.
a. Objets distribués (ORB)
Parmi les premières architectures d’objets distribués est apparu CORBA dont le concept de référence est l’ORB (Object Request Broker) qui permet d’effectuer des appels de procédures distantes et d’échanger des données sous forme d’objets via des mécanismes de sérialisation/désérialisation (une sorte de RPC (Remote Procedure Call) orienté objet). Le formalisme d’échange de données est défini à l’aide du langage IDL.
interface Account
{
void createNewAccount();
void loadAccountDetails();
void markAccountClosed();
void retrieveAccountDetails();
void submitNewAccountDetails();
void validateUser(in String Password, in String UserName);
};
L’Internet Inter-ORB Protocol (IIOP) est une implémentation TCP/IP du protocole GIOP (General Inter-ORB Protocol) qui standardise les communications entre objets distribués.
