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つ言語を学ぶ必要がある
規則の数がとても小さいときでしか適用できない