J'ai utilisé toutes les technologies décrites, et beaucoup d'autres pour l'interface avec D3. Je suis d'accord avec @Glenn et j'ajouterai ... Je comprends que vous vous éloignez de .NET. C'est bon, vous n'en avez pas besoin. Mais considérons que la plupart des implémentations LAMP séparent les serveurs SGBD des serveurs Web. Cette topologie introduit de courts délais entre les niveaux mais les dissocie au cas où vous souhaiteriez utiliser plusieurs serveurs Web ou plusieurs bases de données - une topologie commune même avec D3/MV.
J'ai un client où nous avons un frontal Java/Grails sur Linux, avec toutes les requêtes de données filtrées à travers une seule classe de fournisseur de données élégante qui est abstraite de la logique de l'application. Cela utilise un appel de service Web que j'ai écrit en Java, appelant à un service Web .NET. Le service est facilement généré/modifié, tout comme le client du WSDL. A partir de là, IIS achemine les requêtes entrantes vers D3 via mv.NET, et à ce stade, peu importe si le SGBD D3 est sous Linux ou Windows. Mon service web aurait pu être aussi facilement sous Linux avec Java mais il n'y aurait pas de mécanisme de mise en commun - voir ci-dessous.
Si vous voulez tout Linux alors vous pouvez aller avec la bibliothèque Java MVSP. TigerLogic (maintenant acquis par Rocket Software) s'est engagé à une liaison PHP pour MVSP il y a quelques mois. Plutôt que d'attendre, un de mes clients a créé un wrapper PHP autour de mv.NET, même si MVSP est aussi facile. Donc l'application qui en résulte est essentiellement LAMP, mais avec le M = Multivalue. J'ai aussi écrit un code comme celui-ci - nous pouvons écrire un wrapper dans n'importe quel langage qui expose une API utile et résume à la fois la méthode de connectivité et les dépendances du système d'exploitation. En d'autres termes, peu importe les langues que nous voulons utiliser ou les systèmes d'exploitation impliqués. Cette partie est plutôt triviale et sujette à changement plus tard. Il est préférable de se concentrer sur l'application que sur les communications.
Vous pouvez également quitter le menu, pour ainsi dire, et créer votre propre wrapper Java/PHP autour de la commande d3tcl au niveau OS, qui est un script/wrapper autour de l'exécutable d3. Cela vous permet d'ouvrir une connexion et de passer des commandes. Quelle que soit l'option que vous sélectionnez, vous devez considérer que l'ouverture et la fermeture d'une connexion DBMS est un processus lent. Vous ne voulez pas écrire un login autour de chaque demande de données. Vous voulez ouvrir une connexion et la maintenir ouverte de manière persistante, tandis que votre code client accède et libère cette connexion persistante si nécessaire. C'est pourquoi nous aimons mv.NET et FlashCONNECT. Avec MVSP et d'autres mécanismes, vous devez créer votre propre modèle de persistance. Vous aurez également besoin de gérer un pool de ressources de connexion - que se passe-t-il lorsque vous obtenez 10 requêtes simultanées, ou juste une courte une après une longue? Vous ne voulez pas que les requêtes soient sauvegardées, vous ne voulez pas rejeter ou annuler les connexions, et vous ne voulez pas déclencher une connexion pour chaque client. Vous voulez le nombre correct de sessions de SGBD en attente de connexions entrantes. mv.NET et FlashCONNECT le font pour vous, les autres ne le font pas.
Personnellement, je serais loin de FlashCONNECT. J'étais là pour son développement et ses tests initiaux et pour des années d'implémentation par les utilisateurs finaux. Ce n'est pas aussi largement utilisé que les autres options et est plus un outil pour ceux qui ne sont pas familiers avec d'autres options. Si vous parlez de Java, vous n'êtes probablement pas enclin à utiliser FlashCONNECT. Cela dit, si vous avez des développeurs qui ne connaissent rien en dehors de D3, alors FlashCONNECT est un outil côté serveur décent pour eux alors que quelqu'un d'autre se concentre sur le côté client avec d'autres technologies. Tout le monde devrait utiliser leurs meilleures compétences. Enfin, (déjà?) Si quelqu'un n'est pas familier avec les technologies externes, et plus intime avec D3, alors d'autres options existent comme DesignBAIS et Viságe, supprimant le fardeau des communications et permettant aux développeurs de travailler côté client fonctionnalités et règles back-end dans BASIC.Je discute de tous ces sujets ainsi que de la téléphonie mobile et de la téléphonie au my blog.
HTH
Merci de votre participation Glenn. Nos installations D3 sont principalement basées sur Linux (CENTOS) et je voudrais que les serveurs web tournent sur la même machine ... donc tout est propre et les utilisateurs peuvent simplement passer à travers un navigateur en utilisant un port dédié. D'où l'exclusion de .NET. – user1682651
Glenn Avez-vous des opinions sur l'option MVS Toolkit/WSDL? – user1682651
En outre, je ne suis pas enthousiaste à l'idée d'être fortement dépendante de MS - d'où la stratégie du navigateur frontal. – user1682651