Transmis par: webmaster actif Lundi 08 Mars 2004 à 00:00
Depuis plusieurs mois, on constate un regain d'intérêt sans précédent pour les conteneurs légers d'entreprise. Ces nouveaux types de serveurs d'application répondent aux doux nom de Spring, Pico (J2EE et .NET), Avalon ou HiveMind. Ils sont devenus la clé de voûte d'une résistance accrue contre la domination quasi monopolistique des conteneurs lourds. Et partout les avis convergent pour mettre en avant leur vertus. Peu ou pas d'adhérence avec des API techniques. Une programmation orientée interface et une architecture à base de composants. Un article qui creuse avec vous l'univers de l'inversion du contrôle.
Joie, un décryptage limpide et ultra-pédagogique comme d'habitude sur les pico-containers juste quand j'en ai besoin ... Sami lit dans les pensées, c'est sûr :-)
On découvre également au détour de l'article, le hype de la pure branchitude du moment : les Hoax-Frameworks. (Fabrice, a ajouter dans la liste des catégories sharptoolbox :-)
"[...] Le simplissime poussé à l'extrême allant jusqu'à faire penser à certains que nous arriverons un jour à réaliser des applications sans une seule ligne de code."
Mouhaha, comme on dit chez nous. Si vous êtes passionés par le sujet :
- The invisible Framework: The Invisible Framework cometh
- LOAF: Social Software Experimental Program
- NADA: Nada does nothing for everybody
Juste une question de vocabulaire: pourquoi parle-t-on d'injection de code (qui évoque à tort ce qu'on fait en AOP), alors qu'il s'agit en fait d'injection d'implémentation?
Mes collègues et moi avons lu avec grand intérêt cet article, car nous nous
sommes attaqués à ces mêmes problèmes depuis pas mal de temps, et partageons
plusieurs des points de vues exprimés par l'auteur. Avec l'expérience d'un
framework similaire à Pico dans le monde Java, nous avons développé, dans notre
groupe de R&D, un container léger en .NET appelé LEAF.NET, qui peut se
hoster dans IIS, dans un Service NT, dans un exécutable de type console, dans
un exécutable de type frame, et plus généralement dans toute application .NET.
Les composants sont découverts à l'exécution, obtenu à travers des factory.
Ils sont obtenus localement à l'aide de leur nom, et utilisés à travers leur
interface.
Les implémentations ont une configuration propre manageable dynamiquement.
Une même implémentation peut-être réutilisée plusieurs fois avec un nom et une
configuration différente.
L'implémentation d'un composant peut-être locale ou distante.
Component Types: Les différents types de composants disponibles sont:
Les singletons (configuration, management, interception, publication,
load-balancing).
Les stateless clonés (configuration, management, interception, publication,
gestion dans un pool optionnelle et paramétrable).
Les stateful clonés (configuration, management, interception, publication,
gestion dans un pool optionnelle et paramétrable).
Les Singletons globaux (comme les singletons mais les données sont reparties
sur les instances du cluster, en supportant l'arrivée ou la disparition de
nouvelles machines).
Les façades COM.
Les façades Web Services.
Les façades J2EE (via IIOP.NET).
Le vôtre (Tous les types de composants sont des plug-ins et leur gestionnaire
un composant).
Les statiques (composants bas niveaux).
Configuration:
Chaque assemblage embarque sa propre configuration qui peut surcharger la
configuration des assemblés qu'elle utilise.
Du coup tous les assemblages sont des plug-in. La sécurité, l'instrumentation,
le support de nouveaux types de composants... se "pluguent".
Les assemblages communs se contentent de définir les noms des composants, leur
interface, leurs value objects.
Les assemblages clients "pluguent" des références à des noms de serveurs ou a
des clusters.
Les assemblages Serveurs "pluguent" des implémentations.
Deployment:
Support pour le multi-AppDomain, permet de passer simplement d'un fat client à
du 3-tier en cluster sans toucher à l'implémentation.
Remoting:
Support pour la publication sélective: channel TCP sécurisé/non sécurisé,
compression, encryption, pipe...
Transaction & Data:
Support des transactions déclaratives (via attributs) ou impératives (bloc
using) de granularité méthode au niveau de tous les composants. Abstrait
l'utilisation de COM (transaction multi-AppDomain, XA, interop) ou ADO.NET.
Abstraction complète des différentes bases de données (IDbCommandBuilder,... ).
Support des batches avec des points de reprise.
Support transactionnel pour les fichiers (Compensating Resource Manager).
Security:
Système commun entre Winform, Webform, localisé sur le serveur applicatif.
Re: Les conteneurs légers du futur arrivent à grands pas [MAJ]
par Anonyme actif 03 Juin 2004 à 14:56
Une petite question de traduction : pourquoi dire du type Ioc 2 qu'il s'agit d'Inversion d'accesseur... normalement setter se traduit pas mutateur et getter par accesseur ?!?
