WebサービスにおけるCORBAの役割
企業間取引へのインターネットの利用が急速に進んでいますが、今後この分野のキーとなってくるのが、現在標準化が急ピッチで進んでいる、Webサービスと呼ばれる新技術です。従来のインターネット利用の代表例は、Webサーバが作成したHTMLなどのドキュメントを人間が操作するWebブラウザに表示したり、逆にWebブラウザからWebサーバに指示を与えたりという形態でした。いずれにしても、これまでは、人間とアプリケーションとのやりとりが主流でした。
これに対して、今後市場規模の拡大が予想される企業間取引（BtoB）では、アプリケーションとアプリケーション間のやりとりが主流になるはずです。ここでは、XMLで相手のアプリケーションに要求を送り、その結果をやはりXMLで受け取ることになります。
以下では、WebサービスでCORBAがどのように使われるのかを説明していきますが、その前に、Webサービスの概要について簡単に説明しておくことにします。
■アプリケーション間でのXMLドキュメントの交換を実現するSOAP
SOAP（Simple Object Access Protocol）は、リモート・オブジェクトの呼び出しやXMLドキュメントの送受信をインターネット上で実現するためのプロトコルです（SOAPの詳細については本サイト連載の「SOAPの仕掛け」
をご参照ください）。SOAP仕様では下位のトランスポート・プロトコルを規定していませんが、一般的にHTTPが利用されています。このため、ファイアウォールを簡単に越えることができるばかりではなく、HTTPSを使うことで通信相手の認証やメッセージの暗号化を行うことも可能です。
図2に、SOAPを使った企業間取引のシナリオを示します。以下では、図中の番号に従って手順を簡単に説明します。
- 企業Aは、企業Bが公開しているサービスの詳細を、SOAPメッセージで要求する
- 企業Bは1.への応答として、サービスを利用するためのメッセージ・フォーマットなどを記述したXMLスキーマ（次に説明するWSDL）を企業Aに返信する
- 企業Aは、指定されたXMLフォーマットで要求メッセージ（例えば、オークションへの入札や商品の発注）を作成し、企業Bに送信する
- 企業Bは、要求された処理を実行し、応答をやはりXMLスキーマで定義されたフォーマットで企業Aに返信する
■Webサービスのインターフェイスを定義するWSDL
図2で説明したように、異なる企業がSOAPを使って取引を行うためには、あらかじめXMLメッセージのフォーマット、通信プロトコル、あるいはサービス提供者のアドレス情報などを記述して、利用者に配布しておく必要があります。これらの情報を定義するための言語がWSDL（Web Services Description Language）です。役割的には、CORBAのIDL（Interface Definition Language）とオブジェクト・リファレンスの両方を兼ねています。現時点では、そのための標準があるわけではありませんが、原理的には、CORBAやCOMのIDL、あるいはEJBのリモート・インターフェイス定義からWSDLの定義を生成することも可能です。
■Webサービスの検索を可能にするUDDI
従来のWebでは、検索エンジンを使用して自分が利用したいサービスのURLを検索することができました。これと同様に、WebサービスではUDDI（Universal Description, Discovery, and Integration）を使用してサービス提供者とその詳細情報を取得することができます。UDDIの考え方は非常に簡単です。図3のように、サービス提供者は、UDDIのリポジトリ（第三者が運営するサイト）に自分のサービス内容とコンタクト情報（WSDLへのポインタ）を登録します。サービス利用者は、自分の利用したいサービスの提供者（例えば、オフィス用品のサプライヤ）をUDDIで検索し、そのコンタクト情報（WSDLへのポインタ）を取得します。あとは、SOAPの項（図2）で説明した手順で、サービスを利用します。
■Webサービスの基盤を提供するCORBA
以上、Webサービスの概要を説明してきましたが、ここまでは、特にCORBAとの関係は何も説明してきませんでした。この両者の関係を示したのが図4です。図4では、大きく分けると、CORBAは2つの場所で使われています。1つは、Webサービス自身を実装するための基盤としての使用方法です。もう1つは、企業内のバックエンド・システムと接続するための共通基盤としての使用方法です。後者に関しては、すでに第2回連載で詳しく説明しましたので、ここでは前者を中心に説明していきます。もちろん、Webサービスの実装基盤として候補に挙がっているのはCORBAだけではありませんから、公平を期して（？）、図4ではCORBAベースのWebサービスとCOM+ベースのWebサービスが通信する例を示しています。
■CORBAのプロトコルとしてのSOAP ―― SCOAP
このように、CORBAをWebサービスの実装基盤として使用するためには、SOAPとIIOPのインタオペラビリティが必須になります。このためのSCOAP（Simple CORBA Object Access Protocol）と呼ばれるプロトコルの標準化がOMGで進められています。CORBAのプロトコルとしてのSOAP（SCOAP）には、次のような幾つかの側面があります。
●純粋なCORBAアプリケーション間の通信にSOAPを使用する
SCOAPでは、IDLからXMLスキーマへのマッピングを規定しようとしています。このマッピングを使用することで、IIOPに代わってSOAPをCORBAの通信プロトコルとして使用することが可能になります。このケースの主な目的は、ファイアウォールを越えてCORBAオブジェクトの呼び出しを実現することです（SOAPメッセージは、通常HTTPで運ばれるため、容易にファイアウォールを越えることができます）。
●CORBAアプリケーション間でXMLドキュメントをやりとりするためにSOAPを使用する
SCOAPでは、XMLスキーマ型からIDLのvalue型へのマッピングも規定しようとしています。value型というのは、CORBAのクライアントとサーバ間の通信で、オブジェクト・リファレンス（参照）ではなくて、オブジェクトそのもののコピーを受け渡すためのIDLのオブジェクト型です。このマッピングによって、DOM（Document Object Model）ライクなAPIでXMLドキュメントを表現するvalueオブジェクトを組み立てて、それをSOAPで相手側に送信することが可能になります。この場合、ドキュメントのルート要素に対応するvalueオブジェクトを呼び出しのパラメータとして送ることで、ドキュメント・ツリー全体のvalueオブジェクトが自動的に送信されることになります。相手側では、受け取ったXMLドキュメントをやはりDOMライクなAPIでパーズすることが可能です。製品によっては、valueオブジェクトの操作をアプリケーションから隠ぺいして、DOMのAPIをそのまま使うことを可能にする実装も考えられます。
●純粋なSOAPアプリケーションとCORBAアプリケーション間の通信にSOAPを使用する
ここで、純粋なSOAPアプリケーションとは、CORBAのことをまったく意識しないSOAPのクライアントまたはサーバのことを指します。例えば、COM+のアプリケーションや、今回のテーマであるWebサービスのアプリケーションです。このように、SOAPを利用することで、CORBAとWebサービスのインタオペラビリティを実現することができます。これは、別の見方をすると、WebサービスをCORBAアプリケーションとして実装することができるということにほかなりません。実際に、IONAのOrbix 2000は、SOAPをCORBAのプロトコル・プラグインとして提供しているだけではなく、Webサービス製品であるXMLBusにCORBAの実装基盤を提供しています。
●CORBAベースのWebサービスのメリット
このようなCORBAベースのWebサービスのメリットは何でしょうか？ それは、CORBAベースのEJB実装のメリットと共通で、次の2つに集約されます。
- CORBAのスケーラビリティ
第3回連載の後半で説明したように、CORBAのサーバ側の仕様POAは、柔軟性とスケーラビリティに富んだサーバ・アプリケーションの実装を可能にしてくれます。Webサービスでも、このメリットを生かすことができます。 - バックエンド・システムとの統合
企業間取引（BtoBi）では、Webサービスだけが単独で存在するわけではありません。当然ながら、在庫管理システム、受発注システム、顧客管理システムといった既存のバックエンド・システムとの緊密な統合が求められます。この要請は、従来のBtoCシステムよりもはるかに強くなります。第2回連載で説明したように、企業システム全体の将来にわたる拡張性を考えた場合、システム間を統合する最もエレガントな方法は、標準に準拠した汎用的なミドルウェア基盤を採用することです。CORBAベースのWebサービスでは、これが当たり前のこととして実現されます。
Copyright © ITmedia, Inc. All Rights Reserved.