ebXMLの理解

将来のビジネスWebを解きほどく

ebXMLは多くの部分からなる大きなプロジェクトです。David Mertzは、この記事で、これらの部分がどのように組み合わさっているかについて説明しています。まず、ebXMLの概念についてのご紹介、それから、ebXMLインプリメンテーションの重要な開始点となるビジネス・プロセスの概念がもう少し細かく検討されています。この中では、短いサンプル・コードの例を2つ挙げて、ProcessSpecification DTDとコラボレーションのパッケージをデモンストレーションしています。

David Mertz, Ph.D (mertz@gnosis.cx), Author, Gnosis Software, Inc.

Photo of David MertzDavid Mertz氏は多くの分野で活躍しています。ソフトウェア開発や、それについて著述もしています。その他、学術政策理念について分野を問わず、関係する雑誌に記事も書いています。かなり以前には、超限集合論、ロジック、モデル理論などを研究していました。その後、労働組合組織者として活動していました。そして、David Mertz氏自身は人生の半ばにもまだ達していないと思っているので、これから何かほかの仕事をするかもしれません。



2001年 6月 01日

ebXMLについての解説を読む場合、その解説を正確に理解するのは困難です。ebXMLの「eb」は「electronic business」の略ですが、呼び方としては、「electronic business XML」、「e-biz XML」、「e-business XML」、または単純に「ee-bee-ex-em-el」などがあります。

ebXMLとは

ebXMLは、ある面では、ビジネス間通信に必要なすべてのものを完全に統一してくれるように思われます。反面、ebXMLは、既存の標準には従う価値があるというだけの、立派ではあっても中身のない宣言でしかあり得ないと考えてもよいように思われます。「今度こそはすばらしいものが」と期待する場合は、いつも同様ですが、ebXMLに関しても、真実は中間にあると言えるでしょう。

ebXMLの用語

Registry (レジストリー): ebXMLが動作するために必要な各種のデータを保管している中央サーバー。レジストリーがXML形式で使用可能にする情報としては、Business Process & Information Meta Models、Core Library、Collaboration Protocol Profiles、Business libraryなどがあります。基本的には、ある企業が他の企業とebXML関係を開始したいと考える場合、レジストリーを照会して適切なパートナーを探し出し、そのパートナーと取引するための要件に関する情報を見つけます。

Business Process (ビジネス・プロセス): 企業が携わることができるアクティビティー (および、一般に企業が単数または複数のパートナーを必要とするアクティビティー)。ビジネス・プロセスは、正式には、Business Process Specification Schema(W3C XML SchemaおよびDTDも) によって記述されますが、UMLにモデル化することもできます。

Collaboration Protocol Profile (CPP): ebXMLトランザクションの実行を希望する企業がレジストリーに登録したプロファイル。CPPは、企業のいくつかのビジネス・プロセスを指定するほか、企業がサポートするいくつかのビジネス・サービス・インターフェースについても指定します。

Business Service Interface (ビジネス・サービス・インターフェース): 企業が自社のビジネス・プロセスに必要なトランザクションを実行できるようにする方法。ビジネス・サービス・インターフェースには、企業がサポートするビジネス・メッセージのほか、これらのメッセージが使用するプロトコルも含まれています。

Business Message (ビジネス・メッセージ): ビジネス・トランザクションの一環として通信される実際の情報。1つのメッセージには複数のレイヤーが含まれています。外側レイヤーでは、実際の通信プロトコル (たとえば、HTTPやSMTPなど) が使用されなければなりません。SOAPは、メッセージ「payload (ペイロード)」のエンベロープとしてのebXML推進製品です。他のレイヤーは、暗号化や認証を処理します。

Core Library (コア・ライブラリー): 大型のebXMLエレメントに使用できる標準のパーツのセット。たとえば、コア・プロセスはビジネス・プロセスから参照できます。コア・ライブラリーはebXMLイニシアチブによって提供され、大型エレメントは特定の産業または企業によって提供される場合があります。

Collaboration Protocol Agreement (CPA): 本質的には、複数の企業間の契約を言い、該当する会社のCPPから自動的に取り出すことができます。CPPで「わたしはXを行うことができる」と言う場合、CPAは「われわれは共同でXを行うつもりである」と言います。

Simple Object Access Protocol (SOAP): ebXMLイニシアチブによって承認された分散環境における情報交換のためのW3Cプロトコル。ebXMLに関係するのは、エンベロープ (メッセージの内容とその処理方法を記述するためのフレームワークを定義する)としてのSOAPの機能です。

ebXML.orgホーム・ページは、以下のような簡単な特徴づけを行っています。

ebXMLはいくつかの仕様の集合で、各仕様が組み合わさってモジュラー・エレクトロニック・ビジネス・ フレームワークを使用可能にします。ebXMLの大きな目標は、グローバルなエレクトロニック市場を実現することです。そこでは、XMLベースのメッセージを交換することにより、企業の規模や場所に関係なく、集まったりビジネスを実行したりできます。

言い換えれば、ebXMLは、電子データ交換 (EDIの方が一般的に知名度が高いかもしれません)を引き継ごうとしています。(一般的には、EDIより先に進むというより、まだEDIから学習するという傾向があります。)

ebXMLの用語

ebXMLを整理するには、手順を追って行わなければなりません。ebXMLの詳細を理解するためにまず行わなければならないのは、略語や特殊用語といった様々な用語について理解することです。右側の四角の中では、これらの用語をebXMLの用語という表題で説明していますが、ebXMLについての全体像を見る前にこれらの用語を知っておくと良いでしょう。システム全体に渡って他にも用語はいろいろありますが、手始めとして四角の中の用語を知っておかれるといいでしょう。これらの用語に留意し、ebXMLが出てきた背景について知っておくことによって、ebXMLのすべての異なるプロセスがどのように組み合わさっているかを理解できるようになります。

この記事の冒頭でebXMLについて概要を説明しましたが、最後のセクションでは、ebXMLの基礎インフラストラクチャーの最も重要なエレメントの1つを形成しているBusiness Process Specification Schemaについてより詳しく検討します。

背景

ebXMLは、考えられるほとんどすべての世界規模の大企業や政府標準の関係官庁が参加、支持しているイニシアチブです。正確には、考えられるすべての 組織体ではないかもしれませんが、数百の大企業や団体が参加、支持していることは確かです。

ebXMLの支持団体は、コンピューターやテクノロジー企業だけではありません。他にも、多くの工業、海運、銀行、その他一般に関心のある企業が支持しています。ebXMLの直接のスポンサーは、OASIS (Organization for the Advancement of Structured Information Standards) とUN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) です。また、NIST (National Institute of Standards and Technology) やW3C (World Wide Web Consortium)など多くの標準団体も参加しています。

このように支持者が多いことを考えると、ebXMLは世界を支配する運命にあるように思われます。筆者は、通常、業界専門語や誇大宣伝に対してはつい冷やかになりがちなのですが、ebXMLの場合には、5年以内に大部分のビジネス・トランザクションのグローバル・プロトコルとして宣伝されるようになるだろうと思っています。

個人的には、ebXMLは、企業の任意の 活動に関する仕様にさらに組み込まれていくと同時に、企業が実際にビジネスを異なったやり方で 実行していけるようにすることで、ebXMLが普遍的なものになっていくと思っています。わたしの予想は皮肉なのか、ebXML仕様の開放を助長するものであるのか分かりませんが、ebXMLイニシアチブが「既存の標準とメソッドを受け入れる」姿勢を保持していることは明らかです。


実行

ebXML Technical Architecture Specification (参考文献を参照)に基づいて描いてある図1 は、ebXMLがビジネスにとってどのような意味を持っているかを整理する上で非常に役立つでしょう。

図1のCompany Aは、まず、あるebXMLレジストリーのコンテンツ、特に、そこにダウンロードして調べることができるコア・ ライブラリーのコンテンツを調べます。コア・ライブラリー (および、場合によっては、他の登録済みビジネス・プロセス)を使用すれば、Company Aは、独自にebXMLをインプリメントするための要件(およびebXMLがビジネス・ニーズを満たすものであるかどうか) を判別することができます。

図1: 2つの企業間のebXML対話の高レベルな全体像
図1: 2つの企業間のebXML対話の高レベルな全体像

ebXMLレジストリーから入手した情報に基づいて、Company Aは、予想されるebXMLトランザクションに適合するebXMLインプリメンテーションを構築または購入できます。ebXMLイニシアチブの望みは、ベンダーがebXMLのすべてのエレメントをサポートするようになることです。そのようになると、「ebXMLシステム」は事前パッケージ済みデスクトップ・アプリケーションとほとんど変わらなくなります。あるいは、さらに現実的な言い方をすれば、ebXMLシステムは、少なくとも、商業データベース・システム(まだDBAが必要) と同程度に管理可能になると言えます。図1 は、仮想のCompany Bが事前パッケージ済みアプリケーションを使用することを提案しています。

いずれにしても、次のステップは、Company AがCPPを作成してそれをレジストリーに登録することです。Company Aは、新規のビジネス・プロセスをレジストリーに提供するか、または使用可能なビジネス・プロセスの参照を希望するかもしれません。CPPには、Company Aが関心を持っているビジネスの役割を潜在パートナーが判別するために必要な情報と、この企業がこれらの役割を果たすために使用するプロトコルのタイプが含まれています。

Company Aを登録すると、Company BはCompany AのCPPを見て、それがCompany BのCPPおよび要件に見合うかどうかを判別することができます。その時点でCompany Bは、ebXML標準または勧告として与えられたCPPおよび合意プロトコルへの準拠に基づいて、Company Aと自動的にCPAを折衝することができるはずです。

最後に、この2つの企業は実際にトランザクションを開始します。これらのトランザクションには、さらに厳密にebXML標準と勧告に準拠するビジネス・メッセージの処理が含まれると考えられます。しかし、この全過程のいずれかの時点で、ある場所から別の場所への商品の出荷、サービスのレンダリングなどの現実の活動が行われる可能性があります。ebXMLは、こういった現実の活動の承認、モニター、および検査を手助けします。もちろん、今日の「情報経済」においては、実生活の多くがebXMLの領域に存在していると考えられ、おそらくすべてのものが特定のビジネス関係に含まれています。


ビジネス・プロセス・スキーマ

UMLを使用するUN/CEFACT Modeling Methodology (UMM) は、ebXMLビジネス・プロセスをモデル化する際に役立ちます。しかし、モデル化は推進事項ではありますが、必須要件ではありません。いずれにしても、この記事はXML開発者を対象として書かれており、OOD (オブジェクト指向設計) を検討するものではありませんので、Business Process Specification DTDおよびXML Schemaに準拠したXML文書の中のモデルの表現を検討するのも興味のあるところです。現在では、DTD (別名 "ebXMLProcessSpecification- v1.00.dtd") が基本規則表現です。DTDとW3C XML Schema (意味論的および統合論的に互換性があると推定される) は、どちらもEbXML_BPschema_1.0 (参考文献を参照) で見つけることができます。

ebXMLプロセス仕様は、ルート・エレメントProcessSpecification を持っています。特定のプロセス仕様には、他のプロセス仕様に対するサブノード参照だけでなく、文書仕様や他の情報に対するサブノード参照も含まれていることがあります。ProcessSpecification のDTD宣言は、ビジネス・プロセス文書構造の概要を提供します。

リスト1: ProcessSpecification DTD宣言
<!ELEMENT ProcessSpecification
(Documentation*,
(Include* | DocumentSpecification* |
ProcessSpecification* | Package |
BinaryCollaboration | BusinessTransaction |
MultiPartyCollaboration)*)>
<!ATTLIST ProcessSpecification
name    ID    #REQUIRED
version CDATA #REQUIRED
uuid    CDATA #REQUIRED >

uuid 属性は、プロセス仕様のためのグローバル固有IDです。nameversion は、示されたモデルに固有なものです (name はネストされたプロセス仕様と矛盾してはなりません)。

プロセス仕様内では、Package がコラボレーションのセットを定義していますが、これは、MultiPartyCollaboration エレメントまたはBinaryCollaboration エレメントのいずれかになります。一方、コラボレーションには、これらのグループのさまざまな役割が含まれています。EbXML_BPschema_1.0 (参考文献を参照)に収録されているサンプル・プロセス仕様の抜粋は、この構造を整理するのに便利です。

リスト2: コラボレーションのパッケージ
<Package name="Ordering">
<!-- First the overall MultiParty Collaboration -->
<MultiPartyCollaboration name="DropShip">
<BusinessPartnerRole name="Customer">
<Performs authorizedRole="requestor"/>
<Performs authorizedRole="buyer"/>
<Transition fromBusinessState="Catalog Request"
toBusinessState="Create Order"/>
</BusinessPartnerRole>
<BusinessPartnerRole name="Retailer">
<Performs authorizedRole="provider"/>
<Performs authorizedRole="seller"/>
<Performs authorizedRole="Creditor"/>
<Performs authorizedRole="buyer"/>
<Performs authorizedRole="Payee"/>
[...]
<BinaryCollaboration name="Request Catalog">
<AuthorizedRole name="requestor"/>
<AuthorizedRole name="provider"/>
<BusinessTransactionActivity name="Catalog Request"
businessTransaction="Catalog Request"
fromAuthorizedRole="requestor"
toAuthorizedRole="provider"/>
</BinaryCollaboration>
[...]

結論

ebXML仕様の承認プロセスは、かなり速いペースで進んでいます(標準団体の通常のスピードを考えると特に速いと言えます)。筆者個人の見解では、このような意欲的な見通しに関する問題点の洗い出しや詳細を明らかにするのにあと1、2年かかります。しかし、あと数年もすれば、ebXMLはさらに広範囲に使用されるようになると思われます。したがって、今こそ、企業が独自のebXMLインプリメンテーション計画を真剣に考える絶好の機会だと言えるのです。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML
ArticleID=240114
ArticleTitle=ebXMLの理解
publish-date=06012001