オープン・システムの利点や可能性について、いまさら再確認をする必要がないとは思うが、取材を通してさまざまな中堅・中小企業のシステム構成を知れば知るほど、いまだにメインフレームやオフィスプロセッサで基幹業務を処理している例に出会うことが多い。大手企業では、ERPをはじめとしたオープン・システムが広く普及したというが、日本の産業や経済を支える中堅・中小市場では、まだまだオープン・システムの恩恵を受けているケースが少ないのかもしれない。


求められる真のWebアプリケーション

　一口にオープン・システムと呼んでいるが、その細かいシステム構成やコンポーネントを分類していくと、大きく3つの世代に分かれている。第一世代は、クライアント／サーバ型のオープン・システムだ。最近では、この世代をオープン・システムだと捉えない論調もあるが、1990年代の前半からブームになった「脱メインフレーム」の主役は、クライアント／サーバ型のシステム構成だった。事実、90年代初期の段階からERPを導入した企業では、クライアント側のOSに依存するアプリケーションを使っているために、OSのバージョンアップを行えなかったり、ハードウェアの更新などを制限されてしまうケースもあった。この問題を解決する方法の一つとして、Citrixのような“Thin クライアント”型の25階層モデルも登場した。欧米では、クライアント／サーバ型のオープン・システムが普及していたため、この25階層モデルもかなり普及した。この方式を利用すると、クライアントは単なる「端末」になるので、OSのバージョンやハードウェアの性能に左右されることなく、クライアント／サーバ型アプリケーションを3階層システムのように利用できるようになる。
　この25階層は、暫定的な処理であり、その本来の目的は、第二世代となる3階層型アプリケーションの普及にあった。3階層型アプリケーションでは、クライアントがWebブラウザを使用できればいいので、クライアント／サーバ型モデルのようなクライアント依存がなくなる。OSのバージョンやクライアント側の特定アプリケーションに左右されることなく、全社的なシステムを集中的な管理方法で構築し運用できるので、オープン・システムのコストメリットと、メインフレームのような集中管理による利便性を両立できるシステムとして、現在のサーバ系アプリケーションの主流となっている。しかし、そんな第二世代のオープン・システムにも、大きな課題が横たわっていた。


真のオープン化を目指す取り組み

　Webアプリケーション型のオープン・システムが登場した当時、その仕組みと構造は理想的な存在に思われていた。事実、理想的なWebアプリケーションを構築できれば、どんなOSのどんなWebブラウザでも、目的の情報にアクセスして必要な業務処理を行えるようになるはずだった。しかし、現実には多くの課題が残った。まず、現在のWebアプリケーションの多くは、Webブラウザのバージョンに左右されるケースが多い。OSもWebブラウザも寡占化状態にあるので、ほとんど困ることはないが、特定のスクリプトやコンポーネントに依存するコードが含まれていると、よりオープンな環境を採用しようとした場合に問題になる。
　また、PCだけではなく、携帯電話やデジタル家電などでの利用まで考えると、より汎用的で組み替えの容易な、Webアプリケーションが求められてくる。さらに、Webアプリケーションを実行させるWebアプリケーション・サーバにも、数多くのバージョンや非互換性が存在し、柔軟なコードの再利用や組み換えが困難になっている。こうした課題を解決し、真に柔軟で依存性の低いWebアプリケーションが、第三世代のオープン・システムとなるべき存在だ。


第三世代のオープン・システムの鍵を握るミドルウェア

　第三世代と呼べる真のオープン・システムを実現できるかどうかは、ミドルウェアの存在にかかっている。もはや、OSやWebブラウザによって、乱立したバージョンや機能上の違いを吸収することは困難になっている。今後も、携帯電話のブラウザ機能は仕様拡張が進むと思われる上に、デジタルテレビや情報家電のインターネット機能も強化されていく。そうした進化や変化を柔軟に吸収するためには、Webアプリケーション・サーバだけではなく、それをサポートするミドルウェア群の充実が望まれる。いまや、セキュリティ対策や運用管理などにおいても、ミドルウェアの存在が重要となっている。ネットワークという大きなシステムにとって、OSやクライアント環境が部品の一部となっている今、巨大なコンピュータと化したネットワーク全体において、真の機能を提供できる存在が、ミドルウェアなのだ。そして、そのミドルウェアを的確に採用し自社の情報戦略に活かしていけるかどうかが問われている。
　例えば、社内にLANが施設されていて、電子メールやWebは参照できるのに、基幹システムの情報が個人のデスクトップから閲覧できない、という環境には、勘定系のデータを社内イントラネットやポータルに展開できるミドルウェアが重要なソリューションとなる。同様に、営業支援システムと経営管理システムの連携を考えるときにも、ミドルウェアを活用したデータの交換が最適な解決策となる。反対に、昔ながらのクライアントや固有のOSに依存するシステムを構築してしまうと、それが足かせとなり、将来的な組み換えや発展が困難になる。
　もちろん、すべてのミドルウェアは、何らかのOSや特定の動作環境に依存している。また、現時点ではミドルウェア間での互換性も100%とはいい難い。例えば、「.NET」と「J2EE」という二つの開発環境を比較しても、トランザクションの処理方法やデータの形式などにおいて、細かい違いがある。また、同じJ2EE用のWebアプリケーション・サーバであっても、各社の開発環境には違いがある。特定のWebアプリケーション・サーバ用に開発されたJ2EEのコードが、別の環境では動作しないこともある。そのため、現時点でのWebアプリケーション環境は、まだ第二世代のオープン・システムの影を引きずっている。こうした問題を解決しようという取り組みが、SOA（サービス・オリエンテッド・アーキテクチャ）になる。


SOAで変わるミドルウェア開発

　SOAは、まだはじまったばかりの取り組みといえる。Webアプリケーション間でやり取りする情報を全てサービスという大きな概念で捉えて、データ形式や固有の記述を可能な限り排除して、相互に柔軟に連携できる仕組み作りを目指すものだ。今、J2EE用のWebアプリケーション・サーバが、SOAをサポートするために、新しいバージョンを提供しはじめている。このアーキテクチャに準拠したWebアプリケーションが開発されれば、相互に互換性のあるサービスの利用が可能になるはずだ。理想的には、J2EEで稼動している環境に.NETを導入することも、またその反対も可能にすることだ。レガシーな環境からのデータ転送や連携においても、SOAの規格に則ったミドルウェアとして開発しておけば、その他のミドルウェアからも柔軟に利用できるようになる。
　もちろん、その理想が実現するためには、業界全体で互換性に向けた取り組みを積極的に推進していく必要がある。特定のベンダーが、互換性を阻害するような動きをしてしまえば、真のオープンな環境は実現しない。また、システムを選ぶ側でも、SOAの将来的な動向や可能性を見極めながら、ミドルウェアを選定することが重要となっている。