Rappel sur les principes de SOA
L'architecture SOA est à toutes les sauces bien qu'il existe actuellement plus d'articles sur le sujet que d'implémentations réelles. Néanmoins, SOA permet de répondre à certaines problématiques de design et de développement :
- - Comment optimiser mon taux de réutilisation dans le développement
- - Comment interagir avec mon ecosystème (business, technique, externe ou interne)
SOA est un pattern d'architecture; ce n'est ni une recommendation, ni un standard et SOA ne vous apporte pas une solution toute faite.
Une architecture SOA sous-entend que l'architecture est composée de services. Ces services doivent suivre les quatre principes suivants :
- - être autonome
- - avoir des frontières explicites
- - partager des contrats et des schémas et non des implémentations ou des classes
- - compatibilité basée sur les policies
Stefan Tilkov propose six nouveaux principes qui permettent de caractériser les services :
- - expose des formats et non des API
- - orienté documents
- - faiblement couplé
- - standards compliant
- - indépendant des offres fournisseurs
- - piloté par les metadata
Très bonne interview sur WS-*, REST
par Sanjiva Weerawarana sur le site Infoq.
Best practices JEE IBM
IBM vient de mettre à jour une best practice J2EE datant de 2004 qui devient
une best practice JEE.
En vrac :
- Always use MVC
- Don't reinvent the Wheel
- Apply automated unit tests and test harnesses at every layer
- Prefer JSPs as your first choice of presentation technology.
- ...
La programmation par contrats
La programmation par contrat (design by contract) est une technique largement utilisée dans les architectures modernes.
Le principe est qu'une classe et ses client interagissent avec un contrat; cette idée a été reprise dans les architectures SOA.
Dans le langage objet, l'interface est une intention alors que la classe est une implémentation. L'interface est le concept de base de la programmation par contrats.
Ref : article de jm heidly
Les IHMs reviennent au goût du jour
Abandonnées il y a quelques années pour cause de webisation des applications, les IHMs reviennent au goût du jour dans la mouvance Web x.0 (x > 1).
Au début des années 90 au temps des applications client serveur, des spécialistes IHM travaillaient sur le design, l'ergonomie et l'efficacité des interfaces homme machine dans un contexte d'informatisation de l'entreprise. L'IHM prenait une place prépondérante dans les applications informatiques car ces applications s'adressaient, en majorité, à des personnes peu formées à l'utilisation d'un poste de travail (l'informatisation de certains métiers a engendré de nombreux changements de carrières et de spécialisations).
Ces métiers autour de l'IHM ont complètement disparu avec la mode des applications WEB dans l'entreprise; mode motivée principalement par des critères économiques (baisse de la maintenance et des coûts de formation des utilisateurs). Les IHMs sont prises en charge directement par les développeurs; les designers intervenant à la marge en fournissant un canevas (quelques fichiers css).
Cette démarche de délaissement des IHMs a fait naître le Web 2.0 sur l'Internet; mouvement social déclenché par les utilisateurs de la toile. De fait, l'IHM revient au premier plan mais elle reste encore une affaire de développeurs.
Avec la sortie des technologies WPF XAML de VISTA, des spécialistes travaillent de nouveaux sur les interfaces et desktop de demain (voir ce lien) avec des possibilités améliorées : interfaces en 3D, interactivité avec les entrées sorties.
Pour s'en convaincre, tester le NewYork Times reader ou le catalogue interactif de la FNAC.
Pour les développeurs, un article MSDN très intéressant.
Sérialisation des obets de domaine : pattern ou anti-pattern ?
J'ai trouvé plusieurs articles qui traitaient de ce sujet notamment l'utilité de sérialiser des objets de domaine à travers WCF. Effectivement, ce n'est pas un sujet simple et dans les blogs de dotnetguru cela est considéré comme un anti-pattern ce qui me semble être une position quelque peu limite.
Développer des objets de domaine (ou entités de domaine) est un pattern et est utilisé par tous dansles 2 technologies (JEE ou .NET). Un objet du domaine est un concept métier et non technique donc cela ne me choque pas que ce concept soit manipulé par les différentes couches d'une application y compris par le client. Cette solution peut être préférable à d'autres solutions (multi conversion d'objets, DTO).
De mon point de vue, sérialiser les objets du domaine dans WCF n'est pas un anti pattern mais un design possible qui présente des avantages et inconvénients.
Sérialisation d'objets de domaine Active Record dans WCF
Architecture n-tiers Ajax .NET
WPF : les interfaces homme machine de demain
.NET 3.0 est sorti récemment en version RTM. Il comprend les briques WinFX soit WPF (Windows Presentation Fondation), WCF (Windows Communication Fondation) et WWF (Windows Workflow Fondation).
Après quelques jours de test sur ces nouveautés, je me demande si WPF ne va pas bientôt révolutionner les interfaces homme machine et je pense sincèrement qu'il nous donne un aperçu de l'espace de travail de demain (genre bureau métier futuriste) et que dans la mouvance Web 2.0, WPF permettra de redonner un sens aux applications côté utilisateur en lui proposant des interfaces riches et fonctionnelles.
WPF est composé d'un runtime et d'un langage de description des interfaces pur XML qui se nomme XAML. WPF permet, ce que tout les dévelopeurs attendaient depuis des années, de définir des IHM indépendantes du device (navigateur sur poste de travail, application standalone sur poste de travail, tablet pc, mobile device sous Windows Mobile, PDA). Néanmoins cette indépendance reste cantonner au monde Microsoft mais je vous engage à surveiller de près les évolutions de WPF/E (WPF Everywhere) qui permettra d'exécuter des applications WPF sur n'importe quel OS et n'importe quel navigateur.
Modèle MVC et AJAX
Le modèle MVC (Modèle Vue Controller) permet de découpler la présentation des couches applicatives inférieures.
AJAX permet de concevoir des IHM plus riches où une partie de la navigation est gérée dans une logique cliente.
Il me semble que la confusion entre controller côté serveur et contrôleur côté client risque de semer le trouble et de compliquer la tâche des développeurs. En tout cas, MVC perd son sens contrôleur des actions de l'utilisateur car manifestement celui-ci ne contrôle plus grand chose.
Il n'est pas, à mon sens, insensé de se passer de ce pattern pour les applications de type Web Ajax surtout si les éléments graphiques sont liés à une source de données de type "business object" à la sauce Visual Studio.
