> Tech > Facilité de réutilisation

Facilité de réutilisation

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Les composants sont apparus sur les clients juste après l'avènement des interfaces utilisateur graphiques. Surchargés de travail, les développeurs Windows et Macintosh cherchaient des moyens permettant de s'affranchir des tâches répétitives et laborieuses liées à  la construction des éléments graphiques.

“ On écrivait tout ce code C brut

Facilité de réutilisation

pour construire une application Windows et il
fallait réécrire la même chose à  chaque fois. C’est alors que les développeurs
se sont dit, “ Voyons, nous avons tous besoin d’effectuer les mêmes opérations
sur les fenêtres : les fermer, les redimensionner, les déplacer sur l’écran. Alors,
construisons des composants pour réaliser ces opérations ”, explique Paula Richards,
spécialiste des technologies des applications chez IBM.

Cependant, au fur et à  mesure que les applications devenaient de plus en plus
complexes, poursuit-elle, les développeurs ont souhaité distribuer les tâches
de calcul à  travers un réseau hétérogène très dispersé et lier une information
saisie sur un client donné à  un processus particulier sur un serveur déterminé.
Ainsi, ils ont développé des protocoles qui permettent de connecter des composants
s’exécutant sur des machines différentes reliées en réseau et de faire collaborer
ces composants comme s’ils fonctionnaient sur un serveur unique.

Cependant, pour chaque composant développé, les développeurs qui essayaient de
se conformer à  ce modèle ont vite été obligé de gérer toutes les complexités liées
au réseau, à  savoir : écrire des procédures pour le nommage, la messagerie, la
concurrence, la localisation d’autres composants dans le réseau, etc.

“ Il existe une multitude de questions de ce type. Si chacun de nous devait tout
programmer seul, réinventant la roue à  chaque fois, cela deviendrait très vite
fastidieux et le cycle de développement d’un logiciel s’allongerait considérablement
”, déclare Gopalan Suresh Raj, développeur de composants Windows chez CompuWare
Corporation et coauteur de l’ouvrage Enterprise Java Computing — Applications
and Architecture, à  paraître ce mois-ci chez Cambridge University Press.

Ces inquiétudes ont motivé le développement d’un nouveau modèle de composants,
intégré dans les récentes spécifications EJB (Entreprise JavaBeans), CCM (CORBA
3.0 Component Model), et MTS (Microsoft Transaction Server). Ces modèles sont
communément qualifiés de modèles de composants middleware parce qu’ils utilisent
une structure ou un serveur d’applications qui gère les menus détails de la programmation
système. Ainsi, les développeurs de composants peuvent se concentrer sur la logique
des opérations. Avec ces modèles, les fournisseurs de serveurs d’applications
proposent des emballages ou conteneurs pour encapsuler la logique des opérations
et contrôler les interactions entre composants.

“ Avec l’apparition des modèles de composants middleware tels que MTS, EJB, et
CCM, nous n’avons plus besoin d’écrire de code pour gérer le réseau, notre propre
code transactionnel, ni de coder nos propres routines de gestion du nommage, de
la messagerie et de la sécurité. Tout ces aspects sont désormais pris en charge
par la structure qui nous est fournie ”, explique Gopalan Suresh Raj.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010