Modèle SOA vs ROA

Deux mondes s'affrontent : d'un coté l'informatique en Entreprise de l'autre l'informatique d'Internet destinée à l'utilisateur final.
La frontière n'est pas étanche ,et parfois des technologies se diffuse de part et d'autre, comme par exemple le web 1.0 et les services de messagerie.

Ce schémas illustre mon propos:





Il y a quelques années , le modèle SOA (AOS) était vu comme le modèle qui répondait au mieux au mouvement de la général de mondialisation (globalisation - restructuration ) . Une entreprise X rachetait une entreprise Y , elle devait pouvoir intégrer le système d'information de Y à moindre coût.
Dans un monde SOA , le service informatique 'rentre dans le rang' , il ne dicte plus ses lois (organisation, processus ) au reste des services.
Hélas les retours sur investissement est long ,difficile et hasardeux.

De l'autre coté du fossé , on trouve un autre monde en perpétuelle agitation avec des effets de mode, des coups de poker. Internet est massivement orienté 'ressources' (uri/url ). Plus le système est léger mieux c'est ! (KISS : Keep It Simple and Stupid).

On trouve donc deux philosophie : une prônant les services ,l'autre les ressources :



L'émergence des frameworks légers (en complexité pas en fonctionnalité offerte) comme Rails ou Django dans un premier temps sur Internet et maintenant dans l'entreprise est un signe fort qui n'est pas neutre dans le choix des statégies à mettre en place.
Les applications RestFull (à base de CRUD , AJAX ) sont les seules à pouvoir offrir à l'entreprise un ROI rapide et sûr. Elles evitent les effets tunnel d'un projet qui sera terminer et qu'il faudra immediatement modifier pour plaquer aux évolutions. Les entreprises doivent se préparer à la vague déferlante du WEB 2.0 dans l'entreprise et commencer à se familiariser avec le SAAS (cloud) qui est massivement SAAR (R comme ressource) .
(ici un comparatif Rails/django ). La cote de popularité des langages illustre mes propos : Javascript à le vent en poupe , ainsi que Python , Ruby et PHP (qui n'a pas encore son killer framework ), alors que JAVA piétine voir le The TIOBE Programming Community index.

SOA :partie 2

Dans le premier post sur SOA , j'avais énuméré les différents composants d'une architecture SOA.

Je vais exposer maintenant comment développer une application sous SOA et quel sont les questions à poser pour déterminer si votre organisation est faite pour le SOA

Développer une application SOA .

Une application SOA est un agrégat de d'interaction entre des composants. L'écriture des composants ressemble au développement d'un web service. Mais se qui change c'est le déshabillages composants au profil de la base de registre. Un composant doit etre 'basique' , il doit embarquer le moins d'intelligence possible. Cette intelligence doit être stockée dans la base de registre et l'évolution du traitement métier du composant se fera par la gouvernance de cette base de registre.
On ne parlera pas de mise en oeuvre d'une application mais de la modélisation d'un processus métier par des outils de BPM (Business Process Management) .
Ces outils BPM sont connectés avec la base de registre , le moteur de workflow et le gestionnaire de version.

Questions à se poser avant d'attaquer le SOA.

1) Votre secteur d'activité est-il large et complexe ?
2) Votre secteur change-t-il rapidement ?
3) Vos applications cachent elles des richesses ?
4) Avez vous une architecture informatique flexible ?
5) Comment votre entreprise réagi aux changements ?
6) Les services sont ils interdépendants ?
7) Utilisez vous des technologies propriétaires ou des standards ouverts ?
8) Savez vous où sont vos règles de gestions ?
9) Avez vous confiance dans l'adaptation et la qualité de vos données ?
10) Pouvez vous connecter votre système avec celui de vos partenaires ?


Si vous avez une majorité de 'OUI' vous etes SOA ready .

SOA , féderation d'identité et gouvernance

A la suite de mes lectures sur le SOA et des echanges riches sur ce thème , j'ai réalisé cette 'big-picture' où sont representé les differents processus de gestion et les composants relatifs àla gestion d'identité. Dans une architecture SOA cette fédération peut etre utilisée pour les personnes mais aussi pour les composants entres eux par le biais d'empreinte et de signature.

SOA partie 1

SOA pour les nuls .



Voici je que j'ai retenu de ce livre :

Qu'est qu'une architecture SOA ? :

Une Architecture Orientée Service est une architecture logicielle permettant de construire des applications correspondant à des processus métiers par assemblage 'lache' de composant.


* SOA est fait pour batir des applications de gestion
* SOA est une boite noire , SOA masque la complexité d'un SI et facilite le branchement de nouveaux composant à cette boite noire.
* Les composants SOA sont reliés entres eux par un couplage 'lache' . Cela veut dire qu'il est non seulement possible de remplacer un composant par un autre mais aussi que le nouveau composant peut avoir une interface ou une invocation différente .
* Les composants sont agencés entre eux de manière à fournir un service bien précis correspondant à un processus métier.

Le SI prendra la forme d'un ensemble de composants organisés autour d'un bus applicatif appelé ESB : Entreprise Service Bus.
L'ESB est le tuyau par lequel les messages circulent d'un composant à un autre.

En plus des composants applicatifs , on trouvera un certain nombre de composants spécifiques comme :

* Le SOA registry
* Le moteur de workflow
* Le service broker
* Le superviseur

Le SOA registry est une sorte de base de registre , ou de catalogue où sont stocker les descriptions des composants. Il est utilisé par le broker comme annuaire de référence , mais aussi par les développeurs d'application comme référentiel des composants. Il stocke la descriptions des composants , la façon d'y accéder et les règles de fonctionnement. C'est dans le registry que sont publié les services. On peut utiliser pour cela un annuaire des services (UDDI Registry)

Le moteur de workflow est le composant responsable du bon acheminement des messages par l'ESB.

Le broker est le composant qui permet la mise en relation des composants entres eux.

Le superviseur : c'est le grand chef d'orchestre et aussi le surveillant du bus. Il a la possibilité de communiquer avec des couches plus basses. Il est aidé dans sa tache par des 'agents' qui supervisent les composants.

Cinématique d'une transaction.
Exemple :le composant A désire envoyer un message applicatif au composant B.

* Le composant A va envoyer une requête au broker en lui indiquant sa demande.
* Le broker va lancer une recherche auprès du Registry pour connaitre le composant B à activer et comment le solliciter.
* En réponse du registry le broker va connecter les composants A et B.
* Le composant A va envoyer son message à B.

Chaque composant est doté d'un 'adaptateur' . Cet adaptateur fait l'interface entre le composant et le bus applicatif , un composant peut posséder plusieurs d'accès. Ces méthodes seront exposées dans le Registry.
Exemples d'adaptateur

* Web service : on accède au composant par le protocole HTTP(S)
* Terminal adaptateur
* Connecteurs SQL
* Connecteurs dédiés (LDAP, CORBA,SOAP)

Le composant 'Registry' sert donc à :

* Stocker les descriptions des interfaces
* Les définitions des processus métiers
* Les règles de gestion de ces processus métiers
* La description du niveau de service
* Les règles de gouvernance

Tout ceci forme les métadonnées, ces métadonnées seront exploitées par le Broker

Le Broker va réclamer au Registry les métadonnées des composants pour pouvoir les faire dialoguer entres eux.
Les composants ayant un adaptateur SOAP expose le plus souvent leur interface par le biais du protocole WSDL (Web Service Description Language) . Par ce langage les web service expose ses conventions de connexion , de syntaxe de message et de typage de données . Toutes ces informations sont reprisent dans le UDDI Registry (Universal Description ,Discovery , and Integration) .

Le bus des services (ESB).
Il sert à connecter les composants métiers et techniques, et gère notamment :

* Le service des messages applicatifs
* La validation des messages
* Le transport des messages
* Le transcodage des messages
* La sécurité (intégrité, encryptage)

Enfin il doit etre capable de gérer des niveaux de priorités des massages et doit s'adapter aux performances globales.

La cuisine du SOA et du Mashup (05/04/2008)

J'ai reçu un article d'olivier Picciotto sur les notions de SOA et de Mashup (alliés ou ennemis) .

Qu'est ce que le SOA : Service Oriented Architecture
En clair (pas plus que ça) : On découpe le système d'information d'une entreprise en composant fonctionnel (ATTENTION pas Technique) . Chaque composant doit être autonome , il a donc :
Une interface publique (pas dans le sens GUI ) et des règles d'accès et de fonctionnement (contrat de service) .

Un composant n'a pas d'interface graphique , il communique avec le reste des composant grâce à des messages . Un utilise le plus souvent le protocole SOAP et le XML pour la partie communication.

On parle souvent d'un fournisseur de service et d'un consommateur de service . On parle aussi de couplage faible (aussi appelé couplage léger ou encore couplage lâche) entre les composants. En effet plus le couplage est faible moins il y aura de contrainte ou d'adhérence etre eux. On pourra ainsi remplacer facilement un composant par un autre . Les composant ne sont pas branchés directement sur un bus applicatif (middleware).

Le mashup : traduit par 'bouillie' , compilation . Est un système qui permet de regrouper , d'agréger plusieurs sources de données en une seule. Exemple: j'ai un réseau social sur facebook , un compte sur myspace un compte mai sur google , je vais pouvoir disposer sur une seule page l'ensemble de ses sources de données . C'est déjà ce qui propose le site français Netvibes. Le marshup est un composant base de ce qu'on appelle le web 2.0 .
Le web 2.0 repose sur :
- L'utilisation d'ajax
- Le partage des programmes et des données
- Les blogs et les flux RSS

Donc SOA et le mashup sont deux notions complémentaires et dans cette approche le service de gestion d'identité et d'authentification (SSO) prend une dimension fédératrice.