本稿では、ebXMLにおけるメッセージ配送処理を行うレイヤーであるebXML Message Serviceについて解説します。
本稿では、ebXMLにおけるメッセージ配送処理を行うレイヤーであるebXML Message Serviceについて解説します。
ebXML Message Serviceは、ebXMLで使用されるメッセージの配送を行うアーキテクチャです。ebXML Message Serviceの仕様は、安全で信頼性の高いメッセージの配送が可能となるように設計されています。
ebXML Message Serviceの特徴は以下のとおりです。
*12002年4月末時点で仕様(Revision C)の作成は完了、7月の投票を経てOASIS標準として承認される予定です。
ebXML Message Serviceは、ebXMLで使用されるメッセージの配送を司る仮想的なコンポーネントであり、ebXMLのソフトウエア構成の中でも最も低いレイヤーに位置します。
ebXML Message Serviceは、その内部で概念的に
ただし、ebXML Message Service仕様が定義しているのは以降で述べるメッセージのフォーマットとその解釈方法(メッセージの処理方法)であり、ebXML Message Serviceが特定の環境における実装方法を規定したりしているわけではありません。図1はあくまで仮想的なアーキテクチャであることに注意してください。
ebXML Message Serviceのアーキテクチャにおける最上位層は、ebXMLアプリケーションとebXML Message Serviceの間のインターフェースで、Message Serviceインターフェースと呼ばれます。現在、このAPIも具体的には規定されておらず、仮想的なものになっています。 ebXML Message Service本体は、配送に伴うメッセージの作成、ヘッダーの処理(追加・書き換え)、暗号・署名の処理、エラー処理など、配送のための処理を行う部分です。
トランスポート層マッピングは、ebXML Message ServiceとebXML Message Serviceが使用する下位トランスポートレイヤーの間のインターフェースに当たります。ebXML Message Serviceは、配送プロトコルを具体的には規定せず、SOAPを拡張して使用することだけを定めています。このような構成をとることで、HTTP/SMTP以外にFTP/IIOPなどにも対応することが可能となります。
ebXML Message Serviceの動作は、 “ebXML Collaboration Protocol Profile and Agreement” [ebCPP]で規定されるCPP(Collaboration Protocol Profile)情報・CPA(Collaboration Protocol Agreement)情報など、他の仕様で規定される外部情報にも依存しています。CPPは、ebXMLを用いてビジネスを行うビジネスパートナーの「能力」、すなわち、サポートしている通信プロトコルなどの情報や、ビジネスプロセスの中でどのような役割を担うことが出来るか、といった情報を規定します。また、CPAは、電子ビジネスを行うビジネスパートナー双方がどのような「能力」を利用するか、例えば通信プロトコルとして何を使うか、といった点についてそれぞれのビジネスパートナーが持つCPP情報に基づいて双方が合意した内容についての情報を規定します。ebXML Message Serviceにおいて、ビジネスパートナー間でのメッセージの配送時に参照されるCPP/CPA情報には、メッセージの配送先や電子署名の方法・高信頼性メッセージ配送などがあります。
CPP・CPA情報の詳細については、“ebXML Collaboration Protocol Profile and Agreement” [ebCPP]を参照してください。
ebXML Message Serviceの仕様で規定される機能は、「必須機能」と「付加機能」に分類されます(この分類はVer 2.0仕様([ebMS2])から規定されたもので、Ver 1.0仕様([ebMS1])ではこのような分類はありません)。
ebXML Message Serviceは、トランスポートプロトコルとしてSOAP([SOAP])を、ebXML向けにSOAP Envelopeを拡張して使用します。本節では、このebXML Message Serviceにおける拡張について説明します。
ebXML Message Serviceで規定されるSOAPメッセージの構造を図2に示します。
一つのebXMLメッセージは、アタッチメント付きSOAP (SOAP with Attachments [SOAPwA])の形式で符号化されます。アタッチメント付きSOAPは、MIME形式を用いてSOAPの送信メッセージに「添付ファイル」を付加することができます。このとき最初のMIMEパートにSOAPのXML形式表現、それ以降のMIMEパートにebXMLを使用して送信されるデータ(電子帳票やビジネス文書など)が添付されます。添付される文書はどのような形式でもかまいません。SOAP with Attachments ([SOAPwA])に則る形であれば、XML文書だけでなく、画像など任意のファイルを送受信することが出来ます。
以降の節では、ebXML向けに拡張されたXML要素をみていきます。
ebXML Message Serviceがメッセージの配送に必要な情報を付加するために、SOAPエンベロープは、SOAP HeaderとSOAP Bodyの双方で拡張されています。
SOAP HeaderにはMessageHeader要素とSyncReply要素の二つの要素が追加されており、SOAP Bodyには、Manifest要素が追加されています。
MessageHeader要素は、ebXMLメッセージを配送する際に必要となる各種の情報を保持します。MessageHeader要素には以下で説明する要素を子要素して持ちます。
Role要素は、CPAで指定される指定される文字列で、送受信者それぞれに認定された役割を表します。下記の例では、送信側が買い主を、受信側が売り主をあらわしています。 <eb:From> <eb:PartyId eb:type="urn:duns">123456789</eb:PartyId> <eb:PartyId eb:type="SCAC">RDWY</PartyId> <eb:Role> http://rosettanet.org/roles/Buyer </eb:Role> </eb:From> <eb:To> <eb:PartyId>mailto:joe@example.com</eb:PartyId> <eb:Role>http://rosettanet.org/roles/Seller</eb:Role> </eb:To> |
<eb:Service>urn:services:SupplierOrderProcessing</eb:Service> <eb:Action>NewOrder</eb:Action> |
<eb:MessageData> <eb:MessageId>20001209-133003-28572@example.com</eb:MessageId> <eb:Timestamp>2001-02-15T11:12:12</eb:Timestamp> <eb:RefToMessageId>20001209-133003-28571@example.com</eb:RefToMessageId> </eb:MessageData> |
<eb:MessageHeader id="…" eb:version="2.0" SOAP:mustUnderstand="1"> <eb:From><eb:PartyId>uri:example.com</eb:PartyId></eb:From> <eb:To> <eb:PartyId eb:type="someType">QRS543</eb:PartyId> <eb:Role>http://rosettanet.org/roles/Seller</eb:Role> </eb:To> <eb:CPAId>http://www.oasis-open.org/cpa/123456</eb:CPAId> <eb:ConversationId>987654321</eb:ConversationId> <eb:Service eb:type="myservicetypes">QuoteToCollect</eb:Service> <eb:Action>NewPurchaseOrder</eb:Action> <eb:MessageData> <eb:MessageId>UUID-2</eb:MessageId> <eb:Timestamp>2000-07-25T12:19:05</eb:Timestamp> <eb:RefToMessageId>UUID-1</eb:RefToMessageId> </eb:MessageData> <eb:DuplicateElimination/> </eb:MessageHeader> |
SOAP Headerの子要素として、ebXML Message Serviceがエラーの通知をする際に、エラーに関する情報を保持させるためのオプション要素です。
受信したメッセージにエラーが存在する場合、ebXML Message Serviceはそのエラーを送信先に通知します。その際、エラーの場所や原因などの情報を保持するための要素です。
ErrorList要素は、その子要素として複数のError要素を持ち、Error要素一つが、一つのエラーに関する情報を表します。Error要素はエラーに関する各種の情報を属性で表し、その属性には、エラーの種類を示すerrorCode属性、エラーの重大性(「警告」か「エラー」か)を表すseverity属性、エラーの発生した位置をXPointer形式などで指示するlocation属性などがあります。また、その子要素してDescription要素を持ちここにはえらメッセージが自然言語で示されます。ErrorList要素の例を以下に示します。
<eb:ErrorList id="3490sdo9", eb:highestSeverity="error" eb:version="2.0" SOAP:mustUnderstand="1"> <eb:Error eb:errorCode="SecurityFailure" eb:severity="Error" eb:location="URI_of_ds:Signature"> <eb:Description xml:lang="en-US">Validation of signature failed<eb:Description> </eb:Error> <eb:Error ...> ... </eb:Error> </eb:ErrorList> |
SOAP Headerの子要素として、「同期返送」を指示するオプション要素です。
HTTPのような同期的な通信プロトコルを用いる場合に、送信したメッセージに対する返信が、送信の際に用いられたコネクションと同一のコネクションを用いて返信する必要があることを示すために用いられます。この要素の典型的な使用方法は、メッセージの送受信者の間にファイヤーウォールが存在する際にHTTPを用いて通信するような場合(ファイヤーウォールの中から外への一方向でしかコネクションを張ることが出来ない場合)にも、同一のコネクションを用いることで、送信したメッセージに対する返信の受信を可能にすることだと思われます。
この要素はVer 2で追加されました。Ver 1ではVia要素(この要素もVer 2で廃止されました。)の属性として指定されていました。
SOAPメッセージのペイロードに付加された添付情報の内容を記述するために使用されます。
前述のように、ebXML Message ServiceはSOAP with Attachment([SOAPwA])を用いることで、任意の電子データをアタッチメントとして添付すること出来ます。Manifest要素はこの添付データの内容を表すために使われます。Manifest要素は、その子要素としてReference要素を持ちます。Reference要素は、添付されたペイロード一つにつき一つ、Manifest要素の子要素として付加されます。
アタッチメントを一つ持つ場合のManifest要素の一例を以下に示します。
<eb:Manifest eb:id="Manifest" eb:version="2.0"> <eb:Reference eb:id="pay01" xlink:href="cid:payload-1" xlink:role="http://regrep.org/gci/purchaseOrder"> <eb:Schema eb:location="http://regrep.org/gci/purchaseOrder/po.xsd" eb:version="2.0"/> <eb:Description xml:lang="en-US">Purchase Order for 100,000 widgets</eb:Description> </eb:Reference> </eb:Manifest> |
ビジネス文書、例えば発注書類や入金書類をやり取りする場合に、配送する文書が紛失したり、二重に配送されたりすると大きなトラブルを引き起こす可能性があります。そのため、ebXML Message Serviceには、通常のベストエフォート型の配送の他に、確実にメッセージの配送を行うための高信頼性配送の機能が仕様として規定されています。
ebXML Message Serviceの仕様では、高信頼性配送を実現するための方法として、1) ebXML Message Serviceが利用するトランスポートプロトコルを実装しているソフトウエア(例えば、MOM (Message-Oriented Middleware)などと呼ばれるメッセージ配送用のミドルウエア等)が提供する高信頼性配送の機能を利用するものと、2) ebXML Message Serviceがメッセージの送受信の管理を行い、高信頼性配送を実現するものと、二通りを規定しています。
ebXML Message Serviceのサポートする高信頼性配送の機能には以下のものがあります。
高信頼性配送は、大まかには以下のように動作します(図3参照)。
送信側がAckRequested要素によってメッセージの受領通知を要求した場合、受信側は受信したメッセージIDとともに受領通知を返送します。受け取った受領通知で指示される最初の送信メッセージのメッセージIDから、メッセージの配送が確認されれば送信作業は完了します。
送信側は、CPAで決められた時間が経過しても受領通知を受け取れなかった場合、最初に送信したメッセージと同一のメッセージを再送し、再び一定時間、受領通知の返送を待ちます。ここで受領通知を受け取ることができれば配送作業を完了しますが、ここで再び、一定時間以内に受領通知が返送されて来なければ、CPAで決められた回数だけ同一メッセージの再送作業を繰り返します。それでもメッセージの配送が確認されない場合には、配送失敗のエラーとして処理されます。
このように送信側は、同一メッセージの送信を複数回行う可能性があります。特に、受領通知の返送が失敗した場合、送信側はメッセージ配送が実際には成功しているのにも関らず、それを確認することが出来ないため、複数回メッセージの送信が行われる可能性があります。このため受信側は、同じメッセージを複数受け取る可能性がありますが、メッセージIDから以前に同一のメッセージを受信したことがあることが判明した場合には、受信したメッセージをebXMLアプリケーションには渡さずに破棄し、送信側には前回送ったものと同一の受領通知を送信します。
前節で説明した高信頼性配送時の動作は、CPAやメッセージ中のXML要素として指定される、下記のパラメータにより動作が制御されます。
あるMessage Serviceが、その通信相手となるMessage Serviceが動作しているかどうかを確認するための手段です。pingメッセージを受信したMessage Serviceは、その送信先にpongメッセージを返信します。pingメッセージの送信者は、pongメッセージを受信することによって相手のMessage Serviceと通信が行えることを確認できます。
マルチホップとは、一つ以上の中間ノードが、メッセージの最終的な送受信ノードの間に存在するようなメッセージの配送プロセスです。中間ノードは、単なる中継ノードの場合以外では、第三者機関によるタイムスタンプサービスなどのサービスを利用する用途などにも利用できます。
マルチホップを行う場合は、Acknowledgement要素による受領通知や署名などの取り扱いに注意する必要があります。受領通知は、終端のノード間でのマルチホップとなるそれと、中間ノード間だけのシングルホップのそれとを区別するため、Acknowledgement要素のSOAP:actor属性の値を用いてそれぞれに異なる処理を行います。署名のあるメッセージの処理では、SOAPでは認められている中間ノードのSOAPエンベロープに対する操作が問題になることもあるため、変更削除を行う要素が、SOAP:actor属性の値によって終端ノード宛ての情報となっていない要素だけに、変更や削除を行うことが出来ます。
これまで説明してきたようにebXML Message Serviceは、SOAPをベースにするなどWebの世界の標準に基づいて設計されています。このため、最近大きな注目を集めているWebサービス技術との親和性も高くなっており、Webサービスのコミュニティーからも注目を集め始めています。ebXMLを広義のWebサービスに含める場合もあり、Webサービス技術の発達と合わせて、その動向は非常に興味深いものがあります。また、ebXML Message Serviceは、早い時期からSOAP上で高信頼性メッセージ配送を仕様として規定するなど、その仕様は先進的なものとなっています。
しかし、その一方で現在、改善が期待される部分も幾つか存在します。
本稿では、ebXML Message Serviceの概要について解説しました。
ebXML Message Serviceは、現在のebXMLの各種仕様の中では、最も具体的な実装を行いやすい仕様であるとともに、それ単体を利用することもしやすいものになっています。ebXMLはなかなか具体的な実装を利用することが出来ない状態が続いていましたが、最近では、幾つかのベンダーがebXMLの実装を進め、日本においてもebXMLをサポートするシステムをリリースするベンダーが現われはじめ、ebXMLを利用したシステムの開発が進みつつあります。また、OASISではebXML Messaging Serviceの相互接続性検証についての検討も始まっているようで、このような活動が活発化していけば、電子商取引の標準としてのebXMLの存在感はさらに高まっていくでしょう。そのときには、前節で述べたような幾つかある現状の課題も、問題とはならなくなっているでしょう。
本解説が、ebXML Message Service仕様を理解するための参考に、そして今後のebXMLの発展の一助となれば幸いです。
本稿作成にあたり、NECソリューションズ インターネット基盤開発本部の島村 栄 氏からコメントいただきました。