SeminaireSOA
vendredi 28 septembre 2007
Le séminaire SOA en Action de Softeam du 27 septembre 2007 se découpait en 4 parties:
- présentation de Softeam et des offres
- présentation de la méthode ouverte Praxeme
- approche SOA et présentation de l’atelier objectering
- retour d’expérience sur les projets d’intégration réalisés chez Softeam
- le projet du groupe smabtp
Softeam
De part son passé, Softeam est naturellement très orienté objet et UML. L’approche SOA qu’ils ont choisi est MDA, c’est à dire une génération du code et modélisation des processus métiers à partir d’UML par l’enrichissement de stéréotype. Une approche MDA qui met en avant l’aspect conception des applications et des processus métiers. Selon eux, SOA par MDA permettrait de faire la liaison entre la MOA et la MOE et de rendre l’Architecture d’entreprise (EA) plus agile.
Présentation de la méthode Praxeme
Cette méthode nous a été présentée par Dominique Vauquier fondateur de l’initiative. Praxeme est présentée comme une méthodologie d’entreprise qui prend en compte tous les aspects:
- recenser toutes les informations à traiter, les décisions à prendre, les représentations à élaborer
- transformer la stratégie de l’entreprise, les fondamentaux de son métier, ses processus, son organisation, son outil informatique, sa géographie
La méthode Praxeme permet de répondre aux besoins des projets SOA en permettant de trouver les services, de définissant une bonne architecture, en liant l’urbanisation de SI et la conception détaillée des services. La représentation de l’entreprise peut se décliner en plusieurs aspects:
- Sémantique
- Pragmatique
- Logique
- Technique
- Matériel
- Géographique
- Physique
La cycle Praxeme suit la dynamique suivante:
- analyse stratégique
- vision
- conception globale
- consolidation
- surveillance
Approche SOA et utilisation d’Objectering
- La MOA est concernée
- Le SI est aligné sur les métiers
- Le système est agile, rapidité de prise en compte des évolutions métiers
- L’interopérabilité du systèmes, coopération entre organisations
- La MOA doit participer à la définition des services
- L’approche SOA impacte l’urbanisation des applications, et l’approche d’architecture d’entreprise
- Permettre la connaissance collective
- Assurer la continuité MOA / MOE
- Supporter une cartographie applicative basée sur les services et composants de services
Les outils et techniques de représentation pour la MOA:
- Dictionnaire: termes et définitions pertinentes relatifs au système
- Analyse des besoins et des exigences
- Approche systémique: représentation globale du système présent et futur
- Modélisation des processus métiers
- Règles métier
- Cas d’utilisation
- Modèle conceptuel
- Supporter les problématiques des diverses intervenants
- Offrir des représentations: centrées sur les problèmes de chaque acteur, compréhensibles et acceptées par les acteurs
- S’appuyer sur les normes: UML, BPMN, …
Avec Objectering, on modélise tout suivant les aspects Praxeme. Les modèles correspondent au référentiel du SI. Ils permettent de générer la documentation, le code grace à la définition d’entités et de la réalisation de modèles BPMN
Retour d’expérience sur les projets d’intégration réalisés chez Softeam
Les projets n’étaient pas réellement des projets SOA au sens profond du terme mais juste une abstraction d’une couche métier pour une application. Oui certes, une partie des services encapsulait des services de technologie ancienne. On faisait déjà ça avec les EJBs en 2000 ! Une architecture SOA va bien plus loin, car on le sait, la grande force de SOA est d’ouvrir le SI, de standardiser les échanges entre partenaires et de permettre une transparence entre les systèmes et la technologie utilisée (interopérabilité). Les problèmes majeurs de SOA sont les conséquences de son avantage. La standardisation induit une demande forte en sécurité et en performance. Ils est à noter que tous les projets n’utiliser pas des Web services car peu performants à cause de la sérialisation et désérialisation du XML. Oui mais pourtant, on aurait pu en parler, il existe d’autres technologies comme REST qui sont performantes, standards et simples, l’alternative n’est pas forcément du côté des EJBs (oui pas d’EJB s’il vous plait).
Retours sur le projet SMABTP
Une excellente présentation de Jean Michel Detavernier DSI adjoint de SMABTP qui avait l’avantage d’être concrête, 5 ans de SOA qui peut en prétendre autant en France ? Une approche très intéressante qui montre que le SOA est progressif et passe par plusieurs étapes:
- revamping de l’existant
- externalisation des règles et paramêtres des systèmes existants
- re-développement avec externalisation des règles et des paramêtres
Ceci se traduit par deux phases:
- une phase d’approche technologique: buttom up, évolution de l’architecture, des règles dans le code
- une phase d’approche métier: refonte d’une partie du SI, définition d’une méthodologie, prise en compte de la conception des paramêtres et des rêgles.
Quelle est l’architecture finale ?
- Un bus applicatif contenant les services transverses d’infrastructure: échanges de données avec les partenaires (WBI), Moteur de règles, Editique, Portail, Habilitation
- Des services métiers forte maille: recouvrement, sinistres, polices
Un point très intéressant qui a été soulevé par Jean Michel Detavernier est qu’il n’a aucun moyen de pouvoir tester ses services de façon unitaire, c’est à dire en pouvant controller le contexte du composant et de vérifier les appels aux composants dont il dépend.
Conclusion
Je trouve l’approche Praxeme intéressante sur un point: elle permet de voir le SI sous 7 aspects, c’est interessant à présenter à des DSI. Par contre MDA ne me séduit pas du tout pour plusieurs raisons, il induit:
- un gros effort de conception
- du temps passé pour de la conception qui au final peut être inutile
- de la documentation qui ne sera jamais lue et validée
- des clients non formés à UML
- des développeurs non formés à UML, s’ils connaissent déjà le langage de programmation, c’est déjà une très bonne chose
- un code généré non maitrisé car non testable
Comment fait on pour tester un modèle ? Comment peut on construire une application agile si on n’a pas définit les tests au préalable. Comment fait on du refactoring de modèle sans avoir des tests automatiques sur le code. Bon OK, on écrit des tests sur du code pour tester nos modèles, mais en fait c’est le code qu’on teste et pas les modèles, bref à quoi ça sert les modèles ? A parler à une MOA, à faire réflechir la MOA, à lui donner des jouets pour qu’elle s’amuse ;) Est ce que ça ne suffit pas à la MOA d’avoir une barre verte qui lui dit que son SI fonctionne comme souhaité ?
Comme il existe le développement guidé par les tests (TDD), n’est il pas possible d’avoir l’architecture guidée par les tests (TDA) ? Un composant n’est qu’une classe Java à plus grande échelle. En TDD, chaque classe est testée de manière unitaire de façon automatique indépendamment des autres interfaces grace à des mocks objects.
J’ai bien aimé la réponse à la question: “Peut on faire du SOA avec les méthode agiles ? ”
“Non les méthodes agiles, c’est pour les petits projets (hé oui Patrice, petit projet :o)), c’est pas professionnel, c’est pas documenté”.
Attention l’urbanisation de SI c’est pas pour les artisants ;)
C’est tellement amusant de voir pourtant que les projets utilisent des produits hautement agiles comme Spring issus de programmeurs extremes ! (Spring ne fait pas de l’objet, chuttt …, faut pas le dire trop fort, les UMListes pourraient sévir). Trève de plaisanteries, pour moi la modélisation UML n’a un intérêt que pour du reingeniering et donc avoir une vue statique du code mais pas pour la génération de code, c’est déjà assez compliqué comme ça, les applications souffrent déjà d’un manque de qualité car les entreprises ont décidé qu’un développeur ça ne coûte pas cher et donc c’est les débutants sortis de l’école qui codent. En plus, on demande aux développeurs qui sont de plus en plus débutant de connaitre un niveau langage UML. Non me dira t’on, c’est des concepteurs qui feront le travail, alors on se retrouve encore dans un système de castes hiérarchiques où la communication n’est pas mise en avant, où le concepteur aura raison du développeur. Faisons travailler notre cerveau droit de temps en temps et arrêtons de faire travailler notre cerveau gauche, soyons pragmatique, efficace, concrêt, tourné vers le client et pas vers les modèles, aidons les clients … Aidons la MOA à faire son métier: améliorer le métier et non à l'impliquer dans des modèles à la fois fonctionnelles et techniques, dans une conception où elle se perdra :(
Réfléchissons deux minutes, est ce qu’une DSI n’est pas au service des autres directions ? Si.
Qu’attendent les autres directions de la part de la DSI ? Que ça marche. Les modèles et les spécifications jamais à jour à quoi ça leur sert ? Rien
La DSI a besoin de se rassurer sur ses applications ? Oui.
Qu’est ce qu’a besoin la DSI ? D’une barre verte … les agilistes m’auront compris …
Un peu de lecture sur le métier d’architecte
Un bon architecte est plus un développeur sénior qu’un concepteur. Un architecte est capable de dire ce qui marche et ce qui ne marche pas, il conduit une équipe de développeurs vers des choix technologiques qu’il a éprouvé, pour ceux que ça intéresse de comprendre le métier d’architecte je vous conseille de lire ce livre The J2EE Architect's Handbook. Pour ceux qui ne l’ont pas lu, vous verrez c’est une vision très différente du métier d’architecte tel qu’il est perçu en France… Ha la France … Ha Merise … Tant de nostalgie … ;)
publié par Jeff Helie à
01:19
0 commentaires
