3

私は複雑で成熟した科学的データ処理プロジェクトを持っています。このプロジェクトは、ほとんどが VB6 で記述された複雑な Web サーバーで構成されており、ほとんどの一般的なユーザーが短い VBA プログラムを作成しているため、UI はほとんど使用されていません (フォームもコントロールもありません)。

今後の目標は次の 2 つです。

  1. Linux 上の Web サービス コンポーネントを使用して Web UI を作成します

  2. プロジェクトを徐々に D/Python に移行し、Windows および VB6 から移行します

私たちは、両方の目標の最良の共通の指名者として機能するメッセージング フレームワークを設計する段階にあります。

プロジェクトは、カスタム R スクリプトと LaTeX/MS Word/Excel レポートの実行を含む、大量の処理タスクを実行します。一部の機能を幅広い顧客に公開する必要があり、Web UI が最適なオプションと思われます。一方、私たちの環境での Windows の使用は徐々に減少しているため、最終的にはプロジェクトを Linux に移植するか、少なくともそのオプションを開いたままにして、Windows 固有のテクノロジに縛られないようにしたいと考えています。

  • この観点から、自然な .NET ベースのソリューションは、そもそも避けたいものです。

  • DCOM/MSRPC は VB6 の観点からは当然のように見えますが、このテクノロジは価値が低く、安全ではありません。さらに、プロジェクトの Web サービス部分を Linux に残したいと考えています。

  • したがって、最良のオプションは、Web サービス部分を Linux で作成することです (Python や D などを使用)。VB6 と Python (または D) の間で効率的に通信を行うにはどうすればよいかという問題が残ります。ある種のネットワーク プロトコルになることは明らかです。私たちが必要としているのは、効率的で使いやすいプロトコルであり、2 つのパーティ間でイベントとメッセージを渡すことができます。転送されるデータ量は少なく、高いレイテンシーは重要ではありません。

    • DCOM/MSRPCはローカル通信を行うのに問題ないように見えますが、Linux 側で行うのは本当に簡単でしょうか? これまでのところ、Python の経験はほとんどなく、D ではサポートされていません。
    • カスタム IP プロトコル。私たちのニーズは小さいので、それでうまくいくかもしれません。しかし、それは車輪の再発明ではありませんか?
    • 私たちのプロジェクトの一部はすでに JSON を使用しており、公開されている Python とVB6のクライアントを使用しているため、 JSON-RPCのアイデアが気に入っています。

私たちの仕事には、もっと多くの実行可能な解決策があると思います。私たちはそれを手伝ってくれる人を雇いますが、その前に、どのような技術が利用可能で、どこ (誰) に助けを求めるべきかを知る必要があります。

4

2 に答える 2

4

最初に頭に浮かぶのは、Google Protocol Buffers、Thrift、MessagePack、Avro などのシリアル化プロトコルです。これらは非常に人気があるため、そのうちの 1 つが VB6 で既に実装されている必要があります。私の知る限り、おそらく Avro を除くすべてが D でも実装されているため、VB6 の世界の状況によっては選択肢がほとんどない場合があります。私の提案は、それらのいずれかを選択して使用することです。または、VB6 の REST サポートがある場合は、おそらくLinux 側のVibeDがその仕事をしてくれるでしょう。

于 2013-11-12T22:51:42.347 に答える