Discussion :

[florian.g]

Bonjour,

Il y a deja quelque temps j'ai decouvert ce qu'est reellement la technologie XPCOM de Mozilla Foundation. Suite a ca, j'ai commence a m'interesser vraiment au developpement par composant et j'ai donc egalement lu quelques articles sur la technologie COM de microsoft, et cherche des alternatives.

Je ne suis pas completement satisfait des solutions que j'ai vu jusqu'a present (XPCOM, COM, ICE?)

Je parle principalement de la mise en place du programme et des librairies fournies.
Corrigez moi si je me trompe (c'est pour recevoir des commentaires que je poste en fait)mais voici ce que j'en retiens:

Pour utiliser le "pattern" de developpement par composant, on a besoin de que notre runtime:
1. Permette de charger la DLL specifiee(ou autre "fichier composant").
2. Permette d'instancier une classe depuis la DLL chargee.
3. Permette de decharger la DLL specifiee.

Donc en gros l'interface pour recuperer un composant inconu pour reprendre les termes COM:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public interface IComponentFactory
{
  Object getInstance(Object param,string[] expectedInterfaces);
}

Et nos composants

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
public interface IComponent
{
   string[] getInterfaces();
   void CastTo(String s)
   {
      if( !getInterfaces().contains(s) )
      {
         throw( new InvalidCastException(); )
      }
   };
}

On donne meme la possibilite a lutilisateur de passer des parametres a la creation.

Puis dans notre runtime on propose les fonctions statiques:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public static String Components.GetClass(Class c);
public static IComponent Components.Load(String file);
public static void Components.Unload(String file);
public static void Components.Unload(IComponent compfactory);

En gros on peut charger les composants en indiquant le fichier a partir duquel charger tout simplement, et on peut liberer la memoire quand approprie soit en passant le path/name du fichier, soit en passant l'objet charge (qui agit comme une factory pour les composants).

La fonction Load se charge de charger la DLL de facon a ce que les objets crees puissent etre castes correctement ds le langage ds lequel nous sommes.

Imaginons qu'on aie un objet TCPServer dans le fichier "TCPServer.dll" et que notre composant prennent en entree un objet IPEndPoint

On veut pouvoir ecrire un code du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
// fichier de declaration pour les interfaces implementees par MyServer
// header en C++, cs in csharp par example etc...
// La definition est partagee entre les composants clients
// et l'implementation
namespace SharedNamespace
{
	// Une interface implementee par un composant
	public interface IOtherInterface
	{
		public virtual void OherMethod();
	}

	// Une interface implementee par un composant
	public interface IMyServer
	{
		public virtual void DoSomeStuff();
	}
}

//fichier source pour MyServer
namespace ComponentNamespace
{
	using namespace TCPServerns;
	using namespace MyCOMns;
	using namespace SharedNamespace;
	// Implementation du composant derive toujours de IComponent
	// Aucune classe cliente n'a besoin de connaitre cette classe
	protected class MyServer : IMyServer, IOtherInterface, IComponent
	{
		private ITCPServer server;
		private IComponentFactory TCPserverFactory;
		
		// derive de IComponent
		public static override string[] getInterfaces()
		{
			string[] ifs = new string[2];
			ifs[0] = MyCOM.getClassName(IMyServer);
			ifs[1] = MyCOM.getClassName(IOtherInterface);
		}
		
		// derive de IOtherInterface
		public override void OherMethod(){return;}
		
		// derive de IMyServer
		public override void DoSomeStuff(){return;}
		
		// creation
		public MyServer(Object o)
		{
			this.TCPserverFactory = Components.Load("TCPServer.dll")
			IPEndPoint ipep = new IPEndPoint(...);
			string[] expectedif = new string[1];
			expectedif[0] = "TCPServer";
			this.server= (ITCPServer)TCPServerFactory.getInstance(ipep,expectedif);
		}
	}
	
	public class MyServerFactory : IComponentFactory
	{
		private string[] interfaces = null;
		
		public override Object getInstance(Object o, string[] expected)
		{
			this.check(expected,MyServer.getInterfaces());	//renvoie une exception si on ne connait pas l'interface demandee...
			return (new MyServer());
		}
	}
}
}

//fichier source pour le main de l'appli, qui est aussi notre client...
namespace Clientns
{
	using namespace MyCOMns;
	using namespace SharedNamespace;

	public class MyMain
	{
		public void Main()
		{
			IComponentFactory MyServerFactory = Components.Load("MyServer.dll")
			string[] expectedif = new string[1];
			expectedif[0] = "IMyServer";
			IMyServer server= (IMyServer)MyServerFactory.getInstance(null,expectedif); 
			server.DoSomeStuff();
			IOtherInterface OtherShape = (IOtherInterface)server.CastTo(MyCOM.getClassName(IOtherInterface));
			return;
		}
	}
}

Voila, ca m'a l'air tout a fait possible, et pas besoin de methodes du genre de "AddRef", ou "Release", comme defini par .COM par example.
On laisse l'utilisateur gerer ses objets comme il a l'habitude de le faire dans son language. On lui permet juste de charger dynamiquement certains modules...

Ca me parrait legerement plus simple que XPCOM ou .COM comme approche, non?

En gros ca necessiterait que nos DLL soient accompagnees d'un fichier descriptif pour savoir ou sont les methodes a aller chercher...

Mais ca a l'air completement faisable de generer ca directement depuis le code(avant ou apres compilation). en regardant de quelles interfaces derive l'objet qui derive de IComponent....

En fait l'idee c de simplifier les choses en se passant de fichier IDL par exemple. Les languages de programmations nous permettent de definir des classes "interfaces", donc il suffirait de generer le fichier IDL a partir du code en lui meme.

Donc en gros 3 simplifications par rapport a XPCOM et COM:
- pas de fichier IDL
- pas de gestion mysterieuse de la memoire. La memoire est geree par l'utilisateur comme il en a l'habitude...
- pas de librairie par defaut: le runtime se contente d'etre capable de charger les composants. Un point c'est tout.

L'idee est que je trouve COM tres intrusif dans la facon d'ecrire le code apres coup...
XPCOM m'a l'air tres proche de ca, neanmoins ils ont besoin d'IDL... Mais c'est peut etre la solution?
Mais j'ai vu pas mal de critiques d'XPCOM sur certains forums... Alors qu'en y repensant j'ai vraiment l'impression que ce sont eux qui tiennent le bon bout a l'heure actuelle?

Quelqu'un aurait-il une solution meilleure que XPCOM a proposer pour la base d'un programme ecrit par composants?

Aussi la distribution d'XPCOM que j'ai touve vient avec XULRunner (pour l'instant c'est ce que j'en ai vu), donc on se prend des milliards de classes dont on n'a pas forcement besoin pour n'importe quelle application lambda.

De la meme facon, ICE a l'air de venir en bloc si on peut se permettre le jeu de mot, donc on compile contre des librairies deja orientee communication, alors que je veux juste compiler contre des librairies qui me permettent de charger des composants (et ensuite charger eventuellement des composants responsables de gerer les communications....)

Merci d'avance pour vos conseils...

[Médinoc]

Si l'utilisateur doit choisir lui-même quand charger et décharger la DLL, c'est trop compliqué. CoGetClassObject() et CoCreateInstance() chargent automatiquement la DLL, et CoFreeUnusedLibraries() les décharges après avoir interrogé les DLLs par DllCanUnloadNow().

pas de gestion mysterieuse de la memoire. La memoire est geree par l'utilisateur comme il en a l'habitude...

La gestion manuelle est plus compliquée et plus susceptible d'erreurs que le comptage de références. Si tu veux éviter les addref/release, utilise des pointeurs intelligents (ou un runtime qui gère ça de lui-même, comme .Net)

[Mac LAK]

De la meme facon, ICE a l'air de venir en bloc si on peut se permettre le jeu de mot, donc on compile contre des librairies deja orientee communication, alors que je veux juste compiler contre des librairies qui me permettent de charger des composants (et ensuite charger eventuellement des composants responsables de gerer les communications....)

D'un autre côté, as-tu bien compris ce qui se cachait derrière l'acronyme ICE ??? Internet Communication Engine...

Certes, tu peux aussi avoir des endpoints locaux avec ICE (c'est à dire que la communication ne se fait pas par réseau, mais "directement" dans le code applicatif ICE), ou sur la boucle locale du PC (pour l'inter-processus). Ce n'est pas le cas nominal et idéal, par contre.

Si tu veux une approche "plugin", mais SANS communication, je te conseillerais plutôt d'aller voir du côté de POCO, pour la portabilité, ou effectivement de rester sur COM si seul le monde Windows t'intéresse.

[florian.g]

Merci pour vos reponses!

@MacLAK
En fait oui je sais ce que veut dire ICE, mais au dela de l'acronyme, si tu lis le manuel tu verras que c'est une approche de la programmation par composant d'un certain point de vue. Les composants sont juste distribues sur le reseau.
Et d'ailleurs en regardant un peu plus profondement, ICE propose le service ICEbox, qui permet de charger des composants locaux.

On peut lire dans la description de ICEBox:

Application components can be deployed as dynamic library instead of as a process.

On parle clairement de developpement par composant.

Mais de mon point de vue il y a une erreur dans le sens dans le quel est pris le probleme:
Ce n'est pas la partie communication qui choisit de charger un composant, c'est bien le composant qui peut choisir de charger UNE facon de communiquer.
ICEBOX devrait etre au coeur du systeme ICE, et pas l'inverse.

Une grosse partie de ICE est de definir un protocole de communication pour realiser des RPC/RMI etc...
Mais ils presentent une excellente partie de ce qui devrait etre au coeur de nimporte quelle application en fait (n'importe quelle appli qui ne fonctionne pas en otiste).

En fait je ne reproche que 2 choses pour rendre le modele plus general:
- Inverser la relation composant/communication engine: Un communication engine peut etre charge et utilise comme un autre composant.
- Proposer de charger le support TCP/IP-UDP-Serie-Pipes comme n'importe quelle autre composant.

Je pense qu'au dela de ca l'approche est par ailleurs excellente.

Je parle en fait de l'architecture de base d'une application en general. On pourrait quand meme avoir a notre epoque un moyen d'ecrire une application portable et modulaire sans redefinir a chaque fois son propre format de DLL et ses factories pour les modules... Ce sont quand mme des concepts tres generaux...

Pareil ICE propose un Marshaling des donnees qui a l'air implante comme une partie indisecable de l'appli. Et si l'utilisateur veut utiliser les protocoles de RMI/RPC de ICE sur le format de donnees de Protocole Buffers?

Si le marshalling par defaut de ICE n'est pas suffisament efficace pour une raison X ou Y, on jette le package? Par example, si on serialize nos donnees de facon customisee, on se trimbale la serialization par defaut sans l'utiliser.

De la meme facon, si on ne communique pas par dessus un reseau LAN, mais par dessus un port serie ou un bus CAN par example... la aussi on trimbale une librairie TCP/IP qu'on ne va pas utiliser...

Il y a certains points comme ca ou un poil plus d'abstraction aurait peut etre aide?

En fait je bosse sur de l'embarque, donc je ne peux pas toujours me permettre (niveau memoire notament) d'inclure des bouts de librairies que je n'utilise pas.
L'idee est de ne pas avoir un noyau qui fait 3 fois la taille de ce qu'il pourrait faire...

Pour resumer sur ICE, ICE propose bien plus qu'un simple outil de communication.

@medinoc:
La gestion intelligente de la memoire peut etre implementee comme un composant. Ce serait bien de pouvoir choisir de l'utiliser ou pas selon nos besoin, et de changer l'implementation selon nos besoins aussi, non?
Je cherche peut etre "trop" modulable?
Pourtant ca ne me parait pas absurde.
En tous cas, la gestion intelligente de la memoire impacte les performances, donc sur certains systemes embarques, on aimerait s'en passer.
Comme je parle de systemes qui discutent eventuellement avec des ordis, c la ou se trouve l'interet de supporter des protocoles de communication bien generaux comme ceux implementes par ICE...

Encore une fois merci pour vos reponses. Personellement a force d'en discuter avec pas mal de gens jai fini par bien identifier de quoi nous avons besoin exactement.

[Mac LAK]

IceBox, en soi, n'a presque aucun intérêt : le noeud, c'est IceGrid. C'est ce composant qui permet de correctement référencer les endpoints.

Côté communication, relis l'acronyme... Tu verras pourquoi c'est TCP/IP qui est privilégié ! Il existe toutefois une version embedded de ICE. Par rapport aux divers média possibles, il n'y a pas de besoin réel.

Je bosse aussi dans l'embarqué, mais je n'utilise pas ICE pour les parties RT. C'est surtout pour la com haut niveau, le bas niveau utilisant plus IceStorm que Ice "brut".

Toutefois, rien ne t'empêche d'utiliser un endpoint Ice pour piloter un capteur sur une LS ou un bus de terrain. Mais ne confonds pas un bus logiciel distribué comme ICE avec un bus matériel comme CAN : l'association / pont entre les deux ne sera pas automatique.

[Médinoc]

En tous cas, la gestion intelligente de la memoire impacte les performances, donc sur certains systemes embarques, on aimerait s'en passer

Franchement, je pense que le comptage de références, ça ne consomme rien par rapport à un GC.

Et puis, si tu veux t'en passer, tu peux juste garder UNE référence et utiliser des pointeurs "bêtes" pour le reste. COM a tendance à se passer des AddRef() pour les simples appels de fonction, ne les utilisant que quand il faut stocker une référence quelque part.

[florian.g]

@Medinoc
Mais oui, tu as raison jai dit une annerie. Si la gestion de la memoire se fait par comptage des references en effet ca n'a quasi-aucun impact.
Tres bonne idee en fait donc des smart pointers pour gerer la memoire... je comprends mieux l'interface proposee par COM en fait merci. C'est stupide, c'est comme quand on cherche des lunettes alors qu'on les a sur le nez...

@MacLAK
Je comprends bien ce que tu dis, on est presque sur la meme longueur d'onde en fait.
Je pense par contre que en effet ICEBox ne contient pas "l'intelligence" du systeme, mais que ca devrait justement etre au coeur du systeme. Tres peu d'intelligence, donc une librairie de base tres legere, mais des possibilites infinies.
Cette capacite a charger des composants locaux est la part la plus essentielle de toute application (je parle de maniere generale, la part la plus reutilisable, et qui peur accelerer enormement le developpement).

Ensuite en chargeant les composants qui implementent les interfaces qu'il faut on peut faire de la communication comme on veut.
Pour le fait que I de Ice soit "Internet", oui je sais bien, mais c'est juste un acronyme qui est loin de refleter les possibilites qui sont derriere.
Et on gagnerait surement a pouvoir implementer des composants qui implementent d'autres protocoles que TCP/IP UDP etc... et a pouvoir egalement enlever TCP/IP si on en a pas besoin dans un cas particulier...
Par exemple on pourrait imaginer ce type d'appel:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ic‑>createObjectAdapterWithEndpoints(
                "Example", "serial ‑p COM1");

En implementant l'interface necessaire, on devrait pouvoir fournir notre protocole "serial" de communication.

Pour repondre a mon interrogation premiere, je vais sticker avec Ice(-E) pour un moment, et voir si c'est reellement aussi simple et pratique que ca m'en a l'air.

Merci encore pour vos reponses, c'etait tres interessant.
:

[Mac LAK]

Je comprends bien ce que tu dis, on est presque sur la meme longueur d'onde en fait.

Disons que j'ai une approche très certainement différente, parce que j'utilise réellement ICE dans un contexte concret. Je vois donc mieux ce à quoi il est adapté, et ce qui ne lui convient pas.

Je pense par contre que en effet ICEBox ne contient pas "l'intelligence" du systeme, mais que ca devrait justement etre au coeur du systeme. Tres peu d'intelligence, donc une librairie de base tres legere, mais des possibilites infinies.

Justement, c'est un peu là le problème : à quoi servirait ceci ?? Charger ou décharger un composant de type plugin ? Inutile, voire idiot : d'autres librairies, ou même une simple conception polymorphique de ton code, fait bien mieux et bien plus efficacement.
ICE fournit des couches d'abstraction (notamment sur les threads) non pas pour faire de l'abstraction, mais pour permettre la portabilité de la librairie... Bref, il n'incorpore que ce qui lui est strictement nécessaire. Pour une abstraction plus poussée de la machine, tournes-toi vers POCO ou ACE, qui sont nettement plus dédiés à cet usage.

Cette capacite a charger des composants locaux est la part la plus essentielle de toute application (je parle de maniere generale, la part la plus reutilisable, et qui peur accelerer enormement le developpement).

Non, pas vraiment... Les trois-quart des projets sur lesquels j'ai pu bosser dans ma carrière n'ont aucun besoin de ça, car ils sont orientés embarqué temps réel (et surtout, industriel). Le besoin est connu et défini à l'avance, les rares inconnues sont par exemple la topologie du réseau et les configurations côté utilisateur. Le reste est verrouillé en conception et/ou en production.

Ensuite en chargeant les composants qui implementent les interfaces qu'il faut on peut faire de la communication comme on veut.

Là encore, pourquoi faire ? Un bus de terrain n'est pas forcément adapté à un protocole de type RPC, ni même compatible avec d'ailleurs. Typiquement, implémenter un protocole Modbus de cette façon serait une usine à gaz, car les esclaves Modbus n'ont PAS besoin d'une telle complexité ! La plupart du temps, ils ne répondront qu'à quelques requêtes précises, et renverront des trames "en dur" ou peu s'en faut. Rajouter la gestion d'un endpoint ICE serait du code inutile et coûteux.
Côté superviseur, rien ne t'empêche d'avoir un endpoint ICE côté réseau public (notamment vers les superviseurs de niveau supérieur et/ou les affichages), les requêtes ICE étant traitées au niveau du servant via un appel à une DLL adaptée au bus de terrain (ex : Modbus, donc), et converties ensuite en données publiques.

Ce que tu sembles sous-estimer, c'est l'impact en terme de performances et de footprint d'une architecture de chargement dynamique : c'est souvent beaucoup trop lourd pour un microcontrôleur, qui doit être codé "en dur". Je t'encouragerais plutôt à te tourner vers de la génération de code C bas niveau à partir d'un protocole de haut niveau pour résoudre ce problème (ex : on définit le format des trames, les adresses internes de mapping des diverses données transmises, et on génère un code C pour µC résolvant le problème).

Or, ICE, c'est permettre de faire ça sans forcément tout recompiler, notamment en gérant correctement les facettes des endpoints... Quel besoin de faire ça dans du très bas niveau ? Aucun, c'est trop lourd et trop pénalisant. A réserver aux étages supérieurs, le bas niveau n'est pas appelé "bas" pour rien...

Pour le fait que I de Ice soit "Internet", oui je sais bien, mais c'est juste un acronyme qui est loin de refleter les possibilites qui sont derriere.

Sauf que c'est dans une architecture de ce type, avec une latence de communication relativement élevée, que ce type de protocole est efficace...
Sur boucle locale, pour du transfert "brut", je fais bien mieux que ICE en terme de débit en faisant mon code en dur. Sur connexion Internet, avec les latences de ce réseau, c'est pas gagné d'avance par contre.
Tu comprends mieux la problématique ?

Par exemple on pourrait imaginer ce type d'appel:<snip>
En implementant l'interface necessaire, on devrait pouvoir fournir notre protocole "serial" de communication.

Sauf que ça ne marchera pas. ICE se base, notamment pour la fiabilité des connexions et des transferts de données, sur certaines présuppositions qui ne seraient pas remplies par ton transfert série (intégrité des données, connexion persistante, réémission transparente, acquittements, etc.). Sans ça, tu ne pourrais pas implémenter certaines fonctions sans devoir explicitement demander des acquittements, ce qui plomberait à la fois ton protocole série et tes performances.
Pour résoudre ça, il te faudrait dupliquer le médium de communication, avec un canal "données" (ton protocole série dans ce cas), et un canal "commande" (les données propres à ICE) sur un autre médium... Ce qui serait bien trop lourd.

Pour repondre a mon interrogation premiere, je vais sticker avec Ice(-E) pour un moment, et voir si c'est reellement aussi simple et pratique que ca m'en a l'air.

Attention : c'est une version réduite de ICE, mais ça reste axé sur le même but !! Vois-le plutôt comme une manière simple d'implémenter des servants sur une machine faible en ressources.


N'oublie pas : ICE permet de définir une communication axée sur les données, l'utilisateur d'un endpoint se contrefiche de savoir par où et comment ça passe : il veut la donnée désirée, point barre.
Toi, tu sembles plutôt vouloir supporter un protocole de transfert, ce qui est certes parfaitement automatisable avec les bons langages de description, mais ce n'est absolument pas la même problématique.

Mais c'est par contre tout à fait possible d'avoir des générateurs de code qui, à partir de la description d'un protocole, te crachent un module (plus ou moins portable) permettant de coder/décoder ce protocole, et même de gérer la connexion au médium suivant l'OS. Déjà testé, vérifié, et en production...