ebXML Business Process Specification Schema (BPSS)技術解説
2002年5月10日
株式会社NTTデータ 技術開発本部Webサービスグループ
吉田 英嗣
ebXML Business Process Specification Schema (以下,BPSS)[1]は,ebXMLにおいてビジネスプロセスを定義するための標準フレームワークです.ここで言う「ビジネスプロセス」は,複数者のビジネスパートナ間で行われるビジネス取引の手順などを取り決めたものです.よくebXML BPSSはIBM WSFL(Web Services Flow Language)[2],Microsoft XLANG[3]などと共にWebサービス技術のフロー定義仕様として紹介されていることが多くありますが,ebXML BPSSはパブリックフローを表現するもので,プライベートフローを表現するものではありません.「パブリックフロー」とは,ビジネスパートナ間でやり取りするビジネスメッセージやそのシーケンスなどを定義したもので,各々のビジネスパートナの内部で実行しているフローは表現するものではありません.ebXML BPSSがパブリックフローのみを表現するものであるのに対して,WSFLやXLANGは,各々のビジネスパートナ内部(組織内)で実行されるフローを記述できるものになっています(※).このことは,ebXML BPSSで定義されたビジネスプロセスが,一種の契約情報として複数のビジネスパートナ間で共有することを強く意図して策定されてものであることを示しています.さらに,ebXML BPSSで定義された「パブリック」なビジネスプロセスの実行のために,内部のプライベートフローの定義を含めたWSFLやXLANGを利用することも十分考えられるでしょう.
※ ebXML BPSSとWSFL,XLANGなどとの比較については,参考資料[4]に詳しく述べられています.そちらをご参照ください.
BPSSで定義されたビジネスプロセス定義を,「BPSSインスタンス」もしくは「Business Process Specification (BPS)」と呼んでいます(ここではBPSと呼ぶことにします).つまり,BPSSはその名のとおり,ビジネスプロセス定義のスキーマであり,そのスキーマを使って定義されたビジネスプロセスがBPSと言えます.BPSSは,実際にどのような技術を利用して取引を行うかを取り決めるためのebXML Collaboration Protocol Profile and Collaboration Protocol Agreement (CPP/CPA)を生成するためにも利用できます.BPSSはCPP/CPAと併用されることによって,ビジネスプロセスモデルからebXML準拠ソフトウェアコンポーネントの設定へ落とし込む作業を仲介する役割を担っています(図 2)
BPSS=ビジネスプロセスモデリングとソフトウェアコンポーネント間の橋渡し |
例えば,ある電子部品業界で受発注プロセスを策定し,ビジネスパートナ間でそのプロセスを共有したいとします.その場合,ビジネスプロセス設計者は,共有したい受発注プロセスについてのビジネスプロセスモデルを作成します.ビジネスプロセスモデルの作成方法については,UMLモデリングツール,ビジネスプロセスエディタ,ワークシートといった方法があり,ビジネスプロセス設計者に最適なものを選ぶことができます.作成されたビジネスプロセスモデルは,BPSS仕様に基づいてBPSとして表現できます.そのBPSを元にCPP/CPAが定義でき,そのCPP/CPAによりebXML準拠ソフトウェアが設定できるようになります.このような一連の流れにより,ビジネスプロセス設計から設計されたビジネスプロセスを実現するためのソフトウェアコンポーネント設定までのプロセスが,シームレスに実施できるようになります.
図 2 ビジネスプロセスモデリングからebXML準拠ソフトウェアコンポーネント設定まで
BPSSの仕様のコンポーネント構成は,表 1のようになっています.ここで特記すべきことは,BPSSの仕様がUMLバージョンとXMLバージョンという2つの表現形式をサポートしていることです.前者は特にUMM(UN/CEFACT Modeling Methodology)との関連を意識して策定されており,BPSS仕様のUMLによる表現形式を取り決めています.これに対して後者は,ebXML準拠ソフトウェアが解釈可能なBPSS仕様の表現形式を取り決めています.以降では,BPSSを簡単に理解するためにも基本的にBPSSのXMLバージョンについて解説します.
表 1 BPSS仕様の構成コンポーネント
コンポーネント |
概要 |
BPSSのUMLバージョン |
BPSSのUMLクラス図.
UN/CEFACTで策定されつつあるUMM(UN/CEFACT Modeling Methodology)のメタモデルをベースとしている. |
BPSSのXMLバージョン |
BPSSのXMLスキーマ(DTDおよびW3C XML Schema).直接このスキーマを利用してビジネスプロセス定義(BPS)を記述することが可能で,UML/XMLマッピング定義生成ルールを適用して,XMLによるBPSを生成することも可能. |
UML/XMLマッピング定義生成ルール |
BPSSのUMLバージョンからXMLバージョンへのマッピングを定義するための生成ルール. |
ビジネスシグナル定義 |
メッセージ送受信に関するAcknowledgement(受信の通知)や例外を知らせるためのメッセージ定義.実際にはRosettaNetで策定されているAcknowledgementおよび例外通知メッセージを採用しており,BPSSではそれらのDTDが提供されている. |
では,具体的にBPSSで定義できるビジネスプロセスがどのようなものかを見ていきましょう.簡単に言えば,BPSSで定義できるBPSは,ビジネスパートナロール間でやり取りされるドキュメントとそれを送受信するシーケンス/タイミングを定義します.それを表現するために,BPSは以下に示す定義群で構成されます.
※ ロール=役割.ビジネスプロセスに関わるプレイヤの役割を示す.例えば「Buyer(買い手)」,「Seller(売り手)」,「Shipper(運送業者)」など.
- ビジネスドキュメント
ビジネスパートナロール間でやり取りされるドキュメントの定義.
- ビジネストランザクション
ビジネスドキュメントを交換する方法(プロトコル)の定義.
- バイナリコラボレーション
2者間で行われるビジネストランザクションの集合(フロー定義).
- マルチパーティコラボレーション
バイナリコラボレーションの集合(フロー定義).
- 置換セット(Substitution Set)
業界固有のビジネスプロセスを作るためのより明確なドキュメント定義へのリファレンスなどの定義.
図 3はBPS構成の例を示したものです(ビジネスプロセスによってはより複雑になり得ます).やり取りされるドキュメントは「ビジネスドキュメント」として定義され,そしてそのビジネスドキュメントの授受方法は「ビジネストランザクション」として定義されます.「バイナリコラボレーション」は,2つのビジネスパートナロール間で行われるビジネストランザクションのフローとして定義されます.この構成例ではバイナリコラボレーション中のフローの構成要素がすべてビジネストランザクションのみになっていますが,構成要素にバイナリコラボレーションを含むことも可能です(再帰的構成).さらに「マルチパーティコラボレーション」は,3つ以上のビジネスパートナロール間で行われるバイナリコラボレーションのフローとして定義されます.
以降では,BPSを構成する各定義情報に関して,ビジネスプロセス定義のサンプルをもとに解説します.サンプルとしてはRosettaNetで策定されているPIP(Partner Interface Process)を考えてみます.現在のRosettaNetのPIPはBPSSにより定義されているものではありませんが,それをBPSSで定義するとどのようになるかを示しながら,各定義情報を解説します.
なお,今回利用するRosettaNet PIP標準はPIP3A4です.PIP3A4はBuyer(買い手)とSeller(売り手)の間で行われる受発注プロセスであり,BuyerからSellerへの注文書の送信とSellerからBuyerへの注文請け書の送信で構成されています(図 4).また,それぞれの送信に対して,受信確認(Acknowledgement)のメッセージも送信されます.
図 4 RosettaNet PIP3A4 (V02.00)
BPSSにおいては,ビジネスプロセス中でやり取りされるドキュメントは<BusinessDocument>要素を利用して定義されます.RosettaNet PIP3A4のビジネスプロセスでは,”Purchase Order Request”および”Purchase Order Confirmation”の2つのドキュメントがBuyerおよびSeller間で送受信されます.”Purchase Order Request”および”Purchase Order Confirmation”の各ドキュメントはリスト 1のように定義されます.
リスト 1 ビジネスドキュメント定義(BusinessDocument)
<BusinessDocument name="Purchase Order Request"
nameID="POR"
specificationLocation="http://yoshida.info/schemata/POR.xsd"/>
<BusinessDocument name="Purchase Order Confirmation"
nameID="POC"
specificationLocation="http://yoshida.info/schemata/POC.xsd"/>
|
ビジネスドキュメントの具体的な仕様は,”specificationLocation”属性で指定します.例えば,W3C XML SchemaやDTDなどで定義されたスキーマを指定することになります.
BPSSでは同じ形式(スキーマ)を指定していても,論理的に異なるビジネスドキュメントとして定義することもできます.これは,<ConditionExpression>要素により定義可能で,例えばリスト 2はビジネスドキュメントのスキーマを同じものを指定していますが,ドキュメント中の”Status”要素の値が”Accept”の場合と”Reject”の場合では論理的に異なるビジネスドキュメントとなります.
リスト 2 1つのスキーマからの複数種のビジネスドキュメント定義
<BusinessDocument name="Purchase Order Confirmation"
nameID="POC"
specificationLocation="http://yoshida.info/schemata/POC.xsd">
<ConditionExpression expressionLanguage=”XPath” expression=’//Status=”Accept”’/>
</BusinessDocument>
<BusinessDocument name="Purchase Order Reject"
nameID="POReject"
specificationLocation="http://yoshida.info/schemata/POC.xsd">
<ConditionExpression expressionLanguage=”XPath” expression=’//Status=”Reject”’/>
</BusinessDocument>
|
ビジネスドキュメントを交換する方法(プロトコル)の定義は,<BusinessTransaction>要素を利用して行われます.ビジネストランザクションは要求側と返答側が実行する2つのアクションと,それぞれのアクションに対して送信されるビジネスドキュメントで定義されます.RosettaNet PIP3A4では,”Purchase Order Request”ドキュメントを送信するアクションと”Purchase Order Confirmation”を送信するアクションで構成される1つのビジネストランザクションを定義することになります.PIP3A4ではただ1つのビジネストランザクションのみで定義されますが,より複雑なビジネスプロセスでは複数のビジネストランザクションが定義されます.
リスト 3はPIP3A4のビジネストランザクション定義です.要求側アクションと返答側アクションは,それぞれ<RequestingBusinessActivity>および<RespondingBusinessActivity>要素において定義します.さらに各アクションで送信するドキュメントは,ビジネスドキュメント定義とのリンクを<DocumentEnvelope>要素で指定します.
リスト 3 ビジネストランザクション定義(BusinessTransaction)
<BusinessTransaction name="Request Purchase Order"
nameID="RequestPurchaseOrder_BT">
<RequestingBusinessActivity name="Purchase Order Request Action"
nameID="PurchaseOrderRequestAction"
isAuthorizationRequired="true"
isIntelligibleCheckRequired=”true”
isNonRepudiationRequired="true"
isNonRepudiationReceiptRequired=”true”
timeToAcknowledgeReceipt="P0Y0M0DT2H0M0S">
<DocumentEnvelope businessDocument="Purchase Order Request"
businessDocumentIDRef="POR"
isAuthenticated="persistent"isConfidential="transient"
isTamperProof="persistent"/></RequestingBusinessActivity>
<RespondingBusinessActivity name="Purchase Order Confirmation Action"
nameID="PurchaseOrderConfirmationAction"
isAuthorizationRequired="true"
isIntelligibleCheckRequired=”true”
isNonRepudiationRequired="true"
isNonRepudiationReceiptRequired=”true”
timeToAcknowledgeReceipt="P0Y0M0DT2H0M0S">
<DocumentEnvelope businessDocument="Purchase Order Confirmation"
businessDocumentIDRef="POC" isAuthenticated="persistent"
isConfidential="transient" isPositiveResponse="true" isTamperProof="persistent"/>
</RespondingBusinessActivity>
</BusinessTransaction>
|
ebXMLのようなインターネット上でのビジネスプロトコルでは,意図した相手にビジネスドキュメントが確実に届けられ,それが正確に処理されることを保証することが大変重要となります.また,送受信されるドキュメントに関するセキュリティも重要です.これらについて,BPSSではビジネストランザクションに関して,いくつかの信頼性/セキュリティ項目を指定できるようになっています.PIP3A4のビジネストランザクション定義で利用されている項目を以下に説明します.
- <RequestingBusinessActivity>および<RespondingBusinessActivity>要素
- timeToAcknowledgementReceipt属性
- ビジネスドキュメント受信側は,この属性値で指定する時間内に受領ビジネスシグナル(Acknowledgement)を送信しなければなりません.時間はISO 8601仕様に基づき指定します(リスト中の”P0Y0M0DT2H0M0S”は「2時間」を示します).
- isIntelligibleCheckRequired属性
- 受領シグナル(Acknowledgement)を送る前の,受信ビジネスドキュメントの妥当性チェックが必須どうかを指定します.
- isAuthorizationRequired属性
- アクセス権(ドキュメント送信者がオーソライズされているものであるかどうか)の認証が必須かどうかを指定します.
- isNonRepudiationRequired属性
- 電子署名が施されたビジネスドキュメントを,送信側/受信側双方でそのコピーを保存することを必須とするかどうかを指定します.これは否認を防止するためで,後で問題が起こったときに利用します.
- isNonRepudiationReceiptRequired属性
- 受領シグナル(Acknowledgement)への電子署名付加が必須かどうかを指定します.
- <DocumentEnvelope>要素
- isConfidential属性
- ドキュメントを暗号化しなければならないかどうかを指定します.もちろんこれは許可されてない相手がその中身を見えないようにするためです.
- isTamperProof属性
- ドキュメントの中身が改ざん不可にするかどうかを指定します.具体的には暗号化されたメッセージダイジェストと電子署名を付加することになります.
- isAuthenticated属性
- 送信者を特定するために電子証明書を付加しなければならないかどうかを指定します.上記の”isAuthorizationRequired”属性があるため冗長な気がしますが,ドキュメントの送信者と作成者が異なるような場合を考慮しています.
なお,ビジネストランザクションはいつも成功か失敗のどちらかになることが期待されます.ビジネストランザクションの失敗は様々な要因が想定されますが,失敗時にはそのトランザクションに関わったパートナーはビジネストランザクションの開始時点まで状態を戻さなければなりません.
バイナリコラボレーションでは,3.2で定義したビジネストランザクションを実際に2つのロール間で,どのような順序で実行するかを定義します.PIP3A4の例では,図 5に示すような,ただ1つのビジネストランザクションを実行する単純なフローとなります.
図 5 PIP3A4のバイナリコラボレーションのフロー
これをBPSで定義するとリスト 4になります.バイナリコラボレーションに関わる2つのロールは,コラボレーションを開始する<InitiatingRole>要素と,それに答える<RepondingRole>要素で指定します.フローそのものは,コラボレーションで取り得る状態と状態間の遷移(<Transition>)で定義します.
状態にはビジネストランザクションを指定する<BusinessTransactionActivity>要素の他に,Start,Success,Failure,Fork,Joinの5つの擬似状態があり,これらを<Transition>要素で接続することでフローが形成できます.また,リスト 4では記述されていませんが,他で定義されたバイナリコラボレーションを再帰的に利用するために,”CollaborationActivity”という状態も用意されています.
リスト 4 バイナリコラボレーション定義(BinaryCollaboration)
<BinaryCollaboration name="Request Purchase Order" nameID="RequestPurchaseOrder_BC">
<InitiatingRole name="Buyer" nameID="Buyer_ID"/>
<RespondingRole name="Seller" nameID="Seller_ID"/>
<Start toBusinessState="Request Purchase Order"/>
<BusinessTransactionActivity name="Request Purchase Order"
nameID="RequestPurchaseOrder_BTA"
businessTransaction="Request Purchase Order" businessTransactionIDRef="RequestPurchaseOrder_BT"
fromAuthorizedRole="Buyer" fromAuthorizedRoleIDRef="Buyer_ID"
toAuthorizedRole="Seller" toAuthorizedRoleIDRef="Seller_ID"/>
<Transition conditionGuard="Success"
fromBusinessState="Request Purchse Order" toBusinessState="Request Purchase Order"/>
<Success fromBusinessState="Request Purchase Order" conditionGuard="Success"/>
<Failure fromBusinessState="Request Purchase Order" conditionGuard="AnyFailure"/>
</BinaryCollaboration>
|
マルチパーティコラボレーションは,複数のロール間で行われるバイナリコラボレーションのフローを定義するものです.つまり,マルチパーティコラボレーション定義は複数のバイナリコラボレーションを集めたものになります.今回例として挙げたPIP3A4はマルチパーティコラボレーションになっていません.詳細はebXML BPSS仕様書を参照ください.
BPSはebXML準拠ソフトウェアコンポーネントの設定に利用できますが,そのためにはBPSはebXML CPP/CPAと併用されることが重要となります.具体的にはBPSはCPP/CPAから参照されることで,どのような技術(トランスポートプロトコル,セキュリティアルゴリズムなど)を用いて実際にBPSを実現するかをCPP/CPAで指定することになります.結果として,BPSを参照したCPP/CPAを利用してebXML準拠ソフトウェアコンポーネントの設定が可能となります.
今回,紹介したRosettaNet PIP3A4を実現するBPSでは,ビジネスドキュメント定義として特定の文書定義仕様(W3C XML Schemaによる定義)を指定していますが,これがebXML Core Componentに基づいて決められたビジネスドキュメントを指定することも考えられます.
BPSはビジネスドキュメントおよびビジネスシグナルをどのような順序で送受信するかを取り決めていますが,その取り決めに従ったメッセージ送受信を実際に制御するためにebXML Message Service準拠ソフトウェアが利用されます.
<?xml version="1.0" encoding="UTF-8"?>
<ProcessSpecification xmlns="http://www.ebxml.org/BusinessProcess"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ebxml.org/BusinessProcess \\Harp\rd_fs\DIT\RDS\stg\サービス連携\ΣServ\CollaborationManager\xmlspy\bpss1.03.xsd" name="BinaryCollaboration01" uuid="http://yoshida.info/bpss/bc01" version="R01.00">
<Documentation>Process Specification Sample 1 : a binary collaboration with a business transaction</Documentation>
<BusinessDocument name="Purchase Order Request" nameID="POR" specificationLocation="http://yoshida.info/POR.xsd"/>
<BusinessDocument name="Purchase Order Confirmation" nameID="POC" specificationLocation="http://yoshida.info/POC.xsd"/>
<BusinessTransaction name="Request Purchase Order" nameID="RequestPurchaseOrder_BT">
<RequestingBusinessActivity name="Purchase Order Request Action" nameID="PurchaseOrderRequestAction" isAuthorizationRequired="true" isIntelligibleCheckRequired="true" isNonRepudiationReceiptRequired="true" isNonRepudiationRequired="true" timeToAcknowledgeReceipt="P0Y0M0DT2H0M0S">
<DocumentEnvelope businessDocument="Purchase Order Request" businessDocumentIDRef="POR" isAuthenticated="persistent" isConfidential="transient" isTamperProof="persistent"/>
</RequestingBusinessActivity>
<RespondingBusinessActivity name="Purchase Order Confirmation Action" nameID="PurchaseOrderConfirmationAction" isAuthorizationRequired="true" isIntelligibleCheckRequired="true"
isNonRepudiationReceiptRequired="false" isNonRepudiationRequired="true" timeToAcknowledgeReceipt="P0Y0M0DT2H0M0S">
<DocumentEnvelope businessDocument="Purchase Order Confirmation" businessDocumentIDRef="POC" isAuthenticated="persistent" isConfidential="transient" isPositiveResponse="true" isTamperProof="persistent"/>
</RespondingBusinessActivity>
</BusinessTransaction>
<BinaryCollaboration name="Request Purchase Order" nameID="RequestPurchaseOrder_BC">
<InitiatingRole name="Buyer" nameID="Buyer_ID"/>
<RespondingRole name="Seller" nameID="Seller_ID"/>
<Start toBusinessState="Request Purchase Order"/>
<BusinessTransactionActivity name="Request Purchase Order" nameID="RequestPurchaseOrder_BTA" businessTransaction="Request Purchase Order" businessTransactionIDRef="RequestPurchaseOrder_BT" fromAuthorizedRole="Buyer" fromAuthorizedRoleIDRef="Buyer_ID" toAuthorizedRole="Seller" toAuthorizedRoleIDRef="Seller_ID"/>
<Transition conditionGuard="Success" fromBusinessState="Request Purchse Order" toBusinessState="Request Purchase Order"/>
<Success fromBusinessState="Request Purchase Order" conditionGuard="Success"/>
<Failure fromBusinessState="Request Purchase Order" conditionGuard="AnyFailure"/>
</BinaryCollaboration>
</ProcessSpecification>
|
参考文献
Copyright c XMLコンソーシアム 2002 All rights reserved.
Copyright c 株式会社NTTデータ
2002 All rights reserved.
利用条件
本書は、本書の内容及び表現が変更されないこと、および出典を明示いただくことを前提に、無償でその全部または一部を複製、転記、引用して利用できます。なお、全体を複製された場合は、本書にある著作権表示および利用条件を明示してください。
本書の著作権者は、本書の記載内容に関して、その正確性、商品性、利用目的への適合性等に関して保証するものではなく、特許権、著作権、その他の権利を侵害していないことを保証するものでもありません。
本書の利用により生じた損害について、本書の著作権者は、法律上のいかなる責任も負いません。