créer une bibliothèque dans une langue unique avec des interfaces pour tout le reste

Question

Notre activité tourne actuellement autour du développement d'une bibliothèque, qui peut être utilisée dans un large éventail d'industries (desktop, mobile, web et embarqué). Pour le moment, nous n'avons que des clients dans le monde du bureau et du Web et nous constatons déjà que nous devons essentiellement dupliquer notre code dans plusieurs langues (C#, java et C++). Comment cela est-il généralement géré dans d'autres entreprises, devons-nous vraiment nous contenter d'avoir notre middleware écrit en plusieurs langues pour répondre à des industries très différentes.

Nous avons essayé C# interop avec java jni mais les résultats n'étaient pas aussi bons que nous l'espérions et cela ne semblait pas être une bonne solution professionnelle. Tout le monde a des idées sur la façon de garder le noyau dans une seule langue, mais de développer des interfaces dans différents langages pour les différentes industries.

Answer 1

Je n'ai pas beaucoup d'idées quand il s'agit de l'industrie, mais je suppose que le problème est similaire à d'autres scénarios pas si strictes. On ne sait pas non plus ce que vous entendez par "middleware". Quoi qu'il en soit, je vous encourage à ne pas dupliquer le code et à avoir, si nécessaire, plusieurs interfaces avec les autres langues. Dans un scénario idéal, il serait très pratique d'avoir un processus isolé avec la logique de votre application, écrite dans n'importe quelle langue que vous vous sentez plus à l'aise, et avoir ce processus pour communiquer en utilisant certains mécanismes de communication inter-processus (p. Ex. pipes, sockets, mémoire partagée, fichiers) avec des bibliothèques clientes minces qui pourraient être utilisées par les clients dans les autres langues. De cette façon, vous êtes obligé de créer un protocole de communication/utilisation très propre et d'avoir une séparation des préoccupations (parce que toute la communication doit être sérialisée); vous gagnez en robustesse (une erreur fatale dans votre processus d'application ou dans votre client ne signifie pas nécessairement un crash dans l'autre) et vous n'avez pas besoin d'utiliser des mécanismes ffi, mais plutôt des choses comme des sockets et des pipes. Encore plus, si vous décidez de publier votre comm. protocole, puis les développeurs tiers peuvent créer des enveloppes dans leur langage de prédilection exotique sans avoir besoin de liaison directe/importation à vos composants de développement.

Ce type de paradigme a été utilisé avec succès au fil des années dans le monde unix et des logiciels comme Mathematica. Dans un mouvement similaire, les développeurs de Java ont fait en sorte que le plugin Java fonctionne hors navigateur, dans un processus séparé, afin de réduire la complexité de l'interopérabilité.

Answer 2

Choisissez des normes de dénominateur commun: REST ou SOAP/XML sur HTTP peuvent être utilisés par beaucoup de langages, y compris Java et C#.

Vous serez confronté à des standards WS- * lourds et à une grande latence réseau, mais si l'interopérabilité est votre objectif, c'est une façon de l'atteindre.

Answer 3

Ah, j'ai oublié, peut-être que vous pouvez utiliser ceci: ICE (http://www.zeroc.com/overview.html). C'est probablement la couche d'interopérabilité la plus légère que vous pouvez utiliser pour communiquer de manière propre java, C++, C#, python et quelques autres. Ils ont même une solution d'intégration ...

Answer 4

Jetez un coup d'œil au langage HAXE. Il "compile" à une douzaine d'autres langues.

http://haxe.org/