ebXML Message Serviceについて
NECラボラトリーズ インターネットシステム研究所 
 富沢 伸行
概要

本稿では、ebXMLにおけるメッセージ配送処理を行うレイヤーであるebXML Message Serviceについて解説します。

はじめに

ebXML Message Serviceは、ebXMLで使用されるメッセージの配送を行うアーキテクチャです。ebXML Message Serviceの仕様は、安全で信頼性の高いメッセージの配送が可能となるように設計されています。

ebXML Message Serviceの特徴は以下のとおりです。

  1. トランスポートプロトコルとしてSOAPを利用したメッセージ通信
  2. メッセージの喪失や二重配送を防ぐ高信頼メッセージ配送のサポート
  3. XML署名・暗号を利用したセキュリティ
本稿では、ebXML Message Serviceの仕様(Ver 2.0*1 、[ebMS2])を基に、ebXML Message Serviceの機能と仕組みの概要を、SOAPへの拡張部分と高信頼性メッセージ配送機能を中心に解説します。また、必要に応じてVer 1.0([ebMS1])にも言及します。

*12002年4月末時点で仕様(Revision C)の作成は完了、7月の投票を経てOASIS標準として承認される予定です。

ebXML Message Serviceのアーキテクチャ

ebXML Message Serviceは、ebXMLで使用されるメッセージの配送を司る仮想的なコンポーネントであり、ebXMLのソフトウエア構成の中でも最も低いレイヤーに位置します。

ebXML Message Serviceは、その内部で概念的に

  1. メッセージサービスインターフェース
  2. メッセージサービス本体
  3. トランスポート層マッピング
の三層からなります。これを図1に示します。

fig1

ただし、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])ではこのような分類はありません)。

以降では、上記項目のうち太字のものについて解説します。

拡張SOAPによる送信

ebXML Message Serviceは、トランスポートプロトコルとしてSOAP([SOAP])を、ebXML向けにSOAP Envelopeを拡張して使用します。本節では、このebXML Message Serviceにおける拡張について説明します。

SOAPメッセージの構造

ebXML Message Serviceで規定されるSOAPメッセージの構造を図2に示します。

fig2

一つのebXMLメッセージは、アタッチメント付きSOAP (SOAP with Attachments [SOAPwA])の形式で符号化されます。アタッチメント付きSOAPは、MIME形式を用いてSOAPの送信メッセージに「添付ファイル」を付加することができます。このとき最初のMIMEパートにSOAPのXML形式表現、それ以降のMIMEパートにebXMLを使用して送信されるデータ(電子帳票やビジネス文書など)が添付されます。添付される文書はどのような形式でもかまいません。SOAP with Attachments ([SOAPwA])に則る形であれば、XML文書だけでなく、画像など任意のファイルを送受信することが出来ます。

以降の節では、ebXML向けに拡張されたXML要素をみていきます。

SOAPエンベロープの拡張要素

ebXML Message Serviceがメッセージの配送に必要な情報を付加するために、SOAPエンベロープは、SOAP HeaderとSOAP Bodyの双方で拡張されています。

SOAP HeaderにはMessageHeader要素とSyncReply要素の二つの要素が追加されており、SOAP Bodyには、Manifest要素が追加されています。

MessageHeader要素

MessageHeader要素は、ebXMLメッセージを配送する際に必要となる各種の情報を保持します。MessageHeader要素には以下で説明する要素を子要素して持ちます。

From要素・To要素
From要素・To要素は、メッセージの送受信者を識別するための情報を保持する必須要素です。From要素・To要素、それぞれが子要素として一つ以上のPartyId要素とオプションのRole要素を持ちます。
PartyId要素は送受信者の識別を行うためのIDを示す必須要素です。PartyId要素が複数ある場合には、それぞれのPartyId要素は相異なるtype属性の値を持たなければならず、type属性の値が識別のために用いられるIDコードの体系を示します(type属性が省略された場合,PartyId要素のID体系はURIとなります)。例えば、下の例では、From要素中で、DUNSコード(The Data Universal Numbering System (D-U-N-S)。1962年、D&Bが開発した9桁の企業識別コード)とSCACコード(Standard Carrier Alpha Code。The National Motor Freight Traffic Association, Inc., (NMFTA)が定める運輸会社の分類コード)という二つのコード体系によって指示される二種類のIDが二つのPartyId要素で指示されています。
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>
CPAId要素
メッセージ交換を行う当事者間で、その制御のための情報を規定するCPA情報を一意に識別するため用いられる文字列を指示する必須要素です。
CPAは、ebXMLを用いてメッセージの交換を行う当事者同士が合意した通信方法などの情報ですが、これを一意に定めるためのIDを指定します。
ConversationId要素
メッセージ交換を行う当事者間で、一連のメッセージのやり取りを一意に識別するために用いられる必須要素です。
ビジネス上の一つの処理、例えば発注処理等を行う場合に、「価格問い合わせ」→「価格回答」→「発注書送付」→「発注受領書返送」といった複数のメッセージのやり取りが行われる場合がありますが、この一連のメッセージを正しく関連付けるために用いられるのかConversationIdです。
Service要素、Action要素
Service要素・Action要素は、一連のメッセージのやり取りに与えられる「役割」を識別するために用いられる必須要素です。
Actionは、ビジネスプロセスにおける最も小さい単位の「役割」を表し、複数のActionの集まりがServiceとなります。Service要素・Action要素が表すものの一例とし、前者 が「発注処理」、後者が「新規発注」というようなものが考えられます。
<eb:Service>urn:services:SupplierOrderProcessing</eb:Service>
<eb:Action>NewOrder</eb:Action>
MessageData要素
MessageData要素は、メッセージそのものに関する各種の情報を保持するために用いられる必須要素です。その子要素して、メッセージを一意に識別するIDであるMessageId要素(必須)、メッセージの作成日時を表すTimestamp要素(必須)、あるメッセージへの返送の場合などに関連あるメッセージを指示するためのRefToMessageId要素、メッセージの生存期間を表すTimeToLive要素を持ちます。
MessageData要素の例を以下に挙げます。
  <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>
DuplicateElimination要素
二重配送の防止のために、メッセージの受信側が同一メッセージの重複を検知し二通目以降はebXMLアプリケーションに対して配送しないように指示するオプションです。
この要素が現われた場合は、メッセージの配送は「高々一回(At-Most-Once)」、すなわち、メッセージを重複して受け取ることは無いことが保障されます。この要素は、Ver 2.0で追加されました。Ver 1.0では、同様の機能を利用するためにQualityOfServiceInfo要素のdeliverySemantics属性が用いられていました。詳しくは、高信頼性配送の節を参照してください。
Description要素
メッセージの目的やその内容についての記述を、人間がわかるように自然言語で記述するために用意された要素です。
ここまでMessageHeader説明してきた要素を含むMessageHeader要素の例を以下に示します。
 <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>

ErrorList要素

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>

SyncReply要素

SOAP Headerの子要素として、「同期返送」を指示するオプション要素です。

HTTPのような同期的な通信プロトコルを用いる場合に、送信したメッセージに対する返信が、送信の際に用いられたコネクションと同一のコネクションを用いて返信する必要があることを示すために用いられます。この要素の典型的な使用方法は、メッセージの送受信者の間にファイヤーウォールが存在する際にHTTPを用いて通信するような場合(ファイヤーウォールの中から外への一方向でしかコネクションを張ることが出来ない場合)にも、同一のコネクションを用いることで、送信したメッセージに対する返信の受信を可能にすることだと思われます。

この要素はVer 2で追加されました。Ver 1ではVia要素(この要素もVer 2で廃止されました。)の属性として指定されていました。

Manifest要素

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のサポートする高信頼性配送の機能には以下のものがあります。

受領通知によるメッセージの配送確認
ebXML Message Serviceでは、メッセージの受信側に受領通知(Acknowledgement要素をもつメッセージ)の発行を要求することが出来ます。受領通知には、受信側が受け取ったメッセージIDが含まれるため、これによりメッセージの送信側はメッセージが確実に配送されたことを確認することが出来ます。
二重配送の検出
メッセージを確実に配送するために、再送処理を行う場合には、メッセージが二重に配送される可能性が常に生じます。ebXML Message Serviceでは、ebXMLアプリケーションがメッセージの二重配送について考慮しなくてもよいように、メッセージIDに基づいたメッセージの二重配送の検出・削除機能を提供します。
配送順序管理
アプリケーションによってはメッセージの配送順序が重要になる場合があります。ebXML Message Serviceはメッセージの配送順序を管理し、順序が後のメッセージが先に到着してしまった場合には、それ以前のメッセージがすべて到着するまでebXML Message Serviceの内部に蓄積し、正しい順序でebXMLアプリケーションにメッセージを配送します。

高信頼性配送の仕組み

高信頼性配送は、大まかには以下のように動作します(図3参照)。

送信側がAckRequested要素によってメッセージの受領通知を要求した場合、受信側は受信したメッセージIDとともに受領通知を返送します。受け取った受領通知で指示される最初の送信メッセージのメッセージIDから、メッセージの配送が確認されれば送信作業は完了します。

送信側は、CPAで決められた時間が経過しても受領通知を受け取れなかった場合、最初に送信したメッセージと同一のメッセージを再送し、再び一定時間、受領通知の返送を待ちます。ここで受領通知を受け取ることができれば配送作業を完了しますが、ここで再び、一定時間以内に受領通知が返送されて来なければ、CPAで決められた回数だけ同一メッセージの再送作業を繰り返します。それでもメッセージの配送が確認されない場合には、配送失敗のエラーとして処理されます。

このように送信側は、同一メッセージの送信を複数回行う可能性があります。特に、受領通知の返送が失敗した場合、送信側はメッセージ配送が実際には成功しているのにも関らず、それを確認することが出来ないため、複数回メッセージの送信が行われる可能性があります。このため受信側は、同じメッセージを複数受け取る可能性がありますが、メッセージIDから以前に同一のメッセージを受信したことがあることが判明した場合には、受信したメッセージをebXMLアプリケーションには渡さずに破棄し、送信側には前回送ったものと同一の受領通知を送信します。

fig3

高信頼性配送のためのパラメータ

前節で説明した高信頼性配送時の動作は、CPAやメッセージ中のXML要素として指定される、下記のパラメータにより動作が制御されます。

重複メッセージの削除
DuplicateElimination要素がメッセージ中に存在する場合には、メッセージの受信側で重複メッセージが除去されます。
受領通知要求
AckRequested要素がメッセージ中に存在する場合には、メッセージの受信側は送信側に受領通知を発行します。
最大再送試行回数
CPAのRetriesパラメータにより、メッセージの再送を試行する最大回数が指定されます。
再送試行間隔
CPAのRetryIntervalパラメータにより、送信側がメッセージの再送を試行する際の再送時間の最小間隔が指定されます。
メッセージの最大生存期間
TimeToLive要素により、メッセージの最大生存時間を指定します。この時間を過ぎたメッセージを受け取った場合、受信側はメッセージを破棄して、その旨をエラーメッセージとして送信側に通知します。メッセージの最大生存時間を制限することで、一定期間経過後には配送の完了していないメッセージが存在しないことが保障されるため、エラーとして全体の処理を続行することが可能になります。また、受信側が配送に失敗したと判断した後で、メッセージが配送されるようなケースに対処する必要がなくなります。
メッセージの最大保存期間
CPAのPersistDurationパラメータにより、メッセージが永続的記憶装置に確保される最小時間を指定します。高信頼性配送時には、メッセージの送受信時にメッセージをハードディスクのような永続的記憶装置に保存します。メッセージを送信中に送信側あるいは受信側の電源が切れたような場合にも、電源復旧後に永続的記憶装置からメッセージを読み出して送信作業を続けます。PersistDurationパラメータはこの永続的記憶装置にメッセージが保持される最小保存期間を指定し、この期間内はメッセージが永続的記憶装置にあることが保障されます。
同期返信指定
CPAのsyncReplyModeパラメータ、あるいは、メッセージのsyncReply要素によりメッセージへの返信が、送信時に用いられたものと同一のコネクションを用いて同期的に返信されるかどうかを指定します。CPAのsyncReplyModeパラメータとsyncReply要素が指示する内容が同じで無い場合には、エラーが通知されます。

Pingサービス

ある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全体が仕様として非常に大きいこと
本稿でも説明しましたが、ebXML Message Serviceは、ebXMLの他の仕様とも関連していて、それ単体で閉じてはいません。ところが、ebXMLの仕様は全体として非常に大きいものとなっており、http://www.ebxml.org/specs/から入手できる文書も大変多く、全体を理解するのが非常に大変になっています。そのため、ebXMLの全仕様を完全に満たすようなソフトウエアの実装は非常に労力のかかるものと思われます。
仕様が実装に先行しすぎている嫌いがあること
前項とも関連しますが、仕様の作成が実装に対して先行しすぎているという嫌いもあります。そのため、仕様の記述中に解釈に迷う記述も散見されます。Ver 2では、幾つかの機能が付加機能としてオプション扱いとなりましたが、これも実装が追いついてないことがその一因かもしれません。
バージョン間での仕様の非互換があること
ebXML Message ServiceにはVer 2がVer 1に対して上位互換とはなっていません。SOAP Envelopeへの拡張要素も変更されたため、メッセージの形式そのものが非互換になっています。例えば以下のような違いがあります。
SOAPヘッダーの違い
Via要素が廃止、SyncReply要素の新設。
必須機能・付加機能の分類の導入
Ver 1では必須機能・付加機能の分類はありませんでした。
この違いは、SOAP Envelope中のversion属性の値によって処理を変えることによって、Ver 2とVer 1を同時に処理できるような実装は可能でしょうが、一部のモジュールはバージョン毎に別のものを用意する必要が出て処理もやや面倒になるでしょう。そもそも、Ver 2では、幾つかの機能がオプション扱いになっているので、これから実装するベンダーはVer 2をベースにするでしょう。そのため、今現在、ebXML Message ServiceのVer1を使用するシステムを開発・使用している場合には、今後広く使われるであろうVer 2への移行を考える必要に迫られます。

まとめ

本稿では、ebXML Message Serviceの概要について解説しました。

ebXML Message Serviceは、現在のebXMLの各種仕様の中では、最も具体的な実装を行いやすい仕様であるとともに、それ単体を利用することもしやすいものになっています。ebXMLはなかなか具体的な実装を利用することが出来ない状態が続いていましたが、最近では、幾つかのベンダーがebXMLの実装を進め、日本においてもebXMLをサポートするシステムをリリースするベンダーが現われはじめ、ebXMLを利用したシステムの開発が進みつつあります。また、OASISではebXML Messaging Serviceの相互接続性検証についての検討も始まっているようで、このような活動が活発化していけば、電子商取引の標準としてのebXMLの存在感はさらに高まっていくでしょう。そのときには、前節で述べたような幾つかある現状の課題も、問題とはならなくなっているでしょう。

本解説が、ebXML Message Service仕様を理解するための参考に、そして今後のebXMLの発展の一助となれば幸いです。

謝辞

本稿作成にあたり、NECソリューションズ インターネット基盤開発本部の島村 栄 氏からコメントいただきました。


参考文献
[ebMS1] “Message Service Specification Version 2.0”, OASIS ebXML Messaging Services Technical Committee, 1 Apr. 2002.
[ebMS2] “Message Service Specification ebXML Transport, Routing & Packaging Version 1.0”, OASIS ebXML Messaging Services Technical Committee, 11 May. 2001.
[SOAP] “W3C-Draft-Simple Object Access Protocol (SOAP) v1.1”, Don Box, DevelopMentor; David Ehnebuske, IBM; Gopal Kakivaya, Andrew Layman, Henrik Frystyk Nielsen, Satish Thatte, Microsoft; Noah Mendelsohn, Lotus Development Corp.; Dave Winer, UserLand Software, Inc.; W3C Note 08 May 2000, http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
[SOAPAttach] “SOAP Messages with Attachments”, John J. Barton, Hewlett Packard Labs; Satish Thatte and Henrik Frystyk Nielsen, Microsoft, Published Oct 09 2000 http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211