Discussion :

[My Name]

J'ai des petites définitions dans ma tête et je ne sais pas si elles sont justes ou non!!! Dites moi si elles sont justes s.v.p
1. les composants dans java sont les "jar java"?
2. les composants en générale comportent des ports, alors quels sont les ports au niveau des Jar ? de mon avis les ports d’un jar sont les packages de ce jar, est ce que c’est juste ?

[wiztricks]

Salut,
Ce genre de concept est assez prise de tête et vous devrez y revenir plusieurs fois avant d'en avoir saisi quelques unes des subtilités.
Un jar est tout ou partie de ce que vous livrez, c'est un "composant" de la livraison sans plus.

Le composant à qui on peut accrocher un port est une entité qui sera active lorsque l'application "tourne". (et pour fonctionner, cette chose pourra s'appuyer sur le code contenu dans plusieurs jar).
Un port représente un point de communication avec le composant. Lui est généralement associé une interface définie par un protocole (i.e. des méthodes).
Cette "interface" a des propriétés semblables à celle de l'interface Java mais c'est parfois un faux ami: l'interface Java étant une "chose" qui permet de construire un code Java qui pourra être tout ou partie d'un composant.
Autrement interface et port d'un composant appartienne à une chose "supérieure".
Cordialement,
- W

[My Name]

Salut,
Ce genre de concept est assez prise de tête et vous devrez y revenir plusieurs fois avant d'en avoir saisi quelques unes des subtilités.
Un jar est tout ou partie de ce que vous livrez, c'est un "composant" de la livraison sans plus.

Le composant à qui on peut accrocher un port est une entité qui sera active lorsque l'application "tourne". (et pour fonctionner, cette chose pourra s'appuyer sur le code contenu dans plusieurs jar).
Un port représente un point de communication avec le composant. Lui est généralement associé une interface définie par un protocole (i.e. des méthodes).
Cette "interface" a des propriétés semblables à celle de l'interface Java mais c'est parfois un faux ami: l'interface Java étant une "chose" qui permet de construire un code Java qui pourra être tout ou partie d'un composant.
Autrement interface et port d'un composant appartienne à une chose "supérieure".
Cordialement,
- W

salut,
OK j'ai compris qu'est ce que vous avez dit un peu!
oui vous avez raison on peut pas attacher des ports aux "jar" donc le jar ce n'est pas le composant destiné dans le paradigme orienté composant!
donc:
si je veux utiliser la programmation orienté composant dans java alors je dois le ajouter une extension qui permet ça non?
(mon problème c'est que moi jusqu'à maintenant je ne connais l'orienté composant que dans le niveau modélisation et je veux faire un exemple pratique et c'est mieux avec "java")
Une autre chose, j'ai trouvé que l'ADl "archJava" qui est un adl de programmation,
dites moi est ce que c'est suffisant pour moi de faire une expérience avec "archJava" pour comprendre la programmation orienté composant dans son sens général?
j'ai dit sens général puisque il y a ce qu'on appelle les modèles de composants (EJB par exemple) et la programmation avec les modèles de composants c'est une programmation orienté composant aussi non? Dites moi si je ne suis pas juste!

[wiztricks]

Salut,

Les composants relèvent de la conception pas vraiment de la réalisation.
Je vous suggère la lecture de l'article.
Il décrit comment on peut imaginer la réalisation de composants en Java en faisant abstraction des technologies utilisable pour les réaliser.
Lisez aussi les commentaires. Ils sont révélateurs du "trouble" dans lequel on peut être lorsqu'on parle de ce genre de chose.

Note: Le "trouble" est que si du côté de la "conception" c'est a peut près clair... Quand on passe côté réalisation, sans préciser les technologies qui vont permettre de les réaliser, çà reste trop "ouvert".

Cordialement,
- W

[Hephaistos007]

Le paradigme composant est très difficile car le mot "composant" a plusieurs significations possible et personne ne parle de la même chose. Donc, ma première remarque, c'est de figer un contexte pour mettre les gens d'accord.

Ensuite, je te livre ici quelques éléments de mon expérience sur le sujet :

- Le véritable paradigme des composants fait référence à des briques logicielles que l'on va assembler ensemble (comme un jeu de légo), sans se soucier des technologies qui les implémentent. A partir de là, est considéré comme composant toute chose qui masque son implémentation vis-à-vis de l'extérieur, peut être démarré/suspendu/arrêté (idéalement à chaud), et offre une interface fournie et requise claire.

Ce qui est terrible c'est que la frontière qui détermine un composant n'est pas explicite. Par exemple, une simple fonction peut être considéré comme un composant, et un SGBD entier aussi (des milliers de lignes de codes). Dans ce dernier cas, l'interface du SGBD est un agrégat de plusieurs fonctionnalités disséminées.

Issus du monde universitaire, les ADLs sont des langages qui se concentrent uniquement sur la description des assemblages des composants. Sous ce prétexte, ils bottent en touche, puisqu'ils ne s'occupent pas de savoir ce qu'est réellement un composant ! Ainsi libérés des questions terres-à-terres, les ADLs peuvent proposer des modèles de composants divers et variés : avec ou sans sous-composants, avec ou sans port, avec ou sans interface de gestion de cycle de vie, avec ou sans niveau méta, etc...

Toutefois, l'ADL ArchJava est un cas particulier, volontairement à cheval entre les ADLs purs et dur et un langage de programmation comme Java. En gros, il n'y a que du sucre syntaxique ('public class' devient 'public component', etc.) pour joindre les deux mondes. Ce qui m'amène naturellement à la dernière catégorie la plus répandue : les pragmatiques. Eux ont considéré qu'un composant = un objet/une classe, auquel on rajoute quelques principes pour qu'il soit assemblable avec d'autres objets. L'interface du composant est donc basiquement l'interface de l'objet. Les plus illustres représentants sont certainement les Beans Java.

Pour avoir une vue d'ensemble : http://olegoaer.perso.univ-pau.fr/resources/OCS.pdf