■ ActiveX Scriptingって何?
62回でも少し触れた「ActiveX Scripting」について、今回はもう少し細かく説明していきたいと思います。説明はやや重複しますが、ActiveX Scripting自体は厳密な意味ではスクリプトではありません。複数のスクリプト言語をアプリケーションから共通に使えるようにする、というインターフェイスです。
■ 従来のスクリプトの制限
|
図1:従来のスクリプト言語の対応
|
スクリプト言語と呼ばれるものは68回でもお話したように数多くありますが、基本的にはスクリプト言語と対になるインタープリタと組み合わせて利用されます。例えば3種類のスクリプト言語があったら、インタープリタも3種類必要になるわけです(図1)。
問題はすべてのインタープリタが同じ機能を持っているとは限らないし、またどのスクリプト言語を使いたいかには人間の好みが介在することです。例えば、機能的にはインタープリタ3が1番良いけど、プログラミングに慣れているのはインタープリタ1であるという場合には困ってしまうわけです。
なるべく多くのスクリプト言語に対応する、ということを実現した1つがApacheでしょう。実際、Apache上でCGIを使う場合、PerlやPHP、Rubyなど複数のスクリプト言語でCGIを記述したいという要望が多くありました。これを実現するために、当初は図2の左側のようにApacheから各インタープリタを呼び出して処理をさせ、その結果を受け取って返すという仕組みを取っていました。これは確かに問題なく動くのですが、システム負荷が高いために性能面でのペナルティが無視できなくなってきました。
|
図2:多言語対応例
|
そこでApacheの中に、mod_Perl/mod_PHP/mod_Rubyといった、各々のインタープリタの動作するプラグインを組み込む形で、Apacheが各スクリプト言語を直接解釈・実行できる仕組みを取ったことで負荷の問題が大幅に軽減されるようになりました。
Apacheの場合、多くの人間がApacheへのインタープリタの移植という作業に取り組んだ結果実現したのであって、Apache以外のアプリケーションでも同様にmod_Perlなどを組み込めば使えるようになるのかというと、そういう話ではありません。これらのプラグインはApacheに組み込むことを前提に作られているので、他のアプリケーションで使うことをそもそも考えていません。このため、以下の作業を行なわないと同等の環境を手に入れられません。
・そのアプリケーションに、Apache互換のプラグインのI/Fを追加する
・そのアプリケーション用に、各スクリプト言語用のプラグインを用意する
このあたりが、汎用のスクリプト言語が普及する妨げの1つになっていました。
■ ActiveX Scriptingで提供されるもの
|
図3:ActiveX Scripting
|
さて、それではActiveX Scriptingではどのようなことが可能になるかを示したのが図3です。構図的には図2の左側にちょっと似ていますが、大きな違いがあります。
図2がプログラムそのものを呼び出す形になっているので、極端に言うとスクリプトを処理するたびにインタープリタを起動するようなイメージ(*1)なのに対し、図3ではインタープリタは常駐するか、ケースによっては(呼び出すプログラムと)同じプロセスで処理できるために負荷が小さくなっています。
また、図2のケースでは標準的なインターフェイス(UNIX系ならShell、Windows系ならDOSプロンプト)経由となるので、あまり細かな制御はできません。しかし、図3の場合はスクリプト処理専用インターフェイスとなり、プログラムからの細かな制御が可能になっています。
実際、これにより柔軟な構成が可能になっています。Microsoftは標準でVBScript(正式名称はMicrosoft Visual Basic Scripting Edition)という、Basicライクなスクリプト言語を無償で提供しているほか、JavaScriptに(機能面では)よく似たJScriptというスクリプト言語もサポートしています。これはIEやIIS、あるいは必要ならMicrosoft Officeに含まれるWordやExcelといったアプリケーションで利用できます。しかし、例えばJavaScriptはMozillaやFirefoxなどのブラウザが自前でインタプリタを持っているのに対し、IEはこのインタプリタを持っておらず、ActiveX Scripting I/F経由で使う形になるわけです。
つまり、IEやIIS、Officeなどで、すべて同じインタープリタが動作することになりますから、VBScriptに慣れた人はすべてのアプリケーションでVBScriptを、JScriptに慣れた人はすべてのアプリケーションでJScriptを使うことができるというわけです。
このActiveX Scripting I/Fは、インタープリタとこれを呼び出すアプリケーションの両方に対して公開されています。このため、自分でアプリケーションを作る際に、ActiveX Scripting I/Fへの対応を行なえば、自分のアプリケーションがVBScriptなどで動作するようになりますし、ActiveX Scripting I/Fに対応したインタープリタを作れば、IEやIISの中からこれを利用できるようになります。実際、62回目で紹介したActive Perlを組み込んで、IIS+Perlという構成でサイトを構築する例は少なくありません。何かの理由でWindows+IISという構成でサーバーを立てなければならないという制約があり、しかし自分はPerlに慣れているケースでも、このActiveX Scriptingのお陰で対応できるわけです。
■ ActiveX Scriptingの問題点
最大の問題は、やはりWindowsプラットフォーム上でしか動作しないことでしょう。この点に関しては、62回、63回、64回で書いていますので、ここでは繰り返しません。極めて個人的な話で言えば、複数のスクリプト言語が利用できる環境で、微妙にできることが違うというのは少し厄介だったりします。筆者の体験では、「処理の大半は完成したけど、どうしてもこの1点が解決できない」という理由で書きかけのCShellスクリプトを廃棄してBShellで書き直すなんてことが何度かありましたが、似たような話が再現しないことを祈るのみです。
*1:さすがにこの場合では負荷が大きすぎるので、インタープリタを継続動作させるオプションもあります。
2006/03/20 11:01
槻ノ木 隆 国内某メーカーのネットワーク関係「エンジニア」から「元エンジニア」に限りなく近いところに流れてきてしまった。ここ2年ほどは、企画とか教育、営業に近いことばかりやっており、まもなく肩書きは「退役エンジニア」になると思われる。(イラスト:Mikebow) |
|