© Copyright Roger Jones and licensed for reuse under this Creative Commons Licence.
OASISでは、Energy Interoperation Version 1.0 Committee Specification 02 （以下、EI1.0と略）のebXMLメッセージングへのバインディング仕様が検討されており、そのドラフト版が2012年5月16日公開されています。ドキュメントタイトルは、『Transport Protocol Bindings for OASIS Energy Interoperation 1.0 Version 1.0 Committee Specification Draft 01 / Public Review Draft 01』です。
先月半ばまでパブリックレビュー期間だったので、近日中にコメントを反映したバージョンが公開されるかもしれませんが、今回のブログでは、ドラフト版から、OpenADRプロファイルを含むEI1.0のebXMLメッセージングへのバインディング仕様をかい摘んでご紹介したいと思います。
その前に、自分の知識の整理のためにも、簡単にこの辺りの用語を整理しておきたいと思います。
＃内容はOASIS ebXML Messaging Services Version 3.0の他、WIKIPEDIAやNTTコムウエアのページを参考にさせていただきました。
SOAP：ソフトウェア同士がメッセージ交換するためのプロトコル。元はSimple Object Access Protocolの意味だったが、現在は何かの頭字語(略語)ではないとされている。SOAPはXMLに基づいており、XMLの、ヘッダーとボディを組み合わせるデザインパターンで設計されている。「ヘッダー」は、オプショナルであり、ルーティングやセキュリティー、 トランザクションなどのための情報といったメタ情報を格納できる。「ボディ」部分には、主要な情報（ペイロードと呼ばれる）を保持する。SOAPのペイロードはXML Schemaで規定することができる。
ebXML：Electronic Business using eXtensible Markup Language は、XMLを用いたインターネット上の企業間電子商取引のための仕様群である。UN/CEFACTとOASIS（構造化情報標準促進協会）が共同で1999年にebXML Initiativeを立ち上げて仕様開発の活動を開始し、2001年に主要な仕様の初版を公開した。
ebMS：ebXML Message Service は、ebXMLの仕様のひとつで、企業間電子商取引でやりとりするメッセージをインターネットを通じて伝送するための仕様である。OASIS ebXML Messaging Services技術委員会で仕様策定が行われている。ebMSはSOAPをベースとしており、企業間電子商取引に求められる安全性や信頼性をインターネット上で確保するための機構を追加している。とりわけ特徴的なのは、メッセージが確実に通信相手に届いたかどうかを保証する信頼性通信 (reliable messaging) である。受領通知、リトライ、重複除去といった仕組みを組み合わせて信頼性を実現する仕様を定めている。この機構はWebサービスで同様の信頼性を実現する仕様WS-Reliabilityの元になった。
ebMS MEP：Message Exchange PatternはebMSでのメッセージ交換パターンを規定したもので、One-Way MEPとTwo-Way MEPがある。後者で関連するメッセージは、RefToMessageIdで関連付けられる。
ebMS MSH：Message Service HandlerはebMSのメッセージの搬送サービス処理機能で、SOAPプロセッサーがその処理を行う。
ebMS3.0：ebMSバージョン3.0では、クライアント・サーバ型の通信を実現するプル型メッセージングを新たに盛り込んだ。これにより、自社にサーバを設置できない中小企業などへの導入が容易になると期待されている。
EDI：Electronic Data Interchangeは、商取引に関する情報を標準的な書式に統一して、企業間で電子的に交換する仕組み。
EDIINT：国際的なインターネット標準化団体IETFの中のグループの一つで、インターネットEDIについての検討を行っている。EDIINTはいくつかの提案 を作成しており、AS(Applicability Statement)1、AS2、AS3の規格がある。
EDIINT-AS2：HTTPを使用したEDIINTのEDI規格で、RFC4130として公開されている。セキュリティー（秘密キーを利用しての暗号化を実施。第三者に解読されない。また証明書を利用しての通信のため、なりすましを防止できる）、確実性（MDN：Message Disposition Notificationsを確認済みメッセージとして送信、相手に届いたかをシステムで自動的に確認できる）に優れており、現在ではウォルマートで採用されたのをはじめ欧米では広く利用されている。
では、これらの用語の意味を確認したところで、はじめましょう。
いつもの通り、全訳ではないことと、場合によっては、勝手な解釈や蛇足があるかもしれないことをご承知おきください。
はじめに
本仕様書は、OASIS標準であるebMS 3.0のAS4プロファイルをベースとしたEnergy Interoperation（以降EIと略）メッセージのトランスポートプロトコルバインディング（以下では長いので、EIM-TPBと略）について記述したものである。以下に、EIM-TPBにebMS3.0 AS4プロファイルを採用した場合の利点を示す。
• EIは、エネルギー分野でのB2Bデータ交換を行うものである。ebMS 3.0は、WebサービスでのB2Bデータ交換を標準化したものなので、EIメッセージを交換するために適した通信プロトコルということができる。
• 更に、EI1.0の仕様書では、メッセージヘッダーを規定していないので、ebMS 3.0で規定している共通ヘッダーの機能をうまく利用できる。
• また、ebMS 3.0メッセージングのSOAPヘッダーエクステンションは、エネルギー取引を含む様々な業界のB2Bデータ交換ですでに使用されているebMS 2.0標準を発展させたものなので、現場でも受け入れられやすいと考えられる。
• AS4プロファイルは、ebMS 3.0を軽量化したものであるが、単に単純化しただけではない。ebMS 3.0コアスペックが提供する広範な選択肢を制限することによって相互運用性が良くなっている。
• 更に、EDIINTが企業間電子商取引に求めている安全性や信頼性をインターネット上で確保するための機構が追加されるとともに、ペイロードの圧縮によりebMS 3.0ではメッセージサイズが縮小されるので、帯域幅の小さいネットワークでの利用にも適している。
AS4プロファイルのEIトランスポートへの適用
AS4プロファイルは、EDIドキュメント交換のためのプロファイルである。AS4では、PUSH型及びPULL型の単方向のメッセージ交換パターン（One-Way MEP）と、一組の双方向メッセージ交換パターン（Two-Way MEP）がある。多くのエネルギーの操作は要求と応答のインタラクションで出来上がっているので、Two-Way MEPが使われる。
なお、Two Way MEPには、以下の種類がある。
• Two-Way/Push-and-Push MEP：方向が異なる一対のOne-Way/Push MEPから構成される。
• Two-Way/Push-and-Pull MEP：メッセージ送信側から One-Way/Push MEPと One-Way/Pull MEPが実行される形である。
• Two-Way/Pull-and-Push MEP：同一のメッセージハンドラーからOne-Way/Pull MEPに続いて One-Way/Push が実行される形である。
Two-Way MEPは非同期のメッセージ交換なので、応答メッセージのeb3:RefToMessageIdで、その応答メッセージがどのメッセージに対する応答かを示さなければならない。
EI1.0は、多くのEIサービスと、そのペイロード・スキーマを定義している。以下に、それらのペイロードを含んだEIメッセージを交換するEIサービスの操作とAS4プロファイルのメッセージ交換パターンの対応を示す。
ところで、EIサービスでも、ebMS 3.0のAS4プロファイルでも、PUSHおよびPULLという概念は同じであるが、例えば、EIサービスでのPUSHという概念をメッセージ交換方式として実装するに当たって、必ずしもAS4プロファイルのOne-Way MEPを使う必要はない。
自動デマンドレスポンスでDRイベントを伝える場合を考えると、DRAS（自動ARサーバー）はEiEventサービスのEiDistributeEventの操作を実行することになる。これは、論理的にはOne-Way PUSH型の操作であるが、（非常時接続、クライアントが固定IPアドレスを持っていない、ファイアウォールの制約がきつい場合等）DRクライアント側のネットワーク環境によっては、One-Way MEPでメッセージ交換を実装した場合、DRクライアントまでDRイベントが届かない事態が考えられる。そのような場合も、DRクライアント側からTwo-Way/Push-and-Pull MEPを用いてDRイベントが発生しているかどうかDRAS側に問い合わせることで、論理的なOne-Way PUSHを実現することができる。
EIサービスをAS4プロファイルのメッセージ交換に当てはめる場合、必ずしもEIサービス上のPUSH、PULLの概念にとらわれる必要はない。
EIメッセージのトランスポートプロトコルバインディング（EIM-TPB）仕様
EIM-TPBでは、ebMSのSOAPヘッダーエクステンションに保持する、EI1.0の6章で規定されたEIサービスのメタデータを下表のとおり定義する。MSHは、SOAPヘッダーに含まれている、このメタデータを使用して、ebMS AS4プロファイルでメッセージを送信することになる。
以下は、メッセージ送信に当たっての注意事項である：
• eb3:Messagingの構造は、送信・返信メッセージどちらにも存在する。
• 送信メッセージの場合、eb3:Actionには「EI Operation」、返信メッセージでは「EI Response」を指定する。Service Consumer Role および Service Provider roleには、EI1.0で規定された値を指定しなければならない（サービスインタラクション図でより詳細な役割が定義されている場合は、それを使う）。
• 指定するすべての値はUpperCamelCase（複合語の場合、それぞれの頭文字を大文字化）でなければならない。例えば、EiRegisterPartyサービスにおけService Provider roleには、RegistrarPartyを指定する。
• Two-Way MEPでは、応答メッセージのヘッダー内の「eb3:From」および「eb3:To」に入れる Service Consumer Role と Service Provider Role の値は、受信メッセージのヘッダー内のそれらの値と逆に設定する。
• In ebMS 3.0 these extension header element values are configured by message processing modes, which provide configuration information to the MSH. This transport binding therefore also constrains the allowed values of processing mode parameters.
EIM-TPBへの適合要件
ここでは、実装したプロトコルがEIM-TPBに適合していると宣言できるための必要条件を示す。
一般的な適合必要条件（EI1.0 15.1.1項）
• 実装したプロトコルが、どのEIバージョンに対するものかを明示すること。
• データ構造や、サービス、サービスの操作やペイロード等に改定を加えている場合は、プロトコル実装適合声明書（PICS）にその内容を記載すること。
• メッセージヘッダー（WEBサービス用SOAPヘッダー）を、信頼性・セキュリティー向上のために拡張したり、トランスポート／ネットワーク上の必要に応じてEI1.0で情報交換のために定義しているデータタイプ、ペイロードや、メッセージヘッダーに変更を加えたりしても良いが、新たに加えた変更や制限事項などは、PICSにすべて記載すること。
• 改定部分に関するXMLアーティファクトを作成していなければ、「全てのXML アーティファクトに対応」という表現を使ってはならない。
代替EI（Alternate Interoperation to Energy Interoperation）としての完全適合宣言（EI1.0 15.1.4項）
• 実装したプロトコルが代替EIとしてEIに完全に適合すると主張するには、WEBサービス以外のネットワーク技術を実装に用いていることを除いて、EIに完全準拠していなければならない。
• その際、PICSに使用したネットワーキング技術を明記すること。
• An implementation MAY claim Full Conformance as well as Full Conformance with Alternate Interoperation. The Conformance statement MUST describe the extensions or departures from Full Conformance.
代替EIとしての適合宣言（EI1.0 15.1.5項）
• 実装したプロトコルが代替EIとしてEIに適合すると主張するには、WEBサービス以外のネットワーク技術を実装に用いていることを除いて、EIに準拠していなければならない。
• その際、PICSに使用したネットワーキング技術と、それ以外でEIから拡張／逸脱した内容を明記すること。
• An implementation MAY claim Conformance as well as Conformance with Alternate Interoperation. The Conformance statement MUST describe the extensions or departures from Full Conformance.
EIのNamed Profileの代替EIとしての適合／完全適合（EI1.0 15.1.6.3項）
• 実装したプロトコルがOpenADRプロファイル等、EIのNamed Profileの代替EIとして適合／完全適合すると主張するには、当該Named Profileに含まれないEIサービス／操作以外は、EIに準拠／完全準拠していなければならない。
• ペイロードに関しては、当初の定義通りでも良いし、拡張されていても良いが、拡張されている場合は、PICSに明示しなければならない。
更に、以下の3つのうち、どれかに適合しなければならない
• EI ebMS 3.0のebHandler適合：ebMS 3.0仕様書のAS4プロファイルを規定した6.1節で定義されている「AS4 ebHandler適合節（AS4 ebHandler Conformance Clause）」に適合するか
• EI ebMS 3.0の軽量クライアント適合：ebMS 3.0仕様書のAS4プロファイルを規定した6.2節で定義されている「AS4ライトクライアント適合節（AS4 Light Client Conformance Clause）」に適合するか
• EI ebMS 3.0のミニマルクライアント適合：ebMS 3.0仕様書のAS4プロファイルを規定した6.3節で定義されている「AS4最小クライアント適合節（AS4 Minimal Client Conformance Clause）」に適合すること
EIM-TPBの使用例
次に示すものは、EIメッセージをebMS 3.0トランスポートプロトコルバインディングした場合のSOAP1.2エンベロープ部分を単純化して表示したものである。
※この例では、Party Idに、「OASIS ebCore Party Id Type Technical Specification Version 1.0」で規定された表現が用いられている。
今回は、OASISの、EI1.0で規定されたメッセージのebXMLメッセージングへのバインディング仕様（案）をご紹介しました。
DRイベント通知は、論理的にはDRASサーバー側からのPUSH型メッセージと考えられますが、実際のebMS3.0ASプロファイルを用いたDRイベントメッセージ処理の実装当たっては、Two-Way/Push-and-Pull MEPを用いてDRイベントが発生しているかどうかDRAS側に問い合わせることで、論理的なOne-Way PUSHを実現することができる － というのが、今回ご紹介した『Transport Protocol Bindings for OASIS Energy Interoperation 1.0 Version 1.0 Committee Specification Draft 01 / Public Review Draft 01』を読んで得た収穫の1つではないかと思います。
しかし、CPPのようなDay-Ahead型DRで、クリティカルピーク料金を適用するか否かは一日前にDRイベントとして通知するなら、これでも良いですが、緊急な応答が必要なFast-DRでは、同じ手が使えません。
OpenADR2.0aプロファイルの資料では、トランスポートプロトコルの候補としてRESTとXMPPが挙げられていますが、XMPP（eXtensible Messaging and Presence Protocol）をFast-DRのためのプロトコルと想定しているようです。また新しい情報が手に入れば、ご紹介しようと思います。
なお、今回は自分の得意ではない領域をご紹介しましたので、誤解している部分もあるかと思います。特に、適合要件の部分は、うその内容になってはいけないと思い、一部原文のままを載せています。
WEBサービス以外のネットワーク技術を実装に用いるかどうかを除けば、「完全適合＝元のEIの仕様に対する拡張／逸脱がない」、「適合＝元のEIの仕様に対する拡張／逸脱がある」と理解したのですが、そのように解釈すると、EI1.0 15.1.4項の最後の文「The Conformance statement MUST describe the extensions or departures from Full Conformance.」と矛盾してしまうので、原文で記載させていただきました。
このブログをお読みくださっている専門家諸兄のご意見、ご指摘をいただければ幸いです。
最後に、私同様、ebXML、ebMSの辺の知識は今一つ不案内だという方のために、わかりやすい図表を見つけました。
以下、電気事業連合会「資材系電力ビジネスプロトコル標準 Ⅲ．技 術 編」から、今回の話の内容を理解する上で必要なバックグラウンド知識となる部分を抜粋して、掲載させていただきます。
ebXML仕様の構成
ebXMLの階層構造
ebMSの特徴と2.0から3.0への変更点および3.0の主な機能
ebMSのメッセージの種類とメッセージ搬送の流れ
ebMS3.0でのOne-Way MEP
パッケージング
終わり
Pingback: 新谷 隆之