.NET／Java相互運用の現在・未来 ― .NET／J2EE相互運用の基礎から最新テクノロジまで ― 第1回　相互運用本格時代の到来とその背景

　近年、UNIXとWindowsなど、異なるプラットフォームからなる情報システムの相互運用に対する関心が高まってきた。この背景には、今日のエンタープライズ環境が直面する現実がある。

　エンタープライズ環境では、情報システムの適材適所の配置や、歴史的な経緯などさまざまな理由から、異なるプラットフォームの混在が避けられない。ますます加速するビジネス環境の変化に応じて、新しい情報システム開発の必要性も高まる一方だが、こうして開発されるシステムは、すでに存在するシステムとの連携が不可避である。このため、システムの設計時や選定時に、あらかじめ相互運用性に配慮しておかないと、システム構築にかかる費用や期間、柔軟性に大きな開きが出てくる。

　こうした要求に対し、プラットフォームに依存しないアプリケーション連携を可能にするWebサービスなど、相互運用を支える各種技術が急速に発展している。これらの技術を生かして、J2EE（Java 2 Enterprise Edition）ベースのシステムと、Windows（.NET）ベースのシステムを相互運用し、サービス指向（SOA：Service Oriented Architecture）の情報システムを開発する例などが増えている。

　本稿では、情報システムを企画する立場のITマネージャ、実際に情報システム設計を担当するITエンジニアを対象として、相互運用の現状と未来、それを支えるテクノロジの基礎から最新情報までを4回にわたりまとめる予定である。

　まずは、相互運用の背景を理解するために、相互運用がこれまでに歩んできた歴史を簡単に振り返ってみよう。

　ほんの10年近く前まで、異なるプラットフォーム間ではデータ交換が難しかった。LAN環境では、NetBEUIやIPX/SPX（NetWareの標準プロトコル）など、互換性のないプロトコルが混在していた上、オフコンやメインフレームの世界では、SNA（IBM Systems Network Architecture）やDECNETなど、ベンダごとに異なる独自のプロトコルが利用されていた。

TCP/IP普及以前の情報システム

　これに対し、1990年代後半になると、UNIXプラットフォームで開発され、発展してきたTCP/IPベースのインターネットが普及し始めた。このインターネットに接続するために、WindowsやMacintoshなどでもTCP/IPプロトコルが標準的にサポートされるようになった。その後インターネットは、広域ネットワークの標準プラットフォームに成長した。インターネット接続のためのインフラが整備され、異なるプラットフォームでも共通してTCP/IPが採用されたことで、さまざまな種類のコンピュータ同士が物理的に通信できるようになった。

　しかし、いくらネットワーク・インフラを整備しても、あらかじめシステム間の相互運用を意識してシステムの設計やミドルウェアの選定を行わなければ、システムは有機的に結合しないことが浮き彫りとなった。

TCP/IP普及期の情報システム MQ：Message Queue（メッセージ・ベースのトランザクション処理システム） CICS：Customer Information Control System（IBMが開発したトランザクション処理システム） RMI：Remote Method Invocation（Javaプラットフォームの標準アプリケーション通信プロトコル） DCOM：Distributed COM（マイクロソフトが開発したアプリケーション分散技術）

　上位のアプリケーション同士を相互運用するための技術の標準化は、以前からSGML（Standard Generalized Markup Language）やCORBA（Common Object Request Broker Architecture）などさまざまなかたちで試みられていたが、特に1990年代後半以降、XMLやWebサービスなど、実効的な技術の標準化や普及が急速に進んだ。

WebサービスやXML普及期の情報システム

　これらの技術の普及によって、相互運用性は以前と比較すれば大幅に改善されつつある。特にXMLの普及や、データベース・システムの相互運用支援機能の充実により、データ・レベルの相互運用は、さまざまなベンダの製品の間で幅広く利用可能になっている。

　しかしだからといって、情報システムがTCP/IPやXML、Webサービスをサポートしてさえいれば、それらを簡単に接続できるかというと、実際にはそうもいかない。異機種相互運用の問題に対して、いまなお銀の弾丸（万能の解決法）となるような技術はない。ITの世界では、日進月歩で技術革新が起こっており、日々異なるシステムやアーキテクチャが提案されている。新しいシステムやアーキテクチャは、それらが持つ違いから、相互運用性の問題を新たに引き起こすからだ。情報システムの高度な相互運用を実現するには、上位のアプリケーション・レベルでの連携を実現しなければならない。特に、インターネットを介したアプリケーション連携に取り組むことが重要である。

　ここでは、相互運用によって大きなメリットが得られる代表的ないくつかの局面についてリストアップしてみよう。

■システムの統廃合・分割への柔軟な対応

　銀行のシステム統合が、相次いで延期となったことは記憶に新しい。郵政公社の民営化に向けたスケジュール策定でも、システム側の対応が話題になった。金融機関に限らず、資本市場の発達によって企業の統廃合や分社化、MBO（Management Buy-out）*1などの動きが相次ぎ、企業活動を支える情報システム側でも、組織の変化に迅速に対応できる能力が求められている。

　企業再編や企業内の組織変更のスケジュールは、ビジネス上の要求から規定されるべきもので、情報システムの再編がハードルになることは避けなければならない。情報システムの構築を手がける現代のITアーキテクトは、将来起こり得るシステムの分割や統合に対応できるよう、柔軟かつオープンな設計を行うことが求められている。

■既存資産の再利用

　例えば、ホスト・コンピュータで稼働している給与計算システムと、社員向けポータルWebサイトを連携させるなど、すでに構築されている情報システム（レガシー・システム）と、Webシステムなど、ほかのシステムとの連携が必要になるときがある。このような場合、レガシー・システム側の改修は、インターフェイス（Webサービスなど）を外部に提供するための小幅なものに留め、それ以外の部分をUNIXやWindowsなどのオープン・システムで構築し、両者を連携させたほうが、費用を抑えられる可能性が高い。

　もちろん理論的には、ホスト・コンピュータ・ベースのシステムを拡張して、Webアプリケーション機能を実装することも可能だ。しかしこれは、処理能力の費用対効果が低い上、開発を効率化するためのパッケージやライブラリもオープン系システムと比べて大幅に制限される。結果として、多くを自作しなければならず、開発工数やテスト工数は大幅に増加する。

　汎用機とオープン・システムとを組み合わせるシステム形態は、90年代後半から普及した。HTTPやFTP、MQ、HULFT（ファイル転送ソフトウェア）といったミドルウェアを使ってデータを受け渡す方法が一般的だったが、データ形式はシステムごとで個別に定義していた。

　しかし、Webサービスの登場により、こういったデータの受け渡し方式が標準化された。このためレガシー・システムに対しても、各種Webサービス標準に準拠した入出力を平易に提供できるミドルウェア群が、SOA対応製品と名打って次々と製品化されている。これらを利用すれば、容易に既存資産をサービスとして切り出し、外部に提供することが可能である。

既存資産の再利用の例

■開発サイクル・ギャップの解消

　情報システムを構成する要素には、比較的ライフサイクルの長いものと、短いものとが混在している。例えば、ビジネス・ロジック層やデータ層は、データの一貫性、業務フローとの整合性の関係から、容易には変更されにくい性質がある一方で、ユーザー・インターフェイスを司るプレゼンテーション層は、新たな不正攻撃手口に対応したセキュリティ対策や、新しいデバイスへの対応、次々と登場する新しいテクノロジへの対応など、短期間にさまざまな変化へのニーズが生まれる。

情報システムの構成要素とライフサイクルの違い

　例えばいま、UNIX＋Javaベースで開発された（JSP／サーブレット・ベースで開発された）情報システムのプレゼンテーション層を、Windows＋.NET Framework（ASP.NET）ベースのものに変更する必要に迫られたとしよう。

　このとき、元のJavaベースのシステムにおいて、プレゼンテーション層とビジネス・ロジック層が密に結合している場合には、本来は手を加えずそのまま利用可能なビジネス・ロジック層についても、.NET Frameworkベースに移行させなければならなくなる。開発工数の増大もさることながら、プラットフォームが全面的に変わるため、テストにかかる工数も膨大になる。

Javaベース・プラットフォームから.NET Frameworkプラットフォームへの移行

　しかしこの場合でも、例えばビジネス・ロジック層とプレゼンテーション層を別のサブシステムとして分割し、サブシステム間をWebサービスなどのアプリケーション間通信技術で接続すれば、Javaベースのビジネス・ロジック層はそのままに、プレゼンテーション層だけを.NET Frameworkに移行できる。

アプリケーション間通信技術により、サブシステム分割を実施したシステム

■ベンダ・ロックインの回避

　前項では.NETとJavaだけを例にとって説明したが、さまざまなベンダがアプリケーション連携のための通信プロトコルとしてWebサービスを採用したことで、プラットフォームやベンダを問わず、上位アプリケーションがどのようなユーザー・インターフェイスやサービスを提供していようと、相互接続して協調動作することが可能になった。必要なら、サブシステムごとに、異なるベンダのまったく異なる技術を使うこともできる。

　例えば、データ・ビジネス・ロジックは、移行や再構築のコストを考慮して、既存のCOBOLベースのシステムを残すとして、このシステムと外部との連携に必要なインターフェイスをWebサービスとしてエクスポートすれば、Web系など周辺の新規開発にはまったく異なるベンダの、異なるプラットフォームを自由に選択できる。例えば、Java系のJSF（JavaServer Faces）を使いたければJ2EEを、ASP.NETを使いたければ.NETを、Perl CGIやPHPを使いたければそれらを選択してもよい。特定のベンダに縛られない情報システムを構築できる。

特定ベンダに依存しない柔軟なシステム

■オンライン上の資源を活用する

　企業システムにおいて、今後増加が予想されるのは、例えば、地理情報などといったオンライン上の資源の活用である。昨今では、単純なHTMLベースのサービス（人間がブラウザで直接見ることを前提としたサービス）だけでなく、Webサービス・インターフェイスを備え、コンピュータ・システムとの連携が可能な情報サービスが増加している。Webサービス・インターフェイスを備えた代表的なビジネス向け情報サービスとしては以下のようなものがある。

　こうした情報サービスは増加傾向にあり、ここで挙げた以外にも、路線案内や時刻表、運賃情報など、さまざまなサービスが利用可能になると期待されている。これらのデータのメンテナンスを自社で管理するのは事実上不可能である。しかし外部の情報サービスと業務アプリケーションを連携させることができれば、業務アプリケーションから常に最新のデータを参照できるようになる。例えば、東京ガスが提供している地図情報サービスのGeOAPと交通費算出システムを連携させて、交通費精算の妥当性を自動的に検証するシステムなどが現実に稼働している。

　また、最新のデータを参照できるというメリットに加え、自前でサーバーを持つ必要がないため、開発費用やメンテナンス費用だけでなく、システム運用費用も削減し、システム構築にかかる投資リスクを軽減できる可能性が高い。

業務アプリケーションでのオンライン資源の利用

　相互運用性を意識してシステムを設計することで、変化に強い情報システムを低コストで構築できる可能性が高まるということがお分かりいただけただろうか。オープン・スタンダードのXMLやWebサービス技術を利用することで、特定のプラットフォームやベンダに依存することなく、社内外の異なる情報システム同士を連携できる。旧式だが実績があり安定しているレガシー・システムと、最新のシステムとをごくわずかなコストで連携できる。相互運用はもはや選択肢の1つではなく、今後の情報システム開発における必要条件だといっても過言ではない。

　XMLやWebサービスといった汎用的な相互運用技術を利用することに伴うデメリットもある。しばしば指摘されるのは、資源の浪費である。特定システム間での独自プロトコルなら、必要最小限の情報をやりとりすればよいが、XMLではデータの構造を冗長に記述するため、データ交換のためにより多くの計算量、メモリ、ネットワーク帯域を消費する。しかしコンピュータの計算能力やネットワーク帯域、メモリ／ハードディスク容量は、いまなお急速に能力向上や容量増大を続けており、リソース消費のデメリットよりも開発生産性や信頼性の向上によるメリットの方がはるかに大きくなっている。

　今回は、異機種相互運用が求められる背景と、相互運用によってもたらされる利点の概要について確認した。引き続き次回および次々回では、企業の情報システム開発において現在最も注目されている.NETとJava（J2EE）の相互運用を中心に、相互運用を実現するために利用可能なプロトコルやプラットフォーム、製品の現状と今後について、さらに一歩踏み込んで解説する。