SOA に基づく監視システムのプロトタイピング
アスペクト指向に基づくサービス指向システムアーキテクチャの提案
M2010MM005 長谷川裕記
指導教員：野呂昌満

1

はじめに

2.1

SOA

SOA はシステムを機能単位でモジュール化するアーキ
システムの構成要素や機能の変更に柔軟に対応可能なテクチャ技術である．この機能単位のモジュールをサーアーキテクチャ技術として Service-Oriented Architecture(以下，SOA) がある．SOA システムのアーキテク ビスといい，SOA システムは複数のサービスを連携するチャを設計する際の方法論が提案されている [3]．この方 ことで構成される．連携するサービスを組み替えること法論では，システムに求められる機能特性をサービスと でシステムの機能変更に柔軟に対応可能である．
してモジュール化する方法が提案されている．しかし，非 2.2 アスペクト指向
機能特性のモジュール化については言及されておらず，機アスペクト指向とは横断的関心事をアスペクトとして能特性のモジュール化と同様の方法で行なえるかも明ら分離するモジュール化技術である．分割したモジュールかではない．
Induruwana は，SOA に基づくシステムに対して横断 を結合することをアスペクトを織り込むという．アスペ的関心事の分離にアスペクト指向を用いることを提案し クトを織り込む箇所はポイントカットで指定し，指定さている [1]．この研究では，階層アーキテクチャ上に Ap- れたタイミングになるとアドバイスを実行する．
非機能特性は一般的にシステムを構成する機能特性にplication Service Integration Layer(以下，ASIL) を設けることで二種類の関心事を分離できるとしている．一つ 横断しているので，アスペクトととして分離することがは，仕様の異なるサービスを統合する際の統合ロジック 適当である．非機能特性をアスペクトとして分離すると，の分離である．また，もう一つは，複数のサービスに横 実現したい非機能特性を変更する場合や，非機能特性の断するロギングやセキュリティなどといった関心事の分 実現アルゴリズムを変更する場合は，変更箇所をアスペ離である．ASIL では分離した横断的関心事をどのように クトのみに局所化できる．このようにアスペクトを組み替記述するか定義している．しかし，SOA においてどのよ えることでシステムの構成変更に柔軟に対応可能となる．
うな横断的関心事が存在するか整理されていない．アー 2.3 Application Service Integration Layer
キテクチャはコンポーネントの意味を考慮したシステム
Induruwana は，SOA システムにおける横断的関心事構造を定義する，という立場に立てば，横断的関心事ををアスペクト指向を用いることで分離することを提案し整理分類することが必要となる．ている [1]．この研究では，階層アーキテクチャ上に横断
本研究の目的は，SOA システムのアプリケーションアー的関心事を実現する ASIL を設けている (図 1)．
キテクチャ設計を支援することである．Induruwana のアーキテクチャを参照アーキテクチャと位置づけ，SOAシステムにおける横断的関心事を整理することで，非機能特性を考慮した SOA システムのシステムアーキテクチャを定義する．このシステムアーキテクチャに基づいてアプリケーションアーキテクチャを設計する手順を示す．
一方で我々は，SOA アプリケーションにおいての機能特性は状態遷移機械の集合として実現できることを確認している．これに基づき，非機能特性を付加することを考図 1 ASIL の概要 ([1] より引用)
えた．非機能特性は Georgakopoulos らの研究 [2] を基に分類整理することで，横断的関心事として取り扱いアスペ2.4 SOA システムへの状態遷移機械の適用クトとしてモジュール化することにした．ATM 監視シス
本研究室では，組み込みシステムを設計する際に，システムの設計に今回提案するシステムアーキテクチャを適テムの振る舞いを状態遷移機械の集合として実現してい用することで，システムアーキテクチャの有用性と，システムアーキテクチャを利用することによるアプリケーショ る．SOA システムを設計する際も同様に，システムの振ンアーキテクチャ設計の支援が可能なことを確認した． る舞いを状態遷移機械の集合として実現する方法を適用して，SOA システムを開発することに成功している．シ2 背景技術と先行研究
ステムを構成する Web サービスや Web アプリケーショ
本研究の背景技術である SOA とアスペクト指向につ ンなどのコンポーネントは，すべて状態遷移機械で実現いて以下で説明する．また，Induruwana が提案している されており，状態遷移機械間の通信はすべてイベントとASIL についても概要を説明する．
して表現される．各状態遷移機械はイベントキューを持っており，イベントを受理すると状態遷移を起こし指定のアクションを実行する．システム内のコンポーネントへのアクセスはイベントを用いるのでインタフェースは統一されている．

Integration この非機能特性は，異機種環境のサービスやレガシーシステム，パッケージアプリケーションなどと統合した際にうまく連携できることである．統合の段階は，アプリケーション統合，プロセス統合，情報統
3 非機能特性の整理分類
合，ポータル統合の 4 段階ある．アプリケーションやプロ
Georgakopoulos らの研究 [2] の定義に基づき，SOA シ セスを統合する際は，統合する際のロジックやサービスステムに一般的に求められる非機能特性を整理しアスペ を変形する Service Integration Aspect を抽出する．デークトとして抽出する．Georgakopoulos らの研究は一般的 タフォーマットの統合は Data Integration Aspect がおに認められているので，SOA システムに求められる非機 こない，システム上に配置されたデータへのアクセスは能特性の根拠とする．この研究では，次の 11 つの非機能 Deployent Aspect を介しておこなう．またシステムの構特性が SOA システムに求められていると定義している． 成からユーザインタフェースを分離して User Interface
Aspect を抽出する．
• Service Communication• Dynamic Connectivity• Endpoint Discovery with Quality of Service• Integration• Message Transformation• Reliable Messaging• Topic/Content-Based Routing• Security• Long-Running Process and Transaction• Management and Monitoring• Scalability

Message Transformation この非機能特性は，異なるサービス間のメッセージモデルやデータ方式を変換可能にすることである．提案するシステムアーキテクチャに基づくシステムでは，サービスによってメッセージモデルやデータ方式は変わらない．メッセージの変換が必要となるのは，通信プロトコルを利用する際である．通信プロ
トコルに依存した形式にメッセージを変換する必要があり，この変換処理を Message Transformation Aspect として抽出する．提案するシステムアーキテクチャに基づかないシステムと通信する場合は Data Ingetration Aspectがメッセージの変換をおこなう．

Reliable Messaging この非機能特性は，通知したメッセージが確実に相手に届けられることである．サービスのGeorgakopoulos らが定義する非機能特性を整理する． 要求メッセージを待ち行列を用いることで確実に宛先に通非機能特性ごとにどのような関心事が内在するか考慮し 知することができる．各状態遷移機械は Event Queue を持ち，アクション実行後に Event Queue から次のイベントて，アスペクトを抽出する際に参考にする．
を受理することによって動作する．この処理を Concurrent
Service Communication この非機能特性は，通信プ Aspect として抽出する．
ロトコルを意識せずに通信できることである．また，必要な際に異なる通信プロトコルに応じてサービスを変形 Topic/Content-Based Routing この非機能特性は，できることである．通信プロトコルを意識せずに通信で メッセージの配信先をトピックやメッセージの内容を基きることを Communication Protocol Aspect として抽出 に動的に決定することである．トピックベースの配信は，する．提案するシステムアーキテクチャに基づいたシス 配信希望者が関心のあるトピックを表明することで，メッ
テムでは，Communication Protocol Aspect が通信プロ セージを通知する際に配信希望者のみにメッセージが通トコルへのアクセス方法を統一しているので，通信プロ 知される．コンテンツベースの配信は，トピックを利用せずにメッセージの内容を基にメッセージの通知先を決定
トコルに応じてサービスを変形する必要はない．
する．Routing Aspect の実現の一例として Topic-Based
Dynamic Connectivity この非機能特性は，サービ Routing Aspect と Content-Based Routing Aspect を抽スごとに個別の API やプロキシを使用することなく，動 出する．
的に複数のサービスに接続できることである．提案する
システムアーキテクチャでは，サービスの呼び出しが状 Security この非機能特性は，ユーザ認証やメッセージ態遷移機械間のイベント通知と定義され，サービスのイ の暗号化をすることである．ユーザ認証することを Auンタフェースが統一されるので，サービスごとの個別の thentication Aspect として抽出し，メッセージの暗号化API やプロキシを使用することはない．動的にサービス や復号化を Encrypted Message Aspect として抽出する．
への接続を可能にする．
Long-Running Process and Transaction この非4非機能特性の整理

Endpoint Discovery with Quality of Service こ 機能特性は，同時に発生したトランザクションの副作用の非機能特性は，実行時にサービスを検索して最適のエン を分離したり，プロセス障害からの復旧をサポートしたドポイントを選択することである．サービスの情報を保持 りすることである．
し実行時の検索を可能にする Service Registry Aspect と， Management and Monitoring この非機能特性は，複数の候補から最適のエンドポイントを選択する Routing 管理機能としては動的な負荷の分散やシステムダウン時Aspect を抽出する．のフェイルオーバー，クライアントとサービスインスタンス間の位相的，地理的な親和性を実現すること，また 求められる機能特性の振る舞いを状態遷移機械の集合とし監視機能としてはサービス活動の追跡やサービス運用時 てモデル化する．各アスペクトを織り込んだシステムアーの統計データを集計して提供することが挙げられる．付 キテクチャは図 2 のようになる．状態遷移機械は Push 型
加分散を実現するメッセージの配信を Load Distribution で通信をおこなうので，システムアーキテクチャの図はRouting Aspect として抽出し，インスタンスの位相的， ある状態遷移機械が他の状態遷移機械にイベントを通知
地理的な親和性の実現に Deployment Aspect を抽出する． する場合に前節で分類したアスペクトがどのように織りまた，サービス活動の追跡は Logging Aspect として抽出 込まれるかを示している．また，Error Handling Aspectと Logging Asepct は自身以外のすべてのコンポーネントする．
に対して織り込まれるので記述していない．
Scalability この非機能特性は，システムを拡張した際にも正常に動作することである．状態遷移機械をステー 5.2 コンポーネントの意味付け
トレス化することにより，システムの拡張に柔軟に対応
5.1 節で定義したシステムアーキテクチャの各アスペク可能になるので，Stateless Aspect を抽出する．
トの構造を定義する．主なアスペクトの責務や構成する

4.1

非機能特性の分類整理した非機能特性とアスペクトの関連を表 1 にまとめる．
表 1 非機能特性とアスペクトの関連コンポーネント，ポイントカットを説明する．

Communication Protocol Aspect は，状態遷移機
械間の通信に用いるプロトコルと，その通信プロトコルに依存するメッセージ形式への変換を行なう．このアスペクトの構成は図 3 のようになる．状態遷移機械が通信プロトコルを意識せずにメッセージを送信することができるようにインタフェースを統一する．ポイントカット
はメッセージ送信である．

図 3 Communication Protocol Aspect の構造

5システムアーキテクチャ

システムアーキテクチャを状態遷移機械の集合に非機能特性をアスペクトとして織り込むことで定義する．

5.1

システムアーキテクチャの設計

Service Registry Aspect Service Registry Aspect
は，サービスの名前とサービスのインスタンスの関連を保持する Service Registry を管理する．このアスペクトの構成は図??のようになる．Service Registry はサービス名を基にサービスのインスタンスを返す．よってサービスを利用者はサービス名を知っているだけで，サービスのインスタンスを特定できるようになる．ポイントカッ
トはインスタンスの特定である．

4.1 節で整理した非機能特性を実現するアスペクトを基にシステムアーキテクチャを定義する．SOA システムに

図 4 ServiceRegistry Aspect の構造

図 2 システムアーキテクチャ

Routing Aspect
Dynamic Routing Aspect は，メッセージの通知先を動的に決定する．このアスペクトの構成は図 5 のようになる．
状態遷移機械がイベントを通知する際に，Service Request
Broker がサービスの情報を基に通知するサービスを特定する．この通知先特定のアルゴリズムは切り替え可能になっており，トピックベースやコンテンツベースの通知先決定アルゴリズムを選択できる．ポイントカットはメッセージ通知先の決定である．

ができ，コードの自動生成はコード記述の労力が削減できる．よってシステム開発自体の支援にもなると考える．

図 5 Routing Aspect の構造

図 7 状態遷移機械適用の概要

Service Integration Aspect は，仕様の異なるサー6.3 アプリケーションアーキテクチャの設計支援の妥
ビスへのメッセージ通信を仲介する．Service Integration
当性
Adapter は異なるサービスへのメッセージ通信を仲介し，今回提案するシステムアーキテクチャを基に ATM 監視
必要に応じてメッセージ形式の変換をおこなう．ポイン
システムのアプリケーションアーキテクチャを設計した．
トカットは他のサービスへのメッセージ送信である．
アプリケーションアーキテクチャを設計する際は，保証6 考察
すべき非機能特性のアスペクトを選択，アドバイスのア
6.1 システムアーキテクチャの有用性
ルゴリズムの選択，状態遷移機械の設計などをおこなう
システムアーキテクチャはシステムに求められる非機 のみでよい (図 8)．非機能特性について整理されている
能特性によってアスペクトを組み替えることで，様々な ので，アプリケーションアーキテクチャ設計の支援がなシステムに対応可能である．また，アスペクトのアドバ されていると考える．
イスのアルゴリズムを変更することで，アルゴリズムの変更にも柔軟に対応可能である．よって，システムアーキテクチャは有用であると言える．
例えば Routing Aspect ではメッセージの通知先決定ア
ルゴリズムをトピックベースやコンテンツベース，負荷分散を考慮したルーティングに切り替えることができる(図 6)．他にも Security Aspect の暗号化アルゴリズムや，Logging Aspect のログをとる箇所なども切り替えることが可能である．

図 6 アルゴリズムの切り替えの例

6.2

状態遷移機械適用の有用性

システムアーキテクチャは機能特性を状態遷移機械の集合として定義している．アプリケーションアーキテク
チャの機能特性を設計する際は，機能特性の実現に必要な状態遷移機械を設計するだけでよいので，アーキテクチャ設計が容易になると考える．
機能特性を状態遷移機械の集合としてモデル化できているので，モデル検査やコードの自動生成といった既存の技術を適用することが可能となる (図 7)．モデル検査は状態遷移機械のモデル上での誤りの検出を行なうこと

図 8 アプリケーションアーキテクチャ設計の概要

7

おわりに

本研究では SOA システムのアプリケーションアーキテクチャの設計を支援することを目的として，アスペクト指向に基づくシステムアーキテクチャを定義した．このシステムアーキテクチャでは，SOA システムにおける横断的関心事を整理することで，非機能特性をアスペクトとして抽出している．提案するシステムアーキテクチャ
はアスペクトを組み替えることで異なる非機能特性が求められる SOA システムに適用可能であると考えられる．

参考文献[1] C. D. Induruwana, Using an Aspect Oriented Layer
in SOA for Enterprise Application Integration,” ICSOC, pp. 19-24, 2005.
[2] D. Georgakopoulos, and M. P. Papazoglou, ServiceOriented Computing, The MIT Press, 2009.
[3] M. P. Papazoglou, and W. Heuvel, Service-Oriented
Design and Development Methodlogy,” IJWET, no.
4, pp. 1-17, 2006.