連載
» 2001年04月26日 00時00分 公開

いまなぜCORBAなの?(4):Webサービスをひらく (2/3)

[小野沢博文,日本アイオナテクノロジーズ]

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を使った企業間取引のシナリオを示します。以下では、図中の番号に従って手順を簡単に説明します。

図2 SOAPを使ったサービス利用の手順 図2 SOAPを使ったサービス利用の手順
  1. 企業Aは、企業Bが公開しているサービスの詳細を、SOAPメッセージで要求する
  2. 企業Bは1.への応答として、サービスを利用するためのメッセージ・フォーマットなどを記述したXMLスキーマ(次に説明するWSDL)を企業Aに返信する
  3. 企業Aは、指定されたXMLフォーマットで要求メッセージ(例えば、オークションへの入札や商品の発注)を作成し、企業Bに送信する
  4. 企業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)で説明した手順で、サービスを利用します。

図3 UDDIによるサービスの登録と検索 図3 UDDIによるサービスの登録と検索

■Webサービスの基盤を提供するCORBA

 以上、Webサービスの概要を説明してきましたが、ここまでは、特にCORBAとの関係は何も説明してきませんでした。この両者の関係を示したのが図4です。図4では、大きく分けると、CORBAは2つの場所で使われています。1つは、Webサービス自身を実装するための基盤としての使用方法です。もう1つは、企業内のバックエンド・システムと接続するための共通基盤としての使用方法です。後者に関しては、すでに第2回連載で詳しく説明しましたので、ここでは前者を中心に説明していきます。もちろん、Webサービスの実装基盤として候補に挙がっているのはCORBAだけではありませんから、公平を期して(?)、図4ではCORBAベースのWebサービスとCOM+ベースのWebサービスが通信する例を示しています。

図4 Webサービスの基盤技術 図4 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で運ばれるため、容易にファイアウォールを越えることができます)。

図5 SOAPによるファイアウォール越え 図5 SOAPによるファイアウォール越え

●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をそのまま使うことを可能にする実装も考えられます。

図6 SOAPによるXMLドキュメントの送受信 図6 SOAPによるXMLドキュメントの送受信

●純粋なSOAPアプリケーションとCORBAアプリケーション間の通信にSOAPを使用する
 ここで、純粋なSOAPアプリケーションとは、CORBAのことをまったく意識しないSOAPのクライアントまたはサーバのことを指します。例えば、COM+のアプリケーションや、今回のテーマであるWebサービスのアプリケーションです。このように、SOAPを利用することで、CORBAとWebサービスのインタオペラビリティを実現することができます。これは、別の見方をすると、WebサービスをCORBAアプリケーションとして実装することができるということにほかなりません。実際に、IONAのOrbix 2000は、SOAPをCORBAのプロトコル・プラグインとして提供しているだけではなく、Webサービス製品であるXMLBusにCORBAの実装基盤を提供しています。

図7 SOAPアプリケーションとCORBAアプリケーションの通信 図7 SOAPアプリケーションと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.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。