3

他のアプリケーションから呼び出されるFORTRAN API を持つ古いアプリケーションがあります。しばらくして、彼らはFORTRAN API用の(C)ラッパーを作成しました。次に、 C API用の少しのデータ処理を備えたC ++ラッパーを作成しています。

ですから、どのプログラミング言語からでも呼び出せる API を構築する最善の方法は何かを考えています。

現在、c++ API から RPC サーバーを構築する予定です。その後、任意のプログラミング言語を使用する任意のクライアントがそれを呼び出すことができます。

XML-RPCが優れていることがわかりました。ただし、接続にはHTTP サーバーが必要です。

問題は、私たちの API を呼び出すアプリケーションがデスクトップ アプリケーションであることです。そして、XML-RPC は複雑なオブジェクトを操作できないことがわかりました。

SOAPは適切なソリューションですか? クライアント側は簡単に実装できますか?

では、私の状況に最適な技術的解決策は何ですか? どのテクノロジーを使用する必要がありますか?

コメント: Fortran API と C API を変更する権限がありません。また、新しいメソッドを追加し、ユーザーがメソッドを簡単に呼び出せるようにコードを拡張しているため、c++ API が必要です。

よろしくお願いします、

4

3 に答える 3

2

最善の方法は、それをそのままにして、C API のみを使用することです。実質的にすべてのプログラミング言語は C API を直接呼び出すことができるため、特定の言語のプログラミング モデルが別の方法でより意味のあるものでない限り、ラッパーを作成する理由はありません。

私の言いたいことを明確にするために、GTK+ を見てください。これは C API であり、ほぼすべての言語で使用できます。ラッパーは、GTK+ API への純粋な OOP アプローチを提供するオブジェクト指向言語に存在します。これは、API のドメインを考えると、それらの言語にとって意味があるためです。

オブジェクト化されたインターフェースはアプリケーションにとって意味がありますか? そうでない場合は、わざわざ C++ ラッパーを作成する必要はありません。

RPC に関して言えば、共有メモリを使用した単純なメッセージ パッシング インターフェイスで十分ではないのはなぜですか?

于 2009-02-28T20:16:42.093 に答える
0

SOAP や XML-RPC などは通常、コンピュータ間の通信に使用されますが、これでよろしいですか? それとも、これはすべて 1 台のコンピューターで実行されているだけですか?

1台のコンピューター上にある場合は、C APIをそのまま使用してください。ほとんどのシステムはそれを使用できます

C API を REST スタイル サービスとしてモデル化すると、C API なしでは使用できないが、ドキュメント化するシステムが 1 つしかないアプリケーションに HTTP サービスを提供することもできます。

于 2009-02-28T13:32:05.373 に答える