アカウント名:
パスワード:
（記事はネイティブプログラムの話だと思うけど、、、）複数の言語間で接続するのってCORBAとかなかったけ？
最近だと、システムとシステムとつなぐのに、プログラムの直接呼び出しではなくて、ウェブAPI等で接続するのが一般的になっている気が。メモリやデータベースを直接いじらせなくて済むので、アクセスを制限して、接続を求めてくるシステムを信用する必要がなくて済むし。ニコニコ動画なんか、ベースの部分はPHP、メッセージングはC++、大百科はRuby、他のサブシステムはPythonみたいな。内部のウェブAPIで統一されてるんでサブシステムは何言語でもOK。
CORBA以外だと、MicrosoftのDCOMがそうですね。元ネタはCORBAですが。あと、XMLベースのSOAPとかもありましたね。
これらのプロトコルは独自の型システムを持つ大掛かりなものでしたが、複雑すぎて結局使われませんでした。いまでは、がんばって包括的なスキームを構築するより、個々のアプリをサービスとして設計してウェブAPIで結合するのが一般的になってますね。
ウェブAPIでは主にテキストベースになりますので、ある意味、古き良きUNIX的なテキスト志向の勝利といえなくもないかな？
> 複雑すぎて結局使われませんでした
Mozilla系で使われているXPCOMはCORBA準拠で、C++とJavaScriptを共通のIDL(xpidl)で制御している。今でも。
あるいは、単純なデータのやりとりなら、最終的にはプロセス間通信すりゃいいわけで、d-busみたいなメッセージバスが屋台骨じゃないかな。速度的な問題はあるだろうけど。あと、今だと、ctypesをスクリプト言語で読むのが流行しているような。
python-ctypes [python.jp]DL::Importer [ruby-lang.org]js-ctypes [mozilla.org]とりあえず、Cでライブラリを作っておけば、読めないスクリプト言語はない、という感じで。この辺、ヘッダ(*.h)をスクリプト言語に変換する機能とかがあれば猶いいんだろうけれど。
GnomeもCORBA使ってる。D-BUSも。WindowsもターミナルサービスとかDCOM使ってるんじゃないの？でもって、さらに遡ればいくつかRPCがあるし。でもってXML-RPCとか。
元記事を踏まえると、密結合するのは色々面倒くさくて、歴史的には疎結合へ流れたってところですか。
MozillaはXPCOMをまた徐々に密結合(WebIDL bindings)に置き換えてる最中だけどね。
複雑すぎてと言うより、ネットが遅くて分散処理するのは現実的じゃなかった。
汎用的な話としていっているならば、「ああ、あそこで作ったあの仕組み使いたいなぁ…」っていうときに、公開APIを作ってなかったらいちいちWEB APIを作り、IOコストをかけてリクエストをおくらなきゃいけない。しかも別環境のデータを使わなきゃいけない時にはそれなりに改修を加えたりシなきゃいけない…というのが利便性や要件との適合性の観点で欠点なような…。相互のメンテナンススケジュールを意識しあわなきゃいけないとか、やり始めるとそっちはそっちでも問題出てきますよね。
ところで、元ネタの話し的には、ActiveScriptingって先進的な事やってたよね…という話になるんじゃないかと思ったわけですが、あまり一般的ではないのかしら。
# VBとRubyをActiveScriptingで結合して作った物を本番に出そうとして上から怒られたなぁという十数年前の事を思い出しつつ、AC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
ウェブAPIで疎結合 (スコア:1)
（記事はネイティブプログラムの話だと思うけど、、、）
複数の言語間で接続するのってCORBAとかなかったけ？
最近だと、システムとシステムとつなぐのに、プログラムの直接呼び出しではなくて、ウェブAPI等で接続するのが一般的になっている気が。
メモリやデータベースを直接いじらせなくて済むので、アクセスを制限して、接続を求めてくるシステムを信用する必要がなくて済むし。
ニコニコ動画なんか、ベースの部分はPHP、メッセージングはC++、大百科はRuby、他のサブシステムはPythonみたいな。
内部のウェブAPIで統一されてるんでサブシステムは何言語でもOK。
Re:ウェブAPIで疎結合 (スコア:1)
CORBA以外だと、MicrosoftのDCOMがそうですね。元ネタはCORBAですが。
あと、XMLベースのSOAPとかもありましたね。
これらのプロトコルは独自の型システムを持つ大掛かりなものでしたが、複雑すぎて結局使われませんでした。
いまでは、がんばって包括的なスキームを構築するより、
個々のアプリをサービスとして設計してウェブAPIで結合するのが一般的になってますね。
ウェブAPIでは主にテキストベースになりますので、ある意味、古き良きUNIX的なテキスト志向の勝利といえなくもないかな？
Re:ウェブAPIで疎結合 (スコア:2, 参考になる)
> 複雑すぎて結局使われませんでした
Mozilla系で使われているXPCOMはCORBA準拠で、C++とJavaScriptを共通のIDL(xpidl)で制御している。今でも。
あるいは、単純なデータのやりとりなら、最終的にはプロセス間通信すりゃいいわけで、d-busみたいなメッセージバスが屋台骨じゃないかな。速度的な問題はあるだろうけど。あと、今だと、ctypesをスクリプト言語で読むのが流行しているような。
python-ctypes [python.jp]
DL::Importer [ruby-lang.org]
js-ctypes [mozilla.org]
とりあえず、Cでライブラリを作っておけば、読めないスクリプト言語はない、という感じで。この辺、ヘッダ(*.h)をスクリプト言語に変換する機能とかがあれば猶いいんだろうけれど。
Re:ウェブAPIで疎結合 (スコア:1)
GnomeもCORBA使ってる。D-BUSも。
WindowsもターミナルサービスとかDCOM使ってるんじゃないの？
でもって、さらに遡ればいくつかRPCがあるし。
でもってXML-RPCとか。
元記事を踏まえると、密結合するのは色々面倒くさくて、歴史的には疎結合へ流れたってところですか。
Re:ウェブAPIで疎結合 (スコア:1)
MozillaはXPCOMをまた徐々に密結合(WebIDL bindings)に置き換えてる最中だけどね。
Re: (スコア:0)
複雑すぎてと言うより、ネットが遅くて分散処理するのは現実的じゃなかった。
Re: (スコア:0)
汎用的な話としていっているならば、「ああ、あそこで作ったあの仕組み使いたいなぁ…」っていうときに、公開APIを作ってなかったらいちいちWEB APIを作り、IOコストをかけてリクエストをおくらなきゃいけない。しかも別環境のデータを使わなきゃいけない時にはそれなりに改修を加えたりシなきゃいけない…というのが利便性や要件との適合性の観点で欠点なような…。
相互のメンテナンススケジュールを意識しあわなきゃいけないとか、やり始めるとそっちはそっちでも問題出てきますよね。
ところで、元ネタの話し的には、ActiveScriptingって先進的な事やってたよね…という話になるんじゃないかと思ったわけですが、あまり一般的ではないのかしら。
# VBとRubyをActiveScriptingで結合して作った物を本番に出そうとして上から怒られたなぁという十数年前の事を思い出しつつ、AC