特集:XMLビジネスプロトコル 〜 第3部
BtoBの理想を目指したebXML
新野淳一
@IT編集局
2002/2/16
ebXMLのホームページ 右上に、国連とOASISのロゴが並んでいることが、両社の合弁事業であったことを象徴している。ebXMLイニシアチブは解散したが、ホームページは残っており、その後の情報もいくつか追加されている |
ebXMLは、1999年11月に業界団体であるOASISと、国連の下部組織であるUN/CEFACTとの、18カ月の期限付き合同プロジェクト「ebXMLイニシアチブ」として開始された。アイオナ社のクラウス・ノーヤック(Klaus-Dieter Naujok)氏が議長を務めるebXMLイニシアチブは、当初から活動期間が18カ月と決められており、その期限となる2001年5月には予定どおりウィーンの会議でそれまでに策定された成果を報告した。
現在、ebXMLは運営委員会を残して活動をOASISとUN/CEFACTに引き継ぎ、仕様の開発やアップデートなどを行っている。
■BtoBの枠組みを作る
ebXMLの発端は、これまでEDIの標準化活動を行ってきたUN/CEFACTが、その仕様や技術をXMLをベースにしたBtoBの技術としても活かし続けたいと考えたことと、OASISのメンバーであった米サン・マイクロシステムズや米IBM、米オラクルなどが、団結してBtoBの新たな枠組みを作っていこう(その背景には、マイクロソフトのBizTalkへの対抗があったといわれている)という目的に一致したためだ。
ebXMLイニシアチブの目標は、あらゆる業種や業態、規模にかかわらず世界中のどんな電子商取引でも利用できる、XMLベースの技術的なアーキテクチャを定めることにあった。そのため、大きく分けて下記2点の達成を目指した。
(1)取引相手を探すデータベース、取引相手とのシステム構成のネゴシエーション、そのための通信プロトコルなどの技術仕様を策定すること (2)BtoBの実行時に用いられるビジネスプロセスや、システム構成を、XML文書で記述するためのモデル手法、ボキャブラリ、文書定義などを策定すること |
RosettaNetと比べると、ebXMLは特定の業種や業態をターゲットにしたものではないため、BtoB実行時のビジネスプロセスの中味としてのワークフローやビジネス文書そのものについては定めていない。いかにして取引相手と自社を、技術的にBtoBが実行可能なシステム状態にもっていくか、という点にフォーカスしている。
しかし結果からいえば、ebXMLイニシアチブは、当初目的としていた要求を満たす標準仕様を、18カ月という期間の中でまとめることはできなかった。主に(1)の部分は達成できたが、(2)の部分は仕様ではなく、その手前であるテクニカルレポートという形にとどまった。
では、ebXMLイニシアチブが策定したアーキテクチャを解説していこう。
■ebXMLのアーキテクチャ
ebXMLのアーキテクチャは、大きく3段階に分けて考えることができる。この分類は筆者が説明のために行ったもので、ebXMLの仕様が3段階に分かれているわけではない。
検索 取引したい商品やサービスと、それらを提供してくれる企業などを探す |
↓ |
合意 見つけた取引相手と、通信手段や通信先、フォーマット、そしてビジネスプロセスなどについて合意する |
↓ |
実行 合意内容に基づいて、相手と通信を行い、BtoBを実行していく |
ebXMLでは、BtoB実行時のルールを事細かに決めるのではなく、BtoBのパートナー(ebXMLでは取引相手のことを「パートナー」と呼称している)を探し、そこからBtoBの実行に至るまでの過程を決めている、と考えることができる。パートナーとのやりとりについては、RosettaNetなど業界ごとの標準などにまかせるスタンスだ。それぞれの手順を下記に見ていく。
■レジストリに対する検索
最初の検索は「レジストリ」が提供するレジストリサービスを使って実現される。レジストリには、さまざまな企業の情報が登録されており、登録は通常、企業自らが行う。レジストリは、一種のディレクトリもしくはデータベースだと考えてよいだろう。BtoBのパートナーを見つける際には、まずこのレジストリサービスに問い合わせて、目的のサービスや製品を提供してくれるパートナーを見つける。レジストリに対しては、コンピュータで直接問い合わせを行うこともできるし、Yahoo!のように人間がその内容を参照することができる。
レジストリに対する検索 ebXMLのレジストリには多くの企業情報が登録されており、BtoBのパートナーを探す際にはここで検索する |
また、レジストリにはさまざまな「ビジネスプロセス」も登録される。ビジネスプロセスとは、BtoBを実行する際に企業同士で交わされる文書やトランザクションの全体像だと考えればよいだろう。業界や取引の種類によって、さまざまなビジネスプロセスが存在する。そこで、ebXMLイニシアチブが定義したモデリング手法によってビジネスプロセスをXML文書として記述し、格納しておくことにした。これによって、ebXML自身はビジネスプロセスの種類に縛られることなく、あらゆるBtoBをebXMLの枠組みの中で扱えるようになっている。ビジネスプロセス以外にも、レジストリにはXML文書の中で用いられる用語やさまざまな文書形式、メッセージング方式なども登録される。
レジストリサービスを構築するに当たっては、レジストリが保持する情報を定義した「レジストリ情報モデル」仕様がebXMLイニシアチブから提供されている。これに従って実装すれば、社内サーバやASPなどさまざまなシステム形態でレジストリサービスを提供することが可能だ。
■CPP/CPAをパートナーとやりとりする
さて、レジストリに登録される企業情報は、「CPP(コラボレーション・プロトコル・プロファイル)」と呼ばれる。CPPはフォーマットが決められており、そこには企業情報、連絡先、通信プロトコル、セキュリティ仕様、ビジネスプロトコルなどが記述されている。
ある企業が、取引したい製品やサービスを提供する企業を見つけたら、まず相手企業のCPPをレジストリからダウンロードして参照する。そして相手のCPPと自社のCPPの共通部分を取り出し、調整して、両者がBtoBにおいて共通して処理が可能なプロトコルやセキュリティ仕様、採用するビジネスプロセスなどを記述した文書を作成する。この文書を「CPA(コラボレーション・プロトコル・アグリーメント)」と呼ぶ。CPAは自動的に作成可能だ。
CPAの締結 自社のCPPと、取引相手候補のCPPの共通部分を取り出し、自社でCPAを作成する。それを相手に送り、承認されればCPAの締結完了だ |
取引パートナーとのCPAを作成したら、それを相手に送り、パートナーと自社の両方がCPAを承認するのを待つ。CPAには、両者間でBtoBを実行するときに必要な技術的要件がすべてまとまっているため、CPAを基にシステム構成を設定すれば、両者間でBtoBが開始可能となる。ただし、取引時の法的な取り決めなど(特に国境を越えた取引など)はCPAに含まれておらず、こうしたビジネス環境をいかに整えるのかは別の課題として残されている。
BtoBの開始 CPAに基づいたビジネスプロトコルの受け入れを可能にするために、それぞれがシステムを設定したら、実際にBtoBの開始である |
このように両社のシステム構成が整ったら、BtoBによる取引の開始だ。CPAで合意されたビジネスプロセスに基づき、トランザクションを実行していくことになる。
■通信プロトコルの定義:メッセージサービス
ここでebXMLの通信プロトコルについても説明しておかなくてはならない。レジストリサービスへのアクセスや、CPPの取得、CPAの承認のための取引パートナーとの通信などの場面では、通信プロトコルとして「ebXMLメッセージサービス」を利用することになっている。ebXMLメッセージサービスとは、大まかにいえば、SOAPを基に、確実に相手にメッセージを送り届ける機能やセキュリティなどの、ebXML独自の拡張を施したものだ。
こうしてebXMLのアーキテクチャ全体を見ていくと、「自動化」というキーワードが見えてくる。取引パートナーを探すには、条件を指定してレジストリサービスの検索をすれば自動的に見つかり、その相手との取引方法の交渉、それに合わせたシステム構成の変更も、CPP/CPAを基にすれば可能だからだ。
■ebXMLで仕様として決まったこと、決まらなかったこと
ここで説明したebXMLのアーキテクチャの説明の中で出てきた要素の多くは、2001年5月にebXMLイニシアチブが発表した仕様として、文書が公開されている。一方で、18カ月の期間では仕様としてまとめるに至らなかった領域もある。それぞれを見ていく。
まずは、2001年5月にウィーンで開かれたebXMLの最後の会議で、「仕様」として発表されたものの一覧を示そう。
・ | EbXML Requirements Specification v1.06 ebXML要求仕様 |
・ | Registry Services Specification v1.0 レジストリサービス |
・ | Registry Information Model v1.0 レジストリ情報サービス |
・ | Business Process Specification Schema v1.01 ビジネスプロセス仕様スキーマ |
・ | Message Service Specification v1.0 メッセージサービス |
・ | Collaboration-Protocol Profile and Agreement Specification v1.0 CPP/CPA仕様 |
仕様としてまとめられたのは、レジストリサービスやメッセージサービス、そしてCPP/CPAについてだ。一方で、仕様に至らなかった領域については、それまでの成果をテクニカルレポートという形態でまとめられている。以下にその一覧を示す。
・ | Business Process and Business Information Analysis Overview v1.0 |
・ | Business Process Analysis Worksheets & Guidelines v1.0 |
・ | E-Commerce Patterns v1.0 |
・ | Catalog of Common Business Processes v1.0 |
・ | Core Component Overview v1.05 |
・ | Core Component Discovery and Analysis v1.04 |
・ | Context and Re-Usability of Core Components v1.04 |
・ | Guide to the Core Components Dictionary v1.04 |
・ | Naming Convention for Core Components v1.04 |
・ | Document Assembly and Context Rules v1.04 |
・ | Catalogue of Context Drivers v1.04 |
・ | Core Component Dictionary v1.04 |
・ | Core Component Structure v1.04 |
・ | Technical Architecture Risk Assessment v1.0 |
これを見ると、実はテクニカルレポートの方にebXMLの重要な部分が含まれていると見ることができる。その重要な部分とは「Core Component」、コア・コンポーネントだ。 コア・コンポーネントとは、BtoBにおける取引で使われる一般的なビジネス用語や時間や個数の表記などを統一して定義するものだ。コア・コンポーネントがきちんと定義されなければ、ebXMLをベースとしたビジネス文書を記述することはできないのだ。
ビジネスプロセスを分析して記述するための「Business Process and Business Information Analysis」もテクニカルレポートになっている。これは、BtoBを実践する場合の手順をビジネスプロセスとし、それをebXMLの分析手法でXML文書として記述するための方法論だ。
つまり、ebXMLでは実はまだ、仕様にのっとって取引のためのXML文書を作成することはできないし、取引の手順であるビジネスプロセスを記述することもできない。レジストリやメッセージサービスといった技術的な枠組みはあるのに、そこに乗せるデータを記述するための基本的な部分が欠けている、というのが現状だ。
しかし後述するように、実際にいくつかの企業や団体は、ebXMLの仕様の採用を発表したりしている。これはebXMLのレジストリやCPP/CPAを実装しているのではなく、そのほとんど(恐らくはすべて)が、ebXMLのメッセージサービス仕様の採用である。
■ebXMLは普及するのか?
さて、この壮大な目的を持つebXMLイニシアチブのプロジェクトが成功したのかどうか、まだ結論は出ていない。いずれにせよ、すぐに結論が出るものではないし、また世の中にはebXMLほど壮大な目的を持つわけではないにせよ、BtoBの標準技術を目指すいくつかのライバルは存在する。その中でebXMLが標準の座をすんなり勝ち取れるかは未知数だ。
しかし、RosettaNetはebXMLのメッセージサービス仕様を将来のRNIFでサポートしていくことを表明しており、また、国際的な旅行業界団体のOpen Travel Alliance、小売業界のサプライチェーンのための業界団体GCI(Global Commerce Initiative)、ダイムラー・クライスラー、フォード、ゼネラルモーターズなどが設立した自動車業界のBtoBを実現するCovisint、化学業界でEDIやバーコードなどの標準化を行ってきた団体CIDX(Chemical Industry Data Exchange)なども、ebXMLの支持や利用を表明した。日本でも小売流通業のカスミが、ebXMLメッセージサービス仕様に基づいたデータ交換手順などを用いて、取引先と商品情報や販促情報、販売実績情報などのデータを交換・共有するシステムを構築するなど、その利用は広がりを見せている。
また、ebXMLは前述したように、業界団体のOASISと国連を中心に、そのほか多くの団体が関与しているため、仕様の中立性という意味では特定のベンダや業界に偏るところがなく、多くのソフトウェアベンダや業界が、自社の製品として取り組みやすい仕様だともいえる。当然、その技術使用は無償で公開されており、しかも利用するに当たってどこかのコンソーシアムや組織に属する必要もまったくなく、無料で利用できる。こうした公平性や不偏性は、今後の普及にプラスに作用するだろう。
筆者個人の意見としては、レジストリやCPP/CPAなどにより、あらゆるBtoBを包含する枠組みの構築にはある程度成功したのではないかと思う。CPP/CPAによって取引先とネゴシエーションを行い、システム構成まで行うというアイデアは優れたものだ。また、ebXMLメッセージサービスも多くの組織の採用により、SOAPの拡張としてデファクト・スタンダードとなる可能性は高いだろう。しかし、レジストリはUDDIと呼ばれるWebサービスの機能にそっくりであり、すんなりebXMLのレジストリで一本化されるとは思えない。
一方で、コア・コンポーネントやモデリングの部分。つまりebXMLをベースにしたビジネス文書の作成についても、政治的な駆け引き、技術的な統合の難しさなどがあり、これからまだまだ紆余曲折があることが予想される。つまり、メッセージサービス以外の部分の標準への道のりは、まだ険しいものになると予想する。
(監修協力:イーブリッジ 岡部惠造)
■関連記事
・ ebXMLが野心的なBtoBの実証デモを公開
・ ebXML、ついにSOAPを統合
・ ebXMLの仕様、UN/CEFACTとOASISが承認
第4部〜eマーケットプレイスの標準言語xCBL |
Index | |
XMLビジネスプロトコル | |
第1部〜BtoBを支える「ビジネスプロトコル」の全貌 ・ビジネスプロトコルは複数レイヤを包括する ・なぜビジネスプロトコルが必要なのか? ・ビジネスプロトコルの大統一に向けて |
|
第2部〜ターゲットを絞ることで成功したRosettaNet ・IT業界のBtoBに、関連業界が参加して発展 ・PIPsで文書構造とワークフローを定義 ・さらに領域を広げるRosettaNet |
|
第3部〜BtoBの理想を目指したebXML ・ebXMLのアーキテクチャ ・CPP/CPAをパートナーとやりとりする ・ebXMLで仕様として決まったこと、決まらなかったこと |
|
第4部〜eマーケットプレイスの標準言語xCBL ・xCBLはeマーケットプレイスベンダによって作成された ・xCBLのアーキテクチャ ・xCBLとeマーケットプレイスの将来 |
- QAフレームワーク:仕様ガイドラインが勧告に昇格 (2005/10/21)
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か (2005/10/12)
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ (2005/9/13)
文字符号化方式(UTF-8、シフトJISなど)を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様(XKMS 2.0)が勧告に昇格 (2005/8/16)
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
|
|