 |
|
|
|
Explaining the MX vision
MXのビジョンを説明する
Tim AndersonがJeremy Allaire(マクロメディア最高技術責任者)と語る。
「我々はFlashを、最重要なリッチクライアントとして確立する、ということに完全に焦点を合わせている。」
Tim: 高い視点から見て、あなたはMXをどのように説明しますか。
Jeremy: この18ヶ月間、我々はMXブランドの次世代製品群を熱心に開発してきた。MXはリッチクライアント--ColdFusion MXを中心としたサーバテクノロジと連携したFlash Player--を実現する、完全に統合された製品群である。また、デザインと開発のツールをMacromedia Studio MXとして統合したパッケージである。
Tim: MXというのはなにを表しているのですか?
Jeremy: MXは、頭字語(頭文字を並べたもの)としては特に何もあらわしていない。MXのコンセプトは二つの点に言及する。Webはリッチインターネットアプリケーションを目指していると我々は考えている。リッチインターネットアプリケーションとは、コンテンツ、アプリケーションのユーザインタフェース、ネットワーク上で動くアプリケーション、そしてコミュニケーションを一つの環境に統合したものだ。それはエンドユーザの体験の質を向上させ、企業のコスト削減を可能にする。MXは我々の提供するリッチクライアント、サーバ、開発ツールパッケージを的確に統合したものだ。
Tim: MXは現在どうなっていますか。
Jeremy: Flash MXは1,2ヵ月前に発表してかなり受け入れられている。現在我々は、Flash環境をサポートする全く新しい技術のセットを発表している。ColdFusion MXはこのプラットフォームの主要な新リリースであり、J2EE上で構築されている。これで、(我々自身のものも含めた)J2EEのアプリケーションサーバのどれに対してもコンパイル、設置が可能なサーバアプリケーションを構築するために、素早いスクリプティングが可能な環境が使えるようになる。これは、Flash Remoting と呼ばれる、Flashクライアントと遠隔アプリケーションサーバとWebサービスをつなぐ新たな技術を含んでおり、これはColdFusion MXに含まれる。この技術は、Webサービスとアプリケーションサーバを、クライアント上のFlashオブジェクトと接続することを可能にする。スクリプトレベルの開発者がWebサービスを開発、使用できるように、非常に簡単なレベルで、ColdFusion内からWebサービスを作成、発行、使用するための新たな技術もある。要するに、Studio MXは、一つのスタジオに統合されたツールの集合体の主要なリリースであり、Dreamweaver MX, Flash MX, Fireworks MXをまとめたものである。
これは、それらの製品が姿をかえたものである。Dreamweaverは、Webオーサリングとサイト開発の先導的なツールから、サーバアプリケーションのための強力な開発環境へと移行しつつある。それで我々はDreamweaver、Ultradev、ColdFusion Studio環境を一つの製品、Dreamweaver MXとして結合させた。この製品は、クライアントと、Webサービスやサーバスクリプトなどを含めたサーバアプリケーションの両方を構築することを可能にする。
Flash MXも、各種デザイン機能を付加しただけでなくアプリケーション開発用の拡張もおこなって進化した。これらのツールは、標準的なユーザインタフェースコンポーネント、コンポーネントモデル、より進んだオブジェクトモデル、プログラミングツール、組み込みのデバッグ機能を持った新たなIDEを取り入れている。サーバとWebサービスをより密に統合して、リッチクライアントアプリケーションを構築する能力が真に拡張されている。
Tim: MXツールではなにが違うのですか。
Jeremy: 我々は、これらのリッチなインターネットアプリケーションがコンテンツとアプリケーションの収束を必要としていると考える。そこで我々は、異った観点、異ったタイプの開発者でも扱いが可能なだけでなく、かつこれらの環境に共通したワークフローをもった、ツールを横断できるワークスペースとIDEのモデルを開発することに取り組んだ。多くの異ったツールに分断しようとするよりも、人々にとって購入が簡単なように集約させ、統合するようにしている。あなたがStudio MXを買うとする。USでは$799.00である。これで、一つの環境でそれらのツールを全て手にいれることになる。我々はこれを皆さんのデスクトップに持って行きたい。
最初にこれらのツールを開いたとき、ツールはあなたにこうたずねかけてくる。「あなたはデザイナー? あなたは開発者? あなたはなんでもできる人?」あなたは使用したい視点の種類をえらんで、その仕事のセットに対応したワークスペースを設定することができる。自分の好みのかたちで作業することを真に可能にし、他のタイプの仕事に向いたツールを見えなくしておけるようにした。
Dreamweaver MXを純粋にコーディングビューで開いて、Webサービスとデータベースプログラミングのツールとして、Homesiteのように機能させ、他に全く何もしないということが可能だ。これは非常に効率的なコーディング環境だ。逆に、完全にデザイナーになり、スタイルシートとHTMLをデザインし、グラフィックを統合する、そのような視点をもつことも可能だ。
Tim: ColdFusionがJavaに移行するとなると、DreamweaverのASPサポートはどうなりますか。
Jeremy: 全てのMX製品を通じて、.NETとJ2EEの両方、二つの主要なプラットフォームへの強力なサポートを提供している。我々はソフトウェアのセットを、それらを置き換えようとするよりもむしろ、それらの価値を広げられるようなものとして制作している。ColdFusion MXはどのJ2EEアプリケーションサーバでも動作する。.NetのWebサービスを読み込んで使用することも可能で、ColdFusionで構築したWebサービスは.Net上でも非常に簡単に使用できる。標準的なMicrosoft APIと統合することが可能だ。
Dreamweaver MXでは、実際にサポートを拡張し、.Net開発のためにかなりリッチなサポートを付加した。古いASPと同じようにASP.Netのページを作ることができる。もちろん、この統合はDreamweaver MXとColdFusion MXの間ではより緊密である。それで我々は、MXファミリーでのみ使えるいくつかの付加的機能を加えた。
Flash Remoting
Tim: Flash Remotingについてもっと話してもらえますか?
Jeremy: これは、アプリケーションサーバ上でオブジェクトとWebサービスを、あたかもそれがローカルのActionScriptオブジェクトであるかのように触れることができるようにする技術だ。Java RMIや、.Net Remotingはそれぞれの世界で同じようなことをするという意味で似ている。Flash RemotingはHTTPの上で動く非常に効率的なバイナリプロトコルを使用しており、Flashで作成されたオブジェクトに最適化されている。サーバ内にColdFusion コンポーネントを置いているとすれば、スクリプトを使ってColdFusionサーバ上でそれを走らせることができるが、あたかもそれがローカルのFlashオブジェクトであるかのようにFlash内に読み込み、使うこともできる。つまりこれはクライアントサーバ通信のための非常に強力なフレームワークなのだ。
これで、Flashから直接SOAPのWebサービスを使うことが可能になる。Webサービスはwsdlファイルに、もしくはそのURLに置くことができる。Flash RemotingはそのWebサービスのためのプロキシを形成することになり、FlashクライアントからそのWebサービスのAPIにアクセスすることが可能になる。
Tim: Flash RemotingはColdFusion MXだけの機能なのですか?
Flash RemotingはColdFusionと.NetとJavaをサポートする。この機能はColdFusion MXについてくるが、Flash Remotingサービスを独立で手に入れることもできる。
我々はASP.Net用とJava用のアダプタを用意しているので、どのバックエンドに対しても、Flashをクライアントとして使用することができる。
これは、ColdFusionが果たしている役割が、自身で独立した独占的サーバから、他のインフラを拡張するものになっていくという一つの移行形態である。よって、私がColdFusionを購入したとき、 私が持っているJavaアプリケーションにアクセスするために、Flash Remoting機能をもつColdFusionを使うことができ、Javaアプリケーションサーバ内でコンパイルしかつ動作するアプリケーションを作成することもできる。これは過去に無かったという意味で、多くの人々にとって多少なりとも興味深いものになると思っている。
Tim: リッチクライアントとしてのFlashを推進して行くに当たって、他の種類のクライアントを好む人達を遠ざけることになるという心配は?
Jeremy: 我々はFlashを最重要のリッチクライアントとして確立することに完全に焦点を合わせている。我々は、アプリケーションを構築している人々にとってはこれが避けられないものだと感じられるだろうと考える。Flashのアーキテクチャは今やインタラクティブなアプリケーションにより適しており、過去にそのようなアプリケーションを構築したときよりもより簡単になるようにしている。
しかし、Flashがクライアントでない多くのアプリケーションも存在するだろう。明らかなことだが、基本的な静的HTMLコンテンツはすばらしいし、動的なドキュメントもすばらしい。我々はたまたまこの業界で先導的なHTMLオーサリングツールを供給しているので、かなりの特権と責任ががある。人々が構築しているもののスペクトル分布を知りたいと思っている。このようなことを反映する自前のちょっとした図面ををもっているのだ。
- あるレベルでは静的なコンテンツがあり、そのWebサイトを構築するにはDreamweaver MXとFireworks MXを使うことになるだろう。
- 次にそれを越えたリッチコンテンツがあるが、Flashを使うもののまだ静的であり、アプリケーションではない。
- そして、基本的なWebアプリケーションがある。Dreamweaver MXとColdFusion MX は動的なWebアプリケーション構築のためのすばらしいコンビネーションであり、たくさんの人がこれを使うのを見られるのが楽しみだ。
- 最後に、リッチなインターネットアプリケーションがある。ここでリッチクライアントをてこ入れして、この新たなサービスベースのモデルをサーバ上でてこ入れして、アプリケーションを構築する。
これがスペクトル分布だ。我々はこれらのスペクトルを通じて、人々が将来にわたってこのようなリッチなインターネットアプリケーションへ向かっていくことを可能にしたい。
「Flashはコンピューティングの歴史で最も広く配布されたランタイムである。」
なぜJavaクライアントではないのか?
Tim: Flashをつかうのでなく、リッチなJavaクライアントを開発することは考えましたか。
Jeremy: それは数年前にやろうとしたがうまくいかなかった。Javaはユーザにとって取得が難しいほどの大きな領域を占める。遅いし、人々がFlashのようなもので構築する集約的なタイプのインタフェースには効率的でなかった。実際には真にクロスプラットフォームとは言えず、動作の仕方に一致しないところがたくさんある。
リッチクライアントとしてのFlashについて一つおぼえておくべきなのは、我々がインターネット上で98.3%の普及率を得たということだ。これはコンピューティングの歴史で最も広く配布されたランタイム(実行環境)である。そうなった理由は、焦点がはっきりしており、非常に小さい領域しか消費しないということだ。ランタイムは全部で350Kである。そしてそのランタイムは一日に230万回ダウンロードが行われる。12ヵ月で80%の普及率を得ることができる。これは焦点がはっきりしていたからだ。
我々が、顧客が用意して使ってもらわなければならないものとしてもっと広帯域なインフラを採用していたら、全く異った状況になっただろう。例えば、Flash MXはビデオのランタイムを持っており、それは帯域幅が狭くてもそれなりのクオリティのビデオを得られるようにする非常に効率的なビデオランタイムである。ビデオランタイムは全体で50Kで、もし別のプラットフォームでやっていたとしたら全く想像もできない数字だ。我々は非常に細かいレベルでこれをカスタマイズし、最適化することができる。
Tim: Flashフォーマットについての方針は? これは発表された仕様なのですか?
Jeremy: そのとおり。リリースのあとにいつも発表している。このフォーマットをライセンスした企業は約200あり、あらゆる種類の用途(オーサリングツール、アプリケーション、組み込み機器など)に使われている。これはオープンな技術だ。
なぜColdFusion MX?
Tim: ただJavaを書くだけでいい場合に、なぜ独占的なタグ言語からJavaサーブレットを生成するのですか。
Jeremy: 我々が知ったのは、Webアプリケーションを構築する人々の圧倒的な多数派はスクリプトレベルの開発者だということだ。彼らはシステムプログラマではない。もちろん、システムプログラマと企業レベルの開発者も非常に多くの数がいるが、彼らはかなり満足している。しかしWebアプリケーションのざっと75%はスクリプトレベルの開発者によって構築されていることが分かっている。そのような人々のコミュニティ(スクリプト言語を使うことを好む伝統的なアプリケーション開発者と、Webの他の部分からやってきて現れる新しい開発者、クライアントサイドの開発者、リッチメディアの開発者、その他こちらの方向にやって来る道をもっている人々の両方)にとってこれは非常に重要なことだ。同時に、彼らはEnterprise Javaの標準化の利益とスケーラビリティの利益をすべて享受したいと思っている。そしてこれこそがここで本当に焦点をあてていることだ。我々は実際のところこれが企業に対して非常にアピールすることになるだろうと考える。彼らはかなりの量のインフラ(WebSphereやiPlanet他、主要なプラットフォームの多くのもの)にたくさんの金を投資してきた。そのインフラの多くは、その上でアプリケーションを構築するスキルのある人が十分にいないと言う理由で使われないでいた。だから我々はその価値を拡大するのだ。
我々の持つリッチクライアントモデルと、その関連として開発しているオーサリング、開発ツールでコンパイルすれば、非常にアクセス性が高くて手に入りやすく、採用するのが容易なものになると考えている。
ColdFusion MXとMicrosoft .Net
Tim: ColdFusionはサーバサイドJavaにアクセスでき、Windows COMコンポーネントにもアクセスできます。ネイティブな .Netコンポーネントにアクセスすることは可能ですか?
Jeremy: 二つの方法がある。一つはWebサービスとしてアクセスするという方法だ。これを行うのは非常に簡単だ。.NetのWebサービスを読み込んで、ColdFusion内でそれに合わせたスクリプトを書くだけでいい。Webサービスを使う場合のもっとも簡単な方法だ。Dreamweaver MXにこれを行うためのオーサリングサポート機能がある。これが我々の押し進めるモデルだ。
二つめの方法は、.NetのCOM相互通信技術を使うことだ。COMオブジェクトのCOM APIを読み込んで使うことができ、こうすることでColdFusionがCOM APIにアクセスできるようになる。我々は.Net Remotingのようなもの使った他のタイプの統合に注目していてそれは可能なのだが、まだ早すぎるようだ。.Netオブジェクトはまだ出回っていない。我々は顧客のパターンがどのようなものか、自分のシステムがWebサービスとゆるく合わさっている状態にしておくのがいいのか、それとも緊密なバイナリレベルの統合を求めているのかを見極めようとしている。
Tim: マイクロソフトは開発者をASP.Netに移行させるのに成功すると思いますか。それともJavaが市場のシェアを伸ばすでしょうか?
Jeremy: 私は違った見方をしている。.Netはシステムプログラマにとって非常に魅力的だ。.Netをみるかぎり、これは、その能力においてMicrosoftの大きな飛躍である。これはほとんどJavaだ。いくつか.Netをサポートする異った言語があるが本質的にはこれらの言語は実際にはJavaのようなものだ。VB.NetとC#はほとんど同一であり、かつJavaとも大体において同一である。これらはその内部にかなり素晴らしい機能セットを持っていて、Javaプログラマーにとっても、非常に説得力のあるものと感じられると思う。
同時に、これはスクリプトレベルの開発者にとっては非常に複雑なモデルであり、かなり大きな知的跳躍になってしまう。我々は実際のところ、このような顧客(伝統的なASP開発者だったような人や、ある点においてはこのモデルに脅かされている人)の多くを引き付ける機会があると考えている。もう一つ、.Net周りで我々が手掛けているDreamweaver MXのツールは、この複雑さの多くを隠蔽する。根底にある.Netクラスを抽象化し、伝統的なWebアプリケーション開発者が、C#やVB.Netのプログラマになる必要なしに使うことのできるサーバコントロールがある。
Tim: それではASP.Netは難しすぎると?
Jeremy: 非常に多くのWebプロフェッショナルとスクリプトレベルの開発者にとっては難しすぎると思う。Javaプログラマにとっては魅力的だと思う。
SoapとWDDX
Tim: Webサービスに戻ると、SOAPはWDDXに取って代わったんですか、それとも両方に役割があるんですか?
ほとんど取って代わったことになる。ColdFusion MXは内部に組み込みのWebサービスエンジンを持っている。これはJRunにも組み込まれている。このエンジンはIBMとApacheグループと共同で開発したもので、Axis Webサービスエンジンと呼ばれている。我々の製品はこれを出荷する最初の商用プラットフォームになる。
Tim: Axisはまだベータ段階ですよね?
Jeremy: そのとおり。ある時点で、我々の製品を出荷可能なレベルにするために道を分岐させた。しかしこれは我々のWebサービスエンジンだ。これはいくつか素敵な機能があって、Java用のクライアントプロキシ生成やWSDL生成を行うだけでなく、なによりもスクリプトレベルの開発者が非常に簡単にWebサービスを作成し使うことができるように、ColdFusionコンポーネントフレームワークをこれと緊密に統合した。アプリケーション間コミュニケーションを行うためにはこれが間違いなく我々の進むべき方向だ。
ただ、SOAPが行わないこととして、非常にシンプルな、共通のオブジェクト直列化モデルを提供することがある。これはWDDXでは行われることだ。だから製品ではまだWDDXをサポートし、APIの中に含めて、JavaとCOMのためにAPIが使えるようにしてある。オブジェクトもしくはなんらかのデータを取得してXMLでディスクに書き出したいなら、これは非常に簡単な方法だ。これは役にたつ。
Tim: SOAPの相互運用性の問題をどう受け止めますか?
Jeremy: これは大きな関心事だ。我々自身で多くのテストを行っており、まだかなり不具合が転がっている。我々はIBM、Microsoftと共に内部的な相互運用性の作業を行い、WSIの創立メンバーでもある。人々が快適に思えるような本当の相互運用性が生まれるには1年はかかるだろう。これは業界全体にわたる問題だ。
少し心配がある。人々がこれから上にどんどん自分自身の物を重ねていき、扱いがより難しいものになっていくのを見続けることになるのではと思う。我々のエンジニアの一人はこういう相互運用性問題を扱う仲間の一人で、Microsoftの人間とミーティングをしているが、そのMicrosoftの連中がいうには、内部的に相互運用性に関する非常に多くの試練があるということだ。Microsoft内で実装されているSOAPのスタックでそれぞれ異ったものが12もある。それらの間の相互運用性だけでもかなりの挑戦だ。そう、だからこれは問題だが、彼らはこのことが危機的でかつ注目を浴びていることを理解している。
Homesiteと、Kawaに起こったこと
Tim: Homesiteはどうなっていますか?
Jeremy: いくつか起こったことがある。Dreamweaver MXは、Dreamweaverの基礎部分ののリリースを、かつてUltradevだったものと、Homesite、CodFusion Studioと結合させる。HomesiteとColdFusion studioのおよそ70%の機能を取り上げて、DreamweaverのコードベースにクロスプラットフォームのC++で再実装した。実は、Dreamweaver MXのワークスペースはHomesiteのワークスペースに非常によく似ている。核となるプログラミング機能のほとんど全ては、共通的なWebプログラミングはもちろんColdFusionでの開発においても、Dreamweaver MXに受け継がれている。また、Dreamweaver MXに、我々が呼ぶところのHomesite Plusのフリーコピーをバンドルしている。これはColdFusion Studio 5であり、Homesite 5を改名したもので、とにかく常にHomesiteの上位セットだったものだ。Dreamweaver MXにタダでついてくる。
Tim: Kawaはどうなりましたか?
一年前程まえに開発をストップした。これは良いツールだったが、本当の問題は、この領域で有利に競争するのは困難な戦いになるということだった。我々はこのチームを、他に進めていた開発作業にも必要としていた。JRunアプリケーションを構築するために、他の全てのJavaオーサリングツールにむけて拡張セットを構築していた。しかしこれは我々にとって主要な製品投資には全くならなかった。
Tin Can コミュニケーション
Tim: Webアプリケーションの進化に対する見方として、なにか最近考えることはありますか
Jeremy: 実はまだ話していない別のことがある。我々は通信アプリケーションの新技術を発表しようとしている。このリッチなインターネットアプリケーションの概念は、コンテンツとアプリケーションと通信を結合するものだ。これにはクライアント側の部品とサーバ側の部品がある。
最近リリースされたFlash Playerは内部に、その通信アプリケーションに必要な全てのクライアント機能を備えている。これで、リアルタイム、P2P、一対多、多対多のリアルタイム通信アプリケーションを、共有データや音、ビデオなどと共に配布することが可能になる。これらは全て現在クライアントに組み込まれている。
今年の後半に新しいコミュニケーションサーバを発表することになるだろう。Tin Canというコードネームだ。このような通信アプリケーションを構築することが可能になる。
全体的には、人々はデスクトップでもデバイス上でも、ブラウザ上で動作するもっとリッチなアプリケーションを構築したいと思っているように感じる。我々はそのためのクライアントを持っている。この開発モデルはコンテンツとアプリケーションプログラミングの共同作用を強めるものだと思う。これがまさに、われわれがより良いユーザ体験とより効率的なインタフェースに到達するための方法だと考えている。我々のIDE戦略はこのことを反映している。
もう一つの話しは、サーバサイドはこれまでとかなり異った役割になりつつあるということだ。クライアントにたいしてサービスを供給する方向に向かっており、これは異った種類のモデルだ。我々は企業向けミドルウェアアプリケーションを目的再設定し、SOAPでラップしているが、もっと広い範囲の人々に受け入れられる、サーバの古典的なコンポーネント開発を行う必要があるとも思う。ASP、JSP、PHPアプリケーションを制作しているスクリプト開発者はこのようなバックエンドのサービスをつくろうとするようになるだろう。このようなタイプの開発者に受け入れられ、彼らをJavaプログラマやEJB、COM開発者になるように強制することのないコンポーネントモデルを我々は必要としてる。
これは我々の大きな焦点の一つだ。どうやってスクリプト開発者に対する古典的なミドルウェアアプローチを構成するのか?
通信(コミュニケーション)部分はこれら全ての中でもっとも実験的なものだ。しかしアプリケーション開発は、通信をより統合するかたちになりはじめるだろう。それは、人々がヒューマンインタラクションで自分のインターネットアプリケーションを増強、拡張したいからだ。今日、このようなことを行う独立したソリューションは存在するが、それらはユビキタスクライアントでは一般的には利用できないので、もしくはサーバプログラミングのモデルが難しいので、まだ離陸していない。我々はここで焦点を絞ったアプローチを採用している。
Tim: 通信(コミュニケーション)部分についてもっと話してもらえますか?
Jeremy: 音とビデオをリアルタイムに共有することができる。リアルタイムにテキストを共有することができる。しかしもっと重要なのは、いわゆる共有オブジェクトが可能なことである。共有オブジェクトは、自分のアプリケーションのクライアントにデータオブジェクト、ユーザインタフェースオブジェクトなどどんなオブジェクトでも持ち込み、接続されたクライアント間で共有することを可能にする。だから複数のユーザがデータやユーザインタフェースを用いて相互にやりとりする共同作業的アプリケーションもできるだろう。彼らは通信を行っているかもしれないし、互いに話しあっているかもしれないし、いろいろかんがえられるが、それだけではなく、彼らはまさに、その中でユーザインタフェースとデータを介して共同作業的な相互のやりとりを行っているのだ。
(c) 2002 Tim Anderson. Reproduced by permission. All rights reserved.
|
|
|
|
|
