目次


ebXMLの理解

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

Comments

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

ebXMLとは

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

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対話の高レベルな全体像
図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インプリメンテーション計画を真剣に考える絶好の機会だと言えるのです。


ダウンロード可能なリソース


関連トピック

  • ebXMLのスポンサーは、UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) およびOASIS (Organization for the Advancement of Structured Information Standards) です。
    • ビジネス・プロセスに関する詳しい説明については、「ebXML Business Process Specification Schema Version 1.0 (EbXML_BPschema_1.0)」文書を参照してください。
    • ebXMLの全体的なシステムの意味を学ぶには (多少の努力が必要ですが)、「ebXML Technical Architecture Specification 1.04 (ebXML_TA_v1.0.4)」を参照してください。
  • SOAPメッセージングに関する詳しい説明については、SOAPクライアントの構築に関するBob DuCharmeの記事に記載されています。
  • IBM研究所のR. A. Smithは、ebXMLをe-businessインフラストラクチャーに組み込む方法を解説しています。

コメント

コメントを登録するにはサインインあるいは登録してください。

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