OpenADE　－その７

OpenADE1.0 －　その２

© Copyright John Firth and licensed for reuse under this Creative Commons Licence.

OpenADE 1.0 System Requirements Specification （以降、SRSと略）のご紹介を続けます。

いつも通り、全文翻訳ではないことと、例によって、超訳になっている部分があることを予めご了承ください。また、勝手に補足した部分は文字色=緑にしています。

 

OpenADEのビジネス・アーキテクチャー

次図の中で示されるように、主要なビジネス・フローにはTPSP（第三者サービスプロバイダー企業）の構成・登録・オーソライゼーションと、オーソライズされたデータの交換がある。

図．４　OpenADEのビジネス・プロセス・フロー概要 図の拡大

ビジネス・アーキテクチャーについては、関連ドキュメント『OpenADE　Business and User Requirements Document （Version 1.00）』（以降、OADE BRと略）を参照のこと。ユースケース図と要件の詳細は、そちらのドキュメントでカバーされている。
※OADE BRに関しては、OpenADE―その４のビジネス要件の表 参照

※日本語版のOpenADEビジネスフロー図（出典：経産省第2回スマートメータリング制度検討会資料）はこちら

OpenADEの論理コンポーネント一覧

本SRSでは、複数のシステム間の統合サービスを提供するOpenADEのインターフェースをまとめるにあたって、論理的なコンポーネントを洗い出した。
これは、機能面からまとめた部品であり、特定のシステムへの実装にあたっては、既存の物理的なコンポーネントにマッピングされるかもしれない。
下表に、それらOpenADEのビジネス・プロセスを支援するいくつかの機能を提供する主要論理コンポーネントの一覧を示す。

ADEのデータ交換に関与するコンポーネントを次図に示す。
データ交換のオーソライゼーションにはWebブラウザが使用されることを想定しているが、TPSPが提供する情報提供などのサービスは、Webブラウザ経由ではないことも考えられる。

図．５　ADEの論理コンポーネント

OpenADEの要求仕様

機能要件－ビジネス・プロセス

OpenADEのビジネス・プロセスと、要件は以下のとおりである。
下記箇条書き項目のカッコ内の記号は、OADE BRに記載したビジネス要件の番号である。

１）ADEの展開

• TPSPとユーティリティはSLAを締結し、OpenADEサービスを構築する
（OADE BR-10、12）
• TPSPは、拡張とバージョンを使って、利用可能な操作のリストを入手する
（OADE BR-8）
• 電力会社は、拡張とバージョンを使って、利用可能な操作のリストを入手する
（OADE BR-8）
• TPSPと電力会社は、ADEの通知に関する予約（サブスクライブ）を行う

２）ADEのオーソライズ

• 顧客は、自分のデータ提供の許可を与える（OADE BR-1、2、3、4、9）
• 顧客はデータ提供の許可範囲を拡張できる（OADE BR-3）
• 顧客はデータ提供の許可を取消せる（OADE BR-4、7）

３）ADEでのデータ提供

• TPSPは、顧客の消費実績データを要求／またはデータ提供サービスのサブスクライブを行う
• 電力会社は、TPSPに顧客消費実績データを供給する（OADE BR-14）

機能要件－統合サービス

OpenADE-TFのサービス定義チームは、ユースケース・チームの成果を利用して以下の統合サービスに関する要件を洗い出した。

※原文を直訳しても情報が少なすぎて意味がとおらないので、『OAuthプロトコルを知る』を参考にしてサービス内容を書き換えています

技術要件－統合サービス

ADEの統合サービスは、電力会社と他の企業体の間でのオープンで相互運用可能な実装の要となるものである。下記に、統合サービスを設計するにあたっての指針を示す:

• 終端サービスの祖結合を達成するために、共通のプロトコルおよびビジネス・セマンティクスを用いなければならない
• サービスは、ユニークな仕事のまとまりを表現するものであり、ビジネス機能をまたがって再使用可能でなければならない
• サービスは、電力会社の商慣行にそぐうものでなければならない
• サービス設計は、ビジネス要件に基づき、アーキテクチャーをよく考慮したもので概念の健全性を目指すためには、サービス設計は共通のアプローチおよびフレームワークで管理されなければならない
• 概念の健全性を目指すためには、サービス設計は共通のアプローチおよびフレームワークで管理されなければならない
• 重要なアーキテクチャー上の特質を支援するため、以下の項目に対してSLAをきっちり定義しなければならない：セキュリティ、信頼性、パフォーマンス、可用性、スケーラビリティ、データ品質、情報厳守など

OpenADEのアプリケーション・アーキテクチャー

1. OpenADEのアプリケーション・アーキテクチャーは、電力会社（またはその代理）のWebサイト/ポータルを認証目的で使用する。
2. ユーザはすべて、TPSPおよび電力会社両方に取引口座を持っている。
3. ユーザは、（電力会社によって設定された範囲内で）個々のTPSPにデータ提供を許可した内容を確認したり変更したりできる。
4. 監査情報が保存され、その結果オーソライゼーション、トランスファーその他の重要なイベントに関して、詳細情報（誰が、何を、いつ、など）を含む報告書を作成できなければならない。

OpenADEのデータ・アーキテクチャー

OpenADEのユースケースに基づいて以下のデータオブジェクトが洗い出された。
OpenADEのサービスは、これらのオブジェクトにまつわる要求を行うためのメソッドを実装しなければならない。
• オーソライゼーション要求：未承認のアクセス・トークンを要求する
• 顧客が消費者データへのアクセスを認可するページ：TPSP（X）が、期間（Z）の間、リソース（Y）のデータにアクセスすることを許可する
• TPSPへのオーソライゼーション・コールバック：オーソライゼーション手続きを続行するため、TPSPにリダイレクトする
• アクセス・トークン：認可されたアクセス・トークン
• 通知：例えば、リソース（X）のデータをアクセスするためのオーソライゼーションの取消しや、データ（Y）が新たに利用可能となったことを通知する
• 消費実績読込み要求：期間（X）から（Y）まで、あるいは期間（Z）以降のデータの取得
• 消費実績読込み：計測

消費実績読込みデータに関する要件

主要な消費実績読込みの公開に必要な論理的なデータ要素を以下に示す。

データ要素が互いにどのように関連するか理解を助けるために、典型的なメッセージのあるセクションがどのような感じか概観する。これは単にサンプルであり、サービス定義で著しく変わる可能性がある。

OpenADEのテクノロジー・アーキテクチャー

市場および電力会社内には、すでに種々様々な統合技術が存在しているので、OpenADE準拠のシステム構築にあたって、電力会社は、すでに採用している技術インフラや、自社のアーキテクチャー・ゴールに基づいてシステムを構築してもよい。
ただ、どのような技術を採用するにせよ、相互運用性を達成するにあたって以下のアーキテクチャー上の問題を十分理解し、対応することが必要である。

ネットワーキング基準

1. OpenADEサービスは、TCP/IP（インターネット）のネットワークを用いたサービスとすべきである
（[RFC-1122]参照）
2. OpenADEサービスは、主としてHTTPSプロトコルで提供すべきである
（[RFC-1123]を参照）
3. OpenADEサービスには、SFTPを使うことが望ましい

セキュリティ基準

データを含め、保護されたリソースが許可なくアクセスされないよう安全を確保することは、OpenADEにとっての重大使命である。
その責任の所在は、データを収集する電力会社に始まり、顧客が特定の電力会社のデータ使用を認可したTPSPにも広がっている。データが無認可の団体に提供されないことを保証するために、OpenADE設備は、[ASAP-SG-3P]で文書化された制約とコントロールに従うことになっている。『ASAP-SG Third Party Data Access』で指定された用語に従うと、顧客はResource Owner：リソース所有者で、データ・サービス・プロバイダー（＝電力会社）はResource Owner：リソース保管者である。

サービス・リソースパターン

ランタイム環境で「プラグ・アンド・プレイ」レベルを達成するにあって、サービスやリソースの命名規則を定めることは重要である。
名前は、サービスとそのオペレーションの意味を体現するものだからである。
OpenADEサービスの命名規則は、以下のとおりである:

•Information Object：情報オブジェクト

ビジネス・コンテキストにおけるオブジェクトについて記述する実体(クラスと属性)の集合

•サービス名／リソース名

サービス命名規則は、インターフェース定義用のビジネス・プロセス中の情報オブジェクトに従う

•Operation Name：オペレーション名

オペレーション名は、情報オブジェクトに対して行われる特定の操作である。以下に、IEC 61989で規定された動詞のネーミングに準拠した、オペレーションの命名パターンを示す:

１）次の動詞は、その動詞が意味するアクションの要請にこたえるため情報オブジェクトのマスター・システムで提供されるサービス／オペレーションで使用される

・Create
・Change
・Cancel
・Close
・Delete

２）次の動詞は、その動詞が意味するアクションの結果を情報オブジェクトから受け取りたいシステムで提供されるサービス／オペレーションで使用される。このサービス／オペレーションは、マスター・システムあるいは情報オブジェクトを供給する仲介システムから呼び出される

・Created
・Changed
・Closed
・Canceled
・Deleted

３）次の動詞は、情報オブジェクトのマスター・システムで提供されるクエリー・タイプのサービスに使用される

・Get
・Show

４）次の動詞は、OpenADEでは（OpenADE1.0では？）使用されない

・Subscribe
・Unsubscribe

ガバナンス

ガバナンスとは、効率的なオペレーションを維持するために、システム統合やデータ交換での相互運用性の確保を標榜する当事者が、提供する／利用するインターフェースやコンポーネントを変更するための規則を定義したものである。
OpenADEでは、標準規格の一部となるための修正や拡張と同様に、標準インターフェースの追加や拡張のためのガイドラインを含んでいる。

1. 変更を施す際は、既存の実装に影響を与えないよう、互換性を保たなければならない（機能追加の場合は、その限りではない）
2. 機能拡張が必要な場合、そのビジネス要件のみでなく、他にも提言があれば付加することで、定期的な機能アップ時に検討される。

以上、OpenADE1.0 SRSのご紹介でした。

終わり