資料のダウンロードはこちら(ppt形式)
Download
Report
Transcript 資料のダウンロードはこちら(ppt形式)
8.3 Service Composition Models
2004MT067 永東 丈寛
発表内容
8.3.4 Data and Data Transfer Model
8.3.5 Service Selection
8.3.6 Transactions
8.3.7 Exception Handling
データ転送
データ転送―オペレーション間のデータ伝達
データ転送のためのアプローチ
ブラックボードアプローチ
明示的データフローアプローチ
ブラックボードアプローチ(1)
ブラックボード
―アクティビティが出力を預け、入力を集める変数の集合
オペレーション呼び出し時
入力:コンポジションスキーマの一部として定義された
マッピングに従いブラックボードから値を取る
出力:元のブラックボード内の変数にマッピングされる
ブラックボードアプローチ(2)
変数の変形
新しいメッセージの受け取りにより上書き
極小に実行(アトミック性)
アクティビティによってアクセス権が異なる
例:read-write、read-only
明示的データフローアプローチ
明示的データフローアプローチ
―アクティビティ間のデータフロー作成に基づく
アクティビティ間でデータフローのコネクタを使用
前のアクティビティの出力データを入力データとすることを明示化
A
数量
B
数量
値段
C
図8.12. コンポーネント間のデータ転送のデータフローアプローチ
両アプローチの比較
ブラックボードアプローチ
設計が容易
アクティビティ間の依存度が低い
明示的データフローアプローチ
データ転送の柔軟性が高い
設計が複雑
アクティビティ間の依存度が高い
コンポジットサービスの選択(1)
コンポジションロジックの実行
―メッセージの対象となるサービスの情報が必要
コンポジションスキーマの抽象条件で指定
コンポジション言語は実際のポートよりもポートタイ
プを構成する
コンポジットサービスの選択(2)
エンジンがメッセージの送信先を知る必要がある
→ポートタイプが特定のサービスを特定すべき
コンポジットサービスは特定のサービスを
選択(結合)する必要がある
選択(結合)の手法
静的結合
参照による動的結合
検索による動的結合
動的オペレーション選択
静的結合
静的結合
―コンポジットサービスの仕様の一部としてURLをハード
コードする
単純さ故に使い勝手が良い
例:コンポジションのプロトタイプ、テスト
URIの変更に強くない
実際には「選択」がない
参照による動的結合
参照による動的結合
―アクティビティが特定のプロセス変数から呼び出されるため
にサービスのURIを決定する
どのようにURIが変数に行き着くかを仮定する必要がない
→URIの動的選択の実現性
プロセスの意味論としてURIがディクショナリから動的に選
択される必要がある場合
→この目的のためにアクティビティの定義が必要
orderGoods受け取り
UDDI レジストリ
checkLocalStock
呼び出し
inStock = false
get_bindingDetail 呼び出し
checkShipAvailable 呼び出し
inStock = true
shippingAvail = false
shippingAvail = true
cancelOrder送信
confirmOrder送信
図8.13. サービスディレクトリへのアクセスでの参照による
結合サービス選択
検索による動的結合
検索による動的結合
―コンポジションミドルウェアがクエリーの定義があるディレクトリで各ア
クティビティを実行する
例:WSFL
―選択基準の仕様はUDDI APIによるべき
→ほとんどのサービスは基準を満たすと思われるので複数
のURIが返される
→特定のURIを識別するロジックとともに寄与
動的オペレーション選択(1)
CORBAや従来のミドルウェア
―サービスだけでなくサービス上で呼び出されるオペレー
ションの結合の形が動的に決定される
動的オペレーション選択というアプローチ
飛行機予約
船予約
車予約
…
図8.14. 動的結合:選択の数が増えるにつれて
オーケストレーションスキーマは複雑、困難になる
動的オペレーション選択(2)
複雑性の回避
―呼び出されるオペレーションを明示的に特定しない
抽象アクティビティの定義を認める
→オペレーションはサービスとともにランタイムで選択
オペレーションのシグネチャの変化への対応
例:異なるウェアハウスによる異なるオペレーションの提供
→コンポジットサービスによって呼び出されるオペレーション
はどのサービスが選択されるかに依存する
動的オペレーション選択(3)
問題点
どの特定のオペレーションが呼び出されるか分からないため、
強固なアプリケーションの開発が困難
概念的には開発可能だが、実装は難しい
極小領域
コンポジションサービスへのトランザクションの振る
舞いの提供→極小領域の定義をする
極小領域
―オールオアナッシングな特性を示すアクティビティのセット
すべて実行されるか、どれも実行されない特性(アトミック性)
A
B
C
D
図8.15. 極小領域の簡単な例
極小領域
アトミック性の問題
コンポジットサービス実行のための資源の長期ロッ
クは実用的でない
→ACID特性が緩和されたトランザクションの必要性
極小領域で呼び出されるサービスは実際にコミットされる
→アトミック性の保証がされない
他のオペレーションの実行による補償が必要
補償処理
補償処理
―障害が発生した際、極小領域の不完全な実行をロールバック
するためにアクティビティを補償する
補償プロトコルを実行するエンジンと、WS-Transaction仕様
を実装したWebサービスミドルウェアと連携して処理を行う
サブトランザクションS1
補償サブトランザクションCS1
サブトランザクションS2
補償サブトランザクションCS2
…
…
サブトランザクションSn
補償サブトランザクションCSn
事前の実行
補償フロー
図8.16. sagaはACIDサブトランザクションに分けられ、各々は補償サブトランザクションと関連
補償ロジック
補償ロジック
―極小領域が補償される方法を記述したオーケストレーショ
ンスキーマの形式で明示的に定義
ワークフロー研究における補償ロジック
設計、開発の複雑さ
標準や一般に是認された補償プロトコルが存在しない
Webサービス上の補償ロジック
Webサービスにおける補償ロジック
標準のプロトコル言語が存在する
Webサービスインタフェースやトランザクションプロトコル、
そして補償の情報を拡張する手法が提案されている
→Webサービス上に補償を実装する開発者への負担
補償ロジックの問題解決
問題の解決方法
コンポーネントがトランザクションや補償ロジックの定義を
含む場合
例:オペレーションOがオペレーションCによって補償される
→大部分で補償ロジックを実装する必要がなくなる
コンポーネントが標準の補償プロトコルをサポートする場
合
→自動的な補償、サポートが可能となる
例外処理(1)
Webサービスコンポジションのコンテキストにおける例外
―予期される、または望まれる実行からの逸脱
例
システム内や呼び出されるアプリケーション内の障害
顧客が入力前の注文をキャンセルする
Webサービスの意味論で予期されていても不定期な状況
例外処理(2)
例外処理は部分的に完了した作業を引き起こす
→取りうる1つの方法としてトランザクションを利用
例外処理の主な手法
Flow-based アプローチ
Try-catch-throw アプローチ
Rule-based アプローチ
Flow-based アプローチ(1)
Flow-based アプローチ
―各オペレーション呼び出しの終点において結果がエラー
を検証され、エラーが検出したら適切な動作を取る
課題
呼び出されるオペレーションが結果を全く返さない場合
→同様の手法で処理されるがアクティビティと関連する
タイムアウトの定義を要求する
orderGoods受け取り
checkLocalStock
呼び出し
inStock = false
かつエラーが返らない
例外処理ロジックが命じるなら
繰り返し
エラーが返された、または時間切れ
checkShipAvailable
呼び出し
例外処理ロジック
inStock = true
shippingAvail = false
かつエラーが返らない
shippingAvail = true
cancelOrder送信
confirmOrder送信
図8.17. フローの太字部分が例外処理
Flow-based アプローチ(2)
注意点
例外もコンポジションエンジン、Webサービスによって明
示的に投げられる
メッセージが受け取られるときに例示化されるワンウェイ、
またはリクエストリプライ型のオペレーションと関連したアク
ティビティによって例外は捕捉される
Try-catch-throw アプローチ
Try-catch-throw アプローチ
―try,catch,throwの命令を通じたJavaの手法に似ており、アク
ティビティの例外処理ロジックと関連する
処理の流れ
サービスコンポジションデータ上で伝達するブール条件を感知
→検証されているならコードの例外処理部分が実行
→ ・プロセスは次のアクティビティに移行
・失敗したアクティビティの再試行
・プロセスの終了
Try-catch-throw アプローチ(1)
この手法が有効なとき
オーケストレーションモデルがアクティビティのグループを
定義する可能性や各グループのプロパティを結合させる
可能性を含んでいる場合
サブプロセスという手段、または前述のアクティビティ階
層モデルのように分木という手段によってオーケストレー
ションを階層化できる場合
階層例外処理
階層が使用可能なとき、異なる抽象レベルで例外
ハンドラを定義することができる
Javaの例
アクティビティで定義される例外ハンドラの呼び出し
→特定の階層に従って親アクティビティによって処理されるために、例
外を再び投げる選択
→アクティビティ内で例外ハンドラが見つからない場合、見つかるまで階
層を上って適切なハンドラを検索
→見つからない場合、プロセスの終了
Try-catch-throw アプローチ(2)
Try-catch-throw アプローチの利点
常のロジックと例外処理ロジックの区別を明確にできる
コンポジションが分木によって構築されるとき、例外処理
も同様にその要素となりうる
連続なストラテジーの定義を含んでいる
Rule-based アプローチ(1)
Rule-based アプローチ
―イベントがコンポジットサービスのクライアントによって送られたメッ
セージの形、またはタイムアウトの形で獲られる例外イベントを定
義するECAルールによって例外処理ロジックの仕様を定義
規則の定義
―オーケストレーションを定義するために使われる図式的
な注釈に寄与するテキスト言語で定義
Rule-based アプローチ(2)
長所
プロセスの通常の振る舞いと例外の振る舞いを明確に分
けている
短所
システムが更にもう1つ翻訳のための言語を持っており、
開発者は更にもう1つ言語を学ぶ必要がある
規則の数がとても小さいときでしか適用できない