Erlang対The Real / Outsideの世界、コミュニケーションの方法は?
質問
アーランを学んでおり、mnesia dbに非常に興味を持っています。バックエンドとしてerlangを使用して、C#/ F#で実際のアプリケーションを構築したいです。
外部のアーランノードと通信するための適切なソリューションを探しています。
これまでに見つけたもの:
(A) OTP.net 、「ネイティブ」アーラン通信プロトコルを実装するオープンソースの.netライブラリ
問題はこちら:
- ライブラリはあまり成熟していません
- Javaから移植されたオブジェクトモデルが嫌いです(BCLクラスのほとんど正確なレプリカが多すぎます)
- 接続にスレッドモデルを使用するのは好きではありません。
- 多くのオープンTCPポートが必要です
- セキュリティの欠如
(B)アーランでポート/ソケットを使用し、カスタムプロトコルを実装します。
問題はこちら:
- 経験がない
- 将来のバージョンのために維持/拡張するのが難しい
このトピックに関するアドバイスや経験はありますか?
OTP.netライブラリで作業して自分のニーズに合うようにするか、新しいプロトコルをゼロから実装しようとしますか?
JSONまたはRESTソリューションはどうですか?トリックを行うアーランライブラリはありますか?
解決
ポート/ソケットソリューションは良い考えであり、見た目ほど難しくはありません。 Googleのプロトコルバッファは、まさに必要なものです。それは非常に使いやすく、効率的で保守可能です。 C#、erlang、java、pythonなどの実装があります( OtherLanguages を参照してください)および開発者ガイド)
プロトコルバッファを使用して、要求および応答プロトコル構造を定義できます。次に、それを使用して、アーランと他のサポートされている言語との間で通信します。 チュートリアルですべて説明されています。その後、ポートを介して応答を送信するだけです。
このアプローチの利点は次のとおりです。
- 簡単に拡張および変更できます 将来のプロトコル
- よりもはるかに効率的です RESTアプローチ
- 現在、Googleで使用されています 内部RPCのほぼすべて プロトコルとファイル形式
他のヒント
ErlangでREST APIを実装する場合、行うべきことは1つだけです。優れた MochiWeb Kit を使用して、プロトコルを実装する独自のHTTPサーバーを構築します。
パニックにならないでください。実際に表示されるよりも簡単です。
を含む、その方法に関するチュートリアルが多数あります。 Pragmatic Programmersのスクリーンキャストセット。
jsonライブラリの完全なセットが付属しているので、大丈夫です!
もちろん、ErlangでRESTを実行できます。 http://www.infoq.com/articles/vinoski-erlang-rest-アプリのニーズに適している場合、RESTは優れたアプローチです。 (来週フィレンツェで開催されるPycon Italia Treには、Erlang / Pythonの協力に関するセッションがあります。トスカーナの近くにいる場合はwww.pycon.itをご覧ください;-)。
JSONもありますErlangのライブラリをご覧ください。使ったことがないので、経験からは何も言えません。
YawsまたはMochikitを使用するかどうかにかかわらず、いくつかのRESTソリューションが有用であることに同意しますが、いくつかの中間的な「言語」を定義しようとしていることに気付くでしょう。 Mnesiaが処理できるクエリを生成するため。
したがって、私はこのアドバイスを提供します。自分で考えているプロジェクトが何であれ、それをアーランで実装し、利用可能なツールを使用するだけです。多くの方法で報酬が与えられます。
この場合も、CouchDBをいつでも試すことができます。
これを行うには、YAWSと、クライアント側での単純なhttp要求/応答の実装を使用します。 YAWS実装は、引数を抽出した後、呼び出しを適切なgen_serverプロセスに単に委任します。
このアプローチの唯一の欠点は、それほど高速ではないことです(Googleプロトコルバッファの方が良いでしょう)。そして、接続を「アライブ」に保つことにより、 HTTPの用語では、セットアップコストをすべて削減し、古いソケット接続の数を減らしました。大量のデータを返す場合は、結果をストリーミングすることでもう少し創造性を得る必要があります。問題ではなかったほとんどのデータリクエストでは、応答がメモリに簡単に収まります。
プロトコルの生のパフォーマンスがそれほど問題ではない場合、いくつかの利点があります:
- セキュリティモデル(HTTPSまたは認証)にフックできます
- Webリクエストを行うことができるものなら何でもAPIを呼び出すことができます(古いperlコードとExcelシートがたくさんありました-並べ替えは簡単でした)
OTP.NETを書き直してから
このライブラリは、.NET / CLR用にゼロから書き直されたため、何倍も成熟しています。 (Javaから変換されたばかりの前身とは異なり)
この投稿をご覧ください:
http://blog.aumcode。 com / 2013/10 / nfx-native-interoperability-of-net-with.html