Transmis par: webmaster actif Lundi 17 Novembre 2003 à 00:35
Dans cet article de 22 pages, Julien Brunet réalise un authentique exploit : celui d'illustrer la mise en oeuvre d'une démarche SOA à travers l'enrichissement d’une application déjà connue d'entre vous : Le PetShopDNG. L'exercice est d'autant plus intéressant qu'il part du modèle d'origine pour en extraire d'éventuelles contradictions. Au delà du simple exploit technique, ce document est une mine d'or pour celui qui cherche à comprendre les relations existant entre Orienté Objet et Orienté Services, deux approches naturellement complémentaires. D'ailleurs, vous constaterez que le design n-tiers initial du PetShopDNG 2.0 a sensiblement facilité la démarche d'adaptation en modèle SOA. Bravo Julien, maintenant le débat est ouvert !
Je tiens à féliciter Julien pour la qualité de cet article. Je me suis bien régalé à la lecture, une 2ème est envisagée.
Julien, tu parles de schémas (XSD) pour les contrats de tes services mais en aucun cas, tu en parles ? Est-ce qu'il faut la couche de présentation ? Dommage qu'il faut attendre la version de ASP.NET 2.0 pour la couche de présentation ??? En soi, la version actuelle n'est-elle pas faite pour marcher sur le PetShopSOA ?
Concernant, le WebFacade, il est un peu trop intelligent à mon gout ! Pour 4 services, ça peut être acceptable mais si tu as une centaine ?
De plus, tu le couples avec ton controlleur de UI (NextViewToDisplay), je m'attendais plus à avoir la notion de Context d'utilisateur en jeu ?
Re: Le PetShopDNG 3.0, l'Architecture Orientée Services en action
par precchia actif 17 Nov 2003 à 09:41 (Profil Utilisateur | Envoyer un message)
Allez allons y de la plume pour féléciter ces articles (MSDN, ...) de ces derniers jours ayant pour propos la SOA.
La démarche pédagogique est viable et cette série d'articles constitueront sûrement un guide de référence de qualité. Julien a rédigé une partie "Fondamentaux SOA" à annexer dans tous nos documents.
Par contre, le hic à cette soaisation du petshopDNG est qu'elle est (parait ?) simple. La conception des services est largement accessible. Et la je m'arrete car le problème est que ce premier article est présenté comme un mise en bouche ... D'où quelle sera la suite : Allez vous modéliser les différents processus d'achats en lignes d'animaux ? Quels seront les autres services techniques (sécurité, ...) ? La SOA permet de part l'autonomie des services de capitaliser, ce que nous pourrions voir c'est la publication d'un service d'authentification réutilisable par tous ...
Re: Le PetShopDNG 3.0, l'Architecture Orientée Services en action
par Anonyme actif 17 Nov 2003 à 09:57
Enfin du concret,
A ma connaissance, le premier exemple de refonte d'une architecture avec SOA et d'application pratique des 4 dogmes Donboxien.
Merci Julien
Patrick Smacchia
Re: Le PetShopDNG 3.0, l'Architecture Orientée Services en action
par Anonyme actif 17 Nov 2003 à 10:50
Mais qu'on est-il de "Architecture SOA et EAI sous l'oeil de Biztalk 2004 Server" :
Sami : " Cet article n'a pas vocation à vous donner des remèdes miracles quant à la mise en place d'une architecture SOA. Il cherche simplement à illustrer cette démarche à travers l'outil Biztalk 2004 tout en vous mettant en garde contre les dangers d'une conception trop fine de processus métier."
ou encore ""Une comparaison des 3 architectures prédominantes du moment"
Sami : "C'est étonnant de voir comment les journalistes (et certains architectes) opposent OOA à SOA alors que la granularité et le champs d'action ne sont pas du tout les mêmes."
Je pense, avant de se livrer à une "masturbation intellectuelle à la Don Box" pour refactorer une petite appliquette, il est plus sage de mettre de l'ordre dans vos idées.
La compléxité de la démarche pour cette pauvre application petstore est terrifiante...
Plus sérieusement, je trouve l'article intéressant.
En revanche, je pense qu'il faut faire attention aux phénomènes de mode et veiller à ce que le SOA ne soit pas la nouvelle réponse universelle à toutes les applications d'entreprise. Je suis convaincu par l'intérêt de la démarche dans certains cas et notamment lorsqu'il s'agit de services mutualisés dans un contexte hétérogène. Mais il n'y a aucune chance que j'utilise du XML avec toute la lourdeur que ça entraine (schémas XML, parsing, ...) pour une appli client/serveur ou web.
A nous d'être suffisamment intelligent pour proposer les bonnes solutions aux problèmes que l'on nous présente.
Cela dit je comprends l'intérêt marketing des déclarations du genre "SOA will eclipse OO" ;-).
La référence à Merise m'a fait sourire car c'est à cette méthode que je pensais qqles pages plutôt dans ma lecture. Non pas que je sois du genre à dire qu'on invente jamais rien (à 25 ans cela serait déplacer ;) mais j'ai proportionnellement plus étudié Merise qu'UML ou la POO. C'était peut-être pas si ringard bien que je pense que c'était par manque de compétence qu'on a pas eu un éventail plus complet des outils.
Re: Le PetShopDNG 3.0, l'Architecture Orientée Services en action
par precchia actif 18 Nov 2003 à 09:07 (Profil Utilisateur | Envoyer un message)
Allez hop, il fait un froid de canard dehors, cela me donne la chair de poule. Tiens cela me fait penser au petstore.
Justement, la business facade ne serait elle pas simplement elle même un service comme tu le laisses entendre en conclusion de ce premier article (Contrat applicatif). En effet, la SOA est fractale, de part le soucis d'autonomie, certains services peuvent "inclure" directmeent d'autres services (encapsulation), d'ou le service PetStore qui encapsule le service Account, Catalog, ...
En ce qui concerne ca faible perennité, pourquoi ne pas recourrir à de la programmatoin descriptive (Ami toulousain, il est leur de sortir de ton lit). Je m'explique, il est plus facile de par exemple changer un élement de séquence bpel que de modifier du code ...
Pour revenir sur l'exentisibilité de XML, SOAP de par son orthogonalité est bon exemple, mais sinon regardons le module Human Workflow de Biztalk, ce dernier propose des schemas avec un curieux élement additonnal parameter ....
Julien est à l'origine d'une démarche qui pourrait se révéler constructive et très formatrice.
Re: Le PetShopDNG 3.0, l'Architecture Orientée Services en action
par Anonyme actif 18 Nov 2003 à 14:07
Messieurs les experts .Net,
Excusez mon cynisme, mais je ne vois rien de nouveau dans cette approche. Ces techniques sont utilisées depuis plusieurs années dans certains projets J2EE ou en tous cas dans le développement logiciel.
- Une "couche" est composé d'interfaces de services et de leurs implémentations.
- Une "Factory" permet d'instancier les interfaces
- La couche fournit une "façade", avec des opérations stateless, enrobant ces services (la façade utilise les interfaces des services, et les instancie à l'aide de la factory).
- un "proxy" client vers cette façade est instancié à partir d'une "factory" côté client. La communication entre le proxy et l'implémentation de la façade est transparente pour le client, et peut être par exemple un echange de messages XML, un appel SOAP, ou un appel direct.
En utilisant cette technique, on peut garantir une indépendance entre les couches, et plus généralement offrir des services à une autre application, et donc garantir un niveau de réutilisabilité. Si chaque couche est indépendante, les services offerts par ces couches peuvent donc être accédés indépendamment depuis d'autres applications.
Je disais que cette approche existe depuis plusieurs années. Pour vous en convaincre, vous pouvez aller jeter un oeil aux articles sur les architectures multicouches du site application-servers.com (rubrique publication), datant de 2001. Personnellement, j'ai utilisé cette approche il y a 3 ans, lorsque je travaillais sur le projet "Eclipse".
Par contre, je pense qu'il y a d'autres problèmes, une fois les services disponibles : comment les appeler ? un client doit il connaitre l'adresse du service ou la découvrir ? un client doit il connaitre le contrat du service (interface), ou le découvrir (utiliser un service générique avec des formats pivots, et faire du "late binding" ?). Etc. Etc. Et là je n'ai pas de réponses ;-)
Re: Le PetShopDNG 3.0, l'Architecture Orientée Services en action
par Anonyme actif 18 Nov 2003 à 14:08
Messieurs les experts .Net,
Excusez mon cynisme, mais je ne vois rien de nouveau dans cette approche. Ces techniques sont utilisées depuis plusieurs années dans certains projets J2EE ou en tous cas dans le développement logiciel.
- Une "couche" est composé d'interfaces de services et de leurs implémentations.
- Une "Factory" permet d'instancier les interfaces
- La couche fournit une "façade", avec des opérations stateless, enrobant ces services (la façade utilise les interfaces des services, et les instancie à l'aide de la factory).
- un "proxy" client vers cette façade est instancié à partir d'une "factory" côté client. La communication entre le proxy et l'implémentation de la façade est transparente pour le client, et peut être par exemple un echange de messages XML, un appel SOAP, ou un appel direct.
En utilisant cette technique, on peut garantir une indépendance entre les couches, et plus généralement offrir des services à une autre application, et donc garantir un niveau de réutilisabilité. Si chaque couche est indépendante, les services offerts par ces couches peuvent donc être accédés indépendamment depuis d'autres applications.
Je disais que cette approche existe depuis plusieurs années. Pour vous en convaincre, vous pouvez aller jeter un oeil aux articles sur les architectures multicouches du site application-servers.com (rubrique publication), datant de 2001. Personnellement, j'ai utilisé cette approche il y a 3 ans, lorsque je travaillais sur le projet "Eclipse".
Par contre, je pense qu'il y a d'autres problèmes, une fois les services disponibles : comment les appeler ? un client doit il connaitre l'adresse du service ou la découvrir ? un client doit il connaitre le contrat du service (interface), ou le découvrir (utiliser un service générique avec des formats pivots, et faire du "late binding" ?). Etc. Etc. Et là je n'ai pas de réponses ;-)
Tanguy Crusson
Re: Le PetShopDNG 3.0, l'Architecture Orientée Services en action
par Anonyme actif 18 Nov 2003 à 17:25
> C'est plutôt une démarche Bottom/Up dans le sens où on essaye d'aggréger des services en
> respectant un minimum les préceptes du paradigme SOA
Pour moi cet article explique comment mettre en place une architecture à couches pour développer une appli qui offre des services à l'extérieur, sans mettre en relief comment appeler ces services, ni comment les orchestrer et limiter leurs dépendances. Ce n'est pas un article sur la SOA mais sur les architectures à couches. Ce qui est très bien d'ailleurs, j'ai bossé sur un projet .Net où l'architecture laissait à désirer, les couches n'étant pas réellement indépendantes. Une grosse galère pour la maintenance.
> Quant à la remarque précédente sur le fait que les Factory/n-tiers/etc ... existaient en J2EE bien
> avant .NET, oui c'est sûr, et alors ?
Et alors rien, ma remarque n'était pas que ces concepts existaient en Java avant .Net, mais que ces concepts ne sont pas des concepts de la SOA, plutôt des architectures à couches. Dans les projets "SOA" sur lesquels j'ai bossé, les contraintes étaient plus de la localisation dynamique de services ou de découvertes d'interfaces, d'orchestration de services, etc. Sujets qui sont assez peu abordés mais sont les plus problématiques. Sinon on se retrouve avec un couplage fort entre services... et donc aucune amélioration, mis à part qu'on dialogue en XML (so what ?)
> A ce sujet, vous verrez qu'avec la généralisation de la programmation par aspect, on parlera de
> moins en moins de Factory à l'avenir ...
Je vois ce que tu veux dire, mais je ne pense pas que cette remarque soit adaptée dans ce contexte. Une appli offre des services, et une façade. On y accède via des échanges de messages XML. Pour ce faire, je dois récupérer un proxy vers la façade, cad avec les mêmes méthodes mais qui fait juste de la délégation, en transmettant aux services via des échanges de messages XML. Pour récupérer ce proxy j'utilise une Factory. La programmation par aspect ne m'apporte rien à ce niveau.
Ceci dit tu as raison, on met tout et n'importe quoi sous le nom de SOA, d'ailleurs MS a bien rectifié le tir avec Indigo ! Le problème est que beaucoup d'éditeurs essaient de surfer sur la vague SOA pour vendre des moteurs de webservices... SOA != WSOA
Je ne comprend pas comment le cahier des charges du directeur technique est satisfait dans cette architecture.
Pour rappel : "Je ne veux pas de replication, les volumes sont trop important"...
Trois alternatives:
1) Le catalogue est au moins reproduit deux fois.
2) Nous sommes en contradictions avec une autre promesse de SOA : "pas de couplage"...
3) Quelque chose m'echappe.
Article très intéressant, permet de mieux structurer mon petit cerveau torturé sur ce sujet que je ne connaissais que très mal ...
Petite remarque : A-t-on une idée de quand est-ce que nous aurons la chance de voir la suite/les sources ? (on se moque de Microsoft à la fin de l'article, mais bon ... il vous reste 6 mois pour faire mieux ;-))
Re: Le PetShopDNG 3.0, l'Architecture Orientée Services en action
par alfonso222 actif 28 Nov 2005 à 11:18 (Profil Utilisateur | Envoyer un message)
CAN I DOWNLOAD THE SOURCE CODE RELATED TO THIS ARTICLE, JUST LIKE I DID WITH PETSHOP DNG? FROM WHERE? THANKS IN ADVANCE
Re: Le PetShopDNG 3.0, l'Architecture Orientée Services en action
par sberthu actif 08 Déc 2005 à 10:21 (Profil Utilisateur | Envoyer un message)
superbe article !
l'un des plus constructif et des plus explicite qu'il m'a été donné de lire.
j'attend vivement, mais vraiment très vivement la seconde partie qui, je l'espere va traiter la partie présentation peut être même en client riche (ça serait bien ;)
Re: Le PetShopDNG 3.0, l'Architecture Orientée Services en action
par minsou actif 23 Fév 2007 à 17:38 (Profil Utilisateur | Envoyer un message)
3 an et demi plus tard et pas de sources, la remarque sur les délais de Microsoft m'ont fait doucement rire ;-)
