--サーバ上にあるアプリケーションやデータを仮想的に手元に引き寄せることで、仕事の進め方に自由度が増し、セキュリティリスクやIT管理コストも低減されるというわけですね。とはいえ、Windowsターミナルサービスと近似的な製品という見方もできると思いますが、どのような点が大きく異なるのでしょうか。
MetaFrameはWindows環境のほか、LinuxやMac OSなど、さまざまな環境のクライアントからサーバ上のアプリケーションやデータを扱えるようになります。そのため既存のPCを有効活用できるわけです。
また、通信技術のメリットとしては、20kbpsあれば十分パフォーマンスが保持されることが挙げられます。MetaFrameは独自の圧縮アルゴリズムを使い、差分情報だけをクライアントPCに送ります。このため、ナローバンド環境からアクセスしても操作性は損なわれませんし、PHSやPDAなどでアクセスしても、あたかも自分のPC内にあるアプリケーションを動かしているようなパフォーマンスが維持されます。
--MetaFrameはシンクライアントのソリューションとして評価されていますが、ITの供給側から見るとリッチクライアントも市場をにぎわせています。この両者ですみ分けは可能なのでしょうか。
リッチクライアントが出てきた背景には、ウェブブラウザの操作性や表現力の限界を破りたいというニーズがあります。基本的な流れとしては、ウェブベースコンピューティングはサーバへと集約されていくと考えています。クライアント／サーバモデルが優れている点は厳然としてあり、適材適所的に手法が選択されていくでしょう。
一方、アクセスインフラストラクチャから見ると、ウェブも従来のクライアント／サーバ型のアプリケーションもメインフレームも、同じレイヤーに属するものなのです。例えば、あるユーザー企業ではアプリケーションサーバとクライアントPCの間にもう1つMetaFrameサーバを立てて、その中にWeb Interfaceを設置しました。クライアントPCは自分のPCの中にあるウェブブラウザではなく、MetaFrameを通じてサーバ側にあるウェブブラウザを使います。こうしてプレゼンテーションレベルのシステム統合を実現しました。
この事例では既存システムを1つのウィンドウから利用できるメリットがあるほか、システム管理面ではブラウザのプラグイン管理と修正モジュール配布・適用という負荷を解消しました。その企業では、同じように、今度はメインフレームとMetaFrameサーバをつないで、Windowsクライアントからメインフレーム内のアプリケーションを使うことを検討しているようです。
いま企業内には、ウェブシステムやクライアント／サーバ、メインフレームと、いろいろなシステムが混在しています。これはベンダー側がそのときどきの技術や時流で提案したもので、確かに優れたものではありますが、ユーザー企業のシステム管理工数を圧迫しているのも確かです。MetaFrameサーバにシステムを集約することで、システム全体の維持費も抑えられます。先ほど、古いクライアントPCを含めクライアントマシンの管理コストが低減できると説明しましたが、あらゆる環境のシステムをMetaFrameに集約することで、システム全体のコストが大幅に削減されるわけです。
ナローバンド環境に対応している点とセキュリティ確保というメリットからMetaFrameのニーズは広がってきました。情報に対して適切なアクセスを実現するためのインフラを提供する企業として、顧客から信頼されるパートナーになりたいと考えています。
