SLA に基づくサービス選択の自動化に関する研究
2011SE121 川畑賢史 2011SE233 佐藤裕太

2011SE253 高野寛士

指導教員：沢田篤史

1

はじめにステムの開発では，主に Web サービスが用いられる．既存の Web サービスを効果的に再利用するためには，開発ビジネス環境の変化に迅速かつ柔軟に対応するシステム

者はシステム利用者の要求に満たした Web サービスを検を構築する基盤として，サービス指向アーキテクチャ (以索する必要がある．Web サービスを検索する技術として下，SOA)[8] が注目されている．SOA におけるサービス

UDDI が用いられている．とは，インターネット上でプラットフォームによらず，企業間で相互運用を可能とするものである．SOA に基づく

2.1

UDDI

システム (以下，SOA システム) の開発は，異なるサービ

UDDI は，Web サービスの情報を登録，検索できるレジスを連携させてシステムを実現する．連携させるサービス

ストリである．本研究では，非機能要求を考慮したサービの一種として Web サービスがある．SOA をはじめ Webスの選択を実現するために，サービスの情報を保持し，情情報システムの利用が一般化するにつれ，Web サービスの報を基に検索できるレジストリとして UDDI に着目した．

数は増加し，同様の機能を提供する Web サービスが多く存在するようになる．既存の Web サービスを効果的に再2.2

SLA利用してシステムを構築するために，システムの目的に適SLA は，利用者とサービス提供者の間で取り決められる合する Web サービスを検索するサービスが必要になる．

合意書である．サービスの内容，品質に対する要求水準をUniversal Description, Discovery and Integration(以下，UDDI)[7] をはじめ既存の Web サービス検索では，非規定し，サービスに対しての運営ルールを明文化したもの

機能特性など詳細な条件を指定した検索は困難である．開る文書として着目した．

発者はサービスのメタデータを基にサービス検索を行な2.3である．本研究では，サービスに対する要求を明示していい，結果として得られたサービス群から，それぞれの品質を手がかりに適切なサービスを選択する必要がある．
本研究の目的は，非機能要求を考慮したサービス選択の自動化である．システムの非機能要求を満たしたサービス選択の基準と，選択基準を利用したサービスの検索の仕組みを提案する．非機能要求を考慮したサービスの検索を実現することで，システム利用者のシステムに対する要求を満たしたサービスを自動的に選択し，システムを実現する

Resource Description Framework

Resource Description Framework(以下，RDF)[9] は，インターネット上のリソースに関する情報を表現するための言語である．RDF は XML で記述する．リソースの持つ非機能特性を記述することが可能である．本研究では，非機能特性を XML で記述するフォーマットとして着目した．

2.4

ことができる．

非機能要求グレード

非機能要求グレード [11] は，開発対象のシステムの非機本研究で我々は，非機能要求を考慮したサービス検索を能要求を段階的に詳細化するための手法である．非機能要実現するために，サービスの内容を表記した Service Level

求グレードを用いることで，利用者と開発者の非機能要求Agreement(以下，SLA)[10] の項目を UDDI の記述方法に従って記述できるようにする．SLA はシステム利用者とサービス提供者の間で取り決められる合意書である．SLAの認識の違いを防ぐことが可能になる．本研究では，非機能特性の定量的な評価のために非機能要求グレードに着目した．

を用いることで，サービス選択のために新たな文書を記述する必要がない．サービス検索を行なう際，SLA に関連す3る記述項目を参照することにより，システム利用者の非機能要求を考慮したサービスの検索が実現できる．結果とし非機能要求を考慮したサービス選択の基準と仕組みて，利用者の非機能要求を満たしたサービス選択が可能に

本研究では SLA の記述項目を基にサービスの情報をUDDI に登録する仕組みを提案する．登録された SLA のなる．簡単な例題を用いて，本研究で提案したサービス検記述項目を参照しながらサービス検索するためのアルゴリ索の仕組みの有用性と本研究のアプローチの妥当性についズムを提案し，非機能要求を考慮したサービス選択の仕組て考察した．

みを提案する．

2

背景技術
SOA システムの開発では，開発者は異なるサービスを連携させてシステムを実現する．連携させるサービスとして，Web サービスやピアサービスが存在する．SOA シ

3.1

SLA の記述項目

SLA は一般的に自然言語で記述される．UDDI に SLAの記述項目を統合するためには，SLA を機械処理可能な言語で記述する必要がある．Web サービス用の SLA を定義した Web Service Level Agreement(以下，WSLA)[5]が存在する．WSLA は XML で記述する．UDDI は Web

3.3

UDDI への SLA 記述項目の統合

サービスの情報を登録，検索サービスであり，XML ベー開発者は UDDI の API を利用することで，複数の情スの記述との親和性が高い．以上の理由により，本研究で報を基にサービス検索ができる．ホワイトページ (busi-nessEntity) は，サービス提供者に関する情報を基に検索実現を確認する．WSLA のクラス図 [5] を基に，記述項目 する．イエローページ (businessService) は，サービスのの整理を行なった． 図 1 は，WSLA のクラス図である． 分類情報を基に検索する．グリーンページ (bindingTemplate) は，サービスの技術情報を基に検索する．UDDI の仕組みに従い WSLA の記述項目を統合した．本研究では，サービスを WSLA の情報を基に分類した．非機能特性などの詳細な条件を指定した検索を行なうために WSLA の記述項目を統合するので，categoryBag を用いる．3.1，3.2
節より，Parties は businessEntity，ServiceDefinition はbusinessService，Obligations は bindingTemplate の categoryBag に保持させた．WSLA の記述項目を UDDI に
図 1 WSLA のクラス図
統合したクラス図の一部を，図 3 に示す．
は WSLA を用いて非機能要求を考慮したサービス選択のWSLA は Parties，ServiceDefinition，Obligations の３つの主要な要素から構成される．Parties はサービスを管理する会社に関する情報を記述する．ServiceDefinition はサービスに関する情報を記述する．Obligations はサービスの動作や水準に関連する情報を記述する．
非機能特性は SLAParameter で記述する．SLAParameter の Name に非機能特性の名前，Value に値を記述する．
表１は，SLAParameter を用いて非機能特性の名前と評価値を記述した例であり，応答時間の値は 0.5，稼働率の値
図 3 UDDI に WSLA の記述項目を統合したクラス図のは 99.9 であることを示している．

一部

表 1 SLAParameter の記述例
SLAParameter
Name 応答時間 稼働率
Value 0.5
99.9

categoryBag に保持させた WSLA の記述項目を参照することにより，非機能特性の名前と評価値を基にサービス検索が可能になる．表２は，WSLA の記述項目をcategoryBag に保持させた際の対応表の一部である．
3.2

UDDI のデータ構造

UDDI のデータ構造について，[7] に基づいて作成したク 表 2 SLA の記述項目を categoryBag で保持させた際の対ラス図の一部を図２に示す．企業情報は businessEntity， 応表の一部
SLA の記述項目
UDDI のデータ構造
サービスの分類情報は businessService，サービスの技術
ServiceDefinision categoryBag
的情報は bindingTemplate に情報を格納する．UDDI にServiceObject
keyedReferenceGroupは分類情報を追加するために categoryBag，識別情報を追SLAParameter
keyedReference
NameName
加するために identifierBag が存在する．keyedReference
Value
Valueの名前にカテゴリ名，識別名を記述し，keyedReference を基に情報を検索することが可能である．keyedReference
categoryBag は keyedReference から構成されているのは文字列型の Name，Value，tModelkey を保持し，keye- で，非機能特性の名前と評価値は文字列型で定義される．
dReference を基に WSLA の記述項目を記述する．
文字列型は大小比較が出来ないので，評価値を数値型に型変換する必要がある．

3.4

非機能特性の評価尺度の定義

非機能特性を基にサービス検索を行なうには，非機能特性の評価値を比較する必要がある．非機能特性の中には，数値化が困難な非機能特性も存在する．本研究では，数値
図 2 UDDI のクラス図の一部化が困難な非機能特性を比較するために，非機能要求グレードの項目一覧表を参考にする．数値化が困難な非機能特性の例として，セキュリティの記述例の一部を表 3 にサービスの検索が可能であるかを確認する．この仕組みで示す．非機能特性の評価値を重み付けすることで，数値化システム利用者の要求を満たしたサービス検索が実現できが困難な非機能特性も数値化が可能になり，比較が可能とるか確認する．

なる．
表 3 セキュリティの記述例

4.1

WSLA を基に非機能要求を考慮したサービスの登録とサービス選択の仕組みの妥当性

セキュリティ
項目

レベル 0

レベル１

レベル 2

レベル 3

認証機能

実施しない

一回

複数回

複数回, 方法別利用制限

実施しない

一回複数回

複数回別, 方法別

WSLA ファイルを基にサービスを登録するために，3つの WSLA ファイルを用意した．WSLA ファイル 1 は，サービス名を online shop，稼働率の value が 5 とする．

3.5

サービス検索のためのアルゴリズムの提案

いればサービスの情報を保持し，次のサービスを比較，6)

WSLA ファイル 2 は，サービス名を online shop，稼働率の value が 3 とする．WSLA ファイル 3 は，サービス名を online shop，応答時間の value が 5 とする．WSLA
ファイルを指定のディレクトリに配置し，UDDI のサー
ビス登録の入力を WSLA にして，サービス登録を行なった．サービスを発見するための WSLA ファイルを用意した．WSLA ファイルは，Service Definition の Name を
online shop，SLAParameter の Name を稼働率，Value を4，Compare を >=とする．WSLA を指定のディレクトリに配置し，WSLA をサービス検索の入力としてサービス検索を行なった．結果，WSLA ファイル 1 で登録したサービスの情報が表示された．WSLA を作成し，指定のディレクトリに配置することで，UDDI にサービス情報の登録，検索が実現できた．WSLA を基にサービスの情報の要求を満たしたサービスが登録されていなければメッセー登録が可能になることで，サービスの情報に非機能特性のジを表示し，登録されていれば，要求を満たしたサービス名前とその評価値を付加することが実現できた．サービス群の情報を表示し，プロセスを終了．3) から 5) の処理をを検索する際に既存の UDDI の検索方法に加えて WSLA

WSLA に記述されている非機能要求全て参照するまで繰の記述項目を参照することで，非機能要求を考慮したサーり返す．提案するアルゴリズムによって複数の非機能要求ビス検索が実現できた．結果，稼働率など非機能特性を含を考慮したサービス検索が可能になる．非機能特性の評価めた条件を指定することが可能となった．各サービス毎に値を大小比較するために，SLAParameter に Compare を

WSLA を記述することで，非機能要求を考慮したサービ追加した．Compare に比較演算子を入力することで，非スの検索が実現できた．

WSLA の記述項目を基にサービスの情報を検索するために，既存の API に機能の追加を行ない，サービスの情報を検索するためのアルゴリズムを提案する．図 4 は，アルゴリズムをフローチャートで記述した一部である．1) 指定したディレクトリに WSLA ファイルが配置されているか確認し，WSLA ファイルが配置されていなければ検索のプロセスを中止し，メッセージを表示，2) WSLA ファイ
ルを読み込む，3) UDDI に登録されているサービスの中から，WSLA に記述されたサービス名を基にサービスを検索，4) サービス名が同じサービスに WSLA に記述された非機能特性の名前が登録されているか検索，5) 非機能特性の評価値が要求を満たしているか比較し，要求を満たして機能特性ごとに大小比較が可能になる．

4.2

関連研究との比較関連研究と比較して，本研究で提案する仕組みの特徴を考察した．関連研究として Quality of Service(以下，QoS)に関する研究を取り上げた．QoS は Web サービスの品質を表す．本研究では，QoS を記述するために WSLA を用いたので，関連研究の QoS と WSLA は同義である．

4.2.1

UDDI の追記に関する研究

品質を基にサービスを選択する研究として Garcia らの研究 [1] がある．Garcia らの研究では，UDDI に登録されている Web サービスの品質を明示し，品質からサービスの検索をするために QoS を UDDI に記述する．Garciaらの研究は，記述できる非機能特性を定め，非機能特性の図 4 アルゴリズムのフローチャートの一部

4考察
JUDDI[4] を基に構築した UDDI を用いて，WSLA ファ

イルに記載されたサービスの情報を登録可能であるかを確集合を categoryBag で定義する．本研究では，非機能特性の記述方法を WSLA に準拠し，UDDI のサービスの検索機能の入力を WSLA にした．Garcia らの研究は，予めcategoryBag で定義した非機能特性しか記述できない．本
研究では，WSLA の記述項目に従っているので，WSLA認する．WSLA で記述したサービスの非機能要求を基に， に記述された内容であればサービスの検索が可能で，要求が複雑化した場合でも容易に変更できる．

4.2.2

最適なサービスの選択に関する研究同様の機能を提供する Web サービスの中から最適なWeb サービスの発見に関する研究として Alrifai らの研究
[3] がある．Alrifai らの研究は，サービスの中から利用者の非機能要求を満たすサービスを発見するという点で本研

UDDI への参照を記述することが可能である．本研究では，WSLA を用いて非機能要求を考慮したサービスの検索を行なうので，UDDI を用いて Web サービスの情報を集中的に管理することにより，代替手段より発見が容易である．

5

おわりに究と目的は同じである．Alrifai らの研究は，QoS の値を算

本研究では非機能要求を考慮したサービス選択の自動化出することで，スカイラインサービスを識別する．スカイを目的とし，SLA に基づくサービス検索を行なう仕組み

ラインサービスとは，非機能特性の項目の中で一つだけ突を提案した．WSLA に記述されているサービスの情報を出したサービスである．スカイラインサービスを識別し， UDDI に追加することで，利用者の非機能要求を考慮したサービス全体の要求を満たすようにスカイラインサービス サービス検索を実現した．今後の課題として，サービス全を組み合わせ，最適なサービスを提供する．本研究では， 体の要求を記述した SLA を基にしたサービス検索が挙げ
SLA の情報を UDDI に登録することで，サービスを検索 られる．サービス全体の要求を SLA で記述できれば，よするたびに非機能特性の評価値を計算する必要がない．本り詳細なサービスの検索が可能になり，サービス選択の自研究では，非機能特性を重み付けすることにより，数値化動化が可能になる．

が困難な非機能特性も同様にサービス検索の条件として扱参考文献うことができる．

4.2.3

RDF を用いて QoS の項目の記述に関する研究

非機能特性を機械処理可能な言語で記述する Yessad らの研究 [2] では，ウェブオントロジー言語を用いて QoS の項目を記述している．本研究では，SLA を用いて利用者のサービスに対する要求を記述し，UDDI にサービスの情報の登録，検索を行なう．SLA を用いることで，サービスを選択するための文書を新たに記述する必要がない．

4.3
4.3.1

代替手段との比較

SLA 専用のレジストリ

本研究では，UDDI に SLA の記述項目を統合することで，非機能要求を考慮したサービスの選択の支援を行なった．代替手段として SLA の情報を保持するレジストリを作成し，作成したレジストリと UDDI を連携することで本研究と同様の結果が期待できる．SLA 専用のレジストリを用いたサービス選択では，UDDI と連携して SLA の情報を基にサービスを特定する．UDDI と連携するために，SLA の内容に加えて相互を関連づけるための情報が必要になる．関連づけるための情報を管理することで，SLA の情報のみを変更する場合，変更が容易である．SLA 専用のレジストリを用いたサービス選択では，新しい分類情報を追加する際に，SLA 専用のレジストリと UDDI の間で整合性が保てるように管理する必要がある．本研究では，サービスに関する情報が UDDI に集約するので，サービスに関する情報の管理，発見が SLA 専用のレジストリを用いたサービス選択より容易である．

4.3.2

WSIL を用いたサービス選択

サービスを発見する代替手段として，Web Services In-

spection Language[6](以下，WSIL) がある．WSIL を用いて，非機能要求を満たすサービスを選択することで本研究と同様の結果が期待できる．WSIL は，サービスや[1] D. Garcia, and M. Toledo, ”A Web Service
Architecture Providing QoS Management,” WebCongress, pp. 189-198, 2006.
[2] L. Yessad, and Z. Boufaida, ”A QoS Ontologybased Component Selection,” IJSC, vol. 2, no. 3,
pp. 16-30, 2011.
[3] M. Alrifai, D. Skoutas, and T. Risse, ”Selecting Skyline Services for QoS-based Web Service
Composition,” Proceedings of the 19th international
conference on World wide web, pp. 11-20, 2010.
[4] Apache, JUDDI, https://juddi.apache.org/index.html, 2014.
[5] IBM, Web Service Level Agreement (WSLA)
Language Specification, http://www.
research.ibm.com/people/a/akeller/Data/
WSLASpecV1-20030128.pdf, 2003.
[6] IBM, An overview of the Web Services Inspection
Language,
http://www.ibm.com/
developerworks/webservices/library/ws-wsilover/, 2002.
[7] OASIS, UDDI Spec Technical Committee
Draft,
http://www.uddi.org/pubs/uddi-v3.
0.2-20041019.htm, 2004.
[8] W3C, Web Services Adressing Working Group,
Web Service Architecture, http://www.w3.org/TR/ws-arch/, 2004.
[9] W3C, RDF, http://www.w3.org/RDF/, 2004.
[10] 古川博康，SLA の作成法〜サービス・レベル・アグ
リーメント〜，ソフト・リサーチ・センター，2008.
[11] IPA, 非機能要求グレード利用ガイド， http://www.
ipa.go.jp/files/000026853.pdf，2010.